paratenic

Plate I · Overview

pa·ra·ten·ic adj. of a host: not needed for the parasite’s development, yet keeping its life cycle going.

Host the agents you already run.

Paratenic is an Agent Host Protocol server that runs no model of its own. It adopts Pi sessions where they already live, starts an ordinary Pi in tmux when a client asks for a new session, and keeps every one of them in step across every AHP client — Culture on desktop, phone, watch and web. Other AHP hosts, such as pi-daemon, sit beside it, and Culture connects to each.

Run itWhy it existsHow sessions join

One Paratenic host as a culture dish A single Paratenic host drawn as a culture dish. Each cell is one agent session. Attached sessions (amber) are Pi processes already running in terminals; host-created sessions (teal) were started by the Paratenic Pi provider for AHP createSession, each a Pi in its own tmux session that a person can attach to; offline sessions (grey) are ones whose Pi has exited — the host keeps their history and still answers reads, most of them dormant on disk until opened. A breathing core is a working session, a coral ripple is a session waiting for an answer. Clients — Culture on terminal, web, macOS, iPhone, Apple Watch, Android and Wear OS, and the Petri lab — sit around the rim and all see the same state. macOS iPhone Watch Android Wear OS Web Terminal Petri ATTACHED HOST-CREATED OFFLINE SEQ 18204
attached host-created offline client idle working inbox dormant

What it is

A host for sessions, not for models

The Agent Host Protocol splits an agent system in two: a host that owns sessions and their state, and clients that subscribe to snapshots and ordered actions, reconnect without losing their place, and steer. VS Code’s Agent Host is one such host, and it runs its agents inside its own process.

Paratenic is a host that runs no agents. Runtimes keep inference, tools and files, and register with Paratenic over an owner-private Unix socket. Paratenic turns what they report into official AHP state on one host-wide sequence, persists it, fences stale processes and routes each client command to the single runtime that owns the conversation.

Take Paratenic away and nothing stops: a Pi in a terminal keeps working, and its extension re-registers with backoff when the host returns.

27/27
AHP 0.8 commands
86/86
actions, on the official reducers
v14
live-backend protocol
0
caps on sessions, clients or chats
1
tmux session per created agent
0
Pi runtimes held by a dormant session

Topology

Runtimes on one side, clients on the other

Where Paratenic sits Runtimes on the left own inference, tools and files: Pi processes in terminals, each joined by the Paratenic extension over its own Unix socket, and Pi agents the Paratenic Pi provider started for AHP createSession, each in its own tmux session, which join the same way. The Paratenic host in the middle owns AHP identity, ordering, replay and fencing. Clients on the right — Culture on every platform, the Petri lab and any AHP 0.8 client — subscribe over WebSocket. pi-daemon is a separate AHP host: Culture connects to it directly, beside Paratenic, and merges the hosts on the client. ATTACHEDPi in a terminalParatenic extensionthe TUI stays in charge HOST-CREATEDPi in tmuxstarted for createSessionattach any time provider piPi spawner Paratenicone AHP host per nodeidentity · order · replayfencing · persistence Cultureterminal · web · macOSiPhone · iPad · WatchAndroid · Wear OS Petrilab controller any AHP clientAHP 0.8 RUNTIMES OWN THE AGENT CLIENTS VIEW AND STEER backend protocolone socket per session backend protocol tmux new-session createSessioncommands AHP · WebSocket pi-daemon: Culture connects to it directly
Fig. I.1Runtimes keep inference, tools and files. Paratenic keeps the shared session state. Clients subscribe.

Three tenancies

Every kind of agent, one plane

A conventional host owns every agent it shows. Paratenic shows three kinds side by side, and a client cannot tell them apart until it asks what it can do with each.

PropertyAttachedHost-createdOffline
RuntimeThe Pi process in your terminalAn ordinary Pi the Pi provider started in tmuxNone: its Pi has exited
BornWhen you start piAHP createSession, at a URI the client choseWhen its Pi exits
Joins throughThe Paratenic extension, one socket per sessionThe same extension, claiming its URI with a one-time tokenResuming the conversation in Pi rejoins at the same URI
While idleA live process; it is the sessionA live Pi in tmux; attach any timeHistory on disk; no runtime
A promptRouted once, submitted through Pi’s extension APIThe same: routed once through its extensionRefused until a Pi rejoins

Why three tenancies · Exact join semantics

Protocols

Where AHP ends and the others begin

ProtocolConnectsIn Paratenic
AHPMany clients to one host that owns session stateParatenic is the host: AHP 0.8, all commands, actions and notifications
ACPOne editor to one agent processNot spoken. A runtime’s ACP stream may check parity; it never owns commands
MCPAn agent to tools and context serversRuntimes advertise MCP servers; AHP side channels forward allowlisted calls
AG-UIAn agent run to a frontend event streamA disposable projection of AHP inside Culture’s client core
A2UIDeclarative UI to a component catalogueRendered against an allowlist; it can propose intents, never settle them
BackendA runtime to ParatenicParatenic’s own JSON-lines protocol over a Unix socket, versions 1–14

The protocol map in full

Culture

One client for every host, on every screen

Culture holds an independent AHP connection to each host you configure and merges them into one workspace: one agent list, one feed, one inbox of questions waiting for you. The same Rust core drives the terminal, the browser, macOS, iPhone, iPad, Apple Watch, Android and Wear OS.

Culture on iPhone: the Feed, filtered across all hosts, with a release question waiting and a design review's reasoning Culture on Android: a release agent's turn with tool runs, a pending release-channel question and context telemetry Culture on Apple Watch: a conversation with a dictated reply button Culture on Wear OS: the agent list with a live progress ring

Culture on every platform, and the Petri lab

Start

Four commands to a shared session

  1. Install both binaries

    # from a checkout: ~/.local/bin/paratenic and culture
just install all

  2. Start the host

    paratenic serve # 127.0.0.1:7788, state in ~/.local/state/paratenic

    Loopback only by default. /ahp is the WebSocket; /healthz carries no content.

  3. Attach the Pi you already have

    pi -e ./extensions/paratenic.mjs

    Both sides default to the same socket, $XDG_STATE_HOME/paratenic/backend.sock. Optionally run paratenic provider pi so clients can create sessions, each a Pi in its own tmux session.

  4. Open Culture

    culture config init
culture            # terminal
culture web        # browser, 127.0.0.1:7789

Services, authentication, inventory and updates

Boundary

Not here yet

  • Built-in TLS. Non-loopback plaintext is refused unless a strict token file and an explicit trusted-proxy flag are both given.
  • Full transcript resynchronisation after a runtime loses its outbound buffer.
  • Dynamic model-completion catalogues, and generic Pi extension-UI projection beyond the Pi-AHP bridge.
  • AHP 0.9 additions such as automation channels and chat/turnResume.