The runtime is the agent, not the panel around it
A coding-agent runtime coordinates model calls, context, tool execution, state, and error recovery. An IDE extension, desktop app, or terminal UI presents that runtime to a developer. Treating those layers separately keeps the core agent behavior from being trapped inside one interface.
That distinction shows up when a workflow changes. The same task may begin in a terminal, continue in an editor, and be reviewed in a desktop app. A runtime can keep the model profile, permission policy, plan, and workspace state coherent across those surfaces.
What belongs in a runtime
The runtime should know how to build a request, run a tool, enforce a policy, persist a session, and report events. It should not need to know which button opened a panel or how a particular editor renders a diff.
- Model and provider adapters
- Agent modes and permission policy
- Context, memory, checkpoints, and recovery
- Tool schemas and execution results
- Streaming, cancellation, and structured events
A portable runtime reduces rebuild work
A shared runtime lets a client gain improvements in agent behavior without each client inventing a separate tool loop. It also makes testing clearer because the behavior can be verified independently from the UI.
Truss uses this pattern so its desktop app, VS Code extension, CLI, terminal UI, Neovim client, and mobile companion can share the same agent foundation while remaining focused interfaces.
Next steps
Put it to work in your own workspace.
Pick the surface that fits your day, then connect a model you control.
FAQ
Questions developers ask before switching.
Is a coding-agent runtime a server?
It can run locally inside a client, behind a local service, or remotely. The important part is that it owns agent behavior independently from the interface.
Why not put all agent logic in an IDE extension?
It makes the agent harder to reuse, test, and evolve outside that editor. A runtime lets clients stay focused on UX while sharing reliable agent behavior.