Backlog / future idea (the agent stays single for now). Today the agent backend is a single, specific local coding agent wired in directly (src/agent/*-server.ts, the provider config, and the prompt/session plumbing). Goal: eventually support additional local coding agents through one internal interface.
Hard constraint — self-hosted only
Any agent we add must:
- Run as a local process on the operator's own machine/VM — never a hosted or third-party agent service, and
- Use our own enterprise LLM served from within our own cloud account — key-less via ambient credentials, exactly as today — never a vendor-hosted model API.
This rules out hosted agent apps, online multi-agent routing services, and model gateways (they run as online services, route to hosted models, or both).
Approach
Introduce a small internal AgentBackend interface (start / runPrompt / streaming + history / stop), extracted from today's single-agent code, with one implementation per supported agent.
Prefer adopting an open, standardized editor↔agent protocol — the equivalent of a language-server protocol but for coding agents ("implement once, work everywhere") — over bespoke per-agent adapters, if a suitable one matures. Several local coding agents (including the one we use today) already speak such a protocol, which would make the first implementation a refactor rather than new integration work. That protocol is a local process-to-process channel, so it adds no online dependency; the self-hosted constraint above is purely about which agents and model backends we permit.
Acceptance (when picked up)
- An
AgentBackend interface with today's agent behind it (no behavior change), then a protocol-based implementation, then a second local, in-account-LLM agent added via config.
Backlog / future idea (the agent stays single for now). Today the agent backend is a single, specific local coding agent wired in directly (
src/agent/*-server.ts, the provider config, and the prompt/session plumbing). Goal: eventually support additional local coding agents through one internal interface.Hard constraint — self-hosted only
Any agent we add must:
This rules out hosted agent apps, online multi-agent routing services, and model gateways (they run as online services, route to hosted models, or both).
Approach
Introduce a small internal
AgentBackendinterface (start/runPrompt/ streaming + history /stop), extracted from today's single-agent code, with one implementation per supported agent.Prefer adopting an open, standardized editor↔agent protocol — the equivalent of a language-server protocol but for coding agents ("implement once, work everywhere") — over bespoke per-agent adapters, if a suitable one matures. Several local coding agents (including the one we use today) already speak such a protocol, which would make the first implementation a refactor rather than new integration work. That protocol is a local process-to-process channel, so it adds no online dependency; the self-hosted constraint above is purely about which agents and model backends we permit.
Acceptance (when picked up)
AgentBackendinterface with today's agent behind it (no behavior change), then a protocol-based implementation, then a second local, in-account-LLM agent added via config.