-
Notifications
You must be signed in to change notification settings - Fork 0
Closed as not planned
Labels
Description
Problem
AgentAPI chat is currently exposed as a coder_app in an iframe.
This is convenient for rapid experimentation with agentapi, but has several drawbacks:
- In order to know the "correct" Coder App ID for the
agentapichat, we have a specialsidebar_app_idfield in the database. - This is used by the UI
TaskPageview to properly embed the AI chat window on the left. - Additionally, task status reporting is linked to the agentapi
coder_appviaapp_id.
This is brittle and requires a lot of extra configuration:
- It relies on the AI agent self-reporting status via
MCP(coder_report_task)exposed viacoder exp mcp. - Configuring MCP requires modifying the AI agent configuration, which requires bespoke scripts for each agent type.
- Configuring MCP also requires correctly setting the environment variable
CODER_MCP_APP_STATUS_SLUGas task status are currently linked tocoder_apps. - We currently have some additional foreign key constraints related to this in the database that have historically caused some issues.
Proposed Solution
Use a conceptually similar approach to the new "devcontainers" integration.
This is a rough sketch, more details / RFC TBD:
- Communication between the user and
agentapioccurs viacoder agent. - Template author configures
agentapi_host/agentapi_portin acoder_taskresource (defaultlocalhost:3284). coder agentconnects to theagentapiinstance defined there (we may plumb through some automatically-generated authentication token, or alternatively use ACP)coder agentcan directly poll the task agent for a "coarse" agent status ("idle", "working")coderdcan then query the task agent instance viacoder agentfor chat messages
This allows us to:
- Get rid of
sidebar_app_id - Create a "native" chat interface in
coderd - Remove the requirement for configuring
coder exp mcpand settingCODER_MCP_APP_STATUS_SLUG. More fine-grained status reporting would be possible using this, but not required.