It is tempting to put interaction logic in the UI and treat the backend as a source of records. That works for a form that submits data and renders a result. It breaks down when an agent is involved.
An agent interaction has state management, authority checks, and side effects. The system needs to know which request is active, whether a tool may run, what an approval authorizes, and whether a turn completed, failed, or needs input. If each client answers those questions for itself, every new surface becomes a partial implementation of the agent.
The UI starts to inherit the agent
The first client often begins with a simple exchange: send a message, show a reply. Streaming progress, approvals, reconnects, cancellation, and shared sessions arrive as isolated UI features. Together, they form the agent's lifecycle.
Now the client has to decide whether an event is current, whether an approval still applies, whether an interrupted tool ran, and which response may replace the one on screen. A second client has to reproduce those decisions. Its small differences become inconsistent behavior rather than harmless presentation choices.
The issue is ownership: clients have taken on rules whose meaning must stay the same across every client.
The agent owns the interaction contract
The agent should define the commands it accepts, the state and events it publishes, and the transitions it permits. The contract needs more than a list of messages. It has to identify a submitted turn, progress for that turn, a proposed action, its approval or rejection, cancellation, completion, and failure. Stable identities let a reconnecting client ask for the current state instead of reconstructing it from an incomplete local view.
The runtime applies policy and executes work. It decides whether a tool call is permitted, records the result, and advances session state. A client can request an action or acknowledge an event; it cannot decide that a tool is safe, a retry is valid, or a turn is complete.
The agent is the system of record for the interaction. Clients let people see it and affect it.
Clients adapt the interaction to a medium
This boundary leaves substantial work in the client. A browser manages layout, focus, draft text, and accessible progress. A voice surface manages microphone permission, turn-taking cues, and playback. A terminal deals with line editing and a native client manages its connection and platform storage. Each translates local input into a contract command and renders contract state in a form that works for the person using it.
Those decisions are specific to a medium. The meaning of an approval, a failed turn, or a completed action must remain fixed. A terminal may show a text prompt, a browser may render buttons, and a voice client may ask for spoken confirmation. All three should confirm the same proposed action under the same authority rule.
One owner makes failure testable
When interaction semantics live in the runtime, the system can prove that a cancelled turn ignores a late tool result, that an expired approval cannot authorize a different action, and that a reconnect receives current session state. Each client then tests its mapping: whether it shows the right state, collects the right input, and recovers from its own transport failure.
That separation makes diagnosis faster. A lifecycle failure belongs to the agent contract. A rendering, input, accessibility, or local transport failure belongs to the client. Without the boundary, the same defect appears as a different platform problem on every surface.
Calling this runtime a backend puts the boundary in the wrong place. A conventional backend can return records and let a client compose a screen. An agent must carry an interaction forward. If it publishes only messages, tool output, and fragments of state, every client will reconstruct the missing meaning and eventually implement a slightly different agent.
palOMine reached this boundary when its client interaction code became convoluted. The correction was one interface through which every client communicates with the agent. The clients remain useful, distinct applications. They no longer need their own version of the agent's logic.
Previous: Agents Are State Machines With a Model in the Loop
Next: Tool Selection Is an Interface Contract
The one-line version
A multi-client agent stays coherent when its runtime owns interaction semantics and every client projects the same contract.