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 agentapi chat, we have a special sidebar_app_id field in the database.
• This is used by the UI TaskPage view to properly embed the AI chat window on the left.
• Additionally, task status reporting is linked to the agentapi coder_app via app_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 via coder 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_SLUG as task status are currently linked to coder_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 agentapi occurs via coder agent.
• Template author configures agentapi_host / agentapi_port in a coder_task resource (default localhost:3284).
• coder agent connects to the agentapi instance defined there (we may plumb through some automatically-generated authentication token, or alternatively use ACP)
• coder agent can directly poll the task agent for a "coarse" agent status ("idle", "working")
• coderd can then query the task agent instance via coder agent for 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 mcp and setting CODER_MCP_APP_STATUS_SLUG. More fine-grained status reporting would be possible using this, but not required.