Why most of the agents are just flowcharts in disguise, and what to build instead.I wrote most of this at an airport several months ago and then left it in drafts. The noise has only gotten louder since, so here it is.A few months ago, on our way back from a client workshop, we were discussing the scope of what constitutes Agentic AI and all of us quoted examples from our experience. There was a discussion on why automation can’t solve it and how most of the agentic AI use cases are nothing but glorified automation. The question was, “Give me one real use case for an agent. Not a demo. Not automation. A real one. Because everything I have seen so far, I could have built with a workflow engine and a model call.”We all had been in agentic AI conversations for months at that point. We had architected these systems. We had pitched them. And still, sitting there with a tea and twenty minutes at our hand to spend, we had to think long enough to give an example that survived thirty seconds of scrutiny.That bothered me enough to write it down.The test I reached for firstMy instinct was to define agentic by the shape of the work.Does the task require the system to make decisions mid-execution that could not have been anticipated at the start? If yes, agent. If no, automation.I thought of an example from aviation maintenance, because that is where I had spent the previous six months.An A320 aircraft lands with an ECAM warning, AIR PACK 1 FAULT.What automation does: triggers a checklist, notifies the duty engineer, maybe pulls the MEL reference. Done.What traditional ML does: predicts probability of component failure from historical fault patterns, produces a confidence score. The engineer still decides.What I think an agent would do: it starts with the ECAM(a message in the cockpit systems of the aircraft) message, queries the CFDS(a centralised fault display system)for fault history and finds Pack 1 has thrown the same fault three times in six weeks. That changes the picture, so it pulls the TSM (troubleshooting manual) identifies four candidate root causes. It checks AMOS(a database used in aviation all over the world) for parts on hand and finds that two of those four need a Flow Control Valve, which is not at that station. It then checks which causes are deferrable under MEL(minimum equipment list, the minimum an aircraft needs to have to be air worthy), finds one deferrable under Category C(one of many categories)for ten days, looks at the aircraft’s next ten rotations to understand the operational cost of deferring, and drafts a recommendation: defer under Cat C, order the FCV(valve) for arrival before day eight, flag for deep inspection at the next base maintenance slot.Nobody pre-programmed that decision tree. The plan emerged from the process rather than preceding it.I still was not convinced with myself. And on reflection, I believe, I was right.Why that example failsBecause you can draw that flowchart.CFDS, then TSM, then AMOS, then MEL, then rotations. It is a complicated flowchart with branches, but a competent engineer could have specified it in advance. Complexity is not the same as open-endedness. A tree with two hundred branches is still a tree.This is the mistake almost every agentic pitch deck makes, mine included. We show something intricate and expect the intricacy to be self-evidently agentic. It is not. Intricacy is just a bigger flowchart, and flowcharts have a technology already, and it is cheaper, faster and far more reliable than any LLM you will put in that slot.So where is the actual line?Known unknowns versus unknown unknownsHere is the distinction I have settled on, and it is narrower than most people in this market are willing to admit.Automation handles known unknowns. You do not know whether the part is in stock, but you know that stock is a thing you need to check.Agents handle unknown unknowns. You do not know what you need to check, and you will only find out by looking.Take a use case that genuinely breaks automation: due diligence on an acquisition. The instruction is one line. Identify material risks in this target.No one can draw that flowchart upfront. The agent reads three thousand pages of contracts and notices an unusual indemnity clause in a supplier agreement. That clause references a regulatory filing, so it goes and fetches the filing. The filing hints at an informal environmental inquiry that appears nowhere in the data room. It then goes looking through news archives and court records to size the exposure and surfaces it as a risk that was never on anyone’s checklist.Nobody knew to look for that. The agent found a thread and pulled it. You cannot enumerate what you do not know exists.A second one, closer to the consumer world. A brand has a moisturiser generating complaints. Sentiment analysis flags them and a rule routes them to a team. Fine, that is automation and it works.The agentic version notices that the complaints cluster in humid climates, in summer months, and disproportionately from one retail chain. Nobody asked it to look at that intersection. It hypothesises a cold chain or formulation stability issue, pulls batch numbers, cross references manufacturing and logistics logs, and raises a possible recall exposure before a human has connected any of those dots.That property, where discovery changes direction in a way you could not have mapped, is the whole thing. Everything else is scaffolding.Why real examples are so hard to findThis is the part that took me longest to understand, and I think it is the most useful idea here. There could be gaps but still I want to crystallise the information.Enterprises have spent years deliberately engineering open-ended state out of their processes.That was rational. Human judgment is expensive, inconsistent and does not scale. So organisations built SOPs for every scenario, approval hierarchies with fixed triggers, rule based systems in ERP, CRM and WMS, and workflows where every decision point had a predetermined answer. A purchase order above fifty thousand goes to the CFO. Always. Not because that is the smartest possible rule, but because it is auditable and it scales.The goal was to make processes repeatable without requiring thinking.But when you remove ambiguity from a process, you also remove its ability to deal with anything the designers did not anticipate. So enterprises invented a pressure valve: the exception queue. Anything that does not fit gets escalated to a human. That human applies judgment. If the same exception recurs enough times, someone writes a new rule and it gets absorbed back into the process.Humans were the agents all along. They were sitting at the edges of the process, absorbing the unknown unknowns, and the org chart pretended that was not happening.So when a leadership team sits in a room and asks “where do we use agents”, they look at their core processes, find them fully specified, and conclude there is nothing here. Of course there is nothing there. They spent five decades making sure of it.The opportunity is not in the core. It is at the boundary, where the structured process meets messy reality. Where a supplier stops behaving the way the ERP expects. Where a customer complaint does not fit any category. Where a regulatory change quietly invalidates three workflows at once.So you want to start an agentic journeyThis is the question I get most often now, usually after someone’s board has asked them what their agentic strategy is. Here is what I would actually tell them.Image by authorStart from the exception queue, not from the use case list. Do not run an ideation workshop. Go find where your experienced people are spending their judgment today. Look at what gets escalated, what sits in someone’s inbox for two days, what requires a phone call to a colleague who “knows how this works.” That is your map. Those escalations are the fossil record of open-ended state in your organisation.Assume your bottleneck is access, not intelligence. Almost nobody fails because the model was not smart enough. They fail because the agent could not reach the data, or the document store had no usable metadata, or the source of truth for supplier terms turned out to be four spreadsheets on a shared drive. An agent’s ceiling is the set of things it can actually see and do. Budget accordingly, and be honest that a good part of your first year is plumbing. Had you have a good AI strategy, your agentic strategy will be much easier.Decide the autonomy level explicitly, and write it down. There are three modes: Recommend only, Act with approval, Act and report. Most enterprise use cases should live at recommend stage far longer than the anyone suggests, and there is no shame in that. A system that assembles the evidence dossier and hands it to a human is already removing the expensive part of the work.Build the evaluation harness before you build the agent. This is the discipline gap I see most often. If you cannot tell whether the agent reasoned well on a case, you cannot deploy it, you cannot improve it, and you certainly cannot defend it in an audit. Curate fifty real historical cases with known outcomes before you write a line of orchestration code. The golden set of QnA is what I see missing in most of agentic orchestrations, your system doesn’t need to pass all the cases that are in your golden set but at least it will guide you towards your point A and if you know where your point A is, then only you can go to point B.Change what governance is measuring. Deterministic systems are governed by asking, “was the rule followed”. Agentic systems have to be governed by asking “was the reasoning sound, was it within bounds, and can we reconstruct it.” That is a different control framework and your risk function will need to be brought along early, not shown a finished system.Pick a first domain where being wrong is recoverable. Not because agents are unreliable, but because you are going to learn things about your own data and processes that you would rather learn without a regulatory consequence attached.The uncomfortable part: greenfield is easier than retrofitThis one surprises people, and it runs against how most transformation programmes are structured.It is significantly easier to build an agentic system from scratch than to make an existing application or process agentic.The reason follows directly from everything above. An existing enterprise process has already had its ambiguity engineered out. That was the entire point of building it. So when you go to “make it agentic”, you find there is nothing left for an agent to do except execute a sequence of steps that a workflow engine performs more cheaply, more predictably and with better logging. You end up wrapping a language model around a deterministic process and paying more money for less determinism. I have watched teams do this and then wonder why the business case will not close.Retrofit also drags along everything the original system was designed for. Schemas built for transactions rather than reasoning. Permission models built for named human users rather than service identities acting on behalf of someone. Audit trails that assume a fixed path through the process. SLAs that assume a fixed number of steps. Interfaces that were designed to be clicked, not called. None of that is unsolvable, but it is where the calendar goes.Greenfield teams are not smarter. They simply have less to unlearn. They get to design the process around the properties an agent is good at: open state, iterative discovery, tool access, judgment under incomplete information.The practical middle path, and this is what is recommended: do not try to agentify the process. Leave the deterministic core exactly where it is, because it works. Agentify the exceptions that fall out of it. That is where the open-ended state already lives, that is where your expensive people are already spending their time, and it means you are adding a capability rather than replacing a working system with a probabilistic version of itself.And is automation the first step of an agentic journey?Sort of, but not in the way people mean it.Automation is not stage one of a maturity curve that ends in agents. They are not the same thing at different levels of sophistication. But automation is a prerequisite, in a specific and important sense: your automations become the tools your agents call. Every reliable API, every clean integration, every well defined action you have already built is something an agent can now use as a hand.An agent without solid automation underneath it is a very expensive intern with no hands. It can reason beautifully about what should happen and then do nothing about it.So the organisations best positioned for this are not the ones that skipped process automation to chase agents. They are the ones that did the boring integration work for a decade and now have something worth reasoning over.Where I have landedMost of what we see and term as agentic is automation with a better narrator. That is not a scandal. Automation is genuinely valuable and there is nothing wrong with selling it, as long as we call it what it is.The remaining part is real and it is genuinely new, because it addresses a category of work that no previous technology could touch. The work at the edges. The exception queue. The unknown unknowns that we quietly staffed with experienced humans and hoped for the best.That is the part worth building in the realms of agentic.The spirited discussion ended there at the tea shop but was there in my mind and thus, I wanted to crystallise my thoughts here.If you are working through this in your own organisation, I would be curious to hear where you have found genuine open-ended state, and where you concluded it was automation after all.