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 first My 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 fails Because 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 unknowns Here 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 u...