You probably don't need to build an AI agent for that

Somebody on your team has a repetitive, valuable, slightly fiddly process. The instinct, almost every time, is to build an agent for it. Scope it, spec it, find budget, put it in the roadmap.

That instinct made sense two years ago. It usually does not now, and the reason is worth understanding, because it changes what your AI roadmap should have on it.

What an agent actually is

Strip the word back and an agent is three things:

1. A model that can reason about a task.
2. A set of tools it can call to affect the world.
3. A set of instructions telling it what good looks like here.

You already have the first. You are paying for it. It is the same model whether the task is claims triage or reconciliation.

So a bespoke agent build is really a project to produce the second and third things, plus the plumbing between them, for exactly one workflow. That was a reasonable thing to commission when there was no standard way to connect a model to your systems and no standard way to package instructions. Both of those now exist.

The Model Context Protocol is an open standard for connecting models to tools and data. Connect a system once and every agent you run can reach it, with no new integration per use case.

Agent Skills are folders containing a SKILL.md file with instructions, plus optional scripts and reference material. The model loads one when a task matches its description. That is where your format, your thresholds, your escalation rules and the four things everyone forgets actually live.

Tools and instructions were the expensive parts. Both are now configuration.

The composability argument

This is the part that decides it, and it is not really about cost.

Purpose-built agents do not combine. An agent built for invoice matching does invoice matching. If you later want invoice matching plus supplier risk checks plus a drafted email to the supplier, that is a new scope, a new build, and a fourth thing to maintain.

Skills combine by default. The model loads whichever ones the task calls for and uses them together. Ten well-written Skills cover far more than ten purpose-built agents, because they cover the combinations too. That gap widens with every Skill you add.

There is a maintenance version of the same point. A bespoke agent has to be kept working as your systems change, forever, by someone who understands its code. A Skill is a markdown file describing how a job should be done. When the escalation threshold changes from £25,000 to £40,000, somebody edits a line. That is not a release.

The economics, briefly

Automating a process has always carried a floor: requirement, backlog, scoping, build, integration, testing, and maintenance forever. Realistically weeks to months. That floor determined what was worth automating at all, and almost everything sat below it. The weekly reconciliation that eats half a day. The report rebuilt by hand each month. Individually too small to justify a project, collectively enormous.

Describing a task and connecting it to the systems it touches does not clear that floor. It is closer to writing a good procedure note, and the person who understands the process can do it themselves.

The failure rate of the old approach is not hypothetical. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, from a poll of over 3,400 organisations, citing escalating costs, unclear business value and inadequate risk controls. Anushree Verma of Gartner describes most current agentic projects as early-stage experiments driven by hype and often misapplied.

Read that as a unit-of-work problem rather than a technology problem. If every workflow needs its own project, most of them will not survive contact with a prioritisation meeting.

When you genuinely should build

This is not an argument that custom agents are obsolete. Build one when:

• The behaviour must be deterministic and owned in code, with tests.
• It runs unattended at volume, where per-run cost and latency matter.
• It is a product feature your customers touch, needing SLAs and rollback.
• The logic is genuinely algorithmic rather than procedural, so writing it down in prose would be a worse description than code.

Those are real, and they are narrower than the current build rate implies. For internal work where a knowledgeable person can explain the task to a new joiner, that explanation is the Skill, and you are most of the way there already.

The failure nobody counts

Cancellation is the visible failure. There is a quieter one that is far more common, and it is the reason so little of this compounds.

Someone works out a genuinely excellent way to do a task. They write it up as a Skill. It works. And it stays exactly where they made it.

This is not carelessness, it is the default behaviour of the tools. Anthropic's own documentation is explicit about the sharing model:

• In Claude Code, Skills live in ~/.claude/skills/ for personal use or .claude/skills/ in a project.
• On claude.ai, custom Skills are "individual to each user. They are not shared organization-wide and cannot be centrally managed by admins."
• Through the API, they are workspace-wide.
• And custom Skills do not sync across surfaces: one uploaded in one place is simply not available in another.

So the natural resting state of a good Skill is one machine, one account, one person. Nobody reviews it. Nobody improves it. Nobody else benefits from it. When that person changes team, it goes with them.

That produces a genuinely odd situation. The same organisation is simultaneously running training to teach people how to use AI, and quietly failing to capture the working methods its best people have already invented. We wrote about the sharing options and what each one actually gives you separately, because the choice matters more than teams expect.

There is a governance edge to this too. Anthropic's guidance is to use Skills only from trusted sources, because a Skill can direct a model to invoke tools or run code in ways that do not match its stated purpose. A Skill nobody reviewed, running on a laptop against live systems, is the same shape as every other shadow AI problem: useful, invisible, unaudited.

What to do instead of scoping an agent

1. Write down the task as if onboarding someone. If you can explain it to a new joiner, you can write the Skill. That document is the asset, not the code.
2. Connect the systems once, not per use case. An MCP connection to your ticketing system serves every workflow that touches tickets. Sequence connections by how many processes they unlock.
3. Start with the highest-frequency, most standardised task. Frequency makes it worth doing, standardisation makes it work, and a checkable output makes it provable.
4. Publish it where the team can actually run it. This is the step that gets skipped, and skipping it is what turns a real capability into a personal habit.
5. Keep the record. What ran, on what, and what it produced. Without that you are back to the problem of not being able to tell whether any of it paid off.

The short version

The question is not "should we build an agent for this". It is "what does the agent need to know, and what does it need to reach".

Answer those two and you have a Skill and a connection, which is the same capability without the project. The remaining work is distribution: making sure the answer reaches everyone who has the same problem, instead of living on the machine of whoever happened to work it out first.

That is the part Connor is built for. Take the methods your best people have already proven, publish them as Capabilities the whole team can run, keep them connected to the systems the work lives in, and keep a record of every run.