# ACP introduction and architecture

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | cap-protocol |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | ACP Introduction |
| Source URL | https://agentclientprotocol.com/get-started/introduction.md |
| Source type | documentation |
| Source date (published) | Unknown, not stated (living docs) |
| Date researched | 2026-10-18 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | direct page fetch, read in full |
| Confidence | High |
| Status | Active |

## Summary

ACP standardizes editor-to-agent communication (LSP analogy): local agents run as editor subprocesses over JSON-RPC stdio; remote agents over HTTP/WebSocket (remote support still in progress). Reuses MCP JSON shapes where possible; user text defaults to Markdown.

## Key findings

- Local = subprocess + JSON-RPC over stdio is the stable, specified path; remote is explicitly work-in-progress, so tai's ACP binding targets stdio only.
- Markdown as the default user-text format aligns with tai's TUI rendering.

## Pros / strengths

- Confirms stdio as the SHOULD-support transport, matching CAP's ACP-stdio binding exactly.

## Cons / limitations / caveats

- Positioning page only; no wire detail (covered by the sibling dossiers).

## Relevance to tai

Scopes tai's ACP binding to local stdio and records why remote ACP is out of scope.

## Changelog

| Date | Change |
|---|---|
| 2026-10-18 | Initial dossier created. |