The fastest way to work out whether you want an agent is to look at ones that already exist. These are real builds, ours and our clients’, with what they actually do and what they actually saved.
Five agents we built with clients
Email triage, for a fashion PR agency COO. Sorts 200-plus emails a day, drafts replies in her voice, flags the ones that need her judgement. Saved around eight hours a week and took four working sessions to build.
Proposal drafting, for a content agency. Turns a discovery-call transcript into a tailored proposal inside 24 hours, pulling the matching case studies and holding their house style. It has since become part of what they sell, which is a bigger step than it sounds and we come back to it below.
Contract review, for a solicitor’s practice. Flags unusual clauses, compares against the firm’s standards and produces a comment track for a partner to review. Used on every new matter. Note the shape: it never decides anything, it surfaces things for someone who does.
Monthly client reporting, for a marketing agency. Pulls analytics, campaign and social data, structures it to their template and drafts the commentary. Three hours of assembly became 25 minutes of review.
Overnight research, for us. Runs at 4am, scans the AI tool landscape and leaves a briefing. It is how we track 100-plus tools a month without anyone reading 100 newsletters.
What the good ones have in common
Look at that list again and the pattern is not the technology. It is the shape of the job.
- They are frequent. Daily or weekly, never twice a quarter.
- Someone can describe them. The steps existed before the agent did.
- A person sees the output before it matters. Every one drafts, flags or prepares. None press send on anything irreversible.
- They replace assembly, not judgement. The reporting agent does not decide what the numbers mean. It removes the three hours of gathering so the human hour goes on the interpretation.
That last one is the honest description of where the value sits right now, and it is a more useful promise than autonomy.
How to find the ones in your own company
Reading somebody else’s examples is a start. Finding your own is the actual skill, and it is more systematic than people expect.
Look for the tells, not the technology. Good candidates announce themselves the same way every time:
- It happens in a batch. Month end, Friday afternoon, the first of the month. Anything people brace for.
- Somebody comes in early to get ahead of it. That is a queue, and queues are where agents earn their keep.
- It moves between systems by copy and paste. Every paste is a step somebody is doing because two tools do not talk.
- People complain about it in the same words. Consistent complaints mean a consistent process, which means it is describable.
- It is the reason something else is late. The bottleneck is usually two steps upstream of where anyone is annoyed.
Then run it through the two questions from the other pages. This is where the playbook earns its keep, because the same candidate goes through both lenses:
- From the process page: could three people describe it the same way, can you draw the steps, what starts it, and does the arithmetic work? Most candidates die here, and they should.
- From the tools page: what kind is it, which tier would build it, and where would it have to run? That is what turns a good idea into a scope and a number.
A candidate that survives both is worth a conversation. One that fails the first is a process job, and one that fails the second is usually a budget or hosting conversation rather than a no.
Teach everyone to spot them, not just the AI people
Here is the awkward structural fact. The people who know where the slow processes are almost never in the room when AI gets discussed.
Leadership picks the projects, and leadership sees the org chart rather than the friction. The person who actually knows that reconciliation takes four hours because two systems disagree about client codes is the person doing the reconciliation, and nobody has asked them.
So the highest-return AI investment in most companies is not a build. It is teaching enough people to notice, describe and hand up. Three skills, and none of them technical:
- Notice. Recognise the tells above in your own week. Most people have two or three candidates within a day of being asked properly.
- Describe. Write the job down clearly enough that somebody who does not do it could follow along. This is the same skill as the first one on the People page, and it is worth having whether or not anything gets built.
- Hand up. Give a manager or the AI team something they can act on, rather than a wish.
Start with the people already using AI privately. Most organisations have a quiet population doing this without being asked, in their own time, often without telling anyone because they are not sure they are allowed. They are your best spotters, they already know what these tools can and cannot do, and they are usually invisible on any plan. Finding them is cheaper than hiring anyone.
This is most of what our training programmes actually do, and it is the part that keeps paying after the first build ships.
How to hand it over so it actually gets scoped
The gap between spotting something and getting it built is almost always a communication failure rather than a budget one. Somebody says “could we get AI to do the reports?” and it dies, because there is nothing there to cost.
Write these eight things instead. It takes fifteen minutes and it is the difference between a wish and a scope.
| What to write | Why the AI team needs it |
|---|---|
| The job, in one sentence | If it takes a paragraph, it is probably two jobs |
| How often it happens, and how long it takes you now | This alone kills or funds it. Twice a month at twenty minutes is not a build |
| Everyone who touches it | Cross-department means the process may not exist in one head, and that changes the job entirely |
| What arrives, and from where | Decides whether something has to read messy input |
| What leaves, and to whom | Decides whether it is drafting or acting, which decides the risk |
| Where you have to make a judgement call, and the rule you use | The most valuable line on the page, and the one nobody writes down |
| What happens when it goes wrong, and who finds out | Decides how much oversight it needs, and sometimes decides not to build it |
| What it would need access to | Turns into permissions, and often into the hardest part of the project |
If you are the manager or the AI team receiving this, three things to send back. Is this the same process somebody else has already described to you, under a different name? Would this person’s colleague describe step four the same way? And what would we stop doing if it worked, because an agent that adds a review step to a process nobody trusts has made things slower.
Nothing in that list is technical. That is the point: the scoping conversation is a process conversation, and the technology question comes afterwards.
We ran the test on our own products first
Before you take this to a supplier, here is us applying it to ourselves. Most of what we run is not an agent.
| What we run | What it actually is | Agent? |
|---|---|---|
| Nova chat | One model call, streaming, no tools | No |
| Nova extract | One call, structured output | No |
| AI Advantage Canvas | One call, structured output | No |
| Second Brain Test | One call, structured output | No |
| PRD Agent | One streaming call, no tools | Depends whose definition |
| Agent Builder | A real loop, model-chosen tools, hosted sessions | Yes |
| Our LinkedIn build | An orchestrator plus role prompts, sharing one context window | Not as wired |
Five of seven are single calls, and that is the correct design for those jobs rather than a shortcut. A focused single call is cheaper, faster and more reliable than an agent that can wander.
Now look at the fifth row properly, because it is the most useful one here. Our PRD Agent makes a single streaming call to a model. No tools, no loop. By Anthropic’s definition it is not an agent. By Microsoft’s it comfortably is: an expert system doing a job on somebody’s behalf. Both readings are correct.
It is also genuinely agentic as an experience. You answer questions, it works, a document comes out. What it is not is agentic in architecture, and those two things come apart more often than the marketing suggests.
We call it an agent in the product name because that is what it does for the person using it, and we mark it as arguable here because that is what it is underneath. If that looks like having it both ways, that is precisely the problem this whole page is about, and we would rather demonstrate it on something of ours than only point at somebody else’s.
If a supplier cannot show you their version of this table, that is worth noticing.
The four audiences, and why it matters
The same agent has wildly different requirements depending on who relies on it. The build is identical. Everything around it is not.
- Me. It works when I am driving it. Nothing else needed.
- My team. It needs a name, written instructions, and someone to ask when it misbehaves.
- An internal system. It has to keep working when the person who built it is on holiday.
- Our product. It has to work for people who have never met you.
The line that costs money is the last one. Crossing it adds permissions, authentication, monitoring, error handling, support, onboarding, security and liability. None of that is the agent. All of it is the bill.
Prototype for yourself. Design for the team. Engineer for the customer.
Most people cross that line by accident
The content agency above crossed it deliberately, and priced it. That is the rare version.
The common version goes like this. You build something for yourself. A colleague asks for access. Then a client asks. Now you have a support burden nobody priced and an availability expectation nobody agreed to. No decision was ever taken. The line moved underneath you.
Since August 2026 that step carries a legal dimension too. Use an agent internally and you are a deployer, with the lighter set of duties under the EU AI Act. Put your name on it, change it substantially, or sell access to it, and heavier obligations can attach. Worth reading alongside our EU AI Act guide, and worth knowing before rather than after.
None of this is a reason not to productise an agent. It is a reason to do it on purpose.
So what should you build first?
Pick the thing you do most often that you would be slightly embarrassed to describe out loud, because it is so repetitive. Inbox triage. Turning notes into a first draft. Assembling the same report from the same four places.
Then read from idea to agent, which is the sorting hat: it tells you whether the thing you have in mind is an agent, an automation, or a process problem wearing a software costume.
If you would rather talk it through than read on, that first conversation is usually shorter than people expect.