Agent Workflow is an Oxymoron

Show Notes

The Contradiction of AI Agent Workflows: Why Your Systems Might Be Breaking

The Agent Workflow Paradox

In this episode of Old School New Tech, host Ran Aroussi explores the inherent contradiction in building AI systems with agent workflows. He argues that combining autonomous agents with predetermined workflows creates complexity and brittleness, making these systems difficult to scale. Ran provides examples that highlight the pitfalls of this approach and advocates for a shift toward giving AI agents context and knowledge to enable reasoning and adaptability within defined guardrails, rather than rigid workflows. This episode is sponsored by Automaze, offering CTO-as-a-Service for startups and businesses.

00:00 Introduction to AI Contradictions
01:31 The Oxymoron of Agent Workflows
02:42 Concrete Example: Financial Service Incident
03:54 Guardrails vs. Workflows
05:24 The Alternative: Context and Knowledge
07:19 Evaluating Your AI Systems
09:19 Conclusion and Final Thoughts

-----

This podcast is sponsored by Automaze, the fractional CTO partner for founders and operators. Whether you’re building a high-tech MVP or modernizing internal ops with AI and automation, Automaze can help you scale without the overhead of a full-time team.

Learn more: automaze.io

Creators and Guests

Host

Ran Aroussi

Building software and AI for companies that can't afford to guess | Automaze •VarOps

What is Old School / New Tech?

Old school thinking meets new tech — an unfiltered podcast, hosted by Ran Aroussi and a co-host you won’t see coming.

​Live every episode. No production lag, no editing. Business, AI, tech, startup ideas, and whatever's worth talking about — through the lens of someone who's been building production systems for 35+ years

Ran: Hey everyone and welcome to
Old School New Tech.

I'm your host, Ran Aroussi, and
today we're exploring a

contradiction I've been thinking
about in how we build AI

systems.

Everywhere I look from startups
to enterprises, I see the same

pattern.

We are building AI agent
workflows, but the more I dig

into this, the more I realize
these two concepts might be

fundamentally at odds.

Agent workflow might actually be
an oxymoron.

Here's what I mean, we're trying
to give autonomous agents

predetermined workflows, but
it's like teaching someone to

think while also giving them a
script for every situation.

As these systems grow and face
more and more edge cases, they

become increasingly complex and
brittle, making them nearly

impossible to scale.

So today I want to explore this
contradiction and discuss how we

might build AI systems that can
actually scale without drowning

in complexity.

But before that, I wanna mention
that this episode is brought to

you by Automaze, a full service
technology partner for startups

and businesses that need more
than just code Automaze's

CTO-as-a-Service, combines
strategy, engineering, and

startup thinking without the
cost or complexity of hiring

full-time CTO or a dev team.

To learn more about how we help
ambitious founders visit

automate.io.

All right, let's dive in.

As I mentioned today, we're
talking about a fundamental

contradiction in how we are
building AI systems.

One that explains why your AI
agents might be breaking or need

constant maintenance.

And as I mentioned, the main
issue is that agent workflow" is

an oxymoron.

I know that sounds abstract, but
it's actually very practical.

This contradiction is why AI
systems that demo beautifully

fall apart in production.

Let me explain what I mean.

A workflow is a predetermined
sequence of steps.

Step one, do this.

Step two, do that.

It's based on the assumption
that we can predict what needs

to happen.

An agent by definition is
supposed to be an autonomous

decision maker.

Something, that can assess
situations and determine

appropriate actions.

These concepts are fundamentally
incompatible.

When you put an agent into a
workflow, 9 times out of 10,

you're not creating
intelligence.

You're creating an expensive
script that happens to use LLM

for some steps.

Let's look at a concrete
example.

A financial service company I
used to consult for, built what

they called an intelligent
incident response agent.

The workflow was
straightforward, detect an

incident, analyze logs, check
the runbook, execute

remediation, update ticket and
notify the team.

One time.

They hit a database timeout
during a regional failover,

something that the workflow
hadn't seen before, and it

caused the logs to be in a
different format due to the

failover.

Their intelligent agent just
stopped.

It couldn't parse the logs so it
couldn't proceed to step three.

The entire incident response
system failed, and they had to

page engineers to handle what
the AI was supposed to manage.

That's not intelligence.

That's following a recipe that
only works when all the

ingredients are available and
exactly as expected.

Now, the immediate objection I
hear is:"Ran, we need control.

We can't just let AI systems
make decisions freely." And that

would be an absolutely valid
objection.

But autonomous does not mean
uncontrolled.

Here's the distinction.

A workflow says:"when you
receive a refund, request first,

check the policy, then calculate
the amount, then process it,

then send confirmation." A
guardrail would say:"never

process refunds over a certain
amount without approval.

Always verify the identity of
the requester and maintain audit

trails." The workflow tries to
specify every action.

The guardrail defines boundaries
within which intelligence can

operate.

Think about human employees.

We don't give them scripts for
every conversation.

We train them, set policies and
trust them to think within those

boundaries.

What happens with workflow based
systems is actually

unpredictable.

I see this everywhere.

You build a workflow and it
works fine until it hits an edge

case, or at least what you think
is an edge case.

So you add a conditional, branch
to handle it.

Then another edge case appears
so you create another branch...

and six months later you have
this complex tree of,

conditionals and exception
handlers, and your simple

workflow now has dozens of
branches and a massive runbook.

And the worst part, it's still
brittle, is just complicated and

brittle.

So what's the alternative?

The way I see it, instead of
giving your agent a workflow,

you give it context and
knowledge.

When an incident occurs, instead
of telling the agent to execute

steps one through six, you
instruct the agent to assess the

situation.

You tell it:"here's the
situation, here's our system

knowledge, here's what we've
learned from past incidents,

here are the boundaries for safe
operations, now go analyze and

respond".

The agent, based on the
incident's information, might

start with logs, or it might
check metrics first if it seems

more relevant.

It might recognize patterns from
previous incidents, but notice

differences that require a
modified approach.

So it's not following a script,
it's actually reasoning through

the problem.

Now let me address some common
concerns.

The first one being"LLMs
hallucinate", and that's true,

but you need to remember that
humans also make mistakes.

The solution is grounding
decisions in knowledge and

setting appropriate boundaries,
not removing all decision making

capabilities.

Another common concern might be:
"it sounds too risky".

And to that I'll respond with a
question:"what's riskier?

A system that adapts to
unexpected situations within

defined safety boundaries, or
one that breaks completely when

reality doesn't match the
script?" Another thing that's

worth mentioning is that
reasoning systems actually

provides better observability
They Can explain why they made

decisions, not just log that
they've executed step three

after step two.

Now moving on, here's how I
recommend you evaluate your

current systems.

Take your most sophisticated AI
workflow and give it something

slightly outside its parameters.

It doesn't have to be widely
different, just 10 to 20% of

unexpected stuff, right?

If it adapts and handles a
situation, you might have actual

intelligence, but if it breaks
errors out or need human

intervention, you have an
automated script-you don't

really have an agent.

At least that's how I see it.

I want to emphasize that this
isn't about abandoning all

structures.

It's about recognizing the
difference between enabling

intelligence and constraining
it.

It's about recognizing the
difference between intelligence

and automations.

Both, by the way, have a place
in a business setting.

Companies need to convert their
procedures from rigid step by

step instructions to
institutional knowledge that

agents can reason over.

They need infrastructure that
supports autonomous decision

making within appropriate
boundaries.

Organizations that understand
this distinction, that build

truly intelligent systems with
guardrails instead of brittle

workflows, will have significant
advantages.

While others are constantly
patching edge cases and

maintaining complex workflows,
these companies will have

systems that adapt, learn, and
handle the unexpected.

So the question really is
straightforward: are you

building systems that can think
or are you building expensive

scripts that break on the
unexpected?" The next time

someone shows you their
intelligent agent workflow, ask

them what happens when reality
doesn't match their flow chart.

The answer tells you whether
they're building intelligence or

automation.

So these are my thoughts on this
topic for today.

I would love to hear what you
think.

So come find me on X and let me
know what you think.

That's it for today.

Thanks for listening, and I'll
see you on the next episode.