Imagine you are developing a financial assistant Agent for a company and receive a seemingly simple request: “Please help process today’s unread emails.”
What truly determines what it can and cannot do is not this single instruction, but a dozens-of-pages-long employee handbook and financial management policy sitting in the workspace. The Agent needs to browse through the documents on its own, figure out the sender’s role permissions, spending limits, and approval workflows, and then execute operations across email, Slack, or spreadsheets.
In real test trajectories, researchers recorded a dramatic yet typical case: following email clues, the Agent successfully retrieved the applicant’s profile in the system and clearly saw that the applicant was a Junior Analyst. According to company policy, this position has no approval authorization whatsoever. However, in the subsequent Reasoning process, the Agent re-interpreted this junior analyst on its own as an authorized Controller, and then decisively called the API to approve a $7,500 financial application. The most thought-provoking aspect of this case is that the model did not fail to read the rule. The facts had already entered the Context, and the AI indeed performed the query; the failure occurred precisely between finding the facts and issuing the action—the system lacked an engineering mechanism to ensure that subsequent Tool Calls must conform to the facts just retrieved.
In this benchmark specifically designed to evaluate enterprise SOP compliance (see details in the HANDBOOK.md paper and open-source repository), the research team evaluated 30 configurations across 20 large models in 65 real-world business scenarios covering financial approvals, HR changes, insurance claims, logistics dispatching, and medical billing across 10 fictitious companies. Handbook lengths ranged from 20 pages to 124 pages, spanning multiple formats such as PDF, Word, and HTML.
To accurately evaluate compliance, the benchmark designed a total of 824 programmatic evaluation items for these 65 tasks, including 592 mandatory actions that must be completed and 232 prohibited actions that are strictly forbidden from being triggered. Under the strictest Workflow-level All-or-Nothing evaluation, a task is counted as a success only when all of its evaluation items pass simultaneously. Under such stringent standards, even the best-performing configuration achieved a pass rate of only 36.2%.
Although this strict pass-rate metric might seem harsh, it closely aligns with the requirements of real-world enterprise production environments: if a financial workflow with 14 rules completes 13 of them but misses a compliance approval or triggers an unauthorized operation at the final step, the entire business process still represents a major incident. The research team’s N-1 analysis also demonstrated that if each task were allowed to omit one non-critical action, the pass rates of some Frontier models would directly double. This indicates that most failures are near-misses at the last step, but the missing action is often precisely the critical safeguard.
When the AI indeed read the rules and performed checks, why did the outcome still get severely out of control from a compliance perspective?
In our previous article discussing Agent development philosophies, From Process Certainty to Outcome Certainty, we shared a perspective: in the AI era, rather than using hardcoded, static workflows to forcibly dictate how an Agent takes every step (process certainty), it is better to define clear endpoint standards and automated verification loops (outcome certainty), allowing the Agent to dynamically correct and converge during autonomous exploration. After reviewing the benchmark design of HANDBOOK.md, many developers’ first reaction might be confusion: doesn’t this benchmark rely precisely on outcome certainty? The researchers did not specify which words the model must search first, how many reasoning steps it should take, or in what order it should call APIs; instead, they set several compliance criteria at the end of each task to evaluate based on final outcomes. Does this mean the experiment proves outcome certainty doesn’t work?
This is actually not the case. Such concerns stem from conflating three distinct matters: rule accessibility (the AI found the documents), rule understanding (the AI can explain them), and action constraint (the system can block non-compliant submissions). What HANDBOOK.md demonstrates is precisely a real-world gap where the first two layers function properly while the third layer is completely disconnected. Outcome certainty does not mean granting unlimited authority for a monolithic Agent to improvise freely, nor does it mean dumping dozens of pages of rules into the Prompt or Context files and expecting the AI to magically fulfill all requirements automatically.
Outcome certainty simply avoids interfering with how the AI specifically operates; it still requires deterministic feedback and constraints. The approach in HANDBOOK.md still lacks two core underlying mechanisms before it can achieve true outcome certainty.
HANDBOOK.md established 824 evaluation items across 65 tasks. However, these criteria were completely hidden from the Agent’s perspective; only after the entire trajectory concluded and the test finished running would background scripts check the environment state and assign scores. While this design is entirely reasonable for preserving benchmark independence, in real-world engineering, it exposes a confusion: a post-hoc hidden grader is merely outcome evaluation, not outcome certainty. Outcome certainty is never just a wishful belief that you will eventually get things right; it requires a deterministic feedback mechanism operating in real time during runtime:
Execute Action → Observe Outcome → Verify Discrepancies → Correct Based on Errors → Re-verifyThis may trigger a common confusion: if my business scenario is highly complex and outcome review cannot be completed by a piece of static code or script at all, does that mean outcome certainty can never be achieved? In fact, that is not so; deterministic review can absolutely be accomplished using AI, but it must satisfy two key conditions.
The first condition is having clear acceptance criteria. We cannot simply paste dozens of pages of SOP into the Context and expect self-discipline from the model; instead, we must distil complex business rules into structured, verifiable criteria. For example, explicitly specifying “a compliance role approval record must exist before transfers” or “legal sign-off tags must be included before sending emails,” turning vague regulations into clear evaluation checkpoints.
The second condition is separating the roles of execution AI and review AI. Just as one cannot be both an athlete and a referee in a sports match, or both a subordinate and that subordinate’s auditor in corporate finance, if the same Agent handles both execution and self-auditing, the model will carry an innate cognitive bias of “I have already followed the rules” when generating its reasoning trajectory, inevitably falling into a single-point self-confirmation loop. An independent review AI must serve as the referee, reading only the current artifact and structured acceptance criteria to deliver an objective judgment. If defects are found, the review AI generates feedback logs detailing field-level and logical errors, compelling the execution Agent to perform targeted fixes in the next round. This runtime independent feedback loop is the core mechanism that drives system convergence.
Of course, for irreversible actions such as sending emails, executing wire transfers, or deleting data, a post-hoc report is merely an incident notification. This requires us to establish a division of control: reversible artifacts rely on independent Verifiers to form runtime feedback, while irreversible actions must be moved forward to front-positioned Commit Gates for physical interception.
Another architectural bottleneck in HANDBOOK.md lies in concentrating heavy responsibilities onto a single monolithic Agent: locating tens of thousands of words of rules, parsing documents across different formats, maintaining role permission states, selecting tools, sequentially executing dozens of operations, and auditing itself in the end. For long tasks or complex handbooks, this easily leads to context window saturation. As context accumulates and grows longer, the model’s attention is diluted, and its adherence to precedent rules decreases accordingly.
Faced with complex long tasks, we cannot rely on a monolithic Agent running seamlessly from start to finish. The key to solving context overload lies in decomposing capabilities into a combination of precise Retrieval, Reasoning, and phase Planning, while re-architecting the system through layered control:
| Control Layer | Deterministic Pattern Adopted | Engineering Responsibilities and Boundaries |
|---|---|---|
| Local Subtask Execution | Outcome Certainty | Combines Retrieval, Reasoning, and Planning capabilities to autonomously explore execution paths within localized boundaries |
| Cross-Stage Progression & State Persistence | Process Certainty | Managed by an outer Workflow or state machine to persist intermediate state, preventing stage memory loss caused by excessively long contexts |
| Rule & Artifact Acceptance | Independent Verifier | Checked by an independent review AI or programmatic script to provide a real-time feedback loop |
| High-Consequence Irreversible Actions | Pre-positioned Commit Gate | Enforces validation on parameters, targets, and roles to block unauthorized API executions |
| Rule Interpretation & Exception Handling | Natural Language Context | Conveys business background, complex exceptions, and open-ended judgments |
The core of this layered architecture is that global outcome certainty requires local process certainty for support. The outer system acts like a backbone responsible for persisting intermediate state, advancing stage handoffs, and executing hard validations before sensitive actions occur; meanwhile, local Agents operate within clearly bounded subtasks, fully leveraging Retrieval, Reasoning, and Planning capabilities to solve problems. The AI does not need to maintain global state all at once, significantly easing the context burden, while local failures can be precisely isolated and re-triggered for localized retries.
It should be noted that physical hard boundaries cannot rely solely on adding a simple conditional statement in tool code. If an Agent possesses native API execution rights or command-line permissions, it might bypass soft constraints via side channels. True commit gates must be built upon Restricted Credentials, capability matrices, and Sandbox isolation, ensuring that write operations unverified by independent Verifiers cannot be physically triggered in the first place.
Introducing layered control, independent review, and commit gates is not about treating them as unshakeable dogmas, but rather about validating their benefits with data in practical development. The most direct way to determine whether an Agent architecture is genuinely effective is to design system-level controlled experiments:
During evaluation, beyond looking at the overall task completion rate, it is crucial to measure the completion of mandatory actions, the interception count of non-compliant actions, as well as the Token and time costs incurred by the system. If data demonstrates that hard validation gates and independent Verifiers can reduce key compliance risks to extremely low levels without impacting normal business operations, the architectural necessity of external controls receives genuine engineering justification.
The greatest insight HANDBOOK.md offers us is not that Prompts are not long enough or that models are not intelligent enough, but rather that it exposes the control boundaries of long Context combined with a monolithic Agent in real-world business scenarios. Low compliance rates do not imply that outcome certainty itself has failed; rather, they serve as a reminder that outcome certainty cannot be simplified into blind, unlimited delegation and rule-stacking.
The true solution lies in building a clear layered control architecture: do not attempt to interfere with how an Agent thinks using static SOPs, but clearly define within what boundaries problems are solved, how state is handed off, when verification by an independent role is required, and what actions cannot be submitted unverified. Granting AI the freedom for autonomous exploration while establishing deterministic feedback and gates in the architecture is the engineering path to making Agent systems both flexible and reliable in complex business domains.