AHP is a display protocol built to let many interfaces operate on shared session state. It’s an extensible, bidirectional, state-based protocol that works well across a variety of modalities and network conditions.
Cover
AHP drives the UI by applying actions to state through pure reducers. A client sends a message by issuing chat/turnStarted as a dispatchAction, and can naturally show it in a pending state until the server acknowledges it.
Other clients stay in sync by seeing the stream of actions echoed and broadcast by the agent host. The host is the arbiter of state and can choose to reject or reconcile concurrent conflicting actions.
Read more Actions ↗Client-side state ↗
Because actions are pure, sequenced envelopes, AHP behaves well under network interruptions. Clients can keep letting the user work and reconcile their pending actions when the network reconnects. Here, the phone approves a tool call just as it loses signal.
The host can keep working too. When a client reconnects, the host sends either the actions it missed or simply a snapshot of the current state.
The client then reconciles its pending actions with the current state. Each one is applied, or rejected if it would conflict. The phone’s approval already reached the host before the link dropped, so it’s simply confirmed, and the phone matches every other screen.
Read more Reconciliation ↗Reconnection ↗
Chat is just one channel, and AHP is designed to be extended with more. Automations, for example, are scheduled tasks that live on the host. Any client can start a run and follow it into the session it creates.
Terminals are another optional capability. The agent can run a command, and you can take over the same terminal from any client. The host tracks who’s in control, and output always comes from the host, so every screen sees the same thing.
It’s important that AHP be expressive enough to implement powerful, featureful agent hosts. But it’s just as important that it’s easy to build a simple, useful integration that runs wherever developers want it.
Features beyond basic conversations are optionally implemented and negotiated by clients and hosts when they connect, so you can start with just chat and add more as you go. This host doesn’t offer automations, so the client simply leaves them out.
There are ready-to-use clients in several languages, so it’s easy to build AHP-compatible clients and hosts. If you’d rather implement your own, there are language-independent test suites too. We’ve found that most agents can build fully functional clients and hosts with these packages and minimal prompting.
The guide walks through the concepts, and the specification has the full details.
