Author(s): Shwetha Kumari A

Originally published on Towards AI.

AI in the Wild Is Nothing Like AI in the Room

AI Architect’s Notes · Week 02 · Ground Reality

The demo convinced everyone. Implementation humbled us. Here is what building a real agentic system actually feels like from the inside.

The scope of an AI system looks entirely different on a whiteboard than it does when it meets real users, real data, and real business logic that nobody thought to document.

The Room Was Convincing

The demo was genuinely impressive.

We had built an agentic system to process documents end-to-end — extracting data, validating it, and taking all the actions a human would normally perform to approve or reject it. Clean interface, accurate responses, every data point captured with confidence. Someone said, “this changes everything.” There were nods.

The sample dataset was simple and well-structured. The documents were clear. The business rules were straightforward. It worked beautifully.

We left that room thinking the hard part was behind us. It was not.

The Wild Had Other Plans

The moment real users arrived, the cracks appeared — not in the AI, but in our assumptions.

The actual data looked nothing like the sample. Documents were unclear, low quality, inconsistently formatted. The complexity we thought we had covered in the demo had not even arrived yet. Users needed things we had never considered, described in language we had not prepared for, governed by processes that had quietly changed since anyone last wrote them down.

The agent that had looked so capable in the boardroom began to buckle. Was it the AI’s fault? Not really. We had built it for the room. The room had been a controlled experiment. Production was something else entirely.

With late nights, early mornings, and more than a few weekends, we worked through it. We deployed to production. We thought the hard part was finally behind us.

The Moment We Knew

Then came the next assumption that needed dismantling.

We had confidently said the solution would scale — that it would work equally well for data from different regions and different clients. One architecture, one system, built to fit all.

The moment of truth arrived with a new batch of input documents. Invoices in multiple languages. Entirely different formats. Blurred, chopped, skewed scans that were barely readable even to a human eye. And the underlying business logic? So deeply contextual and undocumented that understanding it felt like archaeology.

Then came the questions. Why was the accuracy not 100%? Why did the AI process this document this way and not that way?

And then came the line that stopped us cold — the one we kept hearing from users when we probed for the rules the system was missing:

“Well… this isn’t documented anywhere, but we’ve been doing it this way for years.”

That was the moment we stopped optimizing and started rethinking.

What We Rebuilt — And Why

The insight sounds obvious in retrospect: one agent cannot hold the entire problem space without collapsing under its own context.

We moved to a multi-agent architecture. A supervisor agent whose only job was to understand the document type and route it appropriately. Specialist agents beneath it — an extractor, a validator, a business rules agent — each with a narrow, well-defined scope, its own tools, its own prompt structure, and its own reasoning chain.

Every agent was now responsible for explaining its decisions. How it extracted a value. How it resolved an ambiguous field. What it did when the data did not match the master records.

The accuracy improved. More importantly, the system became auditable — which in an enterprise context is as valuable as accuracy itself.

The Line Nobody Warned Us About

Then came the edge cases.

Old document headers. Outdated formats. Data on the document that did not match master records — not because it was wrong, but because humans had been making contextual exceptions for years without writing them down and without trying to fix the data at the source. To a human reviewer, these were obvious. To the agent, they were blockers.

This also forced a harder conversation — one that had nothing to do with AI. The existing human process needed to be examined, inconsistencies surfaced, and change management initiated before the system could be reliable.

As a quick fix, the instinct, every time, was to write code. A new rule. A new condition. A hardcoded exception. And each one worked — individually. But collectively, they were doing something dangerous.

Every rule we encoded was a decision we took away from the model. Every hardcoded exception was a piece of reasoning the agent no longer needed to do itself. We were slowly turning a system designed to think into a system designed to execute a rulebook.

The model’s ability to reason, adapt — the very thing that made it valuable — was being quietly suffocated by our own engineering instincts.

We had to keep returning to a question that felt uncomfortable every time:

Is this a problem we should solve with code — or with better context, better prompts, and better routing?

More often than we expected, the answer was the latter.

What This Taught Us

Building agentic systems is fundamentally different from building software. The mental model has to shift.

You are not writing logic. You are designing conditions under which intelligence can operate. The craft is in knowing what to control, what to constrain, and what to leave entirely to the model — and building an architecture flexible enough that when business rules change tomorrow, you are not rewriting code to keep up.

Too much control and you have expensive, brittle software that requires engineering effort for every small change. Too little and you have an unpredictable system that users cannot trust and auditors cannot explain.

The architecture we run today has been revised multiple times. Not because the earlier versions were failures. Because each version was the system teaching us something the previous one could not.

Four things we would build in from day one now:

Specialist agents over generalist ones — narrow scope per agent produces more consistent, explainable outputs than one agent trying to do everything.

Flexible prompt architecture — business rules belong in configuration and context, not hardcoded into prompts. When rules drift, only the context should need updating.

Observability from the start — every agent decision should be logged, explained, and reviewable. In enterprise AI, trust is built through transparency, not just accuracy.

Guardrails as a first-class concern — not an afterthought added before go-live. Define what the system should never do as carefully as you define what it should.

Closing Thought

If you are about to build an agentic system, here is what I wish someone had told us before that first demo:

The whiteboard version will be wrong. Not because you planned badly — but because the wild reveals complexity that no room can simulate. Data drifts. Business rules drift. Human context, built over years of undocumented practice, is invisible until it is not.

Build for iteration, not perfection. And when you feel the urge to solve a problem with more code — pause. Ask whether the model, given the right context, could solve it instead.

The best agentic systems are not the most engineered ones. They are the ones that got out of the model’s way at exactly the right moments.

I build multi-agent AI platforms for enterprise operations — and I am still learning what these systems want to be. Follow along for one honest take every week.

What is the biggest architectural assumption that real users dismantled for you? I would genuinely like to know.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI