Workflow graphs vs agent graphs: who decides what's allowed to happen

The agent hit the deadline. It skipped legal on the way.

A software company asks an AI application to prepare an urgent contract amendment before pricing expires at end of day. The agent can read the current agreement and the customer's redlines, and it can call a pricing service, the contract system and an e-signature service.

It plans well: compare redlines, classify changes, calculate commercial impact, decide which reviews are needed, draft the amendment, send for signature.

One redline changes a data-residency commitment and widens the customer's rights over subcontractors. The agent reads it as a clarification, not a material legal change. That's wrong, but plausible.

The bigger problem comes next. The same classification decides whether legal and privacy review apply. Since the change is "non-material," the agent drops both reviews from its plan, drafts the amendment, calls the contract API and sends it for signature.

Every step succeeds. The plan is coherent. The amendment matches its schema. The service account is allowed to call both APIs. The downstream systems do exactly what they're asked. The trace shows no errors.

Why do agent graphs and workflow graphs look the same?

Because both are boxes and arrows with branches, loops, tool calls and human steps. The difference isn't how they look; it's what each one is authoritative for.

Both can be drawn visually, stored as structured definitions and run across distributed services. Both can be dynamic. Both can include model calls. So the picture doesn't tell you which one you're looking at.

An agent framework's graph is about deliberation: how the agent reads a goal, breaks it down, picks or delegates tasks, gathers evidence, revises its plan and chooses its next action. OWASP describes agents in the same functional terms: they reason, plan, use tools, keep memory and act toward goals.

A governed workflow is about what may happen: which states exist, which transitions are allowed, which contracts apply at each boundary, whose authority is in play, which policies must hold, which writes may commit, which versions stay bound and what evidence must remain.

The split isn't static versus dynamic, visual versus coded, or deterministic versus probabilistic. It's deliberation versus authority. AI moved path selection from development time to runtime, which is exactly why the authority over what those paths may do has to stay fixed and inspectable.

Side by side

Neither column is better. They solve different problems. Things break when one is assumed to cover the other's obligations.

What goes wrong when the two are merged?

The agent ends up writing its own rules: it decides which controls apply, treats tool access as permission, keeps business state in memory and judges its own work before committing it.

OWASP's guidance on excessive agency names three root causes: too much functionality, too many permissions, too much autonomy. Merging the two graphs is how each one gets in.

The planner becomes the policy author. If the agent decides which checks apply, it can remove the checks meant to catch its uncertainty. Policy can use facts the model produced. Whether a control applies shouldn't rest on the same unverified reasoning it exists to check.

Tool access becomes permission. An agent picks from the tools it can see, but seeing isn't being allowed. A tool can be technically callable and still be off-limits for this user, tenant, record, purpose or jurisdiction. Zero-trust guidance is clear that trust isn't implicit and authorization is its own decision.

Working memory becomes the record. Agent memory is good for hypotheses, summaries and plans. It isn't the durable record of a contract, payment or approval. When memory owns business state, retries, long waits and version changes quietly change what the case means. (See agent memory vs application state.)

A generated route becomes the allowed route. A trace shows which steps the agent took. It doesn't prove those were steps the business had allowed.

Delegation inflates authority. A parent agent hands work to a child agent, which calls a service with an application credential, which calls an API. Without carrying who started it and what was delegated, each hop swaps user authority for broader service authority.

The same component judges and commits. Separation of duties exists so no single actor both proposes a high-impact action and certifies that no one else needs to look. That applies to agents too.

Where the line goes

The fix isn't less autonomy. It's putting autonomy where adaptability helps and keeping fixed responsibility where the business owes a durable obligation.

The agent decides:

• which hypothesis to check first and which permitted source to search;
• how to break down an open-ended analysis;
• which approved capability to delegate to;
• whether its answer is good enough, and which plan to propose or revise;
• when to ask for more context or a person's judgment.

The governed workflow decides:

• who is acting, for whom, in which tenant and for what purpose;
• which tools and data sources are eligible for this case;
• the contracts, mappings and business rules each step must meet;
• which policies and approvals apply, and enforcing them;
• durable state, waits, events, deadlines and expiry;
• effect classes, operation IDs, retries, reconciliation and reversals;
• published versions, migrations and evidence.

Four ways to contain agentic behavior

Pick by consequence, reversibility and uncertainty.

1. The agent advises. It gets a typed request and governed context, reasons freely and returns a structured recommendation. It can't write to anything. The workflow validates the output, applies policy and picks the next state. Good for interpretation, investigation, drafting and recommendations.

2. A bounded agentic sub-workflow. Some reasoning needs its own loops, searches and specialists. Run it inside a sub-workflow with declared inputs and outputs, an allowlist of tools and sources, identity and scope carried in, limits on iterations, time, cost and tokens, explicit stop, abstain and escalate outcomes, and no direct path to irreversible actions. Dynamic inside; a governed step from outside.

3. The agent requests; the runtime decides. When an agent may ask for actions, each request enters the runtime as a proposal. The runtime checks the resource, the person and agent, the delegated scope, purpose, policy, typed arguments, effect class and operation ID. The tool runs only after that. (See governing AI agent tool calls.)

4. The agent proposes a plan; the runtime validates it. The most flexible pattern lets the agent produce a plan from approved step types. The plan is data: steps and dependencies, tools and sources needed, assumptions, stop conditions, expected effects and evidence. The runtime checks structure, eligibility, authority, policy, budgets, loop limits and effect rules, then accepts, constrains, sends for review, asks for revision or rejects it.

A plan held as data can be inspected, compared, approved and versioned. Bad steps are rejected without being called. And the record can show three distinct things: what the agent proposed, what the runtime allowed and what actually happened.

Evidence without exposing hidden reasoning

Inspectability doesn't require recording every token the model considered. You need evidence at the control points: the goal and typed request given to the agent; the context and sources it was allowed; the tools it could see; the plan, tool requests and outputs it produced; policy decisions, validations and approvals; the accepted path, the calls actually made and the effects committed; and the model, prompt, workflow and policy versions used. That record is enough to explain and defend the outcome, at design time, at run time and after the run.

Match agent authority to consequence

Common anti-patterns

Ten rules for agents inside governed workflows

1. Let the agent decide what to try; let the workflow decide what's allowed.
2. Never let an agent decide whether its own output needs review.
3. Treat tool visibility and permission as separate questions.
4. Route every agent action through the runtime as a request.
5. Treat plans as data to validate, not instructions to execute.
6. Keep business state out of agent memory.
7. Carry who started the work, and what was delegated, across every hop.
8. Bound agentic sub-workflows with budgets, allowlists and stop conditions.
9. Match agent authority to the consequence of the action.
10. Record what the agent proposed, what was allowed and what happened.

The result: autonomy that composes

Agents widen the range of work software can navigate without every step being planned in advance. That's a real capability, and it isn't the same as authority to redefine the business process while it runs. An agent graph decides how to investigate, plan, delegate and adapt. A governed workflow decides what's permitted, which state lasts, whose authority applies, which controls are mandatory, what may commit and what evidence survives.

Keeping the two apart doesn't make the system less agentic. It makes autonomy composable: agents can change, specialize and improve inside a runtime whose obligations stay stable, inspectable and yours.