One agent. One job. One owner.

I was looking at McKinsey's new State of AI report this week, and one number kept bothering me. Forty per cent of respondents at large organisations said they were scaling AI agents, compared with 22 per cent at smaller organisations.

You can look at that and think the smaller companies need to catch up by building more agents, buying a larger platform and copying whatever the enterprise teams are doing.

I think that is the wrong response.

If we want to build our first AI agent and get something useful into the business, we need one job, one accountable owner and one result we can actually inspect. We prove that first, and if it works we add the next job, and if it does not work we have something small enough to fix.

That sounds less impressive than a company-wide agent system, but it is far more useful.

Does this workflow need an AI agent?

Before we build anything, we need to decide whether an agent is even the right tool.

OpenAI's practical guide says agents fit work where normal rules start breaking down: decisions that need context, rule sets that change too often to maintain, or jobs that depend on unstructured information such as emails, call notes and documents.

If the process is completely predictable, use normal automation. If an invoice arrives, the supplier number is present and the amount is under a fixed limit, we do not need an agent to move that invoice into the right system. A rule can do it faster, more cheaply and with less uncertainty.

The agent becomes useful when the question is more like: “Read these 20 call notes, work out which deals are losing momentum, explain why and tell the account owner what needs attention.”

There is judgement in that job. The language will change from call to call, the evidence sits inside unstructured notes, and the answer needs to explain itself. That is where an agent starts to make sense.

This is the same decision we make when working out what to automate with AI. We are not looking for a reason to use the technology. We are looking for a business job where the result is useful enough to measure.

What should your first AI agent actually do?

One job means one trigger, one defined output and one person who owns the result.

Take the call-note example. A loose brief would be: “Help the sales team understand the pipeline.” That could mean almost anything, and when the output is bad nobody knows whether the prompt, the data, the model or the original request was wrong.

A useful brief is much tighter:

• Every Friday at 15:00, read the notes from the week's 20 priority sales calls.
• Identify deals where momentum has fallen since the previous interaction.
• Explain the evidence in the notes and link back to the relevant call.
• Send the review to the named account owner.
• Escalate uncertain cases instead of making up a conclusion.
• Measure whether the owner agrees with the flag and takes the next action.

Now we have something we can run against historical examples, and we can ask five account owners whether the output would have changed what they did that week.

The unit is a skill with one job. It can sit inside ChatGPT, Claude, Codex or another agent environment, but the product name is not the important bit. The important bit is that a stranger can read the brief and understand what goes in, what comes out and who is accountable.

I have packaged that process into the open-source Workflow to Agent Brief skill. You give it one recurring workflow and it returns an agent-or-automation decision, the one-job brief, a small evaluation set and a safe first experiment.

Keep the first system legible

Anthropic's work with dozens of teams found that the strongest implementations used simple, composable patterns, and their recommendation is to start with the simplest solution and add complexity only when the measured result improves.

That matters because complexity arrives very quickly. We give the agent three tools, then we add another agent to check the first one, then we add routing, shared memory and five different failure paths, and before we have proved the original job we are debugging the system around it.

So for the first version, we keep it legible:

1. Clear instructions for one job.
2. Only the tools and data required for that job.
3. Guardrails for what the agent must not do.
4. A human hand-off when confidence is low or the consequence is high.
5. A named owner who reviews the output.

This is also why I keep coming back to orchestration rather than vague autonomy. The goal is not to remove people from the process. The goal is to give one person a better piece of work, at the right time, with enough evidence to act on it.

Watch: Anthropic on building more effective agents

Anthropic's own 19-minute session goes further into context engineering, tool design and evaluation. The useful bit for this piece is the same: we need to design the work around what the agent can see, what it can do and how we know whether the result is right.

How do we make an AI agent accountable?

The accountable owner is not the person who wrote the prompt. It is the person who can say whether the result helped and what happens when it is wrong.

For the sales example, that might be the account owner. For a support agent, it might be the support operations lead. For a finance review, it might be the controller. Somebody has to own the definition of acceptable, the exceptions and the decision to continue.

NIST's AI Risk Management Framework makes the same underlying point in more formal language: responsibility, oversight and measurement have to be designed into the system. We do not add governance at the end after an agent has already started affecting customer or financial decisions.

For a first implementation, accountability can be very plain:

• Who reviews the output?
• What is the agent allowed to read and change?
• Which cases always need a person?
• What evidence must be included with the answer?
• What error rate is acceptable for this job?
• What result makes us stop the experiment?

If nobody can answer those questions, the workflow is not ready. We need to clarify the job before we automate it.

How do we test the agent before adding more?

We start with a small evaluation set drawn from the real work.

For the call-note agent, I would take ten previous weeks or ten representative deal sets. Include the obvious examples, but also include the awkward ones: a customer who sounds positive but has stopped agreeing next steps, a delayed deal that is still healthy, and a note where the evidence is genuinely unclear.

Then we define acceptable before we run the model. For example, the agent must identify at least eight of the ten known momentum problems, include the correct source note and avoid sending a confident flag where the evidence is ambiguous.

OpenAI recommends establishing the performance baseline with the strongest suitable model first, then checking whether smaller models can maintain the result where cost and speed matter. That sequence is important. If we optimise the bill before we know what good looks like, we can end up with a cheap system that does not help anybody.

We run the first version with a person reviewing every output. We record the misses, false alarms and unclear cases, update the instructions or data, and run the same evaluation again. That is the work. There is no clever shortcut around it.

The smaller-company advantage is focus

The McKinsey number shows a real gap, but it does not mean smaller organisations have already lost.

A smaller team can choose one workflow quickly, sit the builder next to the person who owns the result and change the implementation without a six-month platform programme. That is the advantage, but we only get it if we stay focused.

So pick one recurring job this week. Write down the trigger, inputs, output, owner, tools, guardrails and acceptance measure. Run it against real examples before giving it any authority, and keep the human hand-off until the evidence says otherwise.

If you want the exact structure, take the open-source Workflow to Agent Brief skill and run it against one of your own processes. It is free, it says where it came from, and it will complete the brief before it asks whether you want anything else from NavAIgate.

And if you want to compare the result with other operators, we are doing that inside the NavAIgate Skool community, where we can look at the actual workflow, the first evaluation and what needs changing.

One agent. One job. One owner. Then we prove it.

Sources

• McKinsey — The state of AI in 2026: On the road to ROI
• Anthropic — Building effective agents
• OpenAI — A practical guide to building AI agents
• NIST — AI Risk Management Framework