Communication Model
The protocol follows the JSON-RPC 2.0 specification with two types of messages:- Methods: Request-response pairs that expect a result or error
- Notifications: One-way messages that don’t expect a response
Message Flow
A typical flow follows this pattern:1
Initialization Phase
- Client → Agent:
initializeto establish connection - Client: completes an advertised authentication flow if required; for example,
auth/loginfor an Agent-handled method or launch and reconnect for a terminal method
2
Session Setup - either:
- Client → Agent:
session/newto create a new session - Client → Agent:
session/resumeto resume an existing session
3
Prompt Lifecycle
- Client → Agent:
session/promptto send user message - Agent → Client:
session/promptresponse once the prompt is accepted - Agent → Client:
session/updatenotifications for accepted messages, state updates, progress updates, and advisory notices - Agent → Client: Permission requests as needed
- Client → Agent:
session/cancelto interrupt processing if needed - Agent → Client: An idle
state_updatewhen ready for a new prompt, with a stop reason when foreground work ends.
Agent
Agents are programs that use generative AI to autonomously modify code. They typically run as subprocesses of the Client.Baseline Methods
Some baseline methods belong to optional surfaces. An Agent that returns one or more valid entries inauthMethods MUST implement both auth/login and auth/logout. If authMethods is omitted or empty, Clients MUST NOT call either method.
Authenticate with the Agent (if required).
Send user prompts to the
Agent.
Notifications
Cancel ongoing operations
(no response expected).
Client
Clients provide the interface between users and agents. They are typically code editors (IDEs, text editors) but can also be other UIs for interacting with agents. Clients manage the environment, handle user interactions, and control access to resources.Baseline Methods
Request user
authorization for
operations such as tool calls and commands.
Optional Methods
Request structured information from the user
(requires the matching
elicitation mode capability).Notifications
Report completion of an out-of-band URL
interaction (no response
expected).
Send session
updates to inform
the Client of changes (no response expected). This includes message updates
and chunks, tool calls, updates, and content
chunks, display-only terminal state and
output chunks,
plans, available commands
updates, and config
option updates, and
advisory notices.
Argument requirements
- All file paths in the protocol MUST be absolute.
- Line numbers are 1-based
Error Handling
All methods follow standard JSON-RPC 2.0 error handling:- Successful responses include a
resultfield - Errors include an
errorobject withcodeandmessage - Notifications never receive responses (success or error)
Conventions
Unless explicitly defined otherwise in the schema, ACP-defined JSON object property keys usecamelCase. String values carried by discriminator fields use snake_case. The JSON-RPC envelope fields (jsonrpc, id, method, params, result, and error) follow the JSON-RPC 2.0 specification.
Selected enum-like fields and tagged unions can define custom or future fallbacks. For those fields, _-prefixed values are reserved for implementation-specific extensions, while unknown non-underscore values are reserved for future ACP variants.
Extensibility
The protocol provides built-in mechanisms for adding custom functionality while maintaining compatibility:- Add custom data using
_metafields - Create custom methods by prefixing their name with underscore (
_) - Advertise custom capabilities during initialization
Next Steps
- Learn about Initialization to understand version and capability negotiation
- Understand Session Setup for creating and loading sessions
- Review the Prompt Lifecycle
- Explore Extensibility to add custom features