AI in engineering companies · Agents
What an agent actually is, and isn't
"Agent" has become the most overused word in technology. I have seen it applied to a chatbot with a company logo, a scheduled script that calls a language model, and systems that genuinely plan, act and adapt on their own. When one word covers all of those, it stops helping anyone make decisions.
This is the first article in a series on AI agents in engineering companies. It follows a series on the five levels of AI value, from finding information through to closing the loop from field data to engineering. Agents are how the upper levels of that ladder actually get built, so it is worth being precise about what they are before discussing what they can do.
A working definition
An agent is a language model given four things:
- A goal. Something to achieve, rather than a single question to answer.
- Tools. Defined ways to act on the world: search a document index, query a database, run a test, read a file, draft a report.
- A loop. The ability to take a step, look at the result, and decide what to do next, repeatedly, until the goal is met or it gives up.
- Some state. A record of what it has done and learned so far in the task.
The loop is the defining feature. A chat assistant answers and stops. An agent decides its own next step based on what the previous step revealed. That is what makes agents powerful, and it is also what makes them harder to predict, test and control.
A spectrum, not a category
In practice, there are three kinds of system that get called agents, and it is useful to separate them.
Assistants. A person asks, the AI answers, perhaps using a tool or two along the way. The person decides every step. Most of what organisations currently call agents are assistants.
Workflows. A defined sequence of steps, some of which use AI. The steps and their order are fixed by the people who designed the process. The AI does the reading, extracting, classifying or drafting within each step. A monthly digest of service logs is a workflow.
Autonomous agents. The AI decides which steps to take, in what order, and when it has finished. Given a goal such as "find out why this unit is failing", it chooses which systems to query, what to look at next, and when it has enough evidence.
Each step along that spectrum adds flexibility and removes predictability. Neither end is better. The skill is choosing the right point for each task, which is the subject of the next article, Workflows before agents.
Where agents sit on the five levels
In Beyond search, I described five levels of AI value in an engineering company: find, structure, connect, act and learn. Agents map onto them quite precisely.
At level 1, find, an agent adds little. Search with a good answer is usually enough.
At level 2, structure, the work is high-volume extraction. That is almost always a workflow: the same steps applied to thousands of records.
At level 3, connect, agents start to earn their place. Diagnosing a single failing unit needs judgement about which systems to query next, based on what the last one showed. That is a genuine agent task, even when the agent is only allowed to read.
At level 4, act, agents draft the documents engineering has to produce, with an engineer approving every one.
At level 5, learn, agents monitor, investigate and verify continuously. This is where autonomy is most valuable and where the need for control is greatest.
The pattern is clear: the higher the level, the more an agent helps, and the more carefully it needs to be designed.
What agents are not
They are not colleagues. An agent does not understand your product, your customers or your obligations. It is very good at working through a well-defined task with the tools and information it has been given, and has no judgement beyond that.
They are not reliable by default. A single AI response can be checked. An agent may take twenty steps, each a small chance of going wrong, and each building on the last. Small errors compound. Reliability has to be designed in, through limits, checks and human approval at the points that matter.
They are not free. An agent that loops through a task can use many times the computing of a single question, because it rereads material and reasons at every step. I return to this in The cost and infrastructure of agents.
They are not safe by default either. An agent with tools has access. Anything that can influence what it reads can potentially influence what it does. That is the subject of the security series that follows this one, beginning with The attack surface has moved.
Why this matters for engineering companies
The honest case for agents in engineering is not that they replace engineers. It is that a great deal of engineering work consists of gathering information from many places, working through it methodically, and producing something from it: an investigation, a test plan, an impact assessment. Agents are good at exactly that pattern, provided the information is reliable, the tools are controlled, and a person owns the result.
I have spent the past year building with agents, both to write production software and in an opportunity platform I am developing, where AI roles work within strict limits and nothing leaves the system without my approval. The lessons from both run through this series. The short version is that the model is the easy part. The design around it is what determines whether an agent is useful, safe and affordable.
Four things worth taking seriously
For engineering leaders: when someone offers you an agent, ask where it sits on the spectrum. Assistant, workflow and autonomous agent have very different costs and risks.
For anyone planning AI work: match the degree of autonomy to the task. Most valuable work needs less autonomy than the marketing suggests.
For technical teams: design the tools before the agent. What an agent can do is defined entirely by what it is allowed to reach.
For everyone: an agent's output is only as good as the information and controls around it. The foundations described in the first series still apply.
I would be interested to hear what "agent" means in your organisation today, and whether it is the same thing to everyone who uses the word.
Further reading in this series
Catherine Ives-Yim
Chartered Engineer and independent technical adviser, with a lifetime at the bleeding edge of embedded systems, connected products, data platforms and AI-assisted engineering, who has advised clients across the UK, Europe, the Middle East, the Far East, North America and Africa. Based in Leeds.