Most of what you are planning should not be built
Agent projects fail on governance, not on model capability. We start by cutting the list down to what is actually justified, then build the controls that let a security function sign off the part that survives.
The Problem
The failures are not technical
The models are good enough. What stops agent projects is that nobody can say which tools the thing may reach, under whose identity, with what record of what it did. That question arrives late, from someone with the authority to stop the project, and it usually does.
~40%
of agentic projects are expected to be scrapped by 2027.
~89%
of pilots never reach production.
65 to 75%
of three-year total cost of ownership is operations, not the build.
How We Work
Two questions decide it, and most things fail both
An agent is justified only where at least one of these is true. Both require the decision to be made at run time rather than designed in advance, which is the only thing that separates an agent from a script. Where neither is true, governed retrieval already does the job, and an agent adds cost, latency and assurance burden for no capability gain. This is the method, and we give it away.
Does what it does next depend on what it just found?
The path through the work is decided at run time. If you can draw the whole flow in advance, you can write the whole flow in advance, and then it is a script.
- Yes
- Incident triage, where the alarm determines the runbook, which determines the check.
- No
- “Explain how this service works”, which is one retrieval and an answer.
Does it need to run when nobody is there, and work out what to do when it does?
Both halves are required. A schedule alone does not justify an agent, because a scheduled script runs unattended too. What makes it agentic is that the choice of what to do is not fixed in advance.
- Yes
- A weekly freshness pass that decides which documents to flag based on what it finds.
- No
- “Run this report every Monday”, which is a cron job and a script.
And three that justify nothing
The questions everyone else counts as reasons to build
A scripted integration reaches several systems under one identity. A policy engine refuses and records the refusal. Neither needs a model to decide anything, so neither justifies an agent. What they decide is what has to exist before whatever you build is safe, and that is the work the audit does.
- Does it reach two or more systems, under one identity?
- Decides that you need a classified tool inventory.
- Does it enforce a rule, and does the record of that have to stand up later?
- Decides that you need an audit trail somebody else will read.
- Does it change anything in a live system?
- Decides that you need an approval gate before anything lands.
You can apply this yourself, right now, to the list you are already planning. It takes about two minutes and it runs entirely in your browser.
What You Get
Three pieces of work, priced
Start with the audit. It is deliberately cheap and deliberately fixed, because it exists to tell you whether the rest is worth doing.
Knowledge audit
The diagnostic. It decides which of your proposed agents are justified and produces the artefacts any build depends on. Most of its value is in what it tells you not to build.
£2,500 fixed
4 to 5 days
- The justification test applied to your proposed agent list, scored: these are justified, these are already delivered by capability you have, this one is a category error.
- A tool inventory. Every tool an agent may reach, classified read, platform write or operational write, with identity mode. This becomes the allow-list policy is written against.
- A control model. Identity modes, two-layer policy enforcement, approval mechanics, audit.
- An eval set. Fixed questions with known-correct sources, used to detect regression.
Build
One agent, built against the control model the audit produced. Single-tenant, deployed, and defensible to whoever has to sign it off.
From £9,000
Per agent
- One agent, scoped to a justified use case
- A governed knowledge base behind it
- The eval harness wired into delivery
- Authentication and the identity model it runs under
- Deployed single-tenant, in your estate
Run
Operations are 65 to 75% of three-year total cost of ownership. An agent nobody maintains drifts quietly, and the first sign is usually a wrong answer in front of someone who matters.
£5,000
Per month, model cost passed through
- Eval regression against the fixed set, run on every change to the model, the prompt or the corpus
- Knowledge freshness passes, with drift flagged before it reaches an answer
- A monthly assurance report your security function can file without rewriting it
- Model cost passed through at cost, not marked up
An Internal Developer Platform gives engineers a sanctioned way to get something done without asking a platform engineer: templates, self-service, guardrails compiled in. GoldenPath is ours.
The classic failure of that model is not that the paved route is bad. It is that people cannot find it. The templates exist, nobody knows which one applies, the docs drift, and engineers go round the side because that is faster than working out the sanctioned path.
An agent over a platform fixes exactly that. “How do I get a Postgres instance in dev” returns the right template, the guardrails that apply, and eventually triggers the workflow itself.
You do not need one to buy the other. Most organisations we talk to have no platform yet, and the agent work stands on its own. But each raises the value of the other, and an agent client without a paved route underneath tends to want one eventually.
Find out how many of yours survive the test
Two minutes, no sign-up, nothing sent anywhere. If it says most of your list is not justified, that is the answer working.