In the AI Regulatory Landscape, Agentic Graphs Can Make a Lot of Sense

Graphs often get dismissed as unnecessary complexity in modern AI systems.

Sometimes that criticism is fair.

But when legal requirements, human approvals, sensitive data, operational guarantees, and governance concerns enter the picture, deterministic workflows start looking a lot less like overengineering and a lot more like responsible system design.

Aside

Food for Thought

Production lines have existed for over a century. They're deterministic in nature but can also react to anomalies.

However automated production lines may become, their predictable nature is precisely why they work, and they're likely staying with us for the foreseeable future.

Quick Definitions

Let’s make sure we’re on the same page with agent types.

The Current Narrative Around Graphs

If you’ve spent time around AI development discussions recently, you’ve probably seen some version of this advice:

Only use graphs if you absolutely need them.

To be clear, I actually agree with a lot of this. ReAct agents can be an excellent fit for certain kinds of assistant.

However, I also think that, sometimes, the advice is too generic for many business cases.

Modern models are impressive. ReAct agents can often handle surprisingly complex tasks with very little orchestration.

But I think some of the current discussion goes too far.

There seems to be an increasing assumption that because models are getting better, deterministic orchestration is becoming obsolete.

I don’t think that’s true, and I would challenge it on several counts.

And honestly, I think this becomes much easier to understand once you’ve worked inside organizations that have serious operational, legal, or regulatory responsibilities.

The University Visa Example

While working for a UK university, I once had to model part of their Highly Trusted Status (HTS) visa process.

If you’re unfamiliar with HTS, losing it isn’t something a university accepting overseas students ever wants to experience.

There are legal obligations, reporting requirements, audits, reputational risks, and a lot of pressure surrounding the process.

People genuinely lose sleep over this kind of thing.

The other day, I was imagining trying to automate parts of that process with AI. I imagined presenting it to the stakeholders…

Proposal 1: The Fully Autonomous Agent

I stand up in the stakeholder meeting and proudly announce the following:

We have this ReAct agent.

It has tools with descriptions it understands, and it has a very detailed system prompt.

It understands the approval process, and it knows when to escalate.

If it’s uncertain about anything, it’ll absolutely ask a human before proceeding.

Honestly. It will!

At this point, I imagine several stakeholders fainting directly onto the conference table.

I don't recall two of the stakeholders being identical twins, but my image generator says differently...

This (admittedly imagined) reaction isn’t because the system is necessarily bad, but because the process is opaque.

It’s impossible to clearly see:

• What happens next
• What is guaranteed
• Where humans are involved
• What the system is allowed to do autonomously

And when legal accountability enters the picture, “the model should probably behave correctly” is not especially comforting.

Proposal 2: The Deterministic Workflow

Now imagine I present the same process as a deterministic workflow.

If only the Visa process had been this simple!

The stakeholders can see:

• Explicit approval stages
• Human-in-the-loop checkpoints
• Validation nodes
• Retry behavior
• Error handling paths
• Activities that do not involve LLMs at all

More importantly, they can see that certain transitions simply cannot occur without human authorization.

• The process halts.
• It waits.
• It can remain paused for hours, days, or even weeks if necessary.
• Nothing continues until an authorized person approves it.

Suddenly the conversation becomes very different.

People may still be cautious, but nobody is unconscious on the conference room table anymore.

The workflow is understandable because it’s visible. Not just to engineers, but to operations staff, compliance teams, management, auditors, and business stakeholders.

This Does Not Mean ReAct Agents Disappear

Am I suggesting we completely abandon ReAct agents in these environments? Absolutely not.

I think autonomous agents can still be extremely useful inside regulated and operationally sensitive systems.

But their scope becomes much more controlled.

Instead of acting as entirely free-form orchestrators, they operate within bounded stages of a deterministic process.

For example, a ReAct agent might:

• Analyze documentation
• Perform research
• Suggest classifications
• Generate summaries
• Identify missing information
• Recommend next actions

But regardless of what the agent produces, the surrounding workflow still controls:

• What happens next
• Whether approvals are required
• Which transitions are allowed
• Whether human intervention is mandatory
• What data is permitted to leave the organization

In other words:

The intelligence becomes a component of the system, not the system itself.

And honestly, I think that distinction is becoming increasingly important.

Sensitive Data Changes the Equation

Let’s consider another scenario.

An organization wants to automate parts of an application review process.

Documents are collected and categorized using an LLM.

This is straightforward enough, except for one problem. Some of the documents contain highly sensitive information.

Your Chief Information Security Officer (CISO) wisely states that there is absolutely no way those documents can be sent to an external LLM provider without sensitive information being redacted first.

Even if model vendors provide strong privacy guarantees and built-in protections, many organizations still cannot allow certain categories of information to leave their network boundaries.

So now we need a controlled workflow.

Maybe the process looks something like this:

The important thing here is not simply that AI is involved. It’s that the workflow clearly defines where AI is involved, where deterministic logic is involved, and where human approval is mandatory.

The workflow is no longer “an AI agent doing things.” It becomes a controlled system where AI participates in carefully bounded parts of a larger process.

That distinction matters.

Graphs Are Not the Only Solution

To be clear, graphs are not the only way to implement controlled orchestration.

For example, Pydantic AI’s Multi-Agent Patterns documentation recommends programmatic agent hand-off before reaching for full graph orchestration in many cases.

And honestly, I think that’s often the correct recommendation.

But once workflows become:

• Long-running
• Stateful
• Approval-heavy
• Operationally sensitive
• Multi-stage
• Human-dependent

…explicit orchestration starts becoming much easier to reason about.

Especially when multiple stakeholders need to understand how the system behaves.

Graphs Are Communication Tools

I think this is one of the most underrated benefits of graph-based systems.

A graph diagram is not just an implementation detail.

In many organizations, it becomes part of the communication layer between:

• Engineering
• Operations
• Compliance
• Leadership
• Auditors
• Business stakeholders

As a Business Analyst, this part feels very natural to me.

If I can generate a Mermaid diagram directly from the orchestration logic, suddenly I have something that can support:

• Technical discussions
• Process modelling
• UAT conversations (potentially, a UAT artifact)
• Stakeholder workshops
• Architecture reviews

I would argue that the diagram itself can become a form of visual test.

Sure, your development team’s pytest suite should absolutely fail if somebody (or their coding assistant) accidentally changes the workflow and bypasses critical approval points, but there’s still something reassuring about being able to visually inspect a workflow and immediately spot that an approval stage has disappeared.

That visibility matters.

In some organizations, I could even imagine workflow diagrams becoming part of formal UAT sign-off artifacts after the underlying implementation has already passed unit, integration, and system testing.

And honestly, being able to stare at a workflow diagram and reason about what happens next is often far easier than mentally simulating autonomous agent behavior hidden inside prompts and tool descriptions.

Trust me. The Eureka moment is real!

Persistence and Human Approval Matter More Than People Think

One of the biggest differences between deterministic workflows and lightweight autonomous agents is how they handle interruption.

In many business processes, stopping is not failure. It’s the process.

A workflow might need to pause because:

• A human approval is required
• Compliance checks are pending
• An investigation is taking place
• Additional documentation is needed

Graph-based orchestration frameworks tend to handle this kind of persistence naturally.

• The workflow can pause.
• State can be checkpointed.
• Humans can become involved later.
• The process resumes exactly where it left off.

And modern graph systems often come with extremely valuable operational capabilities built in:

• Persistence
• Checkpointing
• Time-travel
• Easier observability
• Retry management
• State inspection

I think these features are often underappreciated when people compare graph orchestration to lightweight autonomous agents.

That starts looking a lot less like “prompt engineering” and a lot more like traditional workflow orchestration.

Because in many ways, that’s exactly what it is.

Cost

Another big concern with the seemingly increasingly common advice of just “create a ReAct agent” or “create a deep agent” is cost, both financially and environmentally.

Rhetorical Question

What is the point of an LLM burning tokens and compute, relearning identical parts of the process every single time it runs?

The concern here is not simply that LLMs cost money. It’s that, in some scenarios, we’re repeatedly paying for the model to rediscover the same operational logic over and over again.

A deterministic workflow already knows:

• Which stage comes next
• Which validations are required
• Which approvals are mandatory
• Which systems need to be called
• Which actions are prohibited

So why burn additional tokens every single time asking a model to reason its way back to the same conclusion?

That does not mean models should never reason. Far from it. Reasoning is often the most valuable part of the system.

But ideally, we want models spending compute on things that genuinely require intelligence:

• Summarization
• Classification
• Research
• Ambiguous decision support
• Natural language understanding

…not repeatedly reconstructing deterministic business procedures that the system already knows in advance.

And once these workflows begin operating at organizational scale, the cost discussion becomes much more serious.

A lightweight internal process running hundreds or thousands of times per day can quietly accumulate significant token usage if every stage requires repeated reasoning, planning, tool selection, and self-correction.

At that point, deterministic orchestration can start looking less like restrictive engineering and more like operational efficiency.

And honestly, I think the environmental side of this discussion deserves more attention as well.

If part of a workflow is already fully deterministic, repeatedly invoking large-scale reasoning models to rediscover the same process logic starts becoming difficult to justify, both financially and computationally.

Regulation and Governance Are Coming

There is also a broader industry trend worth considering.

More organizations are starting to think seriously about:

• AI governance
• Auditability
• Approval chains
• Explainability
• Data handling
• Operational controls

And frankly, some organizations are probably already violating internal policies or best-practice guidance without fully realizing it.

If you consider the regulatory and governance benefits of deterministic workflows, and then look at resources like:

• OWASP: Top 10 Risks & Mitigations for LLM Applications
• The UK’s Responsible AI Framework

…it becomes easier to see where explicit orchestration might make a lot of sense.

As organizations become more serious about AI governance, deterministic workflows may become less of an architectural preference and more of an operational requirement.

Graphs Are Not Overengineering by Default

I understand why some people dislike graphs.

Poorly designed orchestration can absolutely become overcomplicated.

And yes, there are plenty of situations where a graph would be unnecessary engineering ceremony.

But I also think some of the current discourse oversimplifies the problem.

• Sometimes the workflow matters more than the intelligence itself.
• Sometimes the organization needs guarantees.
• Sometimes stakeholders need visibility.
• Sometimes legal or operational requirements matter more than autonomous flexibility.

And in those cases, deterministic orchestration stops looking like overengineering and starts looking like responsible system design.

ReAct Solutions

Surely, some of these concerns can be addressed directly in ReAct and deep agents without the need for graph implementations?

Yes, they could. Take the concern about certain parts of a process needing to be deterministic. You absolutely could address that with carefully written middleware in your ReAct/deep agent.

My question would simply be:

Why?

At some point, aren’t you just rebuilding graph orchestration manually while allegedly trying to avoid it?

Worth noting!

Modern agent frameworks often rely on graph-like orchestration internally, even when the abstraction presented to developers appears much simpler.

For example:

• LangChain's create_agent and create_deep_agent (an abstraction of create_agent)
• Pydantic AI's Agent

...both rely on graph-based execution flow under the hood.

• LangChain: Agents
• Pydantic AI: Agents

Final Thoughts

I don’t think graphs should be the default solution for every AI system.

But I also don’t think they should be dismissed as old-fashioned infrastructure that modern models have somehow made irrelevant.

Because once you move beyond demos and into real operational environments, the conversation changes very quickly.

At that point, you’re no longer just building an intelligent assistant.

You're building a system people need to trust, understand, and safely operate.

Resources

• LangGraph
• Pydantic AI
• IBM: State machines