paratenic

Plate V · Protocols

One authority among many protocols.

Agent systems now have a protocol for every seam: editor to agent, agent to tools, agent to screen, host to clients. Paratenic implements one of them in full, relays another, projects two for presentation and leaves one alone on purpose.

Map

Each protocol owns one seam

Each protocol owns one seam Culture's screens receive an AG-UI projection from the Rust client core and render A2UI surfaces against an allowlisted component catalogue, sending intents back. The client core speaks AHP to Paratenic. Paratenic speaks its live-backend protocol to the Pi extension in every Pi and to the Pi provider, which starts Pi for sessions clients create. Other AHP hosts such as pi-daemon speak AHP to the client core directly. Runtimes use MCP to reach tool servers, which clients can also reach through AHP side channels. Separately, ACP connects an editor to an agent process it launched; Paratenic does not speak it. Culture screensSwiftUI · Compose · web · TUI A2UI catalogueallowlisted components client coreRust · one replica per host ParatenicAHP host extension provider pi Pi Pi in tmuxcreated sessions MCP serverstools · resources an editor agent process ELSEWHERE: NOT SPOKEN BY PARATENIC AG-UI A2UI AHP backend backend tmux backend MCP ACP · stdio in-process launches
Fig. V.1Only one edge carries authority over a session: AHP, between a client and its host.

Compared

Shape, transport and who holds the state

ProtocolConnectsTransportState lives inIn Paratenic
AHPmany clients ↔ one hostJSON-RPC over WebSocketthe host: snapshots, ordered actions, pure reducersimplemented in full, 0.8
ACPone editor ↔ one agentJSON-RPC over stdio, usually to a process the editor launchedthe agent processnot spoken
MCPan agent ↔ tool and context serversJSON-RPC over stdio or HTTPeach serverrelayed through AHP side channels
AG-UIan agent run → a frontendan event stream; transport-agnosticthe frontend, derivedprojected from AHP in Culture
A2UIdeclarative UI → a component cataloguecarried inside another streamthe rendering clientvalidated surfaces, v0.9.1
Pi RPCa controller ↔ one Pi runtimeframed JSON linesPionly Paratenic’s isolated test harness
Backenda runtime ↔ ParatenicJSON lines over an owner-private Unix socketsplit: AHP state here, execution in the runtimeParatenic’s own, versions 1–14

AHP 0.8

All of it, on the official types

AHP 0.8, every entry Every command, action and server notification in the AHP 0.8.0 specification, as listed by Paratenic's machine-checked conformance inventory, drawn as filled marks: 27 of 27 commands, 86 of 86 actions across the root, session, chat, terminal, changeset, annotations and resource-watch channels, and 8 of 8 notifications, all implemented. root/agentsChanged root/activeSessionsChanged root/terminalsChanged root/configChanged session/ready session/creationFailed session/chatAdded session/chatRemoved session/chatUpdated session/defaultChatChanged session/titleChanged session/serverToolsChanged session/activeClientSet session/activeClientRemoved session/workingDirectorySet session/workingDirectoryRemoved session/workingDirectoryReplaced session/inputNeededSet session/inputNeededRemoved session/customizationsChanged session/customizationToggled session/customizationUpdated session/customizationRemoved session/mcpServerStateChanged session/mcpServerStartRequested session/mcpServerStopRequested session/isReadChanged session/isArchivedChanged session/activityChanged session/changesetsChanged session/configChanged session/metaChanged chat/turnStarted chat/delta chat/responsePart chat/toolCallStart chat/toolCallDelta chat/toolCallReady chat/toolCallConfirmed chat/toolCallComplete chat/toolCallResultConfirmed chat/toolCallContentChanged chat/toolCallAuthRequired chat/toolCallAuthResolved chat/turnComplete chat/turnCancelled chat/error chat/activityChanged chat/workingDirectorySet chat/workingDirectoryRemoved chat/usage chat/reasoning chat/pendingMessageSet chat/pendingMessageRemoved chat/queuedMessagesReordered chat/draftChanged chat/inputRequested chat/inputAnswerChanged chat/inputCompleted chat/truncated chat/turnsLoaded terminal/data terminal/input terminal/resized terminal/claimed terminal/titleChanged terminal/cwdChanged terminal/exited terminal/cleared terminal/commandDetectionAvailable terminal/commandExecuted terminal/commandFinished changeset/statusChanged changeset/fileSet changeset/fileRemoved changeset/filesReviewChanged changeset/contentChanged changeset/operationsChanged changeset/operationStatusChanged changeset/cleared annotations/set annotations/updated annotations/removed annotations/entrySet annotations/entryRemoved resourceWatch/changed COMMANDS27 / 27 initialize ping reconnect subscribe createSession disposeSession createChat disposeChat createTerminal disposeTerminal createResourceWatch listSessions resourceRead resourceWrite resourceList resourceCopy resourceDelete resourceMove resourceResolve resourceMkdir resourceRequest fetchTurns authenticate resolveSessionConfig sessionConfigCompletions completions invokeChangesetOperation ACTIONS86 / 86 root 4 session 28 chat 29 terminal 11 changeset 8 annotations 5 resourceWatch 1 NOTIFICATIONS8 / 8 root/sessionAdded root/sessionRemoved root/sessionSummaryChanged root/progress auth/required otlp/exportLogs otlp/exportTraces otlp/exportMetrics spec/v0.8.0 · 7153143f1c69 · generated from conformance/ahp-0.8.json
Fig. V.2Drawn from the same inventory the conformance test checks: an omission, a duplicate or an unknown entry fails the build.
  • No parallel models. Wire and state types come from ahp-types, reducers from ahp, and acceptance tests drive the official ahp-ws client. All three are pinned to 0.8.0 and will move together.
  • Capabilities are earned. An optional operation is exposed only when the session’s backend advertises it; otherwise the client gets a standard AHP error. Non-advertisement is conformance, not a fallback.
  • What that covers. Root, session and chat channels; multiple chats with forks and side chats; elicitation; tool and result confirmations; client-provided tools; PTY terminals with claims and scrollback; session-root-confined file resources and watches; changesets and annotations; OTLP relay; provider authentication.
  • Not targeted. AHP 0.9 additions such as automation channels and chat/turnResume.

AG-UI and A2UI

Projections can show, never decide

Projections can show, never decide Top: AHP snapshots and ordered actions feed the paratenic-ag-ui projection, which emits standard AG-UI events — RUN_STARTED, TEXT_MESSAGE, REASONING and TOOL_CALL events, RUN_FINISHED, and CUSTOM for anything else — with thread and run ids derived from host, chat and turn, so it can be discarded and rebuilt. Bottom: an A2UI v0.9.1 surface is validated against a client-owned component catalogue and rendered; a user's action becomes a typed intent that is sent as an ordinary AHP command such as chat/inputCompleted. Only the runtime's resolution, arriving back as AHP state, settles anything. AHP statesnapshot + ordered actions paratenic-ag-uiids from host · chat · turn AG-UI eventsRUN_* · TEXT_MESSAGE_*REASONING_* · TOOL_CALL_* a viewany AG-UI frontend A2UI surfacev0.9.1 paratenic-a2uivalidate · client catalogue typed intentcarries AHP ids AHP commandchat/inputCompleted user acts the runtime resolves; state returns as AHP rebuilt from AHP after every reconnect
Fig. V.3AG-UI’s run-interrupt model is not AHP’s in-turn input model, so an AG-UI resume is accepted only as a translated AHP action.

AG-UI is a convenient shape for frontends: runs, streamed messages, reasoning and tool calls. Culture’s paratenic-ag-ui crate derives those events from AHP, with ids computed from host, chat and turn, and throws the projection away on reconnect. A2UI is presentation data: Culture validates a surface against a catalogue it owns, renders it, and turns a user’s action into an ordinary AHP command carrying the original host, session, chat and request identities. Neither can settle an input, a tool or a turn.

MCP

Tools stay with the runtime

A runtime lists its MCP servers when it registers. Paratenic publishes each as an official ready customization with an opaque mcp:// channel, and a client can then send MCP requests through AHP to the runtime that owns the server.

  • Allowlist. The capabilities the runtime advertised are the only methods allowed; MCP initialize is always refused.
  • Verbatim. Request bodies pass through unchanged, and the caller’s own JSON-RPC id is restored on the reply.
  • Isolated. At most 16 MCP requests in flight per client connection and 128 pending in all, on their own task set, so a slow tool never stalls the ordered AHP stream.

Backend protocol

The protocol runtimes speak to the host

Fourteen versions of the live-backend protocol A timeline of backend protocol versions 1 to 14, each still accepted: 1, hello, events and basic commands; 2, input requests; 3, providers, createSession, multiple chats and paged history; 4, tool and result confirmations and client tools; 5, MCP side channels; 6, auxiliary resources, OTLP and provider authentication; 7, source aliases and read-only chats; 8, multiplexed session routes; 9, indeterminate outcomes and readiness receipts; 10, managed invocation and scoped Stop; 11, turn reconciliation; 12, snapshot batches; 13, source turn resources; 14, profile images. 1 hello · events prompt · abort 2 input requests 3 providers · chats createSession 4 tool confirmations 5 MCP side channels 6 resources OTLP · auth 7 source aliases read-only chats 8 multiplexed routes 9 indeterminate readiness 10 managed invocation 11 turn reconciliation 12 snapshot batches 13 source turn resources 14 profile images filled: the versions that changed what a session is — input, providers, routes, honest outcomes
Fig. V.4Every version is still accepted. A backend keeps the version it negotiated, and a host never sends it a frame from a later one.

The live-backend protocol is deliberately small and neutral: UTF-8 JSON objects, one per line, at most 1 MiB, on an owner-private Unix socket. It describes sessions, providers, commands and events, and nothing about any particular runtime or orchestrator. The full specification is published with this site.

ACP

Left alone on purpose

ACP solves a different problem well: one editor driving one agent it launched. Paratenic’s sessions already exist and already have a human somewhere else, so there is no editor to own them. Where a runtime exposes an ACP stream, Paratenic’s plan allows it only as a parity check — never as a second path for commands.