Bring Your Own Agent Runtime

The coding-agent market is not going to settle on one runtime. That would be too neat. Some teams want Codex. Some want Claude Code. Some want a local harness they wrote themselves. Some will want OpenCode, Pi, or a tool that does not exist yet.

SE Studio should support that reality instead of fighting it. The command center should not care whether the agent underneath is from OpenAI, Anthropic, an open-source project, or an internal platform team. It should care about the contract: how to start work, how to resume work, where the repo lives, what changed, what was tested, and what evidence came back.

The product should be the control plane, not the agent vendor

A lot of agent tooling quietly assumes the agent runtime is the product. Pick the vendor, accept the workflow, and build the rest of your development process around that one execution model.

That is not how serious software teams behave. Teams already have local scripts, security policies, package managers, review habits, CI rules, repo layouts, model preferences, and vendor constraints. Agent runtimes need to fit into that environment, not replace it.

SE Studio's job is to be the local command center around those agents: visible terminals, task boards, worktrees, specialist roles, evidence, review gates, and human decisions. The runtime is a powerful worker. It should not own the entire workflow.

Presets where they help

Codex and Claude Code should work out of the box. They are the obvious built-in presets because many users already have those CLIs installed, know their behavior, and want SE Studio to open a repo and start useful work without a setup ceremony.

• Codex preset: launch Codex from the user's local environment and pass the assignment into the agent.
• Claude Code preset: launch Claude Code from the user's local environment with the same SE Studio workspace context.
• Future presets: add tools such as OpenCode when the runtime contract is stable enough to make the default experience reliable.

Presets matter because they remove friction for the common path. A new user should not have to become a runtime integrator before they can run their first agent session. If they choose Codex or Claude Code, SE Studio should know the right defaults and let the built-in workflows run.

Custom runtimes for everything else

The preset list will never cover every useful agent. It should not try. The better design is to let users configure a list of local agent runtimes in settings. Each runtime can have a name, a start command, and a resume command.

name: Pi coding harness
start: pi-agent start --workspace {workspace} --prompt {prompt}
resume: pi-agent resume --workspace {workspace} --session {sessionId}

That small contract is intentional. Start means SE Studio can create a new agent session for a task, sprint role, Switchboard claim, or manual coding run. Resume means SE Studio can return to an existing session without pretending every runtime stores state the same way.

Everything behind those commands belongs to the user. It can call a local model. It can proxy to a hosted LLM. It can run an internal policy wrapper. It can inject company-specific context. It can choose Pi, OpenCode, a private coding harness, or a shell script that launches several tools in sequence.

Examples of runtimes you could bring

The custom runtime path is deliberately broad. If a tool can be started from the command line and can accept enough workspace context to do useful coding work, it should be a candidate for SE Studio.

• Pi or another local coding harness your team already uses.
• OpenCode or other open-source agent CLIs as they mature.
• Aider-style terminal coding workflows.
• A Continue-style local workflow wrapped in a script.
• A company-internal agent launcher with policy, logging, or model routing built in.
• A local-model runner that calls tools through your own shell command.

That list is not a promise that every tool has a polished preset on day one. It is the design target. Built-in presets should cover the common path. Custom runtimes should keep the door open for everything else.

The same SE Studio workflows still apply

Runtime choice should not mean giving up the product surface. A custom runtime should still be able to appear inside SE Studio's normal workflows: terminals, task execution, Sprint Engine roles, Switchboard queues, Watchtower findings, knowledge graph context, worktree isolation, comments, artifacts, and review evidence.

That is the point of being runtime-agnostic. The user can change the agent underneath without losing the command center around it. SE Studio keeps the durable parts: what was assigned, what ran, what changed, what was checked, and what the human decided.

The agent runtime should be replaceable. The workflow evidence should not be.

This also keeps the product honest. If a runtime is good at interactive edits but weak at long-running issue work, teams can use it where it fits. If another runtime is better for test repair, they can make that a separate preset. If a company standardizes on an internal wrapper, SE Studio can call that wrapper instead of asking the team to bypass its own controls.

Why local configuration matters

A local runtime configuration is not just a convenience feature. It is a trust boundary. The commands run on the user's machine, against the user's repo, with the user's installed tools and credentials. SE Studio can make the work visible without forcing source code, prompts, or execution state through a single hosted path.

That is especially important for teams with security review, regulated codebases, private dependencies, or model-selection constraints. They can keep their preferred agent stack and still use SE Studio as the place where agent work is organized, inspected, and reviewed.

A small adapter beats a big abstraction

The tempting version of runtime agnosticism is a huge universal agent API. That sounds clean until every runtime has a different session model, permission system, file-editing strategy, event stream, prompt format, and resume behavior.

A command contract is more practical. SE Studio can pass stable workspace variables into the command, capture output, associate the process with a task or terminal session, and preserve the evidence. More structured adapters can come later for runtimes that expose richer events, but the base layer stays simple enough for users to bring their own tools.

Where this is going

The near-term direction is straightforward: keep Codex and Claude Code as polished presets, add a settings surface for user-defined runtimes, and make the rest of SE Studio treat those runtimes as first-class execution choices. From there, future presets can be added when they earn their place.

That is the kind of agent platform SE Studio should be: opinionated about workflow, evidence, visibility, and review; deliberately unopinionated about which LLM or coding harness a team is allowed to use.