There is no such thing as "just an agent"

For the purposes of this piece, an agent is not just an LLM somewhere in a workflow. It is a system in which the model has some control over how the workflow is executed.

It can decide what to do next, use tools, observe what happened, adjust, and eventually stop or hand control back to a human.

I have encountered several reasons why building a working agent is not so simple. Just off the top of my head.

Most real processes that we hope to automate using agents, or even GenAI workflows, were created by or for humans. That means they are not necessarily ready for machines. This is often a limiting factor.

Understanding real, often poor quality documents can be a limiting factor for your agent. The same is true for data discrepancies that humans currently resolve by applying contextual knowledge and making decisions that are sometimes very “vibey”, inconsistent, or simply suboptimal.

Those decisions do not translate cleanly into instructions for an agent.

A vaguely defined process is doomed when you remove the highly intelligent and adaptive person who was silently compensating for all its gaps.

The agent does not necessarily know what to do when Max from Sales has a genius idea to invoice one product to cover a service performed on another. This happens surprisingly often!

This is the advantage of having a human doing the work. Humans can adapt to unusual situations and do something. Anything that moves the process forward, even when it is not elegant or consistent.

The good news is that I think we can eventually bridge this gap. The potentially uncomfortable news is that not everyone can do it well yet. At least not unless we build fully competent AI agents that can perform the product and technical discovery currently done by experienced individual contributors.

Remember that one of the biggest challenges in product development is that the client often does not actually know what they want. They ask for impossible or contradictory things. In the end, they rely on product and technology teams to deliver the closest reasonable solution to the underlying problem.

Of course, we can speculate that, in the future, someone will simply describe a problem and an agent will work out everything required to breathe life into a solution. I am personally excited about the problems we will eventually solve this way.

At the same time, we have to be acutely aware that we are not there yet. Even if we were, someone would still need to ask the right questions and decide whether the resulting solution was useful.

Not everything that is possible is beneficial.

I am constantly brought back to the same point. One of the purposes of studying computer science, engineering, or science more generally is to learn a couple of really important skills. Most notably, understanding the problem and building an appropriate solution to that problem.

Today, we have enabled people without that training to become solution builders. That is genuinely exciting. But lowering the barrier to execution does not remove the need for judgement.

The obvious risk is that people may not recognise when they are building something that will never work well. They then spend time and money trying to “fix” or optimise it. But sometimes the thing you are trying to optimise is not the right solution in the first place.

System design, including both high level and low level design, gives us mechanisms for surfacing what the solution should actually look like. It can take several people, several hours, and several review cycles to converge on a good answer.

You have to find the appropriate technology for your budget, your problem space, and your ambition.

“Just build an agent” is not yet a solution. It is a proposal for how a solution might be implemented.

Before that proposal can mean anything, someone still has to understand the problem.