Before You Build the Agent, Untangle the Plate

Somebody sent me a photo of spaghetti and meatballs a while back and I couldn't stop thinking about it in the context of work. Which tells you something about the kind of month I was having.

From across the table it's one dish. You'd order it by name. Up close it's a tangle: pasta wound around itself, sauce underneath things, a meatball half-hidden at the back, an olive that may or may not belong, a leaf of parsley someone put there for the photo. You can't tell by looking which strand connects to which.

That's every enterprise process I've ever been asked to “put AI on.”

The request always arrives as a solution

Here's how these engagements start, more often than I'd like. A stakeholder walks in and says “we need an agent for this.” Or “we need RAG.” Or “can we get a copilot on the case queue?” The request comes pre-solved. And the delivery team, wanting to look fast, starts designing the thing that was asked for before anyone has established what problem exists, who actually has it, where the time really goes, what decisions get made along the way, which data can be trusted, or what “better” would even look like.

I've done this myself. It feels productive. Two weeks in you have a prototype and the sponsor is delighted.

What you've actually done is turn assumptions into architecture.

The uncomfortable twist is that generative AI makes this worse, not better. Old-fashioned software forced ambiguity into the open, because requirements had to become fields and screens and rules before anything worked. An LLM will give you a persuasive interface and plausible behavior long before anyone understands the operating model. A prototype can look intelligent while being, for lack of a better word, architecturally homeless.

So the faster we can build, the more dangerous it is to build before we understand.

What's actually on the plate

Ask a process owner to describe their workflow and you'll get something linear. Receive the request, review the information, decide, act. Four boxes.

Then go sit with the analyst who does it. They check three systems. The exception logic is in a spreadsheet on someone's desktop. One senior person knows which policy everyone quietly interprets differently. An email thread kicks off an approval that isn't on any process map. Data gets copied between two systems because the integration was never built. There's a control step nobody can explain, and when you dig, it traces back to an incident from years ago that nobody remembers. And the delay the customer complains about, the one blamed on “the system,” is really a decision nobody owns.

That's the plate. A business outcome produced by a dense knot of judgment, systems, policy, data, exceptions and workarounds. “Build an agent for this” is only the top layer.

If you pour intelligence over the top, you automate the tangle. Some of those strands should be untangled. Some are duplicated. Some should never have been on the plate at all. Discovery is the work of separating the ingredients before you decide what to cook.

Discovery is not requirements gathering

I want to be careful here because “discovery” is a word that gets nodded at and then skipped.

Requirements gathering starts from a presumed solution and asks stakeholders to specify what it should do. It documents the stated process, collects features, and produces a backlog. That's fine when the solution is right. It's a disaster when it isn't, because it faithfully records the wrong thing.

Discovery for AI has to start one level earlier. It challenges the requested solution. It observes the real process instead of documenting the described one. It asks what outcome has to change rather than what users want. It maps decisions, evidence, authority, exceptions and controls. And it's allowed to conclude that a step should be deleted rather than accelerated.

The output isn't a backlog. It's a problem model, an intervention hypothesis, and a build or no-build decision with evidence behind it.

PLATE

I needed something to make this operational rather than a speech, so I use the plate itself. Five things have to be untangled before the architecture hardens.

Problem. What outcome is failing, for whom, and why does it matter? Baseline, economic consequence, target. If you can't state this without mentioning a model, you're not done.

Landscape. What really happens today? Actors, systems, handoffs, wait states, workarounds, exception paths. Not the process map. The actual Tuesday.

Authority. Who or what is allowed to decide and act? Policies, controls, entitlements, approvals, risk tolerance, and which human is accountable when it goes wrong.

Truth. What information can the system trust? Which source is authoritative, how fresh it is, what the fields actually mean, and what context is simply missing.

Evidence. How will we know it worked? Business metrics, an evaluation set, acceptance thresholds, failure criteria, and a loop for learning after launch.

PLATE is done when the team can explain the problem without saying “model,” and can explain the AI's proposed role without hiding behind the word “intelligence.”

The interview is an engineering instrument

The single most useful thing I've changed in how I run discovery is treating the stakeholder interview as a technical activity, not a warm-up. It's how you extract the architecture of the business that nobody wrote down: the decision rules, the exception patterns, the unofficial sources of truth, the competing definitions of success.

A few questions do most of the work.

“Show me the last three real cases.” Not the process. The cases. This is where the generalized description falls apart.

“Where do you leave the official system?” This is where the spreadsheets and the email approvals live.

“What do your best people notice that new people miss?” That's the tacit expertise, and often the thing the AI would actually need to replicate.

“What makes you stop and ask someone?” That's your escalation boundary.

“What happens when this is wrong?” That's materiality, and it decides how much autonomy is even on the table.

“Which step would you delete if policy allowed it?” You'll be surprised how often the answer is the step you were about to automate.

And the one I've come to like the most: “If AI did this perfectly, what work would actually disappear?” If the answer is “none, it'd just be faster,” you've found activity, not value.

Map decisions, not workflows

Process maps show movement. AI systems need something different: a decision map. The unit of analysis is the decision. What question is being answered, on what evidence, who owns the consequence, whether the action can be undone, and what happens when the system isn't sure.

Once you've mapped the decisions, the right technical pattern usually becomes obvious, and it's frequently not the one that was requested. Some problems want a rules engine. Some want retrieval. Some want classification or extraction. Some want a human workflow with AI assistance. A smaller number genuinely benefit from an agent that plans and acts across tools.

Don't start with “agent”

Agentic architecture should be earned by the problem. I use a ladder, and the discipline is to pick the lowest rung that changes the outcome.

Zero: remove or redesign the step. Surprisingly often the work exists because of process debt. One: deterministic automation, when the rules are stable and complete. Two: search and retrieval, when the real problem is finding authoritative knowledge. Three: AI assistance, where interpretation helps but a human stays the actor. Four: AI recommendation, where the system proposes with evidence and confidence. Five: bounded agentic execution, where it can invoke approved tools inside explicit authority. Six: multi-agent orchestration, for the rare case where distinct specialized roles truly need to coordinate.

If a rules engine solves it, don't build an agent. If deleting a handoff solves it, don't automate the handoff.

I'll admit this is the part of my own thinking that's shifted the most in the last year. I used to see the agent as the ambitious answer. Now I see it as the answer that has to justify itself against six cheaper ones.

This is why FDE exists

I lead a Forward Deployed Engineering function, so I have a stake in this, but I'd make the argument regardless. The FDE sits in the most consequential translation layer in enterprise AI, between business intent and production reality. That seat only has value because the problem isn't fully specified. If it were, ordinary delivery could just execute the spec.

A strong FDE doesn't show up as an order taker, and doesn't show up as a technologist looking for somewhere to deploy a favorite pattern either. The job is problem-framing engineer: close enough to the stakeholder to understand the real work, technical enough to see which intervention patterns are feasible, product-minded enough to look for reuse, and disciplined enough to protect production constraints.

The loop is roughly: listen across business, operations, technology, risk and end users; observe real cases and artifacts; decompose the plate into decisions, data, policy, tools, handoffs and waste; challenge whether the requested AI is necessary at all; bound the authority and failure behavior; prototype the riskiest assumption, not the prettiest screen; recompose the workflow around what's proven; and productize whatever turned out to be reusable.

“But discovery is slow”

It's the objection I hear most, and it's half right. Bad discovery is slow. It's a phase gate with a workshop and a deck.

Good discovery compresses uncertainty. It stops a team from spending weeks engineering an assumption that a 45-minute interview or three real-case reviews would have killed. The goal isn't exhaustive knowledge. It's the minimum clarity needed to make the next expensive decision responsibly.

In practice that's about a week. Day one, problem framing and the sponsor interview. Days two and three, cross-functional interviews and real-case walkthroughs. Days three and four, data and architecture reconnaissance. Day five, synthesis and a challenge session. Week two, a thin prototype or shadow test of the riskiest assumption, so the build or no-build decision has evidence behind it.

Speed isn't how quickly the team starts coding. It's how quickly the team eliminates the wrong futures.

The question I'd ask before “what model?”

There are ten I'd want answered, but if I only get one, it's this: what evidence would make us stop this project?

If nobody can answer, discovery hasn't happened. The team has inherited a solution, not understood a problem.

Model access is becoming abundant. Prototyping is getting faster every quarter. Agent frameworks are getting easier. The scarce skill is increasingly the ability to look at a messy business environment and know what should be built, what should be bounded, what should stay deterministic, and what should be removed altogether.

The quality of an AI system is constrained by the quality of the problem it was allowed to understand.

Before you automate the plate, untangle it. Before you choose the model, understand the decision. Before you build the agent, discover the problem.

I'm curious what other people have run into here. What did you learn in discovery that changed what you planned to build?

This article was developed with AI support and reflects my personal views and independent analysis. It is not written on behalf of, affiliated with, endorsed by, or representative of any current or former employer or organization with which I have been affiliated. The discussion draws solely on publicly available information, general industry observations, and conceptual analysis, and does not disclose or rely on confidential, proprietary, or non-public information.