Coding-Agent Management Layer
Agent Studio is a remote-first management layer that orchestrates Codex, Claude Code and Gemini through the subscriptions, configured CLIs and Agent Runners a developer or team already uses. A central Task Server gives that agent capacity a task board, a contract, usage visibility, token reporting, model choice and a review path.
The core workflow is concrete: create a bounded task on the Task Server, choose an agent mode, run it through an Agent Runner on your workstation or a remote host, optionally admit safe parallel work through isolated worktree slots, collect evidence, review the result and decide what happens next.
Claude Code A coding-agent CLI that remains the execution engine for its assigned task.
Codex A coding-agent CLI that Agent Studio can run in an isolated task worktree.
Gemini A coding-agent CLI that returns its work to the same task and review surface.
Codex can use OpenRouter or other OpenAI-compatible endpoints, so the same task workflow can try other models.
Tasks as Work Units
A task is a small, closed, reviewable unit of work. It can be implemented by a coding agent, inspected by a human and followed up when the outcome is not good enough. It is also where GitHub/Git state, screenshot evidence, auto-review, code review and security review become concrete.
The board turns agent work into a reviewable flow: Backlog, Active, and Done & Decide with run and review state on every card.
- Task boards and lanes keep work visible across ready, running, auto-review and human-review states.
- Agent assignment is explicit, so Codex, Claude, Gemini or another runner can be compared by outcome.
- Tasks carry enough context and evidence to be executed without losing the product’s shape.
Git-backed Task Slices
A task is not just a prompt. It is the bounded implementation slice where agent execution, GitHub/Git integration, screenshot evidence, automatic code review, security checks and human acceptance meet.
Review verdict beside the task commit ledger and changed files.
GitHub and Git
Branch, changed files, commits and repository state stay close to the task.
Visual evidence
Screenshots and tutorials show what changed and help reviewers catch UI drift.
Review pipelines
Automatic review, code review and security checks produce follow-up work when needed.
- The task has a clear scope and can be finished, reviewed, reissued, split or admitted into a bounded parallel slot.
- GitHub/Git evidence and changed files are part of the work surface.
- Visual screenshots, tutorials and test evidence make the result inspectable.
- Auto-review, code review and security checks become visible checkpoints before acceptance.
- Every coding run is worktree-isolated — including single-slot resume and reissue — with a guard that keeps the main checkout untouched.
Accepted Work or Follow-up
The review loop is the heart of the product. Agent output does not vanish into a terminal transcript. It becomes accepted software, a rejected attempt or a precise follow-up task.
The end of the loop on one task: review verdict and open findings, browser proof and code-review findings on the left, and three named options with their consequences on the right.
Run
A bounded task is executed by the chosen agent and mode.
Evidence
The product gathers enough proof to inspect the result.
Decision
Accept, reissue, split or turn the result into follow-up work.
- Auto-review checks the work against selected aspects before the human review.
- Evidence can include tests, diffs, screenshots, tutorials and linked documents.
- Human review remains the final control point for product taste and architecture.
Orchestrate Existing Coding Agents
Codex, Claude Code and Gemini are supported as execution backends. The product-level idea is Code Maxing: maximize useful software output from the coding-agent subscriptions you already pay for, with enough orchestration, usage visibility and review to make the work productive.
Managed agent capacity: the CLIs, models, and usage caps for Claude Code, Codex, and Gemini in one settings surface.
- Codex, Claude Code and Gemini are the current supported agent families.
- Subscription usage, tokens and outcomes are visible where work is prepared and reviewed.
- Different agents can be routed to different task types and compared by accepted work.
Subscriptions or OpenAI-compatible Models
Agent Studio can stay in subscription mode when Codex, Claude Code or Gemini are the right execution layer. It can also follow the configured CLI out to an OpenAI-compatible provider, for example OpenRouter, when a task should use API-paid model access instead of a subscription bucket.
Subscription mode
Use the coding-agent account the developer already pays for and watch quota, tokens and accepted output.
Provider mode
Route a configured CLI through OpenRouter, Azure/OpenAI-compatible gateways or local OpenAI-compatible endpoints.
Model registry
Expose selectable model IDs as task settings instead of hiding model choice in a terminal config file.
- Codex can be configured with a custom model provider and an OpenRouter base URL, then started with a chosen OpenRouter model slug.
- OpenRouter exposes hundreds of models through one API and publishes a model list with capabilities such as tool calling, context length and pricing.
- Useful coding-model families to make visible include OpenAI GPT and gpt-oss, Anthropic Claude, Google Gemini and Gemma, DeepSeek, Qwen, xAI Grok, Mistral and Devstral, Meta Llama, Moonshot Kimi, Cohere Command, Amazon Nova and Z.AI GLM.
- The product-level rule stays the same: the selected agent, model, usage and outcome belong to the task so subscriptions and API spend can be compared by accepted work.
Agent Modes
The product is not loyal to one model vendor. It treats coding CLIs, subscriptions and agent modes as swappable execution layers, then judges them by the work they return.
Token and cost reporting: seven days of workspace token usage broken down by project, agent mode, and theoretical cost.
- Implementation, review, documentation, large-context reading and migration work can use different modes.
- Token and usage reporting make subscription steering less anecdotal over time.
- The management layer stays above the agents and keeps the project’s operating model consistent.
Local Mode: The Simplest Start
Remote-first does not mean remote-only. The simplest way to start is one developer, one machine and one local Task Server: the backend watches projects, starts configured coding-agent CLIs and serves the Agent Studio web app to the browser on the same machine. This is the entry path, not the product boundary.
The whole surface in one browser window: the watched workspace and its projects on the left, the task board with its backlog, active and decide lanes beside it.
One seat
A single developer controls the board, the browser and the agent accounts.
Local API
The server is local, but task communication already goes through typed HTTP endpoints.
Known credentials
The product starts CLIs that are already authenticated in the chosen environment.
- The watched repositories, task folders, CLI sessions and credentials stay on the developer machine.
- The HTTP API is still the task communication layer: create, move, continue, review and inspect tasks through the server instead of editing task folders by hand.
- This mode is the best default for personal Code Maxing because the feedback loop is fast and the security boundary is easy to understand.
- Direct CLI work can still happen beside the product, but durable task state should come back through the HTTP API.
Central Task Server Mode
Agent Studio can run as a central Task Server. Instead of every developer keeping private agent jobs in local terminals, all jobs are created on one reachable server, where the board, task state, repositories, agent execution and review evidence stay under one operating boundary.
Workspace Projects
Shared work surface
People connect to one board instead of exchanging terminal transcripts.
All jobs on the server
Task creation, movement, review and follow-up are API calls against one authority.
One execution boundary
The server machine owns repository access and the configured coding-agent CLIs.
- The browser UI and API can be reached by other users or tools when the Task Server is deliberately exposed inside a trusted network.
- Every job starts as a task on that server, so backlog, active work, auto review, human review and follow-up work share one source of truth.
- Multiple users can create tasks, review evidence and coordinate outcomes against the same board, while each project still runs through a controlled task pipeline.
- The Task Server is the coordination point: clients talk HTTP, the server owns task state, CLI execution and review evidence.
- This is different from a hosted SaaS promise. Deployment, authentication, network exposure and repository access must be designed deliberately.
Remote Execution on Your Own Linux Host
Agent execution does not have to run on your workstation. The full pipeline — coding-agent CLIs, per-task git worktrees, Playwright verification and the quota probes — has been proven end to end on a plain Linux host: you keep the browser, the server does the heavy lifting.
Proven end to end
CLI spawn, worktree flow, artifacts and quota probes verified on a remote Linux box.
Your hardware, your rules
A rented dedicated server or any Linux machine you control — no hosted SaaS dependency.
Per-project assignment
Projects get pinned to a dedicated host; heavy runs stop competing with your IDE.
- The path there is CLI-based and documented: provision the host over SSH, seed the already-authenticated CLI credentials, connect — no browser and no interactive login on the server.
- A strong model helps you get there: the same coding agents the product runs can execute the provisioning steps for you, command by command.
- The security model is deliberate: the host holds no Git-hosting credentials, nothing listens publicly, and an SSH tunnel is the only door until you decide otherwise.
- Honest constraint: tested end to end on Ubuntu 24.04. Other distributions and OSes are expected to work but are not yet verified.
- Roadmap: remote hosts become first-class product objects — a host registry with per-CLI quota, per-project execution assignment and a guided onboarding wizard.
Multi-user Work on One Task Server
Multi-user work is the natural extension of the Task Server model: several people or automation clients connect to the same server, create jobs there and review the same task ledger instead of spreading agent work across private machines and chat transcripts.
Workspace Projects
Possible today
The Task Server already provides the shared task surface that multiple clients can use.
Central job ledger
All users create and inspect jobs through the same board and API instead of separate local notes.
Experimental
Most real usage so far has been solo, so multi-user rollout should start small and visible.
Worth exploring
Team usage can become a strong product direction when real projects test the boundaries.
- Several people can connect to the same Task Server and work against the same task surface when it is exposed inside a trusted environment.
- Jobs are not hidden in separate terminals. They are created on the central board, move through shared states and carry evidence into review.
- The shared board makes task creation, execution status, evidence, review and follow-up visible to everyone who should see the work.
- This is not yet a heavily battle-tested team workflow. Authentication, repository access, execution ownership and review responsibility need careful setup.
- If you want to move Agent Studio into a real team setup, get in contact. This is exactly the kind of use case that should shape the next iteration.
Multi-project Work
Serious agent work spans product repos, stable reference checkouts, website projects and marketing or pattern repos. The workbench coordinates those task boards while preserving project boundaries.
Workspace Projects
- Each project keeps its own task board, settings and review state.
- Workspace views help compare activity, software quality, drift and token spend across projects.
- Guard rules keep cross-project power from turning into cross-repo confusion.
Job History Ledger
Every accepted, rejected, reissued or clarified task adds to a product memory. Agent Studio should make that history queryable through the board and API so future work can answer why a decision was made before starting from scratch.
Activity across projects: a queryable ledger of signals, decisions, and actions with per-project and event-class filters.
Search before reasoning
Use API and file search to find prior decisions before asking a large model.
Explain old work
Answer why a feature, workaround or review decision exists.
Feed future tasks
Turn historic findings into better context and scoped follow-up work.
- Job history includes task prompts, lane state, agent choice, logs, evidence, review notes, branches and follow-up decisions.
- A developer or CLI can ask what happened during an earlier task and inspect the relevant files before spending model tokens.
- Small-model summaries can aggregate historical tasks into compact context for planning, debugging or review.
- The ledger is valuable because the result is reviewable: it explains what was tried, what was accepted and what needs another task.
Visual Documentation Library
Every relevant feature should have a documented screenshot in a Markdown docs structure. The image is not just decoration: it shows a meaningful state, explains the feature in simple language and records how the screenshot can be recreated.
A real, documentable task state: the protocol summary of one run.
Simple purpose
Every page says what the feature is for without internal jargon.
Repeatable capture
Playwright and the data state explain how to recreate the screenshot.
Future automation
A button or CI job can refresh the visual library when the product changes.
- Each feature page should include the screenshot, feature purpose, relevant UI state, route, seed data, viewport and Playwright command.
- Screenshots should live beside Markdown docs, for example under a product docs or visual-docs folder, so the documentation can be rendered by GitHub Pages or another static site.
- When the product changes, the screenshot recipe gives maintainers and agents a repeatable way to refresh the visual documentation.
- The long-term goal is one-button regeneration: seed data, open route, capture state, update Markdown evidence.
Orchestrator and Task Chat
Chat lives where the work is: a project-scoped orchestrator conversation and a per-task chat reference real project state — tasks, context, token spend, drift, review states and prepared actions.
Orchestrator and Task Chat
- Task chat and orchestrator chat share one composer: pick CLI, model and thinking level per message.
- A live context-window ring shows how much of the agent context is used, fed from the CLI itself.
- Operator model switches are recorded in the task history, and answers link back to tasks, evidence and review decisions.
Quality Signals
Drift control is visible in the workbench and explained in depth under Software Quality. Product shows the signal; Software Quality explains the discipline.
Drift Findings
- Tasks, review aspects and evidence make quality state visible.
- Drift findings become follow-up work instead of abstract concern.
- The product keeps the quality loop close to the task board.
Conventions That Keep Fast Work Reviewable
Agent Studio favors a few durable operating conventions over a growing wall of settings. They describe how the tool is built and how it is meant to be used.
Convention over settings
A small, legible workflow beats a control panel for every possible preference.
Task-anchored
Prompts, runs, files, usage and decisions belong to a bounded unit of work.
Evidence-first
“Done” is a claim until the diff, checks and visual proof make it inspectable.
Acute vs. history
The board shows what needs attention now; the task record preserves what happened and why.
Human acceptance
Agents produce candidates. A person still accepts, reissues, splits or rejects the work.
CLI, not captive runtime
Codex, Claude Code and Gemini remain the execution tools; the workbench organizes the process around them.