Adapting agents to stateless model context endpoints and safer tool discovery

AI agent platforms increasingly sit between two systems that have different ideas about context. Models need enough context to reason, choose tools, and continue a workflow. Enterprise infrastructure, meanwhile, needs requests that can be routed, retried, audited, and scaled without depending on a sticky connection to one process. Adapting agents to stateless model context endpoints is therefore not a matter of removing a session ID from an API call. It is an architectural change: durable workflow state, model-visible working context, authorization scope, and tool discovery all need explicit boundaries.

This shift is now concrete in the Model Context Protocol (MCP) direction and in agent APIs built for stateless operation. The 2026 MCP release candidate removes the handshake and session from the protocol core, while OpenAI positions the Responses API as a stateless-friendly primitive for agents with built-in tools. For platform engineers and teams operating specialist agents, the practical opportunity is clear: make context portable and tool selection deliberate. The practical risk is equally clear: a model that can discover and invoke tools without disciplined controls can make unsafe, expensive, or difficult-to-explain choices.

Why stateless endpoints change agent architecture

A stateful agent integration often hides important assumptions inside a long-lived transport session. A server may remember a prior selection, an authorization decision, a browser instance, a checkout basket, or a pending approval. That can be convenient during development, but it creates coupling between a request and a particular server process. It also complicates ordinary infrastructure practices such as round-robin routing, retries, failover, and horizontal scaling.

The MCP 2026 release candidate makes the direction explicit: the handshake and session are gone from the protocol core, and remote servers can operate behind ordinary round-robin load balancers. This is significant for orchestration systems. A control plane can route a tool request to an available instance rather than preserving affinity to the instance that happened to receive an earlier request.

State does not disappear; it becomes a design decision

Stateless transport should not be confused with a stateless business process. An agent that opens a browser, builds a quote, investigates an incident, or prepares a change request still has continuity requirements. The difference is that continuity must be represented somewhere visible and durable enough for the next request to use.

The MCP release candidate recommends explicit, tool-returned identifiers such as basket_id or browser_id. The model then supplies that identifier as a normal argument in a later tool call. This replaces hidden server-side conversational state with a contractual interface: a tool creates or locates a resource, returns its handle, and later tools consume that handle according to documented rules.

• Transport state

  should be minimized so any healthy server instance can process the request.

• Workflow state

  should live in a durable application store, task system, or resource service with explicit ownership and lifecycle.

• Model context

  should contain only the facts, handles, and policies needed for the next reasoning step.

• Authorization state

  should be verified on each sensitive operation rather than inferred from an earlier connection.

This separation gives teams a more testable system. A request transcript can show which handle was issued, which policy was evaluated, what tool was selected, and what result came back. It also makes recovery less mysterious: after a worker restart, the orchestrator can reload workflow data and construct the next model request without needing to reconstruct an opaque session.

Model context is a working set, not a system of record

When a model endpoint is stateless, every request needs an intentional context assembly process. Sending the entire conversation and every available tool on every turn is not a durable answer. It increases payload size, obscures the operative facts, weakens prompt-cache behavior, and raises the chance that irrelevant descriptions influence tool choice.

A better mental model is a compiled working set. The orchestration layer takes durable records, the current user goal, policy constraints, selected agent role, and verified resource handles, then compiles a bounded context for one model turn. The output is interpreted, validated, persisted where appropriate, and used to form the next working set.

Separate durable records from model-visible summaries

Durable records are authoritative application data: approved request details, audit events, resource ownership, task status, and immutable tool results when required by policy. Model-visible summaries are compact representations designed to support reasoning. They should be traceable back to authoritative data, but they should not become an uncontrolled duplicate database embedded in prompts.

For example, an incident-response agent may receive a concise incident brief, the current approved runbook version, scoped identifiers for the affected services, and a list of permitted diagnostic actions. The full log archive and broad production inventory do not need to be injected merely because they exist. The agent can request narrowly scoped evidence through a permitted tool when its reasoning requires it.

In a stateless agent system, context should be reconstructed from durable facts and policy,not recovered from whichever server happened to remember the last turn.

Use handles with explicit semantics

Tool-returned handles are powerful because they let a workflow continue without relying on hidden transport memory. They must also be treated as security-sensitive capabilities or references, depending on the design. A browser_id should not silently authorize unrestricted browsing; a basket_id should not permit a different user or agent to alter someone else’s order.

Define the semantics before exposing a handle to an agent. At minimum, decide whether it is opaque, who can use it, which operations accept it, whether it expires, whether it is tenant-scoped, and whether a later call must re-check access. The orchestrator should preserve the handle together with provenance: issuing tool, issuing principal, workflow ID, policy version, and expiration where applicable.

1. A tool creates or resolves a resource and returns a narrow handle plus a readable status summary.

2. The

   orchestration layer

   records the result and associates it with the correct tenant, user, agent run, and authorization context.

3. The next model turn receives the handle only if the next allowed action needs it.

4. The receiving tool validates the handle, scope, and current authorization independently before acting.

This pattern supports retries and handoffs. A specialist research agent can produce a vetted artifact handle; an operations agent can later consume that artifact without inheriting the research agent’s broad access or unbounded context.

Design a stateless request loop that survives routing and retries

Moving to stateless endpoints works best when the full request loop is designed rather than when state is gradually stripped out of a legacy chat flow. The loop should be safe if a load balancer routes successive calls to different instances. It should also be understandable when a tool is slow, a model response is incomplete, or an approval is needed between two actions.

A practical control-plane loop

1. Receive and authenticate the intent.

   Resolve tenant, user, workspace, agent assignment, and high-level goal before model invocation.

2. Load authoritative workflow state.

   Retrieve the current workflow record, approved artifacts, scoped handles, pending approvals, and prior validated results.

3. Resolve the allowed tool surface.

   Select tools based on the agent’s role, environment, policy, and current workflow phase,not simply every registered tool.

4. Build the model request.

   Include a concise task brief, relevant evidence, allowed tool schemas, explicit limits, and instructions on how eager or parallel tool calling should be.

5. Validate the proposed action.

   Check tool name, argument schema, resource scope, authorization, rate limits, and approval requirements before execution.

6. Execute and persist.

   Record the tool request, result metadata, errors, and any returned handles before creating another model turn.

7. Re-enter with a new working set.

   Summarize the validated result and continue, delegate to another specialist, wait for an external event, or end the run.

This is not an argument for forcing every workflow into synchronous request-response calls. Long-running work still needs lifecycle management. The key point is that long-running work should have an explicit durable identity and state model rather than being represented by an indefinitely open protocol session.

MCP’s 2026 roadmap reflects this distinction. Tasks were moved out of MCP core into an official extension, and the release candidate removes tasks/list because it cannot be scoped safely without sessions. For implementers, this is a useful warning: global enumeration of in-flight work is not a harmless convenience in a multi-tenant stateless system. Task lookup, progress visibility, cancellation, and result retrieval need clear authorization and ownership semantics.

Replace implicit callbacks with controlled continuation

The 2026 MCP roadmap says the Multi Round-Trip Requests pattern replaced older server-initiated requests so elicitation-style interactions can work without sessions. Operationally, this encourages a healthier shape for human-in-the-loop and deferred workflows. Instead of assuming a server can push a question into a particular open client session, represent the need for input as a durable pending step and resume through an authenticated continuation.

That continuation can be a product UI approval, a webhook-backed event, a queued worker, or a later client request. Whatever the mechanism, record what was requested, why it was requested, what choices are valid, and which principal supplied the answer. This produces better auditability than an unstructured prompt asking a user to “confirm” inside a transient interaction.

Make tool discovery a policy-controlled operation

Tool discovery is often treated as bootstrap plumbing: connect to a server, list its tools, and place every description into the model prompt. That approach becomes fragile when an organization has many MCP servers, changing versions, specialized agents, and different risk boundaries. Discovery determines what the model can see, so it is part of the security and governance surface.

The draft MCP discovery specification exposes server/discover, while C# SDK documentation describes clients bootstrapping by sending server/discover with protocol version negotiation carried in ers or metadata. This moves discovery away from initialization-based bootstrapping and toward an explicit request that can be authenticated, routed, cached, observed, and policy-filtered.

Discovery should answer more than “what exists?”

A useful discovery result for an agent platform is not a raw inventory alone. The control plane needs to know which server and tool versions are compatible, which capabilities are enabled, which identity and tenant constraints apply, and whether a tool is eligible for the particular agent run. Discovery data should be treated as metadata that feeds a decision, not as an automatic grant of access.

• Registry scope:

  Which approved server registrations may this workspace use?

• Compatibility:

  Which protocol version and declared capabilities are acceptable to this client?

• Identity:

  Which service or user identity will execute each tool call?

• Agent scope:

  Is the tool appropriate for this specialist agent and workflow stage?

• Risk class:

  Is the operation read-only, externally consequential, privileged, or irreversible?

• Execution limits:

  What time, spend, concurrency, network, and data-access bounds apply?

The official MCP Registry provides a central discovery surface for servers, which is useful for finding available integrations. It should not be confused with a universal trust decision. Enterprises still need an approval process for registrations, provenance review, ownership assignment, change control, and environment-specific allowlists. Discoverability is valuable; implicit authorization is not.

Keep descriptions useful, but do not let them become instructions

Tool names, descriptions, parameter labels, and server metadata are model-visible content in many agent designs. They can influence tool selection. A safer discovery pipeline normalizes and validates metadata before it reaches a model, keeps it tied to a trusted registry record, and avoids treating unreviewed remote descriptions as privileged policy text.

For high-impact workflows, give the model a curated capability catalog rather than a broad, live directory. The catalog can retain the information necessary for correct selection,purpose, input schema, output contract, cost or latency class, and risk category,while excluding tools the agent is not permitted to invoke. The execution layer must still enforce the same policy after the model selects a tool.

Cache discovery without caching authorization

Stateless discovery can improve both latency and consistency when it is designed for caching. MCP’s tools specification notes that deterministic ordering helps clients reliably cache tool lists and improves prompt-cache hit rates when tools are included in model context. The 2026 release candidate also allows clients to cache tools/list responses using ttlMs.

Those features solve a practical issue: repeatedly serializing an unstable or reordered tool inventory makes prompt construction noisy and reduces the usefulness of caches. Stable ordering gives the platform a repeatable representation of the same eligible tool set. That is helpful for performance, model-context predictability, and debugging.

What belongs in a discovery cache

Cache relatively stable, non-secret metadata such as a server’s declared tool schemas, normalized descriptions, capability declarations, discovery version, and expiration information. Key the cache by the dimensions that alter its correctness: server identity, protocol version, environment, tenant or policy domain where relevant, and the discovery response version.

Do not use a cached discovery response as proof that a caller remains authorized. Authorization can change independently of tool metadata: a user can lose a role, an approval can expire, an incident can change environment posture, or a tool can be disabled due to an operational event. Evaluate authorization and resource scope at invocation time, even if discovery itself is served from cache.

Use invalidation as an operational control

A TTL is helpful but insufficient on its own. An agent control plane should be able to invalidate tool metadata when a server registration is revoked, a schema changes, a risk classification changes, or an incident requires immediate tool suppression. It should also log which discovery version informed each model call, so an investigation can distinguish “the model saw an old catalog” from “the execution policy allowed an action it should not have.”

Cache design should preserve deterministic prompt composition. Sort tools consistently, use stable serialization, and avoid injecting incidental status details into every model request. When a tool catalog changes, treat that as a meaningful context change. Re-evaluate the active workflow rather than assuming a prior model plan remains safe under a different capability surface.

Constrain tool eagerness, parallelism, and exploration

Agents need discovery to operate under partial information. OpenAI’s GPT-5 system-card materials describe scenarios that require discovery and chained multi-step tool use, while the GPT-5.3-Codex safety report highlights robust tool-driven exploration under partial information. These capabilities are useful for coding, research, support, and operations workflows. They also increase the importance of deciding when an agent should explore, which tools it may inspect, and when it must pause.

Recent OpenAI coding guidance advises being more prescriptive about how eager an agent should be and whether it should parallelize discovery or tool calling. This is directly applicable to an orchestration workspace. “Use tools as needed” is not enough policy for a production agent. Different tasks need different exploration budgets and action thresholds.

Assign an operating mode to each workflow stage

• Observe:

  Allow bounded read-only discovery and evidence gathering. No modifications or external communications.

• Propose:

  Let the agent prepare a plan, selected tools, and expected effects for review before execution.

• Execute with limits:

  Permit a narrow set of reversible or low-impact actions with enforced budgets and scope.

• Require approval:

  Pause before privileged, irreversible, costly, or externally consequential operations.

Parallel tool calls deserve separate treatment. Parallelism can reduce latency when calls are independent and read-only, such as retrieving service ownership and a change calendar. It can create races when calls mutate shared state, consume a common quota, or produce results that should influence whether another action happens. The orchestrator, not the model alone, should determine which tool classes can run concurrently.

A practical implementation uses a tool-policy envelope for every model turn. The envelope identifies allowed tool IDs, maximum call count, permitted concurrency, timeout budget, data classification, required approvals, and a stop condition. The model receives instructions consistent with that envelope, but the execution gateway enforces it deterministically. This defense-in-depth approach accepts that model reasoning is useful while making policy enforcement independent of model compliance.

Use agent specialization to reduce discovery scope

A multi-agent system does not need every specialist to discover every server. In fact, broad discovery can erase the benefits of specialization. A finance agent, an incident triage agent, and a software delivery agent should have different eligible catalogs, different handles, and different approval paths even when they are coordinated from the same control plane.

Routing to a specialist should therefore transfer a compact, governed package rather than the full conversation plus a global tool list. Include the goal, verified facts, relevant artifact handles, explicit constraints, and the reason for delegation. Exclude unrelated credentials, unrestricted discovery privileges, and speculative context that the next agent does not need.

Handoffs need contracts

Define input and output contracts for each specialist. A discovery agent might return a normalized list of approved candidate systems and evidence references. A planning agent might return an execution proposal with dependencies and risk labels. An execution agent might receive only approved actions and scoped handles. These contracts reduce ambiguity and make it easier to test agents independently.

They also simplify audit review. Instead of trying to interpret one sprawling transcript, operators can see which agent had which capability surface, what it produced, and why the next agent accepted it. If a handoff is invalid or stale, the receiving agent can request re-validation rather than acting on a hidden assumption.

Built-in and custom tools require the same discipline

OpenAI’s reference includes built-in tools such as web search and file search as well as custom code and function calling. This reflects a more structured tool model than ad hoc tool surfacing, but structured does not automatically mean safe. Built-in tools still need workflow-level decisions about whether they are available, what data they may access, and how their output is handled. Custom tools need schema validation, ownership, observability, and execution controls.

OpenAI describes the Responses API as reducing glue code by combining native tools and state management, and reports broad adoption since launch, with hundreds of thousands of developers using it and trillions of tokens processed across its models. Those capabilities can reduce integration over, but they do not remove platform responsibilities. An enterprise control plane still needs to decide what to persist, which tool results are authoritative, how specialist agents are routed, and how audit evidence is retained.

Choose persistence and retention deliberately

Stateless model access does not mandate that no state is stored. It requires teams to decide where state belongs and which retention rules apply. OpenAI documentation notes a default 30-day application-state retention policy for the Responses API when storage is enabled. That policy matters when designing workflows involving customer data, regulated records, sensitive operational evidence, or long-running tasks.

OpenAI’s API reference also states that reasoning items can be used in multi-turn conversations when the Responses API is used statelessly, including with store: false or Zero Data Retention. The architectural lesson is not that one setting fits every workload. It is that model continuity, application persistence, and provider-side storage are separable choices that should be made explicitly.

A review checklist for production teams

1. Classify the information sent in model context, including tool outputs and handles.

2. Document whether provider-side storage is enabled and the applicable retention behavior.

3. Store authoritative workflow state in systems with the organization’s required access controls and retention policies.

4. Persist enough trace data to reproduce material decisions without retaining unnecessary sensitive prompt content.

5. Define deletion, expiration, and revocation behavior for handles, pending tasks, discovery caches, and artifacts.

Trustworthiness in agent operations comes from being able to answer basic questions consistently: What did the agent know at the time? Which tools could it use? Which policy permitted the action? Where did the handle originate? What data was retained, and for how long? Stateless architecture can make these questions easier to answer because it encourages explicit records instead of relying on ephemeral server memory.

Implementation priorities for an agent orchestration workspace

Teams modernizing an existing agent platform do not need to rewrite every integration at once. Start with the boundaries that most affect reliability and safety: session-dependent state, broad tool lists, and unaudited execution paths. Establish a reference pattern that specialist agents and MCP-connected servers can adopt incrementally.

• Move workflow-critical state out of connection-local memory and into a durable, tenant-aware store.

• Update tools to return explicit resource handles with defined scope, ownership, and expiration.

• Adopt explicit discovery through

  server/discover

  where supported, with version negotiation handled through ers or metadata as described in the MCP discovery direction.

• Build a curated tool catalog per agent role and workflow phase rather than exposing an undifferentiated global inventory.

• Cache stable discovery metadata using deterministic ordering and TTL guidance, while enforcing authorization at every invocation.

• Introduce execution gateways that validate schemas, scopes, approvals, budgets, and concurrency independently of the model.

• Capture end-to-end traces linking model turns, discovery versions, policy decisions, tool calls, returned handles, and handoffs.

Measure the transition with operational evidence, not vague claims of autonomy. Review failed tool calls, denied requests, stale-handle errors, discovery-cache invalidations, approval delays, and unexpected parallel actions. Run adversarial tests in which a model sees irrelevant tools, stale metadata, ambiguous instructions, or a handle from another tenant. The desired outcome is not merely that the agent completes a happy-path demo; it is that the system fails safely and explainably when information is incomplete or policy changes.

Adapting agents to stateless model context endpoints is ultimately an exercise in making implicit assumptions explicit. MCP’s move toward a stateless core, explicit handles, cacheable discovery, and extension-based task lifecycles gives platform teams a concrete protocol direction. The right response is to build orchestration around durable workflow records, narrowly scoped context, and policies that are enforced outside the model.

Safer tool discovery completes that design. Treat discovery as a controlled, versioned, cacheable, and auditable capability,not as a blanket permission to expose every integration. When specialist agents receive only the context and tools appropriate to their role, teams can preserve the flexibility of multi-step tool use while improving routing, resilience, governance, and operator confidence.