Skip to content

tasks: directly integrate agentapi via coder agent #937

@johnstcn

Description

@johnstcn

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.

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions