Multi-Turn Agent

The Multi-Turn Agent coordinates conversational and tool-using workflows over a persistent connection, with bounded cross-request state.

Overview

The Multi-Turn Agent is a PCC Agent workflows, implemented by the MultiTurnAgent framework, that handles inference requests with three characteristics that distinguish them from one-shot inference:

  • A single client interaction produces a sequence of related inference requests, each of which we call a turn.

  • Within a turn, the agent may invoke the LLM more than once to satisfy server-side tool calls, returning a single final response that incorporates the tool results.

  • Across the turns of an interaction, the LLM’s intermediate computation — specifically, the Distributed inference — can be reused on the server side to avoid recomputing tokens that the model has already processed.

Interactions, turns, and sub-turns

A multi-turn interaction is a sequence of turns submitted by the same Apple Intelligence feature for the same user-initiated task. Each turn corresponds to a single LLM invocation visible to the user — for example, one model response in a conversational exchange. The Multi-Turn Agent further decomposes each turn into sub-turns: server-side LLM invocations made by the agent to satisfy server-side tool calls before returning a final response for the turn.

Persistent client connection

In the one-shot model, the client opens a fresh transport-layer connection from the user’s device to PCC for every inference request, and retransmits the full conversation transcript on each turn. For features that perform many small turns, this incurs both connection-setup latency and redundant transmission of unchanged context.

To avoid this overhead, the user’s device can open a persistent connection to PCC for the duration of a multi-turn interaction and submit each subsequent turn as a sub-request multiplexed over the same connection. The connection uses the standard Application protocol. Once established, each new turn reuses the cryptographic tunnel that was negotiated for the first turn, and the client can transmit only the delta rather than the entire transcript. Each turn carries a multi_turn_metadata field, transmitted in the encrypted body of the sub-request, that ties the sub-request to its session.

KV cache reuse

To avoid recomputing the KV cache on every turn, the Multi-Turn Agent reuses the encrypted KV cache produced by one turn when handling the next turn of the same interaction. To help preserve PCC’s Stateless computation on personal user data property, PCC retains no encryption keys for cached state between turns: the user’s device supplies the keys with each turn’s request, so cached state is cryptographically inaccessible to PCC except during the processing of a turn whose request delivered the relevant keys. The mechanism, the storage flow, and the participating daemons are described for each platform in KV cache reuse and Per-user KV cache.

Sub-turn handling

Within a single client-visible turn, the Multi-Turn Agent may invoke the LLM more than once: an initial invocation produces a response that includes one or more server-side tool calls; the agent executes those tool calls; and a subsequent invocation feeds the tool results back to the model. For some inference identifiers, the Multi-Turn Agent caps the number of server-side tool calls within a turn: once the count reaches the cap, the agent removes the server-side tool definitions from the next invocation’s request, so the model is no longer offered those tools.

A tool registry within the MultiTurnAgent framework enumerates the server-side tools available to the agent. As it builds the prompt, the agent resolves each client-declared tool capability against this registry, rejects any capability the registry does not recognize, and then validates the resolved capabilities’ fields before invoking the LLM.

Each server-side tool call is dispatched according to PCC Agent’s Extending workflows with tools: tools that can run inside the trust boundary do so, and any External tool calls carries additional non-targetability and logging protections.