I'm increasingly hearing requests that begin in a similar way:

“We need an agent.”

Or:

“We could solve this with AI.”

It's understandable. LLMs and agents have opened possibilities that were difficult to imagine only a few years ago, and we can now automate tasks that previously required human intervention.

But there's a risk in starting the conversation with the technology.

Once we understand the process, we often discover that we didn't need an agent. We needed an integration between two systems, a better-defined business rule, a clearer process, or simply traditional software development.

The interesting question stops being:

How can we solve this with AI?

And becomes:

What problem are we actually trying to solve?

The Request Often Arrives With a Solution Attached

This didn't start with artificial intelligence.

For years we've heard requests like:

“We need a dashboard.”

“We need to replace the system.”

“We need to automate this process.”

“We need a new application.”

Now we've simply added another one:

“We need an agent.”

There's nothing wrong with a stakeholder proposing a solution. Someone who works with a process every day probably understands parts of the problem much better than Technology does, and their proposed solution may very well be right.

The mistake would be treating that initial proposal as a specification and immediately starting to build.

When someone brings me a need, I try to start with much more basic questions:

What's the problem?

What outcome are we expecting?

Then the conversation begins.

What happens today? Where is the pain? How much work does it create? Who gets involved? What exceptions exist? What information does someone need to make a decision?

Often, while answering those questions, the original solution begins to change on its own.

Understand the System Before Choosing the Technology

I find it useful to organize that conversation into five steps.

1. Problem

What's actually happening?

The people who live the process every day should primarily explain this. Technology asks questions, listens, and tries to separate the problem from the proposed solution.

Not which system we want to build.

Not which technology we want to adopt.

What problem exists.

2. Outcome

What should be different when we're done?

Business and Technology should agree on an observable outcome: reducing time, decreasing errors, eliminating repetitive work, improving conversion, lowering costs, controlling risk, or enabling growth.

The outcome should be explainable independently of the technology.

3. Pain

Where is the cost, delay, or friction actually being created?

It's worth walking through the process with the people who execute it because visible pain doesn't always originate where the underlying problem does.

A team might ask us to automate manual data entry, for example. But after walking through the process, we may discover that the manual work exists because another system produces incomplete information.

Automating the data entry addresses the pain.

Fixing the source of the information addresses the problem.

4. Constraints

What can't we simplify?

Regulation, security, privacy, human decisions, existing systems, business rules, or third-party integrations.

Business brings the domain constraints. Technology helps distinguish which ones are inherent to the problem and which are consequences of previous decisions.

5. Solution

Only then should Technology propose alternatives.

And there's one question I like to ask:

What's the simplest solution that satisfies everything above?

It could be AI.

But it could also be an API, a rule, a form, traditional automation, a process change, or even a decision not to build anything.

These five steps don't need to become a bureaucratic process. Sometimes thirty minutes at a whiteboard with the right people is enough.

The value isn't in completing a framework.

It's in delaying the technology decision until we understand the problem.

Why Do We Need It to Reason?

This has become especially relevant with the rise of agents.

Imagine a common operational process.

Someone retrieves information from one system, checks five perfectly defined conditions, takes a value, and enters it into another system.

We could build an agent to do it.

But there's a question we should ask first:

Why do we need it to reason?

If the inputs are structured, the five rules are known, and we expect the same outcome under the same conditions, we're probably dealing with a deterministic problem.

Maybe what we need is an integration and five rules.

Not an agent.

The difference is concrete.

An agent introduces model calls, response evaluation, observability, non-determinism management, and new failure modes.

An integration with five rules, in a simple case, might require little development and can be tested with completely reproducible unit tests.

That doesn't make the second solution less technological.

It makes it more appropriate for the problem.

Deterministic Doesn't Necessarily Mean Hardcoded

There's another important nuance.

The fact that we can express a process through five rules today doesn't mean those rules are stable.

Maybe they change every month.

Maybe the business needs to modify them without waiting for a deployment.

That still doesn't automatically mean we need an agent.

It may mean we need configuration.

The rules can live outside the code, be versioned, audited, and modified by the appropriate people.

We now have three different problems:

  • known and stable rules → deterministic logic;
  • known but frequently changing rules → configuration;
  • decisions where the path depends on context, ambiguous information, or reasoning → this is where an LLM or agent becomes much more interesting.

Architecture should respond to the nature of the problem, not to the tool we want to use.

The Most Sophisticated Solution Isn't Necessarily the Smartest

In Building Effective Agents, Anthropic recommends finding the simplest solution possible and increasing complexity only when needed. It also highlights an important trade-off: agentic systems can improve performance on certain tasks in exchange for higher cost and latency.

Microsoft similarly describes different points along a spectrum between agents that dynamically decide what to do and workflows whose behavior is deterministically controlled.

There is no single correct architecture.

If we need to interpret unstructured language, understand context, work with ambiguous information, dynamically select tools, or solve situations whose path can't be defined in advance, an LLM can add tremendous value.

But if we have:

If A and B happen → execute C

writing exactly that may be an extraordinarily good solution.

Using more sophisticated technology doesn't automatically make a solution smarter.

Simplicity Has an Architecture Too

“Let's make it simple” doesn't mean always choosing the smallest possible solution.

A simple solution should still be secure, observable, maintainable, and capable of meeting the real needs of the business.

But it should avoid complexity we don't need.

In 1986, Frederick Brooks introduced a distinction in No Silver Bullet that remains useful forty years later: software contains essential complexity, inherent to the problem we're trying to solve, and accidental complexity, introduced by the tools and mechanisms we use to solve it.

That distinction is particularly relevant today.

We have extraordinarily powerful tools.

And precisely because of that, we have many more opportunities to introduce accidental complexity.

Some Problems Are Genuinely Complex

The opposite mistake would be taking simplicity too far.

Simple doesn't mean simplistic.

This becomes very clear when working with healthcare-related problems.

From the outside, a process may look unnecessarily complex. Then we start to understand it.

There are regulations. Privacy. Traceability. Different stakeholders. Systems that need to interoperate. Clinical exceptions. Audit requirements. Information that can't be handled arbitrarily.

We can try to simplify the technology solution.

But we can't make the complexity of the domain disappear simply because it's inconvenient.

The goal isn't to eliminate all complexity. It's to eliminate the complexity we add unnecessarily.

If the problem is complex, the solution will probably need to represent some of that complexity.

What we don't need is another layer on top simply because a technology happens to be fashionable.

Listening Is Part of the Technology Job

An important part of a technology leader's job happens before architecture is discussed.

It happens while listening.

A stakeholder might say:

“I need to automate this.”

Our responsibility shouldn't be to immediately respond with a diagram.

We should understand what they do today, why they do it, what information they use, where they lose time, what errors occur, and what outcome they need.

And there's something important here:

Technology doesn't necessarily understand the problem better.

The person who works with a process every day has knowledge we don't have.

Our contribution is to combine that business knowledge with our ability to look at the system from another perspective.

The best outcome doesn't happen when Technology imposes a solution.

It happens when Business and Technology understand the problem together.

But Asking Questions Has a Cost Too

We can also go too far in the opposite direction.

We can spend weeks trying to understand a problem perfectly before building anything.

That doesn't always make sense either.

There are situations where a stakeholder can't fully articulate what they need until they see something working.

In those cases, a two-day prototype can teach us more than two weeks of meetings.

Discovery shouldn't become paralysis.

The goal isn't to understand absolutely everything before moving.

It's to understand enough that building becomes the next cheapest way to learn.

Sometimes we need to ask.

Sometimes we need to model the process.

And sometimes we need to build something small, put it in front of users, and continue learning from there.

AI Makes This Conversation Even More Important

Paradoxically, the better our tools become, the more important this distinction becomes.

Today we can build software much faster.

We can generate code, integrate systems, process documents, interpret language, and create agents capable of using tools.

That dramatically reduces the cost of building some solutions.

But it doesn't automatically reduce the cost of building the wrong solution.

It may even accelerate it.

We can spend months building the wrong thing. Or we can build the wrong thing in three days.

The speed changed.

The need to understand the problem didn't.

Problem First. Technology Second.

I love technology.

That's precisely why I try not to start with it.

The value of a technology isn't in how sophisticated it is, but in what problem it allows us to solve and at what cost.

An agent may be the right solution.

An AI model may be too.

But an API, a business rule, or twenty lines of code can be an equally good — or better — technology decision.

And sometimes, after truly understanding the process, we may discover that the problem didn't need software at all.

So when someone comes in saying:

“We need an agent.”

my first question remains:

“What problem are we trying to solve?”

And after understanding the problem, the expected outcome, the pain points, and the constraints, I'd add one more:

“What's the simplest way to solve it well?”

To me, that's where a good technology decision begins.

Not when we choose the tool.

When we understand the problem.

Sources and Further Reading