Agents built on the OpenAI Agents SDK are typically structured as a set of defined agents, each with its own tools and instructions, that can hand a conversation off to one another as a task moves along. That handoff pattern is convenient for building specialized agents that cooperate, and it also means a single user interaction can touch several distinct agents and tool sets before it's done. Securing that pattern well means the enforcement point can't care which specific agent in the handoff chain issued a given tool call, only that the call itself gets evaluated consistently. TELEON works at exactly that level: the tool-call and model-call boundary, reached through the gateway or supported middleware, regardless of which agent definition inside the SDK triggered the call or how many handoffs preceded it.
Handoffs don't change what crosses the boundary
Whether a request stays with a single agent or passes through three handoffs before resolving, each individual tool call still crosses the same boundary as a discrete event: a tool, its parameters, and an identity behind the request. TELEON evaluates that event without needing to track the handoff chain itself. The audit trail can still capture the sequence of calls across the interaction, provided the application passes along enough identifying context to connect them meaningfully.
Policy differences between agents in a handoff chain
Different agents in an SDK-based setup often have different responsibilities, and by extension different acceptable tool usage. A triage agent handing off to a specialized refund agent shouldn't necessarily be subject to the same policy thresholds as the agent it hands off to. TELEON's policy rules can be scoped by identity or agent context passed with each call, letting a team apply different rules to different agents in the chain rather than one uniform policy across a structure that isn't actually uniform in its risk.
Tool definitions still need their own scoping
The SDK's tool definitions determine what an agent can technically attempt. TELEON's enforcement adds a policy layer in front of what's technically possible; it doesn't replace the discipline of defining tools narrowly in the first place. An agent given an overly broad tool because it was convenient to define that way still carries that broad capability into every policy evaluation, and a wide-open tool with a narrow policy rule around it is a worse design than a narrowly-scoped tool from the start.
Teams sometimes define a single, general-purpose tool covering several distinct actions because it's less code to maintain than several narrow ones. That convenience comes at a cost: a single broad tool forces policy rules to do the work of distinguishing between its different possible uses by inspecting parameters closely, rather than letting the tool definition itself carry that distinction. Splitting a broad tool into narrower, purpose-specific ones at the SDK level usually produces cleaner, more reliable policy rules downstream.
Guardrails inside the SDK and policy enforcement outside it
The SDK includes its own mechanisms for constraining agent behavior at the definition level. Those are a different kind of control from TELEON's runtime policy enforcement: one shapes what the agent is built to attempt, the other independently checks each call as it actually happens, regardless of what the agent intended. Relying on either alone leaves a gap; using both gives a team a design-time constraint and a runtime backstop that don't depend on each other to work.
What TELEON doesn't see inside the SDK
Internal agent reasoning, instructions, and the handoff logic that decides which agent should take over next all happen inside the SDK's own execution, upstream of anything reaching TELEON's boundary. If a handoff decision itself is wrong, sending a task to an agent that shouldn't have gotten it, that's not something policy enforcement at the tool-call level will catch, since the actual tool calls that follow might individually look perfectly legitimate.
Catching a bad handoff decision generally requires reviewing the reasoning trace the SDK produces internally, which is a debugging and evaluation concern for the team building the agents rather than something a policy engine watching tool calls can be expected to surface on its own.
Where TELEON fits
TELEON applies policy enforcement and audit recording to tool and model calls from OpenAI Agents SDK-based agents at the gateway or supported middleware boundary, independent of handoff structure or which specific agent definition issued the call. It doesn't control handoff logic, tool definition scope, or the SDK's own guardrail configuration, all of which remain the responsibility of the team building the agents.
A short checklist
- Confirm tool calls from every agent in a handoff chain route through the gateway.
- Pass identifying context with each call so policy and audit records reflect which agent acted.
- Scope policy rules per agent where different agents carry different risk levels.
- Keep tool definitions narrow at the SDK level rather than relying on policy to compensate.
- Use SDK-level guardrails and TELEON's runtime enforcement as complementary, not redundant.
- Treat handoff logic correctness as an application-level concern outside TELEON's visibility.
- Test policy behavior across realistic multi-agent handoff scenarios, not single-agent cases alone.
- Review agent-specific policy rules whenever a new agent is added to a handoff chain.
Handoff-based architectures make an agent system easier to specialize and harder to reason about as a single unit, which is exactly why enforcement that doesn't depend on tracking the handoff chain internally is valuable. TELEON treats every tool call the same way no matter which agent in the chain produced it. Making sure each of those agents was scoped sensibly to begin with is still work that happens inside the SDK, by the team that built it.