Independent work · Product and program architecture
Designing agents around evidence and control
Product direction for an independently built agentic workflow system, with AI-assisted implementation and explicit human decision points.
THE BRIEF
Agentic workflows need to act efficiently without treating incomplete evidence as permission to proceed.
Architecture walkthrough
Request and coordination
Submitted evidence ↓
Evidence and permission
Missing evidence → human review
Permitted action ↓
Authorized work and review
Normal completion
Validated evidence authorizes bounded execution; verification records the result for human review.
Request
The request establishes the objective, constraints, and evidence that must exist before an action can be authorized.
Representative architecture patterns for the public walkthrough. The diagram explains supported design boundaries; it is not a universal live routing trace.My product role
I set the product goals, workflow boundaries and acceptance criteria for an independent agentic workflow system. AI tools assisted drafting, implementation and verification. My contribution centers on deciding what evidence an action needs, when a person must decide, and how failure should be handled.
The design separates deterministic controls from model reasoning. The manager can route work to specialized capabilities, but the system does not treat a generated plan as permission to create an effect. That boundary makes the design easier to inspect and easier to test.
Evidence before action
An intake layer normalizes the request and identifies the work that is allowed. A manager layer routes the task to specialized capabilities with explicit inputs and outputs. An immutable input contract and digest bind the request to the evidence that was reviewed, so later steps cannot quietly change the basis for a decision.
Validation happens before an effect, and a failed check ends or routes the work instead of silently passing uncertainty downstream. The trade-off is deliberate: a missing input can slow the workflow, but an unsupported action is more expensive to unwind.
Bounded execution and recovery
Work has bounded steps, controlled tool access, and explicit stopping conditions. A fail-closed pause prevents effects when a required safety state is active or unavailable. Costly evaluation requires a validated cost context and a request-bound receipt, which makes spend part of the request contract rather than an after-the-fact estimate.
Correlated actions record attempted, succeeded, failed, or compensated effects. An independent readback checks the result after an effect, with bounded convergence and an explicit failure status when the state cannot be reconciled. This gives a reviewer a usable recovery path without implying that every failure can be fixed automatically.
Three ways to inspect the design
In normal completion, the request is routed, evidence is validated, bounded work completes, and the result is recorded for review. In missing evidence, the system stops at the validation gate and asks for the missing input. In partial failure, the trace preserves the decision context and routes the issue for controlled recovery rather than repeating an unknown action.
The architecture is useful because the hard questions are visible: what was known, what was allowed, which effect was attempted, whether the external state matched the expected result, and who must decide what happens next. That separation protects review quality.
This boundary also keeps implementation honest. A specialist can propose an action, but a deterministic contract and gate decide whether the action is admissible. That makes the system easier to review than a single opaque loop and leaves room for human judgment where the cost of a wrong decision is high.
EVALUATION METHOD
How I evaluate this kind of agentic system
Evidence
I start with what the system can actually read and cite. A response should distinguish a supported answer from a guess, expose the relevant record when the user needs to inspect it, and handle missing or contradictory information honestly.
Permissions
I separate reading from changing state. Before a write, the product should show the target, the exact before-and-after values, and the person or policy that can authorize it. Ambiguity is a reason to clarify, not to select a likely record.
Readback and recovery
After an action, the system should make the resulting state visible and explain what happened. For reversible work, the product should support a reviewable undo or reset path. For irreversible work, it should make the commitment and its consequence clear before approval.
Quality, latency, and cost
I would measure grounded-answer quality, target and mutation accuracy, safe refusal or clarification behavior, successful completion, time to a useful response, end-to-end task time, and cost per completed task. The right thresholds depend on the workflow and risk; they should be established with representative cases and human review.
Example scenarios
- Missing evidence: stop before authorization and ask for the required support.
- Ambiguous target: clarify the intended record instead of guessing.
- Partial failure: preserve the action context, read back the resulting state, and route recovery for review.
Illustrative product criteria only; no model benchmarks, production integrations, or completed user research.
WHAT STAYED WITH ME
“Agent reliability is a product and system-design problem, not a prompt-writing exercise.”
MORE TO EXPLORE
See all work ↗