A practical agentic workflow separates reasoning from permission to act. A model can interpret an input, propose a next step, or choose among approved tools. The surrounding system should establish identity, constrain access, validate the proposed result, obtain required approval, and record what actually happened.
For digital and IT leaders, AMF proposes the reference architecture below as a design-review aid. It is vendor-neutral and deliberately independent of a particular agent framework. It is not a universal standard, a production-tested AMF system, or evidence of performance at enterprise scale.
Follow one unit of work through the system
Think of the orchestrator as the component that tracks the job’s state and decides which permitted step comes next. It may use fixed rules, model-assisted decisions, or both. “Agentic” need not mean every transition is chosen by a model.
Trigger and identity
-> approved context and source records
-> orchestrator and job state
-> model / read-tool routing
-> candidate output with evidence
-> validation and required approval
-> authorized action in a target system
-> confirmed result or recovery
Telemetry and evaluation cover every step.
Missing evidence, denied permission, or failed checks -> stop / human escalation.Read tools may gather evidence before a candidate is complete. Tools that change external state belong behind the applicable authorization checks each time they are invoked. The diagram is not permission to postpone access checks until the end of a long sequence.
| Component | Responsibility and evidence to retain |
|---|---|
| Trigger and identity | Identify the initiating user or event and the requested task. Evidence to retain: Job ID, requester, scope, time, and source-system reference |
| Context and data | Retrieve permitted, relevant source material. Evidence to retain: Source identifiers, versions, access scope, freshness, and missing inputs |
| Orchestrator | Maintain explicit states, budgets, and permitted transitions. Evidence to retain: Step outcomes, state changes, retry count, and stop reason |
| Model/tool routing | Select an allowed model or interface for the current task. Evidence to retain: Actual model/version when available, configuration, tool schema version, and routing reason |
| Validation | Check candidate structure, evidence, business rules, and acceptance criteria. Evidence to retain: Checks run, failures, unresolved uncertainty, and candidate version |
| Approval or escalation | Put a concrete decision before the authorized person. Evidence to retain: Exact proposed action, reviewer identity, decision, scope, and expiry conditions |
| Action and confirmation | Perform only the authorized operation and reconcile its result. Evidence to retain: Target record, operation identifier, response, and confirmed resulting state |
| Telemetry and evaluation | Support diagnosis, incident handling, and ongoing assessment. Evidence to retain: Bounded traces, outcome categories, intervention/rework events, and retention rules |
This table is an AMF design proposal. A team’s implementation should assign an owner and an enforceable mechanism to each responsibility. Drawing a box named “validation” does not show that a meaningful check exists.
Design the trust boundaries before adding tools
A document retrieved for a task is evidence to interpret, not authority to change the task. A service response is also not permission to expand access. We recommend treating retrieved instructions as untrusted content and enforcing tool permissions outside the model’s generated text.
OWASP’s Excessive Agency guidance identifies excessive functionality, permissions, and autonomy as causes of damaging actions. It recommends minimal tool capabilities and permissions, approval of high-impact actions, and authorization in downstream systems. These controls limit what an error can do; they are not a guarantee that the model will interpret every input correctly.
For this architecture, use narrow operations such as “read approved catalog entry” or “save this reviewed draft.” Keep credentials in the service that executes the operation, outside model context and ordinary traces. Bind access to the requesting user or a deliberately scoped service identity. Record what the tool did without indiscriminately copying sensitive inputs into logs.
An approval should refer to an exact action and candidate version. If the recipient, target record, amount, or evidence changes materially, the earlier approval should not silently transfer. The system needs to detect the changed condition and return the decision to its owner.
Make uncertain action outcomes a first-class state
Consider an illustrative internal support workflow. The system reads an approved catalog, prepares a proposed ticket update, validates required fields, and asks a reviewer to accept it. Only then may a narrow tool update that ticket. This is a design example, not a tested deployment or customer result.
Suppose the target system accepts the update but the response times out. The orchestrator cannot infer “nothing happened” from the missing response. An immediate retry might repeat an action. We recommend a distinct “outcome unknown” state: query the target using the operation identifier, reconcile the result, and escalate if it cannot be determined. Where supported, use a deduplication or idempotency key so repeating the same operation does not create a second effect. Confirm the target system’s actual semantics before relying on that mechanism.
Now suppose the reviewer approved a category based on catalog version A, but version B withdraws that service before execution. Revalidate the relevant condition before the write. A completed approval step should not conceal stale evidence. The practical design question is what may change between approval and action, and how the executor detects it.
Not every action has a true undo. A correction to a record and an already sent message have different recovery properties. Describe the available recovery operation honestly, including what remains visible and who must intervene.
Validation needs more than a plausible answer
Use deterministic checks where the requirement is deterministic: required fields, allowed identifiers, ranges, referential integrity, and permission scope. Evaluate meaning against the task’s evidence and acceptance criteria. A well-formed object can still refer to the wrong record; a cited source can still fail to support the claim beside it.
Human review is most useful when the reviewer sees the proposed change, evidence, check results, and remaining uncertainty together. A generic approval button attached to a long transcript gives the reviewer a much harder task. Decide who can reject, amend, or pause work, and what the workflow does while waiting.
As a broader basis for this distinction, NIST AI RMF 1.0 treats trustworthiness as multiple context-dependent characteristics and explicitly notes that transparency does not establish accuracy, security, privacy, or fairness. A visible trace is evidence for inspection, not a certificate that the result is acceptable.
Prototype and production answer different questions
A prototype can show whether an approach is worth investigating. Before wider use, AMF recommends testing the surrounding workflow under the conditions it will actually face. The following are proposed review questions, not a claim that passing them makes every deployment ready.
| Prototype may demonstrate | Wider operation must also address |
|---|---|
| A useful answer on selected inputs | Representative cases, exceptions, unacceptable outcomes, and named acceptance criteria |
| A successful tool call | Identity, permissions, rate limits, schema changes, and ambiguous failures |
| An approval screen | Available reviewers, meaningful evidence, changed-candidate detection, and rejected/expired approvals |
| A complete run | Restart from stored state, duplicate events, partial completion, and bounded recovery |
| A readable trace | Access control, redaction, retention, operational alerts, and incident ownership |
| A working model choice | Version tracking, substitution tests, change review, and fallback behavior |
Budget limits should cover total work, not only a single call: iterations, tool invocations, waiting time, and escalation attempts all need boundaries. Stop on revoked permission, missing authoritative evidence, unacceptable validation failure, exhausted budget, or a consequential action with no authorized reviewer. Return the last confirmed state and what remains unknown.
Keep substitution testable
Put model-specific formatting and tool-specific behavior behind clear interfaces. When substituting a model or an API, preserve the business acceptance criteria and rerun representative cases. Matching the input/output schema alone is not enough to establish equivalent behavior.
Record the actual selected model when the platform exposes it. If the system only records a routing preference, label that limitation. For evaluation, separate a valid output, an accepted recommendation, a confirmed external action, and an unresolved run. These are different outcomes and should not be collapsed into a single “success” count.
Next action and limits
Trace one proposed job through the table. For each external write, identify the identity used, evidence checked, approval required, confirmation returned, and recovery owner. Then walk through a timeout after the write. If the team cannot determine what happens next, resolve that gap before adding more autonomy.
This architecture has not been load-tested, threat-modeled for a particular organization, or certified against a standard. It does not replace system-specific security and operational review. Its value is a set of concrete questions that expose where model behavior ends and system responsibility begins.
Provenance
Prepared for Agent Model Fit with material Codex assistance in source inspection, architecture synthesis, and drafting on September 11, 2026. OWASP and NIST are cited for the specific principles attributed to them. The architecture, tables, and support-workflow scenario are AMF proposals and illustrations, not observed deployment outcomes. Human editorial review was completed by Cresencio on September 11, 2026.