Pydantic AI leans on strong typing: tool arguments and outputs get validated against defined schemas before and after a call, which catches a category of error, a malformed argument, an unexpected type, that other, looser frameworks leave to run time and hope. That's a genuinely useful property, and it's also a different kind of protection than policy enforcement. Type validation confirms a call is well-formed. It says nothing about whether that well-formed call should actually be allowed to happen for this identity, at this time, with these specific parameter values. TELEON's policy enforcement, applied at the gateway or supported middleware boundary, is what evaluates that second question, and it works the same way for Pydantic AI as it does for any other framework's tool calls once they reach that boundary.
Type validation and policy enforcement solve different problems
A tool call that passes Pydantic AI's schema validation is guaranteed to be structurally correct: the right fields, the right types, nothing missing that the schema required. It's not guaranteed to be a call that should be allowed. A refund amount that's a perfectly valid float and well within the schema's constraints can still be well beyond what policy should permit without approval. Running both checks, the framework's own validation and TELEON's policy evaluation, addresses two genuinely separate risks rather than one risk twice.
Well-defined schemas make policy rules easier to write
One underrated benefit of Pydantic AI's approach is that its explicit tool schemas make it easier to write precise policy rules in the first place. When a tool's expected parameters are clearly typed and named, a policy rule referencing a specific parameter, an amount field, an account identifier, has less ambiguity about what it's actually matching against. Frameworks with looser or more dynamic tool argument handling can make writing that kind of precise rule harder simply because the parameter shape isn't as reliably consistent call to call.
What passes validation still needs identity context
Pydantic AI's schema validation happens on the shape of the call, not on who's making it. TELEON's policy evaluation adds the identity dimension: the same well-formed, schema-valid call might be entirely appropriate for one agent or user and require approval for another. Passing accurate identity context alongside each call is what lets policy enforcement make that distinction, since the framework's own validation layer isn't designed to carry or evaluate that information.
Output validation doesn't substitute for output-side policy
Pydantic AI can validate that a tool's output matches an expected schema, which catches malformed or unexpected results coming back from a tool. That's a data-integrity check, not a policy check on what the agent does with that output next. If a valid, well-formed output leads the agent toward a subsequent tool call that itself carries risk, that next call still needs its own policy evaluation at the boundary, independent of whether the output that led to it was schema-valid.
It's easy to conflate the two because both happen close together in the call sequence, but they answer different questions. Schema validation asks whether the data is shaped correctly. Policy enforcement asks whether the resulting action should be allowed. A system that only runs the first check has confirmed the data looks right while leaving the actual decision about whether to proceed entirely unexamined.
Where responsibility for schema design still sits
TELEON doesn't design or review a Pydantic AI application's tool schemas. A schema that's too permissive, accepting a wider range of values than the tool should actually support, creates room for calls that are technically valid but practically risky, and policy rules have to work around that permissiveness rather than fixing it directly. Tightening schemas at the framework level remains a complementary control that the team building the agent should still pursue on its own.
A schema constrained to a sensible value range, an integer amount field bounded to a realistic maximum, for instance, reduces the space of calls a policy rule ever has to consider in the first place. Investing in tighter schemas up front generally makes policy rules simpler to write and easier to reason about later.
Where TELEON fits
TELEON applies policy enforcement and audit recording to Pydantic AI tool and model calls at the gateway or supported middleware boundary, evaluating identity and parameter context that the framework's own type validation doesn't address. It doesn't design or validate tool schemas itself, and it doesn't replace the framework's structural validation of call shape or output format.
A short checklist
- Keep the framework's own schema validation in place; don't treat policy enforcement as a substitute.
- Write policy rules that reference specific typed parameters made clear by well-defined schemas.
- Pass accurate identity context with each call, since schema validation doesn't carry it.
- Add policy evaluation to tool calls that follow a validated output, not just the output itself.
- Tighten overly permissive schemas at the framework level rather than relying on policy alone.
- Test policy rules against the actual parameter shapes the schemas define.
- Review schema design periodically alongside policy rule design, since both affect risk together.
- Treat structural validity and policy approval as two separate, both-necessary checks.
Strong typing and policy enforcement aren't competing approaches, they're complementary ones addressing different failure modes. Pydantic AI's validation makes sure a call is well-formed before it ever reaches TELEON's boundary; TELEON's policy layer decides whether that well-formed call should actually be allowed to proceed. Neither one makes the other unnecessary, and skipping either leaves a real gap the other was built to cover.