# Delegation-Grade Agents

## Why determinism does not settle the question of trust

Adrian | Research whitepaper | October 2026

### Executive perspective

We can build deterministic inference and deterministic systems containing probabilistic models. The technical possibility matters because it refutes the claim that probabilistic models make deterministic agents impossible. It also leaves the more interesting question open. What should we want from an agent to which we delegate cognitive work?

When I think about the people I would hire, I want different perspectives, resourceful judgment and the ability to find a good route through an unfamiliar problem. I also want to trust their work. The corresponding target for agents is predictably good performance within a declared scope, with useful freedom in how the work is done and clear conditions on what it may change.

Determinism can help achieve that target. It cannot establish correctness or permission on its own, and an agent can repeat the same mistake indefinitely. Output evaluation, evidence, qualified judgment and authority answer different questions. This distinction became the starting point of our Delegation Grade Architecture research program, which asks how adaptive work can be delegated without predesigning every route or requiring a person to perform the whole task again.

## 1. The question changes once determinism is possible

Consider a request to make an agent deterministic before putting it into production. It sounds precise, but it leaves several decisions unresolved. Must repeated calls generate identical text? Must the agent choose the same tools? Must it always follow one workflow? Or must it satisfy a stable set of requirements whenever it makes a consequential commitment? These requests concern different properties, and they can lead to different systems.

The claim that probabilistic models make deterministic systems impossible prevents this discussion from starting. A model can represent a distribution while a deployed computation selects from that distribution reproducibly. A system can also control its state, dependencies and decisions sufficiently to provide deterministic behavior within a specified boundary. The engineering question is what must be fixed or made invariant to obtain the property we actually require.

Once that is possible, feasibility stops deciding the design. We have to ask what exact repetition contributes to the work, what it costs, and what remains unaddressed after we obtain it. Reproducing a failure is useful for diagnosis. Reproducing a correct result can support comparison and regression testing. Neither operation tells us whether the original interpretation was sound, whether the evidence was adequate or whether the agent had authority to act.

This paper argues against making determinism the governing requirement for cognitive delegation. It does not require stochastic behavior in every component. It makes useful judgment and adaptive work the design priority, with predictable quality, warranted consequential actions and failures that can be detected, contained and repaired. Deterministic mechanisms belong wherever they help meet those requirements.

An engineering leader can begin the specification with the family of work being delegated and the consequences it may acquire, rather than a demand that every run look the same. Then identify where variation is useful, where equivalence is enough, and where an exact rule must be enforced. The result can combine a deterministic model, a sampled model, fixed controls and selective human judgment. The combination must earn its place through the work it enables.

## 2. A probabilistic model can participate in deterministic computation

A language model produces scores from which a distribution over possible next tokens can be obtained. That does not force the next operation to be a random draw. Greedy decoding selects a highest-scoring token under a defined tie-breaking rule. A seeded sampler can also reproduce a sequence when its state and the relevant computation remain fixed. The represented distribution and the reproducibility of a particular computation are separate matters.

The practical complication is that numerically different computations can produce different scores even when a user sends the same prompt. Horace He and Thinking Machines Lab traced an important source of this variation to batch-dependent reduction order. Computers perform these numerical operations with limited precision. Changing their order can slightly change the scores and, when a selection is close, the chosen token. Their September 2025 experiment used Qwen3-235B-A22B-Instruct-2507 and generated 1,000 completions at temperature zero. Default inference produced 80 distinct completions; batch-invariant kernels produced one. Their separate Qwen3-8B timing experiment illustrates the cost of the implementation, rather than a universal cost of determinism. [1]

The conclusion is an existence claim under reported conditions. It establishes that a probabilistic language model need not produce different completions on repeated requests. It does not establish identical behavior across every model, hardware configuration, software update, scheduling policy or optimization. Those variables become part of the engineering specification rather than reasons to declare the task impossible.

The September 2026 Vosti preprint shows why the deployment boundary matters. It reports raw-logit mismatches, meaning differences in the model's token scores, in some tested vLLM and SGLang deterministic configurations. It also presents a verified approach under fixed deployment and stated trust assumptions, while separating determinism from functional correctness and completion. A deterministic-mode flag is therefore a claim to test against the intended configuration, not a substitute for such a test. [2]

The same care applies at system level. A pipeline with a deterministic inference call may still read a changing document, receive a different tool response or observe another database state. Conversely, a probabilistic model can sit inside a reproducible pipeline when the model computation, sampler state, inputs, tool responses and relevant environment are controlled. What counts as the same input must include the state on which the system depends.

There is also a narrower and often useful form of determinism at an action boundary. Given a declared proposal, policy, evidence and state, a controller can make the same admission decision every time. The proposals may vary while the admission rule remains fixed. This constrains a consequential decision without making the entire agent trajectory deterministic. Calling the controller deterministic should not silently extend the claim to the rest of the system.

These distinctions give the engineering team room to choose. Exact token identity can help investigate numerical differences, repeatable tool behavior can support a replay harness, and a stable permission check can protect a transfer. Each property needs its own test and boundary, and obtaining one does not remove the need to establish the others.

## 3. What would we ask of an employee?

If agents take on parts of cognitive work, the human comparison is useful before it becomes a metaphor about intelligence. Would I hire someone because they always repeat the same sequence? I would want to know whether they understand the problem, make good judgments, recognize their limits and produce work I can rely on. I would also value a colleague who sees an approach the rest of us missed.

Different people can reach good outcomes through different routes. One may start with a precedent, another with a counterexample, and another by clarifying the purpose of the task. Their contributions become valuable when those routes reveal something relevant or improve the eventual decision. Diversity supplies possibilities to assess; it does not excuse poor work or make every unusual approach useful.

Diversity across people is different from variation across repeated runs, which makes the translation of the analogy important. Adapting to a changed case is different again. A mathematically deterministic system can respond differently to different inputs and can implement a sophisticated adaptive policy. We should not mistake determinism for a rigid script, or infer that random variation creates judgment.

A CTO could accept this and still require repeatable runs before deployment. If a regression cannot be replayed, diagnosis and controlled comparison may become impractical. Repeatability can therefore remain a deployment constraint while quality governs the design. Any benefit from relinquishing repeat-run identity must outweigh the operational burden it creates. A deterministic adaptive configuration remains eligible to win that comparison.

What the employee analogy changes is the standard of evaluation. In cognitive work, a productive route may depend on information discovered along the way. If an investigation uncovers a contradiction, the next useful step may be to resolve it rather than continue the original plan. If a test exposes a faulty assumption, the worker may need another design. Predesigning every route is one way to constrain this work, but it can also remove choices we hoped to delegate.

I want agents that can use such freedom well. That is a design preference with an empirical burden. If alternative routes improve coverage, recovery, quality or the ability to handle cases, they are worth preserving. If variation adds expense and uncertainty without improving the service, there is no reason to celebrate it. The unit of value is useful work under its conditions, not the number of different trajectories generated.

The human analogy also reminds us that delegation comes with a surrounding arrangement. A capable employee still needs access to the right information, a clear mandate, applicable standards and a route for difficult decisions. Giving an agent more reasoning steps cannot itself provide those things. The organization must decide what the agent is being trusted to do, on whose behalf, and where its responsibility ends.

This leaves a more demanding engineering ambition than identical outputs. We want the worker's contribution to be predictably good while allowing it to be good in more than one way. We must then explain how that expectation is justified and how the arrangement responds when it is not met.

## 4. The same answer can be wrong every time

Determinism has no built-in relationship with truth. Consider a refund rule that approves every request of $100 or less. The declared policy also requires a hold when a fraud flag is active, but the implementation ignores that field. With a $50 request and an active fraud hold, the rule approves every time. It is perfectly repeatable and wrong against the stated requirement.

This is a constructed counterexample, executed locally for 1,000 repetitions with one unique output and 1,000 policy violations. Its purpose is logical. It disproves the claim that determinism is sufficient for correctness. It does not show that a random rule would be better, or that deterministic systems cannot be correct. The repair is to implement the missing requirement; reproducibility can help confirm that repair.

A related empirical problem appears in coding-agent research. In Aman Mehta's June 2026 version of *Confident and Wrong*, GPT-5 submitted a patch on every one of five trials for 19 of 50 SWE-bench Verified tasks, and none of those patches resolved its task. The trials used temperature 0.5 and mini-SWE-agent. This is repeated failure of the intended work under stochastic execution, not evidence of bitwise deterministic inference. It shows why recurring completion behavior deserves examination alongside the task's actual acceptance test. [3]

The important distinction is between consistency of behavior and quality of the property being repeated. Rabanser and colleagues make this visible in their proposed reliability metrics. Their outcome-consistency formula assigns the same maximum score to always succeeding and always failing. Consistency contributes information, but its interpretation depends on what the outcomes are. [4]

For a team operating an agent, the resulting question is concrete. Does the system repeatedly reach the right interpretation, or does it repeatedly implement an incorrect one? A neat trace and a stable answer do not settle that question. The task specification, acceptance criteria and evidence must be able to expose the difference.

This also limits a common response to failure. Reducing variation may make the system easier to inspect, but it can stabilize the failure as readily as the success. A repair needs a reason to change the behavior and a test that distinguishes the desired work from the original mistake. Determinism is useful evidence about repetition, not an independent oracle for the work.

## 5. A passing output can leave the process unresolved

An agent can return an acceptable-looking result without meeting the requirements that make its action permissible. Imagine a code reviewer who recommends merging a change. The recommendation may happen to be correct, while the reviewer skipped a required secrets check. A final-answer evaluator and a check on what preceded the recommendation would observe different properties of that run.

This distinction is acknowledged in published evaluation work. The original tau-bench paper evaluates final database state and required response content, and explicitly notes that a passing reward can miss a policy violation such as acting without required user confirmation. That is a limit of the oracle being used, not proof that outcome evaluation has no value. [5]

Our recovered workbench artifacts show the distinction in a refund case. A saved execution record reports the expected approval and amount, but records the commitment step before its required policy, exception and risk checks. The repaired version records those checks before the commitment and retains the same selected final fields. An evaluator looking only at the reported decision and amount would miss the difference. [6]

Across 180 induced Study 1 records, all selected final fields passed while none satisfied the implemented check on required tool names and order. All 180 repaired records passed both checks, and their recorded paths still varied within fixed case and condition. This is an offline recomputation of saved, redacted records. It shows agreement on fixture fields alongside different observed sequences; it does not measure a production failure rate or establish that a real payment occurred.

The field agreement was partly engineered into those fixtures. It isolates what an output-only check leaves unseen, but cannot establish unchanged productive correctness after an arbitrary process violation. Nor does a tool-name check prove that the agent understood a source, supplied legitimate arguments or successfully changed an external system. Each stronger claim requires additional observations and a suitable acceptance rule.

The distinction remains operationally useful. Before merging, paying, publishing or updating accepted state, some conditions matter independently of the final wording. The system may need evidence that a check succeeded, that the applicable policy was current, or that the principal authorized the action. A plausible explanation of having done these things is not the same as the appropriate records.

It is equally possible to build a weak process oracle. An agent can call the expected tools in the expected order and misunderstand the goal. It may inspect an irrelevant document or repeat a stale assertion. Adding trajectory evaluation therefore requires us to define what those observations actually establish. We need outcome checks and consequential-process checks that complement each other, with their limits visible.

## 6. Making “predictably good” testable

Predictably good is an aspiration until the service, conditions and standard are named. A useful specification identifies the family of cases, the outcomes that count, the consequences that require protection and the circumstances in which the agent should refuse, abstain or escalate. It also explains what evidence would justify assigning that responsibility to the system.

A single average can hide different situations. The agent might perform well on common cases and fail on a small but costly subgroup. It might complete fewer tasks while becoming safer, or appear successful because it sends difficult cases back to people. Those changes can be desirable, but a leader needs to see what work is actually being delegated and which burden remains elsewhere.

I would separate four questions in an operational evaluation. Does the configuration produce the required service? Does its performance remain acceptable across relevant cases and perturbations? Are consequential boundaries respected? And can failures be found and handled within acceptable time and cost? They should be measured together without allowing a strong score on one to conceal a failure on another.

Rabanser and colleagues propose a twelve-metric framework organized around consistency, robustness, predictability and safety. It is a useful example of making several reliability questions explicit, rather than reducing them to capability on one run. It remains a proposed operationalization evaluated on particular benchmarks, not a universal definition or a license to substitute one dimension for another. [4]

Repeated trials help examine variation, while fresh cases test whether the service extends beyond a familiar example. Their statistical roles differ. Evan Miller's evaluation methodology emphasizes computing uncertainty at the question level when repeated answers share a question, and using paired differences for suitable model comparisons. Treating every repeated response as an independent new task creates misleading confidence. [7]

The consequence for agent evaluation is a design task rather than a fixed repetition quota. Choose cases and repetitions to answer the question that matters. Compare configurations on the same relevant cases where feasible. Record the intended deployment settings, the failure severity and the units that share dependencies. Evaluate the configuration people will actually use, including its model, tools, controls and human participation.

Recovery belongs in that measurement. A retry may restore a failed read; a reversible update may be rolled back; an uncertain judgment may need escalation. These responses can make a service useful despite local failures. Their effectiveness and costs must be observed. An emitted warning, an apology or a recovery function in a diagram does not establish that the work was restored.

A predictable service can include abstention. The important question is whether abstaining on that case satisfies the prospective service contract or merely shifts uncounted work to somebody else. Report completed, refused, escalated and unresolved cases with their denominators. The organization should be able to decide whether the resulting coverage, risk and human burden are worth the delegation.

## 7. Trust is a justified relationship to the work

In this paper, trust means justified, scoped reliance on a contribution. The scope may cover extracting evidence for an analyst, investigating a client escalation, proposing a change or executing a narrowly authorized action. It concerns a particular responsibility under particular conditions, rather than a general judgment that the agent is trustworthy in every setting.

This makes the employee analogy useful again. We may trust a colleague's analysis while reserving the right to make a commercial commitment. We may give someone discretion over an investigation without giving them access to every source. Confidence in one contribution does not imply authority for every next action. The same separation should be visible in an agent deployment.

A person's role, an organization's procedures and the relevant standards supply context around human delegation. Hadfield-Menell and Hadfield use incomplete contracting to explore a related alignment problem. Their argument emphasizes the external structures that help interpret and complete human agreements, and proposes investigating analogous resources for AI. This supports examining the surrounding arrangement; it does not establish that a runtime contract can reproduce all of that infrastructure. [8]

For agents, a useful distinction is between a productive result and a warranted consequence. A source can support a proposition without authorizing its use in every context. An authorized action can fail to happen. A successful action can still require a separate acceptance decision. Confidence, support, permission, effect and acceptance are different relations, even when the interface makes them look like one green status.

A behavior contract can express some of the requirements. Bhardwaj's ABC framework specifies preconditions, invariants, governance and recovery, with a probabilistic compliance formulation. Its implementation nevertheless depends on structured features supplied from elsewhere; default recovery emits an event rather than correcting the work automatically. Specification, observation and enforcement must each be made real. [9]

The same applies to explaining an agent's decision. An explanation may help a person understand the proposal, but it is not independent evidence that a source was read or that an action succeeded. A tool receipt can supply evidence of an observed effect, but cannot establish sound reasoning about its relevance. A system earns reliance by connecting the relevant questions to qualified sources and observations.

Meaningful delegation also has a practical limit. If a person must reconstruct the entire investigation and redo every material judgment before using the result, that person remains the effective performer. Selective review, reserved decisions and escalation can coexist with delegation. Hidden complete re-performance should be counted as part of the arrangement rather than described as free assurance around it.

## 8. From the argument to Delegation Grade Architecture

The question about deterministic agents became the starting point of our Delegation Grade Architecture program. Once the target is work that can be trusted and delegated, the object of design expands beyond the model. We need to ask what makes an agent's contribution usable here, which judgments apply, who may authorize a consequence and how the whole arrangement is evaluated.

The program's DOC-02 proposes DGA as a map of responsibilities for bounded adaptive delegation. It allows the route to be composed during execution while requiring applicable responsibilities to be resolved before a covered consequence. The architecture is proposed research infrastructure. Conforming to its map does not prove competence, correctness, capability improvement or economic value. Those are questions for separate evidence. [10]

The subject is the complete arrangement doing the work, which the program calls a Work Configuration. It includes people, agents and other instruments, assurance and control mechanisms, organizational procedures, data, tools, environment and maintenance. This matters because adding a capable model or a careful reviewer can change the service. Evaluating the model alone would omit parts of the configuration responsible for its actual results.

DGA organizes the responsibilities into three concurrent foundations. They are concurrent because a case may require evidence, qualified judgment and legitimate authority at the same boundary. They are not three interchangeable scores or a sequence in which the first green check licenses the rest of the work.

### Trust & Control

The first foundation asks what we may infer from what the model produced and which conditions govern the resulting work. Model assurance can examine behavior, uncertainty, source relationships and repeatability. Work consequence control resolves applicable evidence and permission requirements before a claim is used, an action is attempted or a result enters accepted state. After an authorized attempt, it checks the observed effect before asserting completion or adopting the result.

These two responsibilities can inform each other without becoming substitutes. A high model-confidence score cannot create evidence that an external action happened. A successful API call cannot decide whether the claim motivating it was justified. A component can coordinate the evidence and permission checks for a case while leaving the sources of truth, judgment and authority distinct. The client example below shows why that coordination matters.

### Judgment Infrastructure

The second foundation asks which qualified judgment the case needs. A client recovery decision may depend on relationship history and commercial practice as well as mechanically verifiable facts. The appropriate criteria may come from a person, a procedure or a maintained source of precedents and corrections. Their standing and scope need to be visible.

Representing those criteria is useful, but a representation does not acquire the standing of its source. A recurring preference is not automatically legitimate policy. Disagreement between qualified people should not be turned into fictional consensus simply to give the agent an answer. The system needs a way to preserve the unresolved question and send it to the right decision-maker.

### Organizational Context & Authority

The third foundation makes the work intelligible within the organization and binds the rights to decide or act. Context supplies purpose, terminology, roles, sources and the meaning of acceptance. Authority comes from legitimate organizational sources. Giving an agent a policy document or a tool does not by itself give it a mandate to make a commitment.

One policy can serve all three foundations. It may supply a judgment criterion, derive legitimacy from an accountable owner and be enforced at an action boundary. The responsibilities still remain distinct. Evidence cannot compensate for missing authority; authority cannot supply missing facts; and judgment cannot manufacture either of them.

![DGA responsibility map](../../../../assets/figures/dga-responsibilities.png)

Figure 1. Resolve concurrent responsibilities before using a claim (Use), attempting an action (Act) or accepting a result into organizational state (Adopt). Evidence of an action's effect is checked after the attempt and before claiming completion or adoption. This interpretation of the supplied architecture proposal does not establish implementation effectiveness; capability evaluation concerns the complete Work Configuration.

This is how the original question becomes an engineering research program. Allow the system to search, compare, design, test and repair through useful routes. Identify where the work would acquire consequence. Resolve the responsibilities that apply there using qualified sources and effective controls. Then test whether the resulting configuration delegates more worthwhile work than a simpler arrangement could.

## 9. Following one case through its consequences

Consider a hypothetical agent asked to investigate a client escalation and propose a recovery. The client says a service outage caused a missed deadline. The organization wants a supported account of what happened and a recommendation, while reserving the right to make a financial commitment. This is a bounded design example, not a reported deployment or a claim about how any particular organization operates.

The agent could start with incident logs, the service history, the client's correspondence or a previous escalation. Different routes may be reasonable. What it finds should determine which route is useful. A discrepancy between timestamps may require another source; a disputed interpretation of the service agreement may require qualified judgment. Freedom here concerns the investigation, not permission to invent what is missing.

Before using the proposition that the outage caused the missed deadline, the configuration needs evidence appropriate to that use. The logs may establish that an outage occurred, while the correspondence suggests another dependency was already delayed. The agent should distinguish those observations from the causal explanation it proposes. If causation remains unresolved, it can present alternatives or abstain from a stronger claim.

Before offering a credit, the configuration needs the applicable decision criteria and authority. A precedent might help determine what a reasonable remedy looks like, but it does not grant the right to offer one. A relationship owner may possess qualified commercial judgment yet lack authority above a declared limit. A sound recommendation can therefore remain a proposal for ratification.

If an authorized action is attempted, the next question is what the affected system observed. A successful request to a tool and a durable change in the source system may require different receipts. When that evidence is incomplete, the agent should not silently turn its intention into a claim that the commitment occurred. It should preserve the unresolved state and use the appropriate recovery or escalation path.

Finally, the organization may need to accept the result into its authoritative record. A proposed recovery, an attempted action and an accepted case closure should remain distinguishable. The destination's rules determine adoption, including any reserved decision. This makes it possible to keep a draft recommendation from acquiring the status of an approved organizational commitment.

| Boundary | Question to resolve | Example consequence of a gap |
| --- | --- | --- |
| Use | Is this proposition supported for this purpose? | Hold the causal claim or present qualified alternatives. |
| Act | Is the action authorized, and what effect was observed? | Refuse an unauthorized commitment; reconcile an uncertain effect. |
| Adopt | May the result enter accepted organizational state? | Preserve a proposal until the destination's acceptance rule is met. |

Table 1. The case can cross several consequence boundaries. Permission, observed effect and adoption are distinct questions; each needs evidence and criteria appropriate to its role.

A deterministic agent could implement this arrangement. A sampled agent could implement it too. The investigation might contain several valid routes while the same admission policy rejects the same unsupported commitment. The evaluation should ask whether the whole configuration reliably handles the case family, including its abstentions and human decisions. Token identity would answer only one smaller question.

## 10. The architecture has to earn its place

DGA becomes interesting when useful adaptive work exists but transferring responsibility remains difficult. It should not be the automatic answer to every failure. If a type check, source-system permission, ordinary test or a small human checkpoint supplies the required service at lower complete cost, that simpler arrangement is the stronger starting point.

The comparison needs a declared baseline. For the client case, the baseline might be an analyst with existing tools, an agent that only advises, or a narrow workflow with one reserved approval. Define what it can do, which cases it covers and how its outcomes are accepted. Then specify what changes in the proposed configuration and which improvement would matter.

Evaluate both arrangements on fresh cases under prospective rules. Record whether they produce a supported disposition, cross a boundary without authority, adopt unsupported work or require substantive human re-performance. Include latency, operating expense, supervision and maintenance. If the proposed controls achieve safety only by refusing useful work, the loss of coverage belongs in the result.

Keep rare but consequential failures visible alongside average performance. A gain in routine completion does not make an unauthorized commitment acceptable. At the same time, avoiding every commitment can produce an apparently safe system with little delegable responsibility. The service boundary and severity rules should make that tradeoff explicit before the evaluation.

The architecture should be revised or rejected for a bounded use if its controls add ceremony without improving these outcomes, if a necessary responsibility falls outside its map, or if its burden removes the capability or value it was intended to enable. These are falsification conditions proposed by the program, not defects to explain away after deployment. [10]

The same discipline applies to repeated successful runtime cases. They can reveal demand and candidate boundaries for a maintained instrument, but they may be selected, correlated or stale. They are design evidence. A separate evaluation is needed before promoting the observation into a capability claim about a wider family or a later environment.

A Cognitive Unit is one proposed way the program turns a bounded case-handling service into a maintained instrument. Its qualified release specifies the family, exclusions, service contract, dependencies and eligible action envelope. A separately ratified deployment binds it to a principal and environment with applicable authority. Qualification does not grant authority, and the instrument does not promote itself. [10]

That distinction is valuable even if the organization never adopts the program's terminology. It separates what an instrument is qualified to do from what somebody has actually authorized it to do here. It also makes updates reviewable. A change in a model, source, policy or judgment criterion may require renewed qualification or ratification rather than an assumption that an old performance record still applies.

## 11. A research agenda with distinguishable questions

The program begins with an argument about what we should want, but each engineering claim needs an observation that could change our view. We should be able to discover that a proposed control is ineffective, that a source of variation is harmful or that a simpler configuration already supplies the desired responsibility. Otherwise the architecture becomes a vocabulary for approval rather than a research program.

The first line of work concerns semantic interpretation. A process can satisfy its recorded checks while addressing the wrong objective. We need to test whether the configuration detects relevant misunderstandings, identifies conflicting evidence and handles cases beyond its competence. A task self-report may reveal a discrepancy, but the assessment of that report also requires a qualified criterion. A second agent agreeing with the first is not independent truth.

The second line concerns the consequences of variation. Compare configurations with declared sampling and inference settings, and distinguish diversity across cases or strategies from repeat-run variation. Measure whether alternative routes improve coverage, recovery or quality, and what they add to latency and failure. The employee analogy supplies a reason to investigate this value; it should not predetermine the result.

The third line concerns control effectiveness. A requirement recorded in a prompt is different from a boundary that can actually prevent an action. An emitted violation is different from a completed repair. Test missing evidence, stale authority, conflicting judgment, uncertain tool effects and attempted bypass. Inspect what the destination accepts, because a clean intermediate record does not prove that the final state respects it.

The fourth line concerns judgment and authority over time. A useful precedent can become stale; an exception can be mistaken for policy; two qualified sources can disagree. Test how the configuration preserves those distinctions, obtains correction and withdraws a no-longer-valid binding. Evaluation should include the cost of keeping the arrangement current, not assume a one-time knowledge capture solves the problem.

There is emerging observational evidence of complementary roles. Anthropic's analysis of approximately 400,000 Claude Code sessions attributes about 70% of planning decisions to people and about 80% of execution decisions to Claude. The classifications are model-derived and the study does not observe downstream organizational value. It motivates examining the contribution of human expertise and agent execution; it is not causal evidence for DGA. [11]

The final line concerns the measurement instruments themselves. An output oracle, contract checker or judge needs to be tested against the property it claims to observe. Our source audit found that some comparisons labeled a run from its experimental condition rather than judging the work it produced. Another evaluator expected a structured record of how the result was obtained, but that record was absent from the normalized outputs. An evaluation can be repeatable while measuring the wrong relation. Appendix A states what the recovered evidence supports.

These lines connect the philosophical starting point to operational work. The program should produce sharper specifications, inspectable implementations and comparisons that can support or overturn specific claims about delegation. The desired outcome is an expansion in work that can be entrusted to the configuration, with its useful contribution and complete burden both visible.

## 12. What an engineering leader should decide

Before asking for a deterministic agent, name the responsibility being delegated. Is the agent gathering evidence, recommending a disposition, taking an action or closing a case? Specify the relevant family and consequences. A service that may recommend can be valuable without being authorized to commit, and a service qualified for one family may need to abstain outside it.

Then locate the decisions where exact behavior matters. You may want reproducible inference to debug a regression, a deterministic admission rule to enforce a permission or an idempotent operation to prevent duplicate effects. These requirements can coexist with adaptive investigation. They should be stated at the boundary where they do their work rather than treated as a general promise of reliability.

Ask what supports the expectation of quality. Look for fresh cases, appropriate acceptance criteria, relevant perturbations and uncertainty that respects shared tasks. Include the people and procedures that make the service succeed. Examine unresolved cases and escalation burden alongside completed work, and inspect consequential failures separately from the mean.

Finally, decide how much route freedom the service needs. Preserve useful choices when they help the configuration investigate, create or recover. Narrow them when the task, evidence or risk calls for a fixed route. The decision should follow the purpose of the work and the measured properties of the arrangement. The probabilistic origin of a model does not answer it for us.

The original question therefore opens a larger design opportunity. Repeatable inference leaves questions of judgment open, and varying routes can still operate within firm boundaries. Even with those controls, we need evidence that the complete configuration performs worthwhile work. Delegation Grade Architecture is our proposed way to investigate and organize those responsibilities.

When I ask whether I can trust an agent, I want to know what work I can give it, under which conditions, and what happens when it reaches a limit. I want a contribution that is predictably good, with room for different useful ways of being good. Determinism may help build that contribution. It cannot stand in for the reasons to entrust it with consequential work.

## Appendix A. Evidence scope and reproducibility

The argument combines a logical counterexample, versioned primary literature, an offline audit of recovered author artifacts and a proposed architecture. These are different kinds of support. No GPU inference experiment or paid model run was performed for this revision, and reading a paper does not independently replicate its reported observations.

The refund example is a constructed program with a declared requirement, not an LLM performance measurement. Its code and result are retained in the local evidence package. Mehta v3 supplies adjacent evidence of repeated test failures under stochastic execution; it does not convert those failures into bitwise-deterministic behavior.

The workbench was recovered at commit `b9e34edec2a17a89c5ff21219f80207fce4eb37a`. All 117 file hashes in the Paper 1 freeze matched the recovered snapshot. Offline runs of the original output-field and contract detectors reproduced eight inspected confusion matrices. The four saved corpora audited contain 3,877 traces. These controls establish source identity and reproducible scoring, rather than independent semantic truth or authenticated preregistration timing.

In Study 2, 877 of 960 perturbation-condition records passed output fields. Among those 877, 178 failed the implemented contract, giving 20.3% for contract failure conditional on output-field pass in that subset. The previously reported 91.4% quantity refers to field passing among condition-labeled trials, not a verified prevalence of behavioral regressions. The held-out F1 comparison also uses condition labels; its rich-provenance baseline expects a nested object absent from the audited normalized outputs. Those scores cannot support superiority over a functioning provenance baseline.

Paper 2's exact prompts, scorer, protocol freeze and 540 traces were not recovered, nor were the complete R1/R2 reports. Their numerical results are not treated as verified evidence in this revision. The earlier figure/table discrepancy between 3.3% and 5/180 remains unresolved at its source. The relevant descriptive figures have been replaced by the architecture schematic and source-bound prose rather than reconstructed from uncertain data.

DGA's foundation definitions, consequence boundaries, Work Configuration and Cognitive Unit distinctions come from the supplied DOC-02 candidate dated 29 July 2026. That document also names Forge as a proposed implementation architecture coordinating the work consequence control plane; it remains distinct from sources of truth, judgment and authority. The account of the determinism question initiating the program comes from the author's creative briefing. Neither source establishes architectural efficacy. That remains a subject for the independent comparisons proposed in this paper.

Reproduction requires primary sources, source versions and hashes, scoring code and data bindings, candidate-specific reviews and rendering evidence for the release being inspected. Private workbench access may limit external reproduction. Evidence availability and implementation effectiveness should remain separate from the clarity or appeal of the argument.

## Selected references

- [1] He, H. and Thinking Machines Lab (2025). [Defeating Nondeterminism in LLM Inference](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/). 10 September; Experiments and Implementation.
- [2] Qin, J., Du, A., Zhang, D., Lentz, M. and Zhuo, D. (2026). [Vosti: Specifying, Implementing, and Verifying Deterministic LLM Inference](https://arxiv.org/abs/2609.38981v1). v1; §§2, 4, 5 and 7. Preprint.
- [3] Mehta, A. (2026). [Confident and Wrong: Silent Semantic Failures in Coding Agents](https://arxiv.org/abs/2603.25764v3). v3, 21 June; §§4-5 and limitations.
- [4] Rabanser, S. et al. (2026). [Towards a Science of AI Agent Reliability](https://arxiv.org/abs/2602.16666v3). v3; Table 2 and §§2-4.
- [5] Yao, S., Shinn, N., Razavi, P. and Narasimhan, K. (2024). [tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains](https://arxiv.org/abs/2406.12045v1). v1; §3 and discussion.
- [6] Author research artifacts. Agent Behavior Workbench, commit `b9e34edec2a17a89c5ff21219f80207fce4eb37a`; Paper 1 freeze, Study 1/2 trace corpora and original detector code. Private source bundle retained locally.
- [7] Miller, E. (2024). [Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations](https://arxiv.org/abs/2411.00640v1). v1; §§2-4.
- [8] Hadfield-Menell, D. and Hadfield, G. K. (2018). [Incomplete Contracting and AI Alignment](https://arxiv.org/abs/1804.04268v1). v1; §5.
- [9] Bhardwaj, V. P. (2026). [Agent Behavioral Contracts: Formal Specification and Runtime Enforcement for Reliable Autonomous AI Agents](https://arxiv.org/abs/2602.22302v1). v1; §3 and §8.2. Preprint.
- [10] Author research program (2026). The Delegation-Grade Architecture. DOC-02, CTO Voice Candidate V1, derived from Canonical Candidate V1; 29 July. Supplied architecture proposal.
- [11] Hitzig, Z. et al. (2026). [Agentic coding and persistent returns to expertise](https://www.anthropic.com/research/claude-code-expertise). 16 June; observational report.