Agent Workflow is an Oxymoron

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

-----

🎧 Brought to you by Automaze

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

Transcript

Ran: 0:03

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.