Let me start with a thought experiment. You have two new hires joining your team on the same day.

The first is a fresh graduate who is smart, eager, but inexperienced. You give them a specific task: build a login screen. You describe exactly how it should look, what validations it needs, what happens when the user clicks submit. You ask them to check in with you before moving to the next step. You would not hand them an entire product and say “figure it out.” Not yet.

The second is a seasoned solutions architect with fifteen years of experience. You do not brief them on the login screen. You tell them about the customer’s problem, the current bottleneck, and what success looks like, the outcome, the acceptance criteria. Then you leave them to it. They’ll figure out the login screen, the data model, the integration points, the trade-offs. Nobody tells them each step. They are given context and trusted to find the path.

Same organisation. Same codebase. Completely different relationship.

Now here is the question I have been sitting with: when we build software systems with AI, which of these two are we actually building? And are we honest about the answer?

Before we look at what teams are building, let’s be precise about what we should mean when we say “agent.”

An agent, as I understand it, is a system that is given context and an outcome — and then figures out, on its own, how to get there. It can plan. It can decide which tools or skills to invoke, and in what order. It can reason about what to do when something unexpected happens. It does not need to be told each step. Much like the seasoned architect, it is trusted with the destination, not handed a map.

A tool, by contrast, is given a task with specific instructions on how to execute it. It does its job well, reliably, and within the boundaries it has been given. It does not know why it is doing what it is doing. It does not know what comes next. It finishes, and it waits.

Most software systems built with AI today are, if we are being honest, tools. That is not a criticism. Tools are valuable. But tools are not agents, and we do ourselves a disservice by calling them one.

Here is a concrete example. One of my teams has been building what they call a financial data agent. It takes a PDF of a company’s financial statements, identifies the income statement, balance sheet, and cash flow tables, extracts the relevant rows and values, and maps them into a structured JSON schema ready for downstream processing.

It uses LLM prompts to do some of this. The output looks intelligent. And so the team started calling it an agent.

But consider what this system actually does. It receives exact instructions on what to find, where to find it, and what format to produce. It does not understand why it is extracting this data. It cannot decide to look for additional context if a table is ambiguous or missing. It cannot reason about whether the numbers it has extracted make sense in relation to each other. It executes a defined task and waits.

That is not an agent. That is a well-engineered tool. A useful, reliable, valuable component, but a component, not a collaborator.

The presence of an LLM prompt is what gave the team reason to call it an agent. But the LLM is not the measure. The architecture is.

Now imagine you were building something that genuinely simulates the work of a credit analyst. That analyst does not just parse PDFs. They ingest financial statements, yes — but they also search for news about the company’s management, benchmark against industry peers, cross-reference public disclosures, and synthesise signals from multiple sources. They weigh all of this together, draw on past cases, apply judgment about what matters most in this particular situation, and produce a credit report with a recommendation.

Nobody hands that analyst a checklist. They are given the company name, the purpose of the analysis, and the standard they are being held to. They figure out the rest.

That process is non-deterministic. It involves autonomous planning — deciding what information to gather, in what order, and how much weight to give each source. It involves knowing when to go deeper and when enough is enough. It involves reasoning under uncertainty, informed by experience.

In that pipeline, the FinData parser I described earlier would be one tool the agent calls. One skill among many. A reliable component it reaches for when it needs structured financial data — and then moves on from.

This is the distinction that matters: the tool becomes a building block. The agent is what orchestrates the building blocks toward an outcome.

There is a consequence to calling a tool an agent that goes beyond words: we stop asking the harder questions.

If a system is labelled an agent, it feels complete. Sophisticated. Done. We don’t ask what it would do if it encountered something unexpected. We don’t ask whether it understands the context it is operating in. We don’t ask whether the approach we have taken is actually the right one.

I see this play out in a specific way: teams reaching for an LLM when deterministic, procedural code would have served them better.

Parsing structured tables from a financial PDF is a well-understood problem. There are reliable, cost-efficient ways to do it without an LLM — layout parsers, rule-based extraction, structured document libraries. These approaches are fast, fully debuggable, and cheap to run at scale across hundreds of thousands of documents. They do not hallucinate. They do not produce subtly wrong JSON on the ten-thousandth document because a table was formatted slightly differently.

When a team routes that task through an LLM prompt instead, they have introduced non-determinism where determinism was available. They have incurred per-token costs that compound at scale. They have made the system harder to debug and harder to trust. And — crucially — they have likely done this not because the problem required it, but because using an LLM made the system feel more intelligent, more agent-like.

An LLM earns its place when the task is genuinely ambiguous, contextual, or requires a form of reasoning that code cannot replicate. Not before.

I want to be clear about something. I am not saying true agents are easy to build and my teams are simply being lazy. They are not.

A system that can genuinely simulate the reasoning of a domain expert — a credit analyst, a software architect, a regulatory affairs specialist — is technically complex and organisationally demanding. It requires engineering depth, yes. But it also requires genuine subject matter expertise sitting alongside the engineering. You cannot build a credit analyst agent without someone who understands how a credit analyst actually thinks: what signals they trust, what heuristics they apply, how they handle uncertainty, when they escalate.

The engineering team and the domain expert have to work together deeply, over time, translating a human expert’s reasoning process into something a system can approximate. That collaboration is rare. That work is slow. And the result — a system that earns the word agent — is genuinely different from what most teams are building today.

When I review AI systems now, I ask one question: if I gave this system a context and an outcome would it know what to do?

If the answer is no, if it needs to be told each step, if it waits for instructions at every junction, if it has no awareness of the bigger picture, it is part of, then it is a tool. A potentially excellent tool. But a tool.

If the answer is yes, if it can plan, decide, course-correct, call on the right skills at the right time, and produce an outcome that meets the criteria it was given — then you have something that deserves the word agent.

Most of what I see today is closer to a tool. That is fine. Let us build excellent tools. Let us compose them thoughtfully. Let us be honest about what we have. And let us save the ambition, the investment, and the cross-functional effort it requires for what it would take to build an agent.