AI agents that act on your systems and cannot do more than you allowed
Agents built on Claude that read, propose and act inside your own systems through narrow tools and least-privilege credentials, with a person approving anything irreversible, an evaluation set, a spend ceiling and a log of every call.
This page is for buying an AI agent that does work inside your business systems: one that looks things up across the CRM, the job system and the inbox, proposes what to do, and does some of it. The engineering that matters is not the model. It is what the agent is allowed to touch, how that is enforced outside the prompt, and who confirms the step that cannot be undone.
Our evidence is one build, stated carefully. On a UK commercial solar installer's operating system, the in-app copilot runs a tool-use loop over the live CRM. Its writes call the same business logic as the REST API and sit behind a flag, the same tool registry is exposed as an MCP server with an OAuth layer, and the public website chatbot gets exactly one tool, which captures a lead. The system is live with the client team. The write-up does not say how heavily the copilot is used, and no case study on this site is an agent acting unattended in production.
We build agents on Claude where it fits: the Claude API's tool use and MCP servers over your own systems, and Anthropic's Agent SDK where a long-running loop needs it. We are an independent studio with no partnership, certification or endorsement from Anthropic, and the model stays a setting. More often than the current enthusiasm suggests, the right answer is not an agent at all, and the first section is how to tell.
Agent, workflow, or a workflow with one model step
An agent is a model choosing its next step in a loop, with tools. A workflow is a path you decided in advance. Our own case studies sort into both, which is the clearest way to see where the line falls.
| The job | What it needed | Why |
|---|---|---|
| Work across a live CRM from a chat panel (solar operating system) | An agent with tools | The next lookup depends on what the last one returned, and writes go through the same gates as a person's |
| Classify and summarise industry news (marketing platform) | A workflow with a model step | The path is fixed. The model only classifies and summarises; the link and the title come from the feed |
| Draft an estimate from a brief (estimating assistant, a working demo) | A workflow where the model chooses from a list | The model picks parts only from price-book candidates, and code sets every price |
| Approve and pay supplier invoices | A deterministic workflow | Money moving needs rules, limits and a person, not improvisation. Our accounts payable page is built that way |
| File an inbound order onto a board and start an SLA clock (fleet order automation) | A workflow, with no model claimed | The write-up does not say a model does the parsing. The value is in the rules and the clock |
Tools split by what they can break
The tool list is the security boundary. A sentence in the prompt saying never do this is a request; a tool that cannot do it is a rule.
Read tools, given freely but narrowly
Look up a customer, list a project's open tasks, fetch a document. Each returns only the fields the job needs, through a read-only credential, with a cap on output size. Most agents should start with nothing else, pointed at staging or a copy.
Propose tools, which only create a draft
Draft a reply, propose a status change, suggest a match. The tool writes a proposal to a queue and nothing more. A person sees it beside its evidence and approves or rejects it, the same shape as invoice capture on the trading ERP, where the model proposes and the confirmation writes.
Act tools, reversible and behind a flag
Change a field, create a task, move a record on a stage. Added one at a time, each calling the same business logic as your application so validation, gates and permissions still apply, and each switched on separately. On the solar operating system the copilot's writes sit behind a flag for exactly this reason.
Tools an agent does not get
Pay, send to an outside address without approval, delete, change permissions, change bank details. Where the job truly needs one, the tool raises a request for a person to carry out. An agent that reads untrusted content and can also send or pay on the same credential is one poisoned email away from a bad day.
What an agent ships with before it touches live data
Seven controls, each enforced in code or configuration rather than in the prompt.
- 01
Least-privilege credentials
The agent never holds an account-wide token. On the fleet-telematics order system, the monday.com token that reaches commission data lives in exactly one server process, and the front end cannot import the module that talks to it without the build failing. An agent gets the same treatment: the broad credential stays in the server and the model sees narrow, typed tools. Anthropic's guidance on prompt injection says to apply least privilege so that a successful injection can do minimal damage.
- 02
An MCP server with authentication, when several clients need one door
Where more than one agent or AI client needs the same systems, the tools belong in one server with its own authentication and per-user permissions, so each person's agent sees only what that person may see. The solar copilot's tool registry is exposed this way, with an OAuth layer, so Claude can connect to it as a custom connector. Our MCP server development service covers that build; we have not published a standalone MCP server.
- 03
Your application runs the tool
With Claude's tool use, the model asks for a client tool and your application executes it and returns the result. That puts the permission check, the input validation and the rate limit in code you control, not in the model. Tool results, and anything else the agent reads, are treated as untrusted text.
- 04
A person on every irreversible step
Anything that sends, pays, deletes or could not be quietly reversed next week waits for a named person. The approval shows what will happen and the evidence for it, not a bare confirm button that nobody reads.
- 05
An evaluation set
Real cases with known-good outcomes, awkward and hostile ones included, run on every prompt, tool or model change. Did it call the right tools, in a sensible order, and stop when it should have? Anthropic's guidance on evaluations starts from measurable success criteria and held-out test cases, and so do we.
- 06
Cost caps
A step cap and a token budget per task, with a defined outcome at the cap: stop and hand to a person. Usage logged per workflow, with an alert on it. Anthropic lets an organisation set its own spend limit, and when it is reached the API returns a 429 with no retry-after header and retries keep failing, so the agent must treat that as an alert and not as something to retry.
- 07
A log of every call
Each tool call with its inputs, its outputs, the model and prompt version, and the user it acted for, written somewhere the agent cannot edit. On the trading ERP the audit table allows insert and read but no update or delete, so the trail cannot be rewritten through the API. When someone asks why the agent did that, the answer comes from the log.
What we build agents with, and why the model stays a setting
For most agents the Claude API with tool use is enough: a loop in your own code, a short list of tools and the controls above. Where an agent needs more of the machinery of a long-running loop, Anthropic's Agent SDK provides it and we would use it rather than write it again; no case study on this site uses it yet. Where the same tools must serve several clients, including Claude itself as a custom connector, they go behind an MCP server.
MCP brings its own risk. Anthropic's Claude Code documentation tells users to verify they trust each MCP server before connecting it, and notes that servers which fetch external content can expose you to prompt injection. So we prefer servers you host over third-party ones, review their scopes, and treat whatever they return as untrusted.
None of this ties you to one provider. The trading ERP fails over between Claude and OpenAI, and an agent with an evaluation set behind it can be measured on another model before anyone commits. Where another model suits the job better we will say so. Our Claude platform page and our Claude API integration page cover the wider Claude work, including pipelines that are not agents at all.
What we have built, and what we have not
The solar operating system is the agent build. Its copilot runs a tool-use loop over the live CRM, and its writes go through the same business logic as the REST API, so the pipeline's stage gates, the permissions and the audit log apply to the copilot exactly as they apply to a person. Writes sit behind a flag. The public chatbot on the client's website is given one tool, capturing a lead, and none of the read tools, which is the narrow-scope rule applied to the one agent strangers can talk to.
Two other builds bear on it without being agents. The school ERP was built with Claude Code and reviewed by seven agents that only read the code. That is agents used at build time, not an agent acting on business systems, but it is the read-only principle in practice. The fleet order automation shipped behind a shadow-mode flag that logged what it would have done before it was allowed to do it, which is how we would introduce an agent's first write.
Five stages from read-only to acting
Access widens on evidence from the log, one stage at a time:
- 01Read-only on a copy. The agent answers questions over staging data or a snapshot, and every call is logged.
- 02Read-only on live data, with the evaluation set passing and a person reading the answers.
- 03Shadow mode for any action. The agent records what it would have done, and someone compares that with what people actually did.
- 04Proposals. The agent's actions become drafts in a queue that a person approves or rejects.
- 05Narrow writes behind a flag, one tool at a time, reversible ones first, with a cap on the number of records per run.
Before the first write we agree the incident plan: how to switch the agent off, who is told, and how to find and reverse what it changed. Our article on securing AI agents sets out the tests to run with hostile documents before launch and after every prompt or model change.
What an agent build costs and what moves it
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and no case study on this site states a price or a duration. Model usage is a running cost on top, and for an agent it varies by case, because each step feeds the next. We estimate it from a sample of your real cases and budget for the expensive tail, not the average.
- How many systems the agent has to reach, and whether each has an API that can issue a scoped, per-user credential.
- How much of the job is reading and how much is writing. Every write tool needs its own approval path and its own tests.
- Whether an MCP server is needed because several clients share the tools, or the agent can call them directly.
- Whether an evaluation set exists, or has to be built from your cases first.
When an agent is the wrong answer
When the steps can be written down. A deterministic workflow, with a model for the one step that needs language or vision, is cheaper, faster, identical every time and far easier to test. High-volume work that follows the same path is a workflow, and an agent only adds cost and variance to it. When money moves, or you must prove later exactly what happened and why, use fixed rules and a person approving; our accounts payable automation page is that design.
It is also the wrong answer where nobody will read the proposals, where the systems involved cannot issue a scoped credential, or where you cannot yet describe what a good result looks like. In that last case, build the evaluation set first. You are not ready for an agent or a workflow, and the set will tell you which one you need.
Where it has shipped
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot an agent, and the write-up does not say a model does the parsing. It is here for two controls an agent needs: the account-wide token kept in one server process behind a boundary the build enforces, and a shadow-mode flag that logged what the system would have done before it was allowed to do it.Case study
- An independent school groupSchool management ERP with permissions enforced per branchNot an agent acting on business systems. It was built with Claude Code and reviewed by seven agents that only read the code, which is the read-only, narrow-scope principle applied at build time.Case study
- An Australian AV integratorAn estimating assistant where the model names the parts and code sets the pricesA working demo, and not an agent. The model chooses parts only from price-book candidates, anything else it returns is dropped, and code sets every price. It is here because a model whose choices are bounded by a list is often a better design than an agent.Case study
- A UK commercial solar installerA content engine that is not allowed to make things upNot an agent. It is a fixed workflow with model steps: the model classifies and summarises news while the link and title come from the feed, and drafts land in an approval queue. It is here as the deterministic alternative that suits most content work.Case study
Platforms that bear on it
Related reading
Neighbouring solutions
AI agent development, specifically
An agent is a model given a goal and a set of tools, deciding which tool to call next until the job is done. Building one for a business is mostly the work around the model: the tools and what each may touch, the credentials behind them, the approval step for anything irreversible, an evaluation set, spend limits and a log of every call. We build that on Claude, and we also tell you when a plain workflow would do the job better.
Usually automation, with a model at the one step that needs it. If you can write the steps and the exceptions down, a workflow is cheaper, faster and easier to test. An agent is justified when the path depends on what each lookup returns, such as working across several systems to answer a question, and an error is cheap or a person reviews the result before it matters.
By limiting what it can do rather than asking it nicely. Tools are split by consequence and start read-only, credentials are scoped to the job with the broad token kept in one server process, your application runs every tool so the permission checks sit in your code, anything irreversible waits for a person, and steps, tokens and spend are capped. Prompt injection cannot be fully prevented, so the design assumes it will occasionally work and keeps the damage small.
We build agents on Claude through the Claude API's tool use and MCP servers, and Anthropic's Agent SDK where a long-running loop needs it. We are not an Anthropic partner and hold no certification or endorsement from Anthropic. The model stays a setting, so an agent with an evaluation set behind it can be measured on another provider before anyone commits.
Only if several agents or AI clients need governed access to the same systems. One agent inside one application can call its tools directly. Where a server is right, it gets its own authentication and per-user permissions, starts read-only and calls your existing business logic. Our MCP server development page covers that build in detail.
With an evaluation set of real cases, awkward and hostile ones included, run on every prompt, tool or model change to check that it called the right tools and stopped when it should. Then in stages: read-only on live data, shadow mode where it logs what it would have done, proposals a person approves, and only then narrow, reversible writes behind a flag.
One, with its limits stated. On a UK commercial solar installer's operating system, which is live with the client team, the in-app copilot runs a tool-use loop over the live CRM with its writes behind a flag and through the same business logic as everyone else, and its tools are also exposed as an MCP server with OAuth. The write-up does not say how heavily it is used, and none of our case studies is an agent acting unattended.
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation. What moves it is how many systems the agent reaches, how much of the job is writing rather than reading, whether an MCP server is needed and whether an evaluation set exists. Model usage is a running cost on top, and for an agent it varies by case.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Tool use with Claude · Anthropic (Claude Platform Docs)
- Mitigate jailbreaks and prompt injections · Anthropic (Claude Platform Docs)
- Define success criteria and build evaluations · Anthropic (Claude Platform Docs)
- Rate limits · Anthropic (Claude Platform Docs)
- Connect Claude Code to tools via MCP · Anthropic (Claude Code Docs)
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no