Coder Agents

Coder Agents is a chat interface and API for delegating development work and research to coding agents in your Coder deployment. Developers describe the work they want done, and Coder Agents handles selecting a template, provisioning a workspace, and executing the task.

Coder Agents includes its own self-hosted AI coding agent that runs the agent loop directly within the Coder control plane.

No specialized software, API keys, or network access is required inside your workspace. The only requirement is network access between the control plane and external LLM providers.

What Coder Agents is and isn't

It is a standalone agent written in Go that implements standard agentic patterns — sub-agent delegation, context compaction, file editing, and shell execution — and works with any LLM provider you configure.

It is not a wrapper around third-party agent tools like Claude Code or Codex.

Coder Agents is not a replacement for your text editor or IDE. It is the primary interface where developers work with and orchestrate coding agents. Developers still connect to workspaces via VS Code, Cursor, JetBrains, or any other editor to review, refine, and complete work that the agent produces.

Who Coder Agents is for

Coder Agents is designed for organizations that need to self-host their AI coding workflows and maintain full control over how agents operate. It is a strong fit for:

• Regulated industries such as financial services, healthcare, and government, where AI tools must run on controlled infrastructure with auditable access and strict network boundaries.
• Platform engineering teams that want to provide developers with a high-quality AI coding experience without managing per-workspace agent installations, API key distribution, or third-party agent licensing.
• Organizations with existing Coder deployments that want to add agentic capabilities using their current templates, workspaces, and identity providers rather than adopting a separate SaaS product.

Coder Agents runs entirely self-hosted. There is no SaaS or managed component — the agent loop, chat history, and all tool execution happen within your Coder deployment.

How it works

The agent loop runs inside the control plane. When a user submits a prompt, the control plane:

1. Sends the prompt to the configured LLM provider (Anthropic, OpenAI, Google, Azure, AWS Bedrock, or any OpenAI-compatible endpoint).
2. Receives the model's response, which may include tool calls such as reading files, writing code, or running shell commands.
3. Executes tool calls by connecting to a Coder workspace over the existing workspace connection — the same path used for web terminals, port forwarding, and IDE access.
4. Returns tool results to the model and continues the loop until the task is complete.

The workspace itself has no knowledge of AI. It is standard compute infrastructure — there are no LLM API keys, no agent harnesses, and no special software installed. All intelligence lives in the control plane.

The agent loop runs in the control plane. It makes outbound requests to LLM providers and connects to workspaces only when tool execution is needed.

Automatic workspace provisioning

Not every chat requires a workspace. The agent runs in the control plane and can answer questions, discuss architecture, or plan an approach without any infrastructure. Workspaces are only provisioned when the agent needs to take action — reading code, running commands, or editing files.

This means:

• Faster responses — conversations that don't require workspace access start immediately with no provisioning delay.
• Lower infrastructure cost — workspaces are only created when the agent needs to do real development work.

When a workspace is needed, the agent reads the templates available to that user — including their descriptions and parameters — selects the appropriate one, and creates a workspace automatically. Template visibility is scoped to the user's role and permissions, so the agent can only select templates the user is authorized to use. Users can also manually choose which workspace is used when starting a new chat.

Platform teams control template routing by writing clear template descriptions. For example, a description like "Use this template for Python backend services in the payments repo" helps the agent select the correct infrastructure.

Examples of what triggers workspace creation:

Sub-agents

Coder Agents supports sub-agent delegation. The root agent can spawn child agents to work on independent tasks in parallel. Each sub-agent gets its own context window, which keeps individual conversations focused and avoids the quality degradation that occurs as context windows grow large.

For example, an agent tasked with "explore this repository and document its structure" might spawn separate sub-agents to analyze the backend, frontend, and infrastructure directories simultaneously.

Chat persistence

All chat state is stored in the Coder database, not in the workspace. If a workspace is stopped, deleted, or rebuilt, the full conversation history survives. The agent can resume work by creating a new workspace with the same template and continuing from the last known state, such as a git branch.

Users can also fork a chat at any point to explore a different direction while preserving the original conversation.

Message queuing

Users can send follow-up messages while the agent is actively working. Messages are queued and delivered when the agent completes its current step, so there is no need to wait for a response before providing additional context or changing direction.

Image attachments

Users can attach images to chat messages by pasting from the clipboard, dragging files into the input area, or using the attachment button. Supported formats are PNG, JPEG, GIF, and WebP up to 10 MB per file. Images are sent to the model as multimodal content alongside the text prompt.

This is useful for sharing screenshots of errors, UI mockups, terminal output, or other visual context that helps the agent understand the task. Messages can contain images alone or combined with text. Image attachments require a model that supports vision input.

Security benefits of the control plane architecture

Running the agent loop in the control plane rather than inside the developer workspace is an architectural decision that directly addresses the primary concerns regulated organizations have with AI coding tools: how do you give developers access to coding agents without introducing unnecessary risk?

Traditionally, agents run inside the same compute where code lives. This means the agent needs LLM API keys in the workspace, outbound network access to model providers, and often elevated permissions. In a regulated environment, this creates a surface area that is difficult to lock down.

Coder Agents eliminates this by moving the agent loop out of the workspace entirely:

• No API keys in workspaces. LLM provider credentials never enter the workspace. The control plane makes all outbound requests to model providers directly, so there is nothing for a developer or a compromised process to exfiltrate.
• No agent software to manage. Workspaces don't need Claude Code, Codex, or any agent harness installed. This eliminates a class of supply chain risk and removes the need to keep agent software up to date across all workspaces.
• Network boundaries are simpler. Because the workspace doesn't need access to LLM APIs, you can apply strict egress rules. An agent-only template might permit access to only your git provider (e.g., github.com) and nothing else. The workspace never needs to reach the internet for AI functionality.
• Centralized, enforced control. Platform teams configure models, system prompts, and tool permissions from the control plane. These settings are enforced server-side — they are not user preferences that developers can override.
• User identity is always attached. Every action the agent takes — PRs opened, code pushed, commands run — is tied to the user who submitted the prompt. There is no shared bot identity or anonymous execution.
• No privilege escalation. The agent operates with the exact same permissions as the user who submitted the prompt. If a developer cannot access a template, workspace, or resource through the Coder dashboard, the agent cannot access it either. There is no escalation of privileges and no shared service account.
• Workspace isolation is preserved. The agent can only access workspaces owned by the user who submitted the prompt. There is no cross-user workspace access — an agent running on behalf of one developer cannot read files, execute commands, or interact with another developer's workspaces.

LLM provider support

Coder Agents works with any LLM provider. Administrators configure providers and models from the Coder dashboard or API. Supported providers include:

Most providers support custom base URLs, which allows integration with enterprise LLM proxies, self-hosted model endpoints, and internal gateways.

Administrators can configure multiple providers simultaneously and set a default model. Developers select from enabled models when starting a chat.

The model configuration panel in the Coder dashboard.

Built-in tools

The agent has access to a set of workspace tools that it uses to accomplish tasks:

These tools connect to the workspace over the same secure connection used for web terminals and IDE access. No additional ports or services are required in the workspace.

Platform tools (list_templates, read_template, create_workspace, start_workspace) and orchestration tools (spawn_agent) are only available to root chats. Sub-agents do not have access to these tools and cannot create workspaces or spawn further sub-agents.

Comparison to Coder Tasks

Coder Agents is a new approach that differs from Coder Tasks in several ways:

Product status

Coder Agents is in Early Access. The feature is under active development and available for evaluation. See Early Access for enablement instructions and program details.