OpenAI Agents SDK Agents-as-Tools vs Handoffs: Which Pattern Exposes Less Customer Data Under Reg S-P

How each pattern moves context, inputs and outputs

In the agents-as-tools pattern, a manager agent keeps control of the interaction. It calls specialist agents the way it calls any other tool, with an input it chooses, and receives an output it then incorporates into its own response. The specialist does not own the conversation. What it sees is whatever the manager puts in the tool input, plus any shared context object you configure.

In the handoff pattern, control moves. The receiving agent takes over the conversation, and conversation context transfers with it. The receiving agent then responds to the customer directly and may call its own tools. A handoff input filter is the mechanism for narrowing what transfers. Without one, a sound planning assumption is that the receiving agent can see what the prior agent saw.

These are different data contracts. Agents-as-tools is closer to a function signature: a defined input and a returned result. A handoff is closer to a transfer of the whole case file. That difference is a starting point for analysis, not a verdict, because both contracts can be widened or narrowed by configuration.

Comparing the patterns on customer data exposure

Use the same criteria for both patterns, and score your actual configuration rather than the pattern name. The table summarizes how each pattern typically behaves before you add controls.

• Context scope at transfer: Agents-as-tools: the manager defines the specialist's input. Handoffs: conversation context transfers unless an input filter narrows it.
• Who holds the full record: Agents-as-tools: the manager sees the whole interaction and concentrates exposure there. Handoffs: the receiving agent can hold the full record after transfer.
• Downstream tool reach: Agents-as-tools: specialist tools are reached through the manager's scoped call. Handoffs: the receiving agent calls its own tools with the context it holds.
• Output handling: Agents-as-tools: returned output passes through the manager and can be checked before reuse. Handoffs: output goes to the customer from the receiving agent.
• Persistence and shared state: Both: memory or context objects readable by several agents create exposure paths that depend on configuration.
• Task continuity: Agents-as-tools: less context for the specialist, so more design effort. Handoffs: richer continuity, with more data in play.

Exposure is a design outcome, not a pattern property

A manager that forwards the entire conversation as a tool input recreates the exposure of an unfiltered handoff. A handoff with a tight input filter, a narrow tool set and no shared memory can expose very little. The levers that matter are the same in both patterns: handoff input filters, structured tool inputs, context objects, per-agent tool permissions, and where state persists across sessions.

General agent models describe tools as the path between an agent and its environment, including external APIs and file systems, and note that memory can persist across sessions and agents can collaborate in multi-agent systems. Every tool call is therefore a point where customer data can leave the model context, and shared memory is a path by which one agent's data becomes visible to another.

Reg S-P adds scope considerations. The 2024 amendments apply the safeguards and disposal rules to nonpublic personal information a covered institution collects about its own customers and to information it receives from another financial institution about that institution's customers. Your data inventory for each agent should cover both sources. Short-lived, attenuated credentials for downstream agents and tools are a further way to limit what a delegated agent can reach.

Where policy can be enforced in each pattern

Runtime policy acts on individual interactions and tool calls. In agents-as-tools, the useful points are the manager's call to a specialist, the specialist's own model calls and tool calls, and the output returned to the manager. In handoffs, they are the receiving agent's first model call after transfer, each of its tool calls, and its responses to the customer. At each point the decision options are the same: allow, redact, block, or escalate for human approval.

Redaction fits fields a downstream step does not need, such as account identifiers sent to a summarization specialist. Blocking fits a tool call that would send customer data to an API outside the approved set. Escalation fits calls that are legitimate but high-consequence, where a person should approve before execution.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Enforcement happens at runtime, not reviewed after the fact, and each decision produces audit-ready evidence. This does not cover transaction-level governance or end-to-end tracing of a multi-agent workflow, so your design documentation still has to describe the overall flow.

A decision framework rather than a single answer

Start with the data. If a task needs only a few fields and returns a bounded result, agents-as-tools fits well, because the specialist's input is explicit and the manager can inspect what comes back. If the task needs sustained, multi-turn interaction with the customer under a specialist's control, a handoff fits better, and the design effort goes into filtering what transfers and limiting the receiving agent's tools.

Then weigh the trade-off. Minimizing the data passed between agents reduces exposure but can reduce task continuity and specialist accuracy, and the manager in agents-as-tools becomes a concentration point that needs its own scoping and policy. Handoffs reduce re-explanation but widen what a downstream agent can see.

Finally, treat the pattern choice as secondary to controls. Whichever you select, define the data each agent may receive, restrict tool permissions, enforce policy at runtime on interactions and tool calls, and keep evidence that shows what happened. Supervisory conclusions about compliance should rest on that combination, since no pattern or single control ensures compliance alone. Regulatory details are stated as of November 2026.