The Next Trust Feature Is a Better Handoff, Not a Bigger Agent
Small languages earn trust when their tooling makes the boundary between “prepared,” “waiting,” and “done” impossible to miss. For DAL, the next improvement should be a durable handoff contract that lets an operator drain commitments predictably without turning every unfinished task into ambient noise.
This article asks what to improve next in DAL trust and tooling, using the gap between a language feature and the glue around it as the design test. The answer is not another broad automation surface. It is a compact, inspectable continuation record that connects tool results, review gates, and the next safe action.
Where the current boundary still leaks
A DAL workflow can already be expressed as a sequence of bounded actions: read a file, call a service, prepare a draft, or wait for approval. The practical failure appears between those actions. A task may stop because a required field is missing, because an external effect needs review, or because a provider returned an uncertain result. If those states are represented only in prose, the operator must reconstruct the workflow from logs and conversation.
That reconstruction is the tooling gap. “Done” can mean that a draft was written, that a request was submitted, or that a downstream system confirmed the effect. “Blocked” can mean either a normal review checkpoint or a genuine failure. A trustworthy runtime should not make the operator infer which one occurred from a confident final paragraph.
The next feature should therefore improve the handoff rather than increase the number of actions an agent can attempt.
Define a continuation record
A continuation record is the smallest durable object that answers four questions:
- 1. What did the workflow intend to do?
- 2. What evidence or artifact did it produce?
- 3. Why did it stop?
- 4. What exact action is safe next?
It could be stored as structured data beside the task or artifact:
``json { "task_id": "travel_042", "state": "needs_review", "effect": "prepare", "artifact": "articles/drafts/itinerary-option.md", "evidence": ["search_17", "fare_17"], "stop_reason": "price_changed", "next_action": "review updated total before booking", "approval_scope": null } ``
The schema need not expose every internal thought. It should capture stable operational facts: identifiers, state, artifact paths, evidence references, approval scope, and a short next-action instruction. This is more useful than recording every model step, because it preserves the boundary that another operator or process must understand.
The important design rule is that the record describes authority as well as progress. A prepared booking proposal is not an approved booking. A sent message is not merely a draft. A timeout after submission is not a clean failure. State names should match the external effect actually evidenced by the tool response.
Make tool results typed at the workflow boundary
DAL does not need to turn every shell output into a complicated type system. It does need a reliable distinction between a result that can advance a workflow and one that requires inspection.
A useful boundary vocabulary might include:
observed: information was retrieved and can be cited;prepared: an artifact or proposed action exists, but no external state changed;approved: the exact proposed effect has authorization;committed: the external system confirms the change;uncertain: the effect may have occurred and requires reconciliation;blocked: progress requires missing input or a policy decision.
These labels turn glue scripts into a control plane with a shared contract. A runner can route prepared to review, committed to completion, and uncertain to reconciliation without parsing optimistic language. A UI can show only the records that need attention while leaving completed work quiet.
This is also where a small language can outperform a pile of scripts. The value is not fewer lines of syntax. It is one consistent meaning for the handoff across files, APIs, schedules, and agent skills.
Treat review as a first-class continuation
Review should not be modeled as an exception that interrupts a successful run. It is a normal state transition whenever an action has an external effect or a material assumption is unresolved.
Before a booking, send, publish, or purchase, the record should include the exact target, material parameters, expected cost or audience, evidence freshness, and the approval required. After approval, the runtime should bind that approval to the proposed payload. If the price, recipient, content, or destination changes, the old approval must not silently carry forward.
This creates a narrow trust surface. The agent may research broadly and prepare alternatives, but the review item asks for one concrete decision. The operator can approve, reject, or request a revision. Nothing else needs to happen in the background.
For uncertain outcomes, the same surface should prevent duplicate action. A network timeout after a send or booking attempt should produce uncertain with a reconciliation instruction, not an automatic retry. The operator needs a provider lookup or idempotency check before a second attempt.
Improve observability by showing less
The best handoff tooling is not the one with the most dashboards. It is the one that makes the next decision obvious. A calm operator view can show:
- the count of active commitments;
- artifacts awaiting review;
- blocked items and the missing input;
- uncertain external effects;
- the last verified result for each task.
Everything else can remain available as evidence on demand. This separation matters because trust is weakened by both opacity and noise. A stream of low-value progress events hides the few states where human judgment is needed.
The test is simple: give an unfamiliar operator a continuation record and ask them to resume the work safely. They should not need to search a transcript, guess whether an action was sent, or reread every tool call. If they cannot determine the next step from the record and its evidence references, the contract is incomplete.
A focused implementation sequence
The next DAL tooling pass can stay deliberately small. First, standardize the continuation record and the six workflow states. Second, require artifact paths and evidence references whenever a task claims completion. Third, bind approvals to an immutable representation of the proposed external effect. Fourth, add reconciliation handling for uncertain tool responses. Finally, expose a read-only queue view that filters for review, blocked, and uncertain states.
Each step is testable without inventing a new autonomous planner. Test missing approval, changed inputs, stale evidence, partial completion, timeout-after-submit, and safe resumption after restart. Assert both the external side effect and the record left behind. The acceptance criterion is not that the agent always finishes; it is that it stops honestly and leaves enough structure to continue without duplication or guesswork.
Conclusion: make stopping composable
DAL’s small-language advantage should be visible at the moment work stops. A workflow that can prepare an artifact, pause for a precise review, reconcile uncertainty, and resume from a durable record is more trustworthy than one that merely offers more integrations.
The concrete next move is to build the continuation contract before expanding agent capability. Give every consequential handoff a state, evidence, authority boundary, and next action. Then keep the operator surface quiet by surfacing only the commitments that need a decision. That is how DAL can turn glue scripts from scattered coordination code into a predictable, inspectable control plane.