Skip to content

Integrated AI agent

An agent pane that opens beside your tasks, so you can hand over work without leaving the list you are looking at.

The pane

The agent is a pane in the app, not a separate window or a chat site. It sits next to the list you are already in, which means the context you have built up — the task, its project, the tags around it — is context the request already has.

Connecting opencode

The pane does not bundle an agent — it connects to opencode over the Agent Client Protocol (ACP). Install opencode so the opencode executable is on your PATH, then open the agent pane on a directory-backed project:

terminal
 1  which opencode
 2  opencode --version
  1. Install opencode and confirm opencode resolves on your PATH.
  2. Sign in or add provider keys in opencode itself (opencode auth login) — the pane reuses that authentication, there is nothing separate to enter here.
  3. In the app, open a project backed by a directory and switch the right pane to the agent.
  4. The pane launches opencode acp in the project directory and shows the resolved command while starting. Each project keeps its own session, resumed across restarts.
  5. Pick the model and mode from the chips in the pane header — those options come from opencode's session configuration.

If the pane reports the agent was not found, opencode is missing from PATH in the environment the app was launched from. If it reports an authentication error, fix it in opencode (login or provider key) and retry — the pane surfaces what opencode acp reports.

Delegating work

The pane is for delegation rather than conversation. Requests that read naturally against your own lists are the ones it is built for:

  • "Group today's triage by what should happen next."
  • "Set up the release checklist for next month."
  • "Take this task through the coding workflow."
  • "Turn these notes into tasks in the right project."

Because it acts on the same database the rest of the app is reading, the result shows up as real tasks you can edit — not as a summary you have to transcribe by hand.

What it inherits

The pane drives the same agent as the terminal tool, over the Agent Client Protocol, so it inherits that configuration rather than reimplementing it:

  • The provider and model you selected, including fallback when a provider fails before producing output.
  • The tools the agent has — files, search, shell, and anything you have added as an MCP server.
  • Hooks bound to agent events, so automation outside the app still fires.
  • Fallback combos — a named list of provider/model pairs tried in order when one fails before producing output.

The protocol and the client that speaks it are covered on the contributor side inthe agent protocol.

Configuring it

Nothing needs configuring to use the local lists. To use the agent, pick a provider and give it a key — that is one JSON file, documented in Configuration. Tool servers and hooks live in the same file. API keys can come from a command, an environment variable, or a literal value, and per-model settings such as token limits and temperature are available for tuning.

Workflows are the interesting part
A single request is useful; a task that carries its own process is better. See Semi-automated workflows for the staged version of this.

Edit this page on GitHub