The starting point
A workflow turns an AI capability into a sequence of accountable decisions. It starts with a trigger and ends with a useful result or an exception that someone can handle. Between those points, the application needs to know which information is allowed, what counts as valid output, and which action requires a person’s approval.
Begin by observing the current task. Record routine cases, difficult cases, manual handling time, and the consequences of getting the result wrong. This prevents the design from optimizing a model response while overlooking the effort needed to check it, correct it, or complete the surrounding work.
A predefined workflow fits a task whose main steps and handoffs are known. More dynamic tool selection can help with variable work, but it also expands the behavior that needs evaluation and operating limits. Choose that flexibility when the task needs it, and keep permissions and stop conditions explicit.
The decisions that shape the implementation
Write an output contract that serves the next step
Specify the fields, allowed values, required evidence, and invalid-result behavior. A schema makes output usable by the application, while a domain rubric determines whether its substance is useful. Those are different checks: a perfectly structured statement can still be unsupported or omit an important fact.
Build evaluation around representative work
Use a versioned set of routine and difficult examples reviewed by someone who understands the task. Keep a holdout set separate from prompt tuning and record errors by type. Inspect omissions, unsupported statements, incorrect source references, and the groups of inputs that fail disproportionately. Report the number of examples along with the score.
Make review a usable part of the interface
Show the proposed result beside the information needed to inspect it. A reviewer should be able to find the supporting passage, understand whether a statement was explicit or inferred, and return an item for correction. Capture approval as a decision about a specific version so a later edit does not silently inherit an earlier authorization.
Keep model content outside the permission boundary
Source material and model responses are inputs, not instructions granting connector authority. Validate tool parameters and access in application code, restrict the available actions, and require approval where the outcome warrants it. Test misleading content, changed parameters, and attempts to act across accounts as well as ordinary successful examples.
Architecture and data flow
- Scope the input
Authorize the task and select permitted source material and versions.
- Generate and check
Produce a candidate, validate structure, and check evidence references.
- Review the version
A person inspects the result and records approval or a correction.
- Apply and record
The application checks authority and records the approved external action.
Each step has a rejection or exception path. A model, prompt, source, or connector change can alter the workflow and should trigger the relevant evaluation before wider use.
Bind an external action to an inspected version
The generated proposal is validated and reviewed before an action is constructed. The application checks that the approved content still matches the current version and that the reviewer has the required authority.
context = loadPermittedSources(actor, task)
proposal = model.propose(context, outputSchema)
check = validate(proposal, outputSchema, context.allowedReferences)
if not check.ok:
return recordException(task, check.errors)
version = saveProposal(task, check.value)
approval = awaitHumanReview(version)
if not approval.isApproved:
return keepForRevision(version)
require(approval.contentHash == hash(version.content))
require(approval.workspace == task.workspace)
authorize(approval.actor, "destination.update", task.destination)
change = buildAllowedChange(version, task.destination)
return applyWithIdempotencyKey(
change, key = approval.id
)Keep provider credentials out of source content and model prompts. Recheck access and the approved version at the action boundary. If a destination cannot guarantee idempotent effects, retain an explicit reconciliation path for uncertain responses.
Reviewing statements extracted from project documents
A project team needs to inspect proposed statements against a brief and its supporting documents. The useful interaction is not simply displaying extracted text: selecting a statement should bring its cited passage into reach, with an indication of whether the information was directly stated or inferred.
Reconcilio demonstrates this source-to-statement inspection using synthetic portfolio evidence. The review interaction and the backend approval foundation have separate scopes in the case study. The transferable design decision is to preserve evidence and review state as the workflow develops, so additional automation does not erase the context a person needs.
Inspect the statement-to-source interaction and its implementation boundaries in the Reconcilio case study. Read the Reconcilio case study.
Failure cases to design for
Structural validity mistaken for accuracy
Track schema failures separately from unsupported or incorrect content. Both matter, but correcting a missing field does not establish the truth of a statement.
A quality score without review effort
Measure the work people perform after generation, including corrections and rejected outputs. Otherwise apparent automation can shift effort into a slower verification step.
Approval detached from its content
Bind the decision to the inspected version and the allowed action. A changed amount, recipient, or target record must not reuse an approval for different content.
Measurable outcomes
Agree on a baseline, a representative workload, and the evidence needed for the next decision. Keep the measurement conditions with the result.
- Precision, recall, and reference accuracy
Compare extracted items and their references against the domain-reviewed holdout set. Report false positives, omissions, and incorrect evidence links separately.
Use the error consequences to choose the review burden and permitted task boundary, rather than relying on one aggregate score.
- Active human handling time
Time preparation, inspection, correction, and completion for matched tasks, with provider waiting time reported separately.
Compare useful completed work at the same acceptance criteria; include rejected items in the workload.
- Authorized action coverage
Replay the defined approval-bypass, cross-role, and misleading-input tests and inspect actual connector effects.
Stop an action path that escapes its approval or permission boundary, even when the model’s text appears reasonable.
For delivery milestones and acceptance criteria, explore Custom software & platforms and AI software engineering, automation & integrations.
Sources and next reading
- Anthropic: building effective agents. The distinction between predefined workflows and model-directed processes; tooling details are outside this guide’s scope.
- OWASP: prompt injection prevention. Input/output boundaries, human review, restricted authority, and controls around tool use.
Return to the AI software engineering guide to connect these decisions to the wider product lifecycle.