When Agentic Workflows Break a Programmer’s Brain

“Can’t see the forest for the trees'“ AI is a new kind of forest, and it’s remarkably easy to disappear into the trees. We need builders willing to study every branch, but we also need systems thinkers who keep walking back to the clearing, looking at the whole landscape and asking: Is this the easiest solution?

The best solution is pairing technical / IT/ coders with systems thinkers who can step back and ask what should be automated, what should be agentic, and what humans should still own.

Event / Source

Client working session · Enterprise AI implementation · September 2026

What it was about

I recently sat in on a working session with an experienced enterprise automation professional who was building a multi-agent workflow inside an enterprise Microsoft environment.

The architecture sounded straightforward.

One specialist agent retrieves internal information. A second receives information from the first and researches an approved external source. A third receives a few pieces of context and conducts broader research. Their outputs ultimately need to come back together into one usable deliverable.

But getting those pieces to work together had become surprisingly difficult.

The builder came from a traditional automation background, where a workflow is explicitly constructed:

This happens → this variable gets created → this condition gets checked → this value gets passed → the next action runs.

So when the agent system became unreliable, the natural response was to add more structure.

Topics. Variables. Schemas. Input definitions. Output definitions. Child-agent handoffs. Flows. More explicit instructions.

Instead of making the system easier to understand, every additional layer created another architectural decision.

At one point the builder described looking at another possible approach and seeing a “tree of 400 decisions.”

The cognitive load was becoming visible in real time. Our builder had gone a little Paul Bunyan, hacking through a forest of topics, schemas, variables and handoffs, only to discover that every tree he felled seemed to reveal three more behind it.

What I’m keeping

Low-code agent builders can reduce coding effort while increasing architecture decision load.

The problem isn’t necessarily writing the code anymore.

It’s deciding what should be explicitly programmed and what the AI should be allowed to figure out.

3–5 things I learned

• Deterministic automation and agentic orchestration require different mental models. Traditional automation rewards specifying exactly what happens next. Agentic systems can work better when they’re given a goal, appropriate tools, boundaries and a definition of success, then allowed to determine some of the path themselves.

• More control can create more complexity. When an agent behaves unpredictably, the instinct is to add another rule, variable, schema or routing mechanism. But every new control also creates another interaction that someone has to understand, test and maintain.

• The deterministic parts don’t disappear. They move. If a final output must conform to an exact structure, that doesn’t mean every research and reasoning step leading to it needs the same rigidity.

• Agent responsibilities should be small and distinct. “Retrieve this information,” “research this approved source” and “find relevant external coverage” are easier to reason about than one enormous workflow trying to control every intermediate decision.

• The hardest part may be deciding where reasoning ends and automation begins. That’s becoming one of the more interesting design questions in enterprise AI.

The human + AI arrangement I would test next

After the call, I kept thinking about where the boundaries should actually sit.

I would separate the system into three layers.

Humans define the contract.

What are we trying to produce? Which sources are permitted? What information is required? What happens when information is missing or sources conflict? What requires human review?

Those are business and governance decisions. People should own them.

AI handles interpretation, research and synthesis.

The orchestrating agent interprets the request, determines what information the specialist agents need, asks the user only for information that’s actually missing, sends work to the appropriate specialists and synthesizes what comes back.

The specialists each get one clear job.

Traditional automation handles exact execution.

Once the research and reasoning are finished, deterministic automation can take over where precision matters: validate required fields, transform structured data, populate a template, save a file or trigger the next business process.

In other words:

Human → defines intent and boundaries

AI → interprets, researches and synthesizes

Automation → executes the predictable steps

How this changes my work

This call changed the question I want to ask when an agentic workflow becomes complicated.

Not:

“What else do we need to add to make this work?”

But:

“How do we keep this IT person invested in this project build but reduce his cognitive load?”

Start fresh. Bring in the human orchestrator. Access IT only on the integrations and validations piece.

Reduce the data to 1-2 pieces and validate the plumbing.

If that works, add complexity one piece at a time.

Because sometimes the problem with an AI workflow isn’t that we haven’t engineered enough.

It’s that we’re still engineering parts the AI was supposed to handle.