← Back to blog

By Evoloop

/

11 July 2026

/

9 min read

/Adoption

Why the second AI agent costs less than the first: one assistant, many jobs

A business looking at its first AI agent gets a quote, and the quote looks expensive. That reaction is fair, but it usually rests on a misread. The number in front of you is paying for two different things at once: the job you asked for, and the groundwork every job of this kind needs before it can run at all. Nobody separates the two on the page, so the first project carries the full weight of both, and the real economics stay hidden. Once you can see them, a pattern appears that changes how you plan. The second agent costs less than the first, and the third less again, because most of what made the first one expensive only has to be built once.

Two things hidden inside one quote

Think about what a useful agent actually requires. It needs the job itself defined and built: read these incoming orders, draft this quote, watch these deadlines. That part is specific to the task, and it is the part everyone pictures when they imagine the project. But underneath it sits a second layer that has nothing to do with any single job. The software has to reach into your systems in a controlled, logged way. It often needs a place to hold the knowledge it draws on. And it needs rules about what it may do on its own and what it must pass to a person. That second layer is the groundwork, and the first quote pays for all of it even though almost none of it is unique to the first job.

This is why comparing the first project to the price of a subscription feels unfavourable. A subscription hides its groundwork by spreading it across thousands of customers and charging you a slice every month forever. A build puts the groundwork in front of you once. The honest way to read the quote is to ask which part is the job and which part is the foundation, because the foundation is the part you stop paying for.

What the groundwork actually is

Elsewhere on this site the groundwork gets summed up as one controlled door, and behind the image sit specific, buildable things.

  • Read-only credentials, issued per system and scoped to exactly the data each job needs, instead of one account that can see everything.
  • An audit log that records every query the software makes and every action it takes, so what happened is never a matter of memory or trust.
  • An approvals workflow with named people in it, so "a person signs this off" is a defined route with a defined owner, not a hope.
  • Where the work calls for it, a knowledge store holding runbooks, procedures, product data, and past decisions, so the software acts with context rather than guessing.

Standing all of that up the first time means mapping your systems, agreeing what may be touched, and getting the right names into the workflow. That is where much of the first quote goes.

Reuse, for a later agent, means inheriting all of it. The second agent does not get a second connection designed from scratch. It gets its own scoped credentials issued under the same model, writes to the same audit log, and routes its escalations through the same approval workflow to the same named people. The knowledge store assembled for the first job is already there for it to read from and add to, because runbooks, procedures, and past decisions are the business's shared property, not the possession of one agent. Which is why the conversation about agent two starts at "what is the job and what may it touch", instead of "how does anything get connected to anything at all".

Why the second agent is smaller to scope

The clearest way to see the difference is to sit in the two scoping conversations. Scoping the first agent, a large share of the questions are about plumbing. Which systems does the software need to reach, and how does it connect to each one safely? What accounts and permissions have to be created, and who signs them off? Where do the logs live, and who looks at them? How does an approval actually reach a named person, on what channel, with what happens if they are away? Where do the runbooks and procedures live today, and what state are they in? Every one of those questions turns into a line of work on the quote.

Scoping the second agent, those questions already have answers. The conversation goes straight to the job itself: what exactly it does, what it may touch and what it must escalate, which slice of the knowledge store it needs and what is missing, and what its approval rules are. That is still genuine work and it deserves care. But whole categories of effort have simply vanished from the quote, which is why the second agent is a smaller thing to scope and price than the first, and the third smaller again. This is deliberately qualitative: no fixed discount, no promised figure, because the size of any job depends on the job. The claim is only about shape. The questions that dominated the first project do not need asking twice.

The subscription stack runs the economics backwards

Picture instead a business adding the fifth tool to a growing subscription stack. Before anyone logs in, someone has to do due diligence on a new supplier. There is now a fifth place company data lives, which someone has to track for GDPR and account for in the privacy notice. There is a fresh set of per-seat licences that grows every time you hire, a fifth login for every member of staff, and, waiting at the far end, a fifth export problem, because data tends to come out of these tools far less easily than it went in. And the wiring is the quiet cost: the fifth tool does not need one connection, it may need a connection to each of the four already there, so integration effort grows with every pairwise link rather than settling down. None of that spending compounds into anything the business owns. Each addition makes the next one harder, which is the built-once economics running in reverse.

What one foundation can host over time

It helps to see the range of jobs a single foundation can carry. Each of these is an agent in the sense that matters here: a bounded job, with defined access and defined approval rules, not a new platform to buy and bolt on.

  • Reading incoming orders or enquiries out of email and PDF attachments into a clean draft, ready for a person to approve rather than retype.
  • Drafting a quote from live pricing and current stock, so the numbers are right and the human just checks and sends.
  • Watching contract deadlines and notice periods, and raising the ones that are about to matter before they slip past.
  • Spotting patterns across incoming complaints that are hard to see one message at a time.
  • Preparing a short morning summary of yesterday's numbers and anything that fell outside the normal range.

None of these is a separate product. They could be five jobs running through one connection, drawing on one knowledge store, following one set of approval rules, added one at a time as the evidence justifies them. From the second onward, each would be an extension of something that already exists rather than a fresh build from zero.

A real example of the groundwork in action

This is not theory. Evoloop recently built an infrastructure support agent for a UK business that watches monitoring alerts, investigates what is behind them, fixes routine faults that sit inside an agreed safe list, and escalates anything consequential to a person. What makes it work is exactly the groundwork described here. It has a knowledge store of runbooks and past incidents it reads before it acts, and it has a controlled, scoped connection to the systems it looks after. The earlier post on this site, on the AI junior sysadmin at /blog/ai-sysadmin-agent-infrastructure, walks through how that agent decides what it may touch and what it must hand to a human. The point for this post is narrower: the foundation that agent runs on is the same kind of foundation a second, unrelated job would reuse.

The rule that makes compounding safe

Adding agent after agent to one foundation only makes sense if the foundation is safe to build on, and one design rule keeps it so: the software prepares, a named person approves anything that matters, and everything it does or declines to do lands in the log. New agents inherit that rule rather than inventing their own, which means each addition arrives already governed. You are not deciding afresh, every time, how oversight works. You are pointing a new job at an oversight model that is already in place and already trusted.

The approval gate is not overhead to remove once you trust the software. It is the thing that lets you keep adding jobs to one foundation without the risk growing with them. Autonomy on the routine, a person on the far side of anything consequential, and a full log of both.

How to sequence it

If the second agent is cheaper than the first, the order you build things in matters. A sensible sequence looks like this.

  • Start with the job where time is most visibly being lost, and where the result is easiest to measure. A clear before-and-after is worth more than a clever one.
  • Record a baseline before anything is built. How long the task takes now, how often it slips, what it costs in attention. You cannot judge the payback without it.
  • Let the first agent run long enough to produce evidence, then let that evidence choose the second job rather than a guess made on day one.
  • Reuse the foundation deliberately. When you scope the second job, be clear about what the door and the knowledge store already give you, so the quote reflects only the new work.

The honest caveats

This argument only holds if a few things are said plainly. The foundation is real up-front work, and the first project carries it, so the first quote will always look heavier than the ones that follow. That is not a flaw in the pricing. It is the shape of building something you own. A business with exactly one job to automate may build the first agent and never need a second, and that is a perfectly good outcome. The compounding is an option, not an obligation, and you should not build a foundation for jobs you do not have.

The last caveat is the sharpest. Groundwork done badly makes every later addition riskier, not cheaper. A master key instead of a scoped door, no logging, no approval rules: those choices might look faster on the first job, and they turn every agent added afterward into another way for a single mistake to reach something it should never have touched. Cheap-to-extend depends entirely on the foundation being built well. A bad foundation compounds the wrong thing.

So read the first quote for what it is. Part of it buys the job in front of you. The rest buys a door, and where the work needs it a memory, that every job after this one gets to walk through. That is why the second agent costs less than the first. Not a trick of pricing, but the plain result of building the expensive part once.

If one job in your business is visibly eating time, bring that job to a call. Thirty minutes is enough for an honest read on whether it should be your first agent, what groundwork it would need underneath it, and what baseline to record before anything gets built.

Ready to explore AI for your business?

Three ways to get started:

  • Book a Workflow Review - 30-minute assessment of where AI fits your practice
  • Get in touch - Evoloop responds within one working day
  • See Evoloop's services - structured scoping and builds