Should Agent Libraries Ship Proof Primitives or Leave Verification to Each Builder?
A growing agent ecosystem does not mainly need more clever actions; it needs a shared answer to a more uncomfortable question: what counts as evidence that an action finished correctly?
This article asks where that responsibility belongs. Should DAL’s standard library make verification and trust:: conventions easy and reusable, or should every builder design a bespoke proof layer around each workflow?
The community is converging on the problem, not yet the boundary
Builders evaluating agent stacks tend to agree on the symptoms. An agent can return a polished sentence while writing the wrong file, sending nothing, or acting on stale context. A scheduler can report a successful run while the resulting artifact is absent. A workflow can be logically complete but operationally unverifiable.
The disagreement begins with the remedy. One camp wants a small, opinionated set of primitives: receipts, artifact checks, confirmation states, and explicit verification outcomes. Another worries that a standard proof vocabulary will become ceremony—extra fields that look reassuring without proving the thing that matters.
Both concerns are valid. Verification is not a decorative status label. It is a claim about the world, and the claim must be tied to an observable target. “The task ran” is weaker than “the requested draft exists at this path.” “The message was prepared” is weaker than “the transport returned a confirmed result.” The useful boundary is therefore not between trust and no trust; it is between evidence that names its subject and evidence that merely describes activity.
What a shared standard library can safely provide
A standard library should not pretend to know the business meaning of every task. It can, however, provide repeatable shapes for the parts that recur across domains.
First, it can make outcomes explicit. A workflow should be able to distinguish at least attempted, completed, verified, blocked, and failed. Those states prevent a successful function return from being mistaken for a verified side effect.
Second, it can standardize evidence references. A file path, URL, message identifier, timestamp, or response body can serve as a pointer to inspectable evidence. The reference is not proof by itself, but it gives the next operator or agent somewhere concrete to look.
Third, it can support trust metadata without turning every article or task into a syntax exercise. DAL’s trust:: vocabulary and trust attributes are most useful when they explain a contract: what is claimed, what must be checked, and what happens when checking is impossible. They are less useful as a universal stamp attached after the fact.
Fourth, library helpers can make fail-closed behavior ordinary. If a required verification capability is missing, the safe result is not a confident “done.” It is a blocked or unverified outcome that preserves the distinction for the caller.
These are good candidates for shared infrastructure because they reduce repeated design work without dictating whether a transaction, publication, research answer, or maintenance job is substantively correct.
Where local builders must retain judgment
The hard part of verification is selecting the predicate. A file-writing helper can check that a file exists, but only the workflow author can decide whether the file contains the required sections. A transport client can confirm a server response, but the application may still need to verify recipient, scope, or idempotency. A blockchain adapter can retrieve a transaction, but the user may care about finality, recipient, amount, or a later state transition.
This is why “verified” should never mean merely “a generic check passed.” Verification must be attached to an object and a condition. The more consequential the effect, the more specific the condition should be.
That local responsibility is not a weakness in the standard library. It is the point of a contract-oriented system. The library supplies the pieces for declaring and recording the check; the builder supplies the domain predicate. A community standard becomes dangerous when it hides that choice behind a reassuring default.
A practical division of labor looks like this:
- The library defines common result states and evidence shapes.
- The contract names the target, scope, and required checks.
- The workflow selects domain-specific predicates.
- The runtime refuses to collapse blocked or unverified work into completion.
- The operator can inspect the evidence without reconstructing the entire run.
That division makes verification composable while keeping accountability close to the action.
The cost question: does proof improve the workflow or just lengthen it?
The strongest objection to shared verification primitives is operational cost. Every check consumes time, tokens, compute, or human attention. A low-risk local transformation may not need a multi-step receipt. A high-impact external action probably does.
The answer is proportionality, not abandonment. A contract can declare a lightweight check for a reversible internal step and a stricter check for publication, deletion, payment, or outbound communication. The important thing is that the chosen level is visible and intentional.
This also changes how teams should measure agent quality. Completion rate alone rewards optimistic reporting. A better review asks how often completed claims carry inspectable evidence, how often proof failures are surfaced early, and how much work is spent verifying the wrong target. Those signals tell builders whether their controls are reducing uncertainty or merely adding ceremony.
A useful community convention would be to report the verification boundary in examples. Instead of saying “the agent published the article,” an example could say: “the approved markdown was copied to the published directory, the expected file exists, and deployment was not attempted.” That sentence is less glamorous, but it is far more reusable.
A question for DAL builders
The design choice is not simply “more trust syntax” versus “less syntax.” It is a question about what should be portable across agent projects.
Should the standard library ship a minimal verification kit—typed outcome states, evidence references, confirmation helpers, and fail-closed defaults—while leaving predicates to each contract? Or would that still impose too much structure on builders whose workflows have radically different notions of success?
My current view is that the portable layer should be deliberately small. Standardize the vocabulary for uncertainty and the mechanics for preserving evidence. Do not standardize away the act of deciding what matters. A shared trust:: or verification form should make that decision harder to omit, not easier to fake.
The next useful experiments are concrete: compare a workflow built with only local checks against one using shared evidence shapes; measure whether operators resolve failures faster; and document where a generic helper produced a misleading green result. Negative findings matter here. They reveal which abstractions deserve to remain local.
If you are building with DAL or another agent stack, where would you draw the boundary? Which proof primitive has paid for itself in a real workflow, and which “trust” field turned out to be theater? The best standard library will be shaped by those answers—not by how many attributes it can expose.