Tools and their edges
Every tool the agent can call is a small, explicit contract: what it accepts, what it returns, what it refuses. Vague tools produce vague behaviour, and most agent failures start there.
Services
Agentic AI Development
Software that decides and acts on its own is mostly a question of permissions rather than prompts. We build agents scoped to what they are allowed to do, and evaluated on it.
You have watched a demo where a model reads a request, checks three systems and files the result, and it worked. The distance between that and your own process is the approvals, the exceptions nobody documented, and the person whose name is on it when something goes wrong. Before asking whether an agent can do that work, ask what it is allowed to do while it tries.
Assistant or agent
Autonomy is a cost, not a feature.
An assistant in the loop
Drafting, summarising, retrieving, suggesting: a person reviews and acts on all of it. Every output passes a human before it touches anything, which makes the whole thing simple to govern.
- A wrong answer gets caught before it becomes an action
- Cheaper to run, since a person decides when to ask
- Fits work where the judgement is the hard part
- The copying between systems stays on your team's desk
An agent that finishes
It plans, calls tools and carries a task through to a result. Worth doing when the steps are many and dull, and the judgement narrow enough to write down.
- Handles the fetching and copying that eats the working day
- Needs tool boundaries, logging and a rollback path from day one
- Harder to evaluate: the failure is a sequence, not an answer
- Earns its keep on volume, not on one impressive run
What the agent is allowed to do
An agent does not get an account with broad rights and a prompt telling it to behave. It gets a named set of tools, each with its own boundary: this query, that endpoint, this range of values. Where it acts on behalf of a person or a service, it inherits their permissions and nothing more, so it cannot read a record its principal could not read.
Anything expensive or hard to undo stops at a person. Everything else is written down as it happens: the input, the tool called, the arguments it was given, the result that came back. A decision can then be reconstructed weeks later by someone who was not there. And uncertainty is a designed state rather than an accident, because an agent that guesses confidently is worse than one that stops and asks.
The moving parts
Four things decide whether an agent works
Prompts are the part everyone looks at and the part that matters least.
Holding context across steps
By step nine the agent has forgotten step two, or it is carrying so much history the model loses the thread. What gets summarised, what gets stored outside the context window and what gets fetched again is a design decision.
Evaluating a sequence
Grading a single answer is easy. A ten-step run that reached the right result by the wrong route is not, and it will fail differently next week. The test set has to be whole runs rather than answers.
Cost and latency at volume
An agent that reasons at length and calls the model repeatedly is fine in a demo and untenable across a queue that never empties. Token spend and wall-clock time belong in the design, not in the post-mortem of a pilot.
How the work runs
Agent projects go wrong early, in the choice of what to automate, more often than they go wrong late. So the first work is narrowing: one process, one set of tools, one definition of done.
- 01
Scoping
We walk the process as it is performed, including the exceptions people handle without noticing. Some of it turns out to need a form rather than an agent. You get a written scope naming what the agent will do and what it will not.
- 02
Tools and permissions
Before any reasoning is built, we define the tools, their arguments and their limits, and decide which identity the agent acts under. Review the tool contracts and the permission model; this is the document your security team will want to argue with.
- 03
Evaluation set
We collect real cases, including the ones that went badly, and write down what a correct run looks like for each. You see the case set and the scoring before a line of agent code is written, and you can add to it.
- 04
Shadow running
The agent runs against live work with its actions held back for approval, so you can compare what it proposed with what your team did. You review the queue of proposed actions and the disagreements, which is where the real design feedback comes from.
- 05
Release and operate
Autonomy is widened one action type at a time, each with a rollback path, and the whole thing ships with dashboards, runbooks and on-call procedures. You get the traces, the cost per run and the alert thresholds, in your own accounts.
What we build on
Most of this is decided for us: if you already run on a cloud and have a model provider under contract, that is what we use. Where there is a real choice, it goes to whatever your team can operate without us.
- Anthropic Claude
- OpenAI
- Google Gemini
- LangGraph
- Model Context Protocol
- Temporal
- pgvector
- Elasticsearch
- Qdrant
- LangSmith
- OpenTelemetry
- Kubernetes
- AWS Lambda
The awkward questions
Assume it will. The design question is what a wrong action can reach: anything costly or irreversible waits for a person, and the rest is recoverable. Every run is traced, so the step that went wrong is identifiable rather than a mystery. Accountability stays with your organisation, which is why the boundary of what the agent may do unattended is your decision, not ours.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.