Navigating stateless protocols: managing task handoffs between specialist models and tool hosts

Stateless protocols simplify individual requests: a caller sends the inputs needed for a turn, receives a response, and does not assume the connection will remember what happened before. That model is useful for reliability, scaling, isolation, and data-governance constraints. It becomes harder when an enterprise workflow spans specialist models, MCP-connected tools, asynchronous jobs, approvals, and several operational systems.

The central engineering challenge is not whether a model can produce a tool call or decide that another specialist is better suited to a task. It is how to make that transfer safe, inspectable, resumable, and bounded when no connection-scoped session can be treated as the source of truth. This article explains a practical architecture for managing task handoffs between specialist models and tool hosts while preserving the benefits of stateless APIs.

Why stateless calls need an orchestration layer

A stateless API is a request-response interface, not a complete workflow runtime. OpenAI’s February 27, 2026 partnership statement describes stateless APIs as a baseline cloud collaboration surface, while distinguishing them from more workflow-heavy production agent systems. The same statement says stateless API calls resulting from collaboration with third parties, including Amazon, would be hosted on Azure.

That distinction matters because production work has a timeline. A task may begin with triage, branch into research and retrieval, launch a long-running tool operation, require a human approval, and return to a specialist for synthesis. The individual model calls can remain stateless, but the workflow cannot rely on the absence of remembered state.

Statelessness is not the absence of state. It is a decision to externalize, identify, and replay the state that a given operation needs.

OpenAI’s February 2026 agent-runtime announcement makes the operational gap clear: “one prompt, one answer” prototypes can address simple cases, while real workflows unfold across multiple steps, prior actions, tool outputs, approvals, and system state. The practical implication is that a platform must own continuity outside the model endpoint.

• Model endpoints

  reason over the supplied context and produce structured decisions, messages, or calls.

• Specialist agents

  own bounded responsibilities such as policy review, document analysis, coding, or customer-operations triage.

• Tool hosts

  execute capabilities such as search, retrieval, code execution, ticketing, and business-system actions.

• The orchestration control plane

  records workflow state, applies policy, dispatches work, and exposes observability.

Keeping these responsibilities separate prevents a common design error: treating chat history as an execution ledger. Conversation text may be useful context, but it is not a sufficient record of tool authorization, idempotency, task ownership, approval status, or final business outcomes.

Define the handoff boundary before selecting protocols

A robust design starts by deciding what constitutes a handoff. A handoff is not simply an agent mentioning another agent in generated text. It is a controlled transfer of responsibility for a defined unit of work, with an identified sender, receiver, task contract, and lifecycle state.

Use specialists for bounded responsibilities

Microsoft’s May 7, 2026 guidance on handoff orchestration says the pattern works best when each specialist can complete its task in one pass. That does not mean every business workflow needs only one model call per agent. It means the delegated assignment should have a clear objective, expected output, and completion condition.

For example, a procurement workflow can delegate “classify the supplier’s exception against the current policy and return cited findings” to a policy specialist. It should not delegate “handle procurement” without limits. The latter invites ambiguous ownership, unbounded exploration, and repeated transfers.

Separate tool execution from specialist delegation

Emerging architecture guidance draws a useful line: use MCP for tool-shaped calls and A2A-style interaction for delegation to independent specialist services that own reasoning, state, and task lifecycle. In practice, the labels matter less than the boundary. A tool host performs a capability under a defined interface; a specialist accepts responsibility for reasoning over a task.

• A search service, file retriever, code interpreter, or CRM action is usually a tool-shaped capability.

• A legal-review agent, incident commander agent, or finance-analysis service is usually a specialist delegation target.

• An orchestration layer should be able to invoke both, while preserving different contracts and audit records for each.

This separation also limits accidental coupling. A tool host does not need to infer a business workflow from conversation history, and a specialist does not need direct, unrestricted access to every enterprise system simply because it was asked to help.

Make state explicit, durable, and minimal

In a stateless design, every meaningful continuation needs a durable reference to its state. The IETF’s July 2026 draft taxonomy notes that agentic protocols need conventions for data and context management to support coherent collaboration. It also distinguishes stateless or near-stateless agents from separate agent-to-tool protocol concerns.

The key word is relevant. Replaying every prior message and every tool payload creates cost, latency, privacy exposure, and confusion. Replaying too little causes the next specialist to act on an incomplete or misleading view. The orchestration layer should construct a scoped state package for each next step.

Build a handoff envelope

A handoff envelope is a structured record passed to the next model, specialist service, or tool host. It should be machine-readable, versioned, and stored independently of any model’s transient context window. Its fields should support execution and audit, not merely make a prompt longer.

1. Workflow identity:

   a workflow ID, task ID, parent task ID, correlation ID, and attempt number.

2. Ownership:

   the current responsible specialist, the proposed target, and the reason for transfer.

3. Objective:

   a bounded task statement, acceptance criteria, priority, deadline, and stop conditions.

4. Context references:

   links or content-addressed references to approved documents, prior outputs, retrieved evidence, and user inputs.

5. Execution history:

   completed actions, pending actions, failures, retries, and idempotency keys.

6. Controls:

   authorization scope, data classification, required approvals, allowed tools, budget, and escalation rules.

7. Return contract:

   expected output schema, confidence or evidence requirements where applicable, and the next state on success or failure.

OpenAI’s current API guidance states that stateless or Zero Data Retention flows should pass back relevant returned output items on each turn. A handoff envelope operationalizes that principle. Rather than assuming the provider remembers a prior response, the orchestrator deliberately returns the output items that the next turn requires.

Minimal state does not mean impoverished state. A coding specialist may need a repository snapshot reference, test results, a change request, and policy constraints. A customer-operations specialist may instead need a case summary, verified account facts, consent scope, and an escalation rule. Context should be selected according to the recipient’s job.

Let models recommend handoffs, but make the platform govern them

Routing is partly semantic. Microsoft’s handoff-orchestration guidance observes that the decision to transfer work is often “fuzzy, contextual” and is better made by a model than by typed predicates alone. A specialist can recognize that a request contains a policy exception, a security concern, or a domain-specific question that exceeds its remit.

That does not make the model the sole workflow authority. A production platform should distinguish between a model’s handoff recommendation and the control plane’s handoff authorization. This preserves useful semantic judgment while enforcing organizational constraints.

A practical routing sequence

1. The active specialist returns a structured recommendation: continue, invoke a tool, request clarification, hand off, escalate to a human, or close the task.

2. The

   orchestration layer

   validates the schema, target eligibility, permission scope, data-sharing rules, and workflow budget.

3. The policy layer checks directed-edge rules, approval gates, rate limits, retry limits, and any tenant-specific restrictions.

4. The control plane creates a durable handoff event and dispatches a scoped envelope to the accepted target.

5. The target produces a bounded result, an explicit inability to complete, or a further recommendation that re-enters the same governed sequence.

Microsoft describes developers declaring agents and directed edges between them. Directed edges are valuable because they turn an open-ended mesh into an intentional workflow graph. A triage agent may hand off to a security reviewer or a billing specialist, while neither may directly invoke a payment-release action. Such constraints are easier to test and explain than prompt-only prohibitions.

Use deterministic rules for conditions that must be deterministic: permissions, regulated data boundaries, spending limits, approval requirements, and known service-health conditions. Use model judgment where language, intent, relevance, or domain ambiguity genuinely require interpretation. The strongest systems combine both rather than forcing one mechanism to solve every decision.

Design tool hosts as stateless, contract-driven execution surfaces

Tool hosts should not depend on a long-lived conversational session to know what an agent means. Google’s 2026 MCP stateless update emphasizes explicit tool calls over connection-scoped session memory. MCP migration guidance similarly explains that host, client, and server remain logical roles even as connection-scoped state no longer survives in its earlier form.

This creates a constructive discipline: each tool request must carry or reference the information needed to execute safely. The host should validate the request against a stable schema, authorize it, run it idempotently where possible, and return a result that can be persisted by the orchestrator.

Standardize definitions and outputs

OpenAI’s practical agent-building guidance recommends standardized tool definitions to support flexible many-to-many relationships between agents and tools. Standardization does not mean every tool has identical arguments. It means tools follow common conventions for names, schemas, validation errors, authorization, result status, and references to large artifacts.

• Define input schemas that separate required execution parameters from optional model hints.

• Return typed outcome states such as succeeded, failed, pending, denied, and requires_approval.

• Include an execution ID and idempotency key so retries do not silently duplicate business actions.

• Store large outputs externally and return durable references plus concise summaries.

• Record the actor, authorization basis, policy decision, and versioned tool definition used.

OpenAI’s current guidance recommends hosted tools, including web search, file search, code interpreter, image generation, and computer use, when they fit the workflow. The same principle applies whether a team uses hosted capabilities or its own MCP-connected services: choose the tool based on the work, then bind it to clear authorization and return contracts.

A tool result should be treated as evidence, not automatically as a final decision. A search result may inform a researcher. Code-interpreter output may inform a data analyst. A workflow must still decide which specialist is responsible for interpreting the result, whether more evidence is required, and whether an action requires approval.

Handle long-running tasks with explicit lifecycle controls

Stateless protocols are especially unforgiving when work outlives a single response. Jobs such as indexing files, running tests, generating documents, waiting for a vendor system, or collecting human approval need explicit lifecycle state. A caller must be able to retrieve status without assuming that a previous connection or model context remains available.

MCP migration guidance describes a redesigned Tasks extension that uses explicit task handles together with tasks/get and tasks/update. This fits a stateless handoff pattern: an orchestrator stores a handle, polls or receives an update according to its integration design, and rehydrates the appropriate task context when work is ready to continue.

Model a task as a state machine

A useful lifecycle includes states such as created, queued, running, waiting_for_tool, waiting_for_approval, succeeded, failed, cancelled, and expired. The exact names are less important than making transitions explicit and validating who may cause them.

For instance, a document-generation tool may move from running to succeeded. The tool host should not independently mark the overall customer workflow as complete; only the orchestration layer can do that after applying the workflow’s return contract. Similarly, an approval service can report approved or rejected, but the policy layer decides what subsequent action is permitted.

• Use deadlines:

  every delegated task should have an expiration or review point.

• Use retries deliberately:

  classify transient failures separately from invalid requests and policy denials.

• Use compensation:

  where a workflow performs side effects, define how to reverse or contain partial completion.

• Use checkpoints:

  persist meaningful intermediate outcomes before crossing a model, tool, or human boundary.

Longer-horizon work is increasingly relevant. OpenAI reported that after Codex’s public release, internal users shifted from short interactions toward harder, longer-horizon tasks, including engineering, legal, finance, and recruiting use cases by around April 2026. These use cases make task lifecycle engineering a product requirement rather than a back-end detail.

Prevent loops, deadlocks, and inconsistent workflow views

Multi-agent systems can fail in ways that single-agent chat experiences do not. An ICLR 2026 workshop paper on agents in the wild warns that task transfer can produce circular delegation and deadlock when work passes indefinitely between agents. The paper also identifies inconsistent state management as a failure mode when no unified view exists across multi-protocol workflows.

These are architecture problems, not simply model-quality problems. Even capable specialists can create a loop if each receives an ambiguous task and is allowed to delegate back without a shared record of prior attempts.

Put hard boundaries around delegation

1. Track the delegation path.

   Store source, target, timestamp, task revision, reason, and outcome for every transfer.

2. Set hop limits.

   Cap the number of specialist-to-specialist transfers for a task branch, then escalate or request human intervention.

3. Detect repeated states.

   Flag a task when the same specialist, objective, and material context recur without new evidence.

4. Require a delta.

   A re-delegation should specify what new information, capability, or authority makes another attempt worthwhile.

5. Define terminal ownership.

   Identify which agent, queue, or human role owns a task when automatic routing cannot resolve it.

A unified event log is essential. Microsoft Agent Framework exposes a typed HandoffSentEvent and a uniform workflow-event stream that preserve source and target breadcrumbs. Whether a team uses that framework or another runtime, equivalent event semantics are valuable: operators need to reconstruct what happened without asking the model to narrate its own history.

Do not use observability only after an incident. Feed it back into runtime controls. A rising rate of rejected handoffs may indicate poor routing instructions, stale capability metadata, or overly broad agent descriptions. Frequent retries from a tool host may indicate an integration contract problem rather than a need for a more verbose prompt.

Build traceability, evaluation, and human control into the control plane

Trustworthy orchestration must answer basic operational questions: Who initiated this action? Which specialist owned the task at each stage? What context and tool results were supplied? Which policy allowed the action? What changed in the external system? Statelessness makes these questions more important because continuity is distributed across explicit records rather than hidden in an open session.

Minimum evidence for each workflow transition

For every material transition, capture immutable or append-only records appropriate to your environment. Link the event to a workflow and task identifier, but avoid indiscriminately duplicating sensitive payloads into logs. Store secure references where full content is not necessary for routine operations.

• The initiating user, service identity, or upstream workflow.

• The source and target specialist or tool host.

• The version of prompts, agent instructions, tool schemas, and policy rules in effect.

• The context references and output references used to make the transition.

• The model recommendation, policy decision, approval decision, and final dispatch result.

• Timing, retries, status changes, and the final disposition.

Evaluation should test the workflow graph, not just answer quality. Create cases where the correct outcome is a handoff, a tool call, a refusal, a clarification request, an approval pause, or a terminal escalation. Test whether the orchestrator supplies the right context, rejects unauthorized paths, prevents duplicate side effects, and produces understandable traces.

Human control is most effective when it is targeted. Put approval gates around high-impact actions, unclear policy interpretation, financial commitments, irreversible updates, and exceptions to normal routing. Give reviewers a compact state summary, the evidence references, the proposed action, and the rationale for escalation rather than a raw transcript with no execution context.

OpenAI’s API guidance advises new agentic systems to use current Agents SDK patterns for tool orchestration, tracing, handoffs, and state management instead of rebuilding all orchestration ad hoc. That guidance reflects a practical lesson: mature workflow concerns deserve first-class runtime primitives. A platform can extend those patterns for enterprise policy and MCP-connected infrastructure, but it should not dismiss tracing and state management as optional features.

Implement a pragmatic rollout for enterprise teams

Teams do not need to begin with an unrestricted network of autonomous specialists. Start with one high-value workflow, a small number of bounded roles, and a limited set of tools. The goal is to prove that the handoff contract, state model, and operational controls work under realistic failures.

1. Map the workflow.

   Identify business outcomes, specialist responsibilities, tool calls, approval points, external side effects, and terminal states.

2. Write contracts first.

   Define task envelopes, tool schemas, output formats, error categories, and lifecycle transitions before optimizing prompts.

3. Choose the state owner.

   Establish a durable orchestration store as the workflow source of truth, with model context treated as a derived view.

4. Constrain the graph.

   Declare permitted specialist edges and tool permissions. Add hop limits, deadlines, idempotency controls, and escalation routes.

5. Instrument every boundary.

   Emit correlation-friendly workflow events for dispatch, handoff, tool execution, approval, retry, and completion.

6. Evaluate adverse paths.

   Simulate unavailable tools, stale context references, rejected approvals, duplicate deliveries, conflicting specialist recommendations, and circular delegation.

7. Expand deliberately.

   Add new specialists and MCP tool hosts only after their contracts, authority boundaries, and operational ownership are clear.

A single control plane is useful here because it can route users to the right specialist, hand off scoped context, run tool-backed workflows, and provide one operational view across providers and protocols. It should not erase the distinct responsibilities of hosts, clients, servers, models, and specialists. Instead, it should coordinate those logical boundaries with shared identifiers, policies, and events.

Model capability still matters. OpenAI’s GPT-5.5 deployment card positions the model for multi-tool, real-world work including coding, online research, information analysis, document and spreadsheet creation, and moving across tools. But stronger multi-tool reasoning increases the need for disciplined orchestration: more capable systems can traverse more of the workflow, so their permissions, state, and evidence need equally mature controls.

Conclusion: Stateless protocols can support durable agent workflows

Stateless APIs and stateless MCP-style tool calls are not barriers to multi-agent systems. They are a constraint that encourages clearer architecture. Treat each call as an explicit operation, preserve task state in a durable control plane, replay only the context that is relevant, and make every transfer accountable through structured contracts and events.

The safest pattern is straightforward: let specialist models apply semantic judgment to bounded work, let tool hosts execute clearly defined capabilities, and let orchestration govern state, policy, lifecycle, and traceability. With directed handoff paths, explicit task handles, standardized tools, loop controls, and human escalation, teams can turn isolated stateless turns into reliable enterprise workflows.