← Back

Oct 22, 2026 · AI transformation · Technical guide

AI workflows and agents: tools, state and human approval

Define tasks, authority and completion before combining models and tools, then verify actual outcomes.

AI workflows and agents: tools, state and human approval

Key points

  • Compare a simple fixed workflow before adding autonomy.
  • Enforce authorization in tools and downstream systems.
  • Make parallel work, continuity, unknown outcomes and recovery traceable.

How do agent workflows differ from ordinary automation?

An AI agent workflow lets a model interpret information, select tools and adapt steps based on results. Execution still needs explicit inputs, permission, state and acceptance. Ordinary automation follows predefined rules. Agents can handle more variation but add uncertainty, cost and error propagation. Decide whether dynamic choice is actually necessary rather than turning every process into multiple agents. Anthropic distinguishes workflows following predefined code paths from agents dynamically directing their process, and recommends the simplest workable approach.[S1] Its article flags changes in the tooling landscape; this article uses the architectural distinction, not historical feature lists or concurrency limits. Producing a good answer and reliably completing an external action are separate capabilities.

Scroll the diagram horizontally to read

Human and agent roles with governance boundaries
English labels translated from the original AiTOM technical handbook diagram (11 October 2026), used to illustrate the method. It does not assert that all controls or products are publicly deployed.

Define a task contract before assigning roles and tools

A task card should include objective, scope, input versions, required material, allowed tools, writable areas, output, completion conditions, stop conditions and accountable person. Replace handle this with a concrete deliverable, such as a candidate summary of specified documents with sources and unknowns, without sending it. Every capability should serve the task; unnecessary write or external-action functions should not be enabled in advance. Roles must state work, decisions outside their authority and escalation conditions. A researcher can propose a finding without making it an authoritative company fact. An editor can revise without gaining publication permission. Systems check actual authorization; the model’s reasoning cannot expand scope or change the operating identity.

Make the tool loop explicit and bounded

A basic loop reads the task and state, proposes a step, validates tool and parameters, executes, receives the result, updates state and chooses whether to continue. Distinguish prepared, running, completed, failed, denied and unknown outcomes. A timeout must not be interpreted as proof that nothing happened. Keep traceable task, action and result records without unnecessary confidential text. Bound steps, time, cost and retries. On reaching a limit, return completed work, unfinished work and continuity information. Stopping makes uncertainty manageable. Replanning indefinitely is not progress, and a denied tool must not lead to another identity or an uncontrolled direct write merely to satisfy a completion metric.

Enforce authority outside the model

External files, pages, emails and tool results supply data. A sentence saying publish immediately does not create human approval. OWASP’s excessive-agency guidance identifies excessive functionality, permission and autonomy as risk multipliers, and recommends downstream authorization and human control for consequential actions.[S2] A prompt asking the model to be careful is insufficient. Separate reading, draft editing, formal-data changes and publication capabilities. Where approval is required, bind it to a concrete content version, action, destination and validity conditions, rechecking applicability after changes. The organization’s policy and risk determine which actions need individual confirmation. A general source recommendation is not automatically a universal policy for every business.

Use multiple agents when the work can be separated

Parallel work is useful when inputs are independent, outputs differ and integration points are clear, such as separate research topics or non-overlapping documents. An integrator should serialize shared configuration, authoritative records and version state. Concurrent editing of the same area needs conflict detection, versioning and merge rules; separate conversations alone do not isolate writes. A delegation needs the task, scope, essential context, sources, output contract and prohibited changes. Verify the artifact rather than accepting the agent’s completion statement. Every extra agent also adds context, tools and review cost. Highly dependent subtasks or repeated clarification may be clearer in one sequential workflow. Agent count is not evidence of maturity or efficiency.

Keep continuity outside a private conversation

Record the goal, completed work, evidence, open questions, authorized scope, next action and important versions in readable, versioned state. Model context is only the material visible for the current run, not a promise of permanent recall. Keep long-term rules, formal knowledge, project state and temporary results under distinct responsibilities, assembling relevant context for each task. Test continuity with a new session or another operator using permitted records. If they still need private chat to discover the status, the handoff is incomplete. Unknown-origin memory does not become a rule or formal fact automatically. Reflection can propose improvements, but cannot silently expand permissions or redefine acceptance without appropriate testing and confirmation.

Illustrative scenario: separate research, editing and publication

Imagine updating a service article. A research agent reads specified material and proposes claims with evidence. An editor organizes confirmed material into a candidate. An integrator reviews differences and limits. Publication follows existing authorization for a concrete version and retains a result receipt. An instruction inside a research file to delete an old draft does not authorize deletion. If the publishing tool times out, first inspect whether that version exists at the destination instead of immediately resending. If the result cannot be established, report it as unknown. This hypothetical flow is not a claim of an operating round-the-clock agent factory. Defined roles and diagrams differ from implemented permissions, scheduling, monitoring and recovery.

Verify the outcome rather than the completion claim

Anthropic’s evaluation guidance distinguishes tasks, repeated trials, graders, traces and the final state of the environment: saying complete is not the same as the outcome existing.[S3] Check files, data state, URLs or receipts and whether actions stayed within scope. Combine code checks, expert review and calibrated model grading where appropriate, rather than relying on self-assessment. Include ordinary work, missing data, denial, injection, conflicts, tool failure, unknown outcomes and interrupted continuity. Retain success, error types, unauthorized attempts, cost and waiting across trials rather than selecting the best run. Specifications, sandbox exercises, product validation and live operation need separate statuses. A smooth demonstration does not complete untested capabilities.

Frequently asked questions: autonomy, scale and learning

Must an agent be fully autonomous? No. It can read, organize and propose while consequential decisions remain with the appropriate role. Autonomy follows authorization and evidence. Is parallel work always faster? Independent work may reduce waiting, while integration, duplicated context and review add cost. Measure the whole task rather than counting agents. Can an agent upgrade its own rules? It can propose a change with failure evidence. Formal changes still need appropriate tests, versions and confirmation. A system should not remove failed cases or broaden permissions merely to pass its own evaluation. Traceable learning, rather than unreviewed self-modification, supports improvement.

Sources and evidence boundaries

  1. S1 · Building effective agents

    Anthropic · Accessed 2026-10-22

    Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

  2. S2 · LLM06:2025 Excessive Agency

    OWASP Gen AI Security Project · Accessed 2026-10-22

    Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

  3. S3 · Demystifying evals for AI agents

    Anthropic · Accessed 2026-10-22

    Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

Related practical guides

Explore the capability areas

Explore related capabilities and practical guides.

Search AiTOM

135 pages found

Learn more