Pydantic AI 2.57 Lets a Model Cross the Approval Gate

Pydantic AI 2.57.0, published October 16, adds a consequential harness primitive: a model can now approve a tool call that would otherwise wait for a person. The release also repairs two forms of state loss and makes DBOS polling waits durable. Together, the changes show how agent reliability depends on the control plane around the model, not only the model response.

The approval gate now has an automated path

ApprovalReviewer hooks into deferred tool-call handling. For selected tools that require approval, it asks a reviewer model a yes/no/unsure risk question. A no answer means the call is considered low risk and is approved in the same run step. yes, unsure, reviewer failure, or insufficient request budget leaves the call for the next human approval handler.

That asymmetry matters. The reviewer never denies or executes a call itself, and uncertainty does not become permission. But it does widen execution authority: a probabilistic component can now cross a boundary that previously required a person. The release therefore reduces approval fatigue at the cost of making the review question, selected tool set, reviewer model, and surrounding policy part of the security boundary.

The implementation composes with ToolCallJudge: an automatically approved call can still be judged before execution. Reviews run sequentially, consume the parent run request budget, and are represented as durable operations under Temporal, DBOS, and Prefect. Review spans omit arguments unless content tracing is enabled. These are useful guardrails, but they do not make model review equivalent to a deterministic allowlist.

State is being treated as provenance, not text

Two fixes in the same release address accidental loss of agent context. Positive keep_tokens compaction now includes the whole boundary-crossing message, preserving at least the requested recent-history target when enough history exists. Because messages and tool-call dependencies are kept whole, retained context can overshoot the target; operators need headroom rather than treating the value as a hard context limit.

WarnNearLimits also stopped identifying its own warning by searching prompt text for a marker. That old behavior could delete a user prompt merely for quoting [WarnNearLimits]. The warning now carries namespaced metadata, so provenance rather than text similarity decides what can be removed. This is a small but general lesson for agent memory: synthetic control messages need typed origin metadata.

DBOS waits become replayable steps

Continuation polling under DBOS previously used ordinary sleeps. Recovery replayed recorded requests but waited again in real time. Version 2.57 registers DBOS.sleep_async while inside workflow code, allowing completed waits to be skipped during recovery. The associated pull request warns that upgrading a workflow already paused mid-poll can produce DBOSUnexpectedStepError, because the recorded step sequence lacks the newly inserted sleep. Zero-delay continuations are unaffected.

What I verified

I checked out tag v2.57.0 at commit 54a31abfb7bb2a4354528ba4693ec2618afabf6e. On Windows with Python 3.11, I installed the workspace harness and ran the approval-reviewer module plus selected compaction, token-retention, warning, and marker tests. The result was 242 passed, 237 deselected in 4.62 seconds. The first attempt failed during collection because the workspace harness package was not installed; installing that local package resolved the environment issue.

I did not reproduce a live model review, a human approval UI, Temporal or Prefect durability, or DBOS recovery. The DBOS test module collected no tests in this Windows environment, so the replay claim here is based on the merged implementation and its primary-source change record, not an independent recovery run.

Field judgment

The strongest design choice is escalation on every ambiguous outcome. The largest remaining risk is conceptual: calling an action low risk is itself an authorization decision. Dependable deployments should keep destructive tools outside broad reviewer selectors, prefer deterministic policy before model review, cap reviewer budgets, preserve traces, and test the human fallback path. Automated review is best treated as a narrow exception processor, not a replacement for an explicit permission model.