Agentic AI is the difference between software that answers and software that acts. An agent does not just describe what should happen — it reads the state of your systems, decides on a sequence of steps, calls real tools, and produces a result. That capability is genuinely new, and it is also where most enterprise AI projects come unstuck, because acting on real systems raises questions a chatbot never had to answer.
We consult on and implement agentic AI end to end: choosing the use case, designing the architecture, integrating with your systems, securing the boundary, evaluating before rollout, and supporting it in production.
Where Agentic AI Actually Pays
The honest filter is narrow. An agent earns its keep when a task is repetitive but not rule-simple, spans several systems, and currently consumes skilled people’s time on coordination rather than judgement. Typical fits:
- Work that requires reading unstructured input — documents, tickets, emails — and then doing something with it.
- Processes that touch three or four systems that do not integrate cleanly.
- Triage and preparation work: gathering context so a person can decide faster.
- High-volume tasks where consistency matters more than creativity.
Equally, we will tell you when an agent is the wrong answer. If a task is fully deterministic, a workflow tool is cheaper and more reliable. If it needs genuine human judgement on every instance, an agent adds risk without removing work.
How We Implement
- Use-case assessment — which workflow, what it touches, what it is worth, and what could go wrong.
- Architecture and prototyping — a working slice against real systems, early, so the decision is informed by evidence.
- Integration — connecting the agent to your tools through a governed MCP layer rather than bespoke glue.
- Security and permissions — scoped access, server-side authorization, audit logging.
- Evaluation — golden test sets and tool-call testing before anything reaches users.
- Rollout and operation — staged deployment, monitoring, and a plan for when the model changes underneath you.
Why the Boring Parts Decide the Outcome
Building an agent that works once is a weekend. Building one that still works in six months — after a model update, a permissions change and a schema migration — is engineering. Most of what we do is that second thing: the evaluation harness, the permission model, the observability, the human-approval path for consequential actions.
That discipline is described in more depth on our AI agents page, and the platform we are building to make it repeatable is AgentOS.
Tell us the workflow you are considering and we will give you an honest assessment — including whether an agent is the right tool for it.
Related services
- AI Agent Development — What we build once the plan is agreed: AI agents.
- AI Evaluations, Guardrails and Observability — Related: AI evaluations and guardrails.
Questions That Decide the Use Case
The use-case assessment is mostly interrogation, and the useful questions are not about the technology. They are about how the work is checked today, what happens when a step goes wrong, and who currently notices.
Two of these can end the conversation before any architecture is drawn. A task nobody can verify cheaply cannot be evaluated, and a task whose worst action is irreversible cannot run unattended at any accuracy you are able to demonstrate up front.
- Can a person confirm the result is correct without redoing the work? If checking costs roughly what doing costs, there is no cheap verification step and no basis for a golden test set.
- What is the worst single action in the sequence, and is it reversible? Drafting, tagging and opening a ticket can run ahead of a person. Issuing a credit, mailing a customer or closing an account cannot.
- Does the shape of the work vary by instance, or is it the same every time with only the content changing?
- How often do the underlying systems change? Field renames, API version bumps and permission model changes set the maintenance floor for everything built on top of them.
- Who owns the exception path today? An agent does not remove exceptions; it surfaces more of them, and they have to go somewhere.
- What does the work look like when the input is bad? If the current process quietly tolerates incomplete input because a person fills the gap from memory, that knowledge has to be written down before any of it can be automated.
The Tool Layer Is the Interface You Actually Design
Most of the design work in an agent is not prompt writing. It is deciding what the agent is allowed to call and what those calls give back. A tool definition is an interface, and its name, description and parameter schema are read by the model on every turn, so editing the wording of a description changes behavior in the same way a code change does. Tool definitions belong in version control and in the test suite next to the system prompt.
MCP is worth using at this boundary because it puts the boundary in a separate process. The protocol is JSON-RPC 2.0 carried over stdio for local servers or streamable HTTP for remote ones, and a server exposes three kinds of thing: tools the model can call, resources it can read, and prompts it can be handed. The server holds the token for the underlying system and checks the caller before it acts, so scope is enforced by code the model cannot talk its way past.
Two constraints then shape the tools themselves. Tool results land in the context window, so any tool that returns a list needs a limit, a cursor and a way to say that more exists, or it will eventually return more than the model can hold. And any tool that writes needs an idempotency key supplied by the caller, because a timeout does not tell you whether the write happened, and the ordinary response of an agent to an unclear result is to try the call again.
Errors should come back as structured, readable data rather than as stack traces or bare status codes. A model that receives "permission denied on field owner_id" can stop and ask for help. A model that receives a 500 will usually retry the identical call until something else stops it.
What a Trace Has to Contain
Observability for an agent is a different problem from logging a web service, because the thing that failed is a step inside a sequence and the sequence is different on every run.
When someone reports that the agent got it wrong, the plausible causes are: it chose the wrong tool; it chose the right tool and passed bad arguments; the call succeeded but the upstream system returned stale or partial data; the call was refused on permissions and the model wrote around the refusal instead of stopping; or every call was correct and the final summary misread them. If the only thing recorded is the final assistant message, all of these present identically as the AI getting it wrong, and none of them can be reproduced.
So the record has to be per step rather than per conversation, and it has to be complete enough to replay:
- The model identifier and the snapshot version actually used for that call.
- The system prompt and tool definitions in force, referenced by version or hash rather than copied in.
- Full arguments as sent and the raw response as received, before any formatting or truncation.
- Decision points: where approval was requested, what the approver was shown, and what they chose.
- Retries, marked as retries and distinguishable from first attempts.
- Token counts and latency per step, which is how you find the tool that is quietly returning forty thousand tokens of JSON on every run.
- A redaction rule applied at write time, because a trace of a system that reads customer data is itself customer data.
Model Versions, and Why One Passing Run Proves Little
Agents are sampled, not computed. The same input with the same prompt and the same tools can produce a different tool-call sequence on the second attempt, so a single successful demonstration is evidence that the path exists, not that it is reliable. Anything measured on one run should be measured across several and reported as a rate.
Pin the acting model to an explicit snapshot rather than a floating alias, because an alias moves on the provider's schedule and the behavior change then arrives with no deploy on your side.
Pinning buys a known window rather than permanence, since providers publish deprecation dates for snapshots. The end of that window is a comparison exercise, and the differences that matter tend to show up in unglamorous places first: how strictly the model holds to a schema, how readily it asks for approval instead of proceeding, how it reacts to a tool error. An evaluation set that only checks final answers cannot see any of that, so it has to assert on the calls as well.
What the Work Depends On From Your Side
Almost none of the dependencies are engineering time. They are access, decisions and data, and each one is normally owned by somebody who is not in the project meeting. Naming them early is usually the difference between a prototype that runs against your systems and one that runs against mocks.
- A named owner of the workflow who can say what a correct outcome looks like and settle the edge cases when two people in the room disagree.
- A non-production environment, or an agreed subset of production the agent is allowed to touch.
- Service credentials scoped to the actions the agent is meant to take, issued as their own identity rather than borrowed from a person's account, so the audit log can tell the two apart.
- A network path between the agent runtime and the systems it calls, and whoever signs off on allowlists, private endpoints or VPN access.
- Seeded data that includes the awkward cases: the malformed input, the duplicate, the record with a missing reference. Clean sample data hides the failures you are trying to find.
- A decision on which actions require human approval before they execute, and who is on the other end of that request.
- A destination and a retention rule for traces, which will contain whatever the agent was able to read.
Frequently Asked Questions
What do we get out of the consulting phase itself?
Documents and a prototype, not a production system. The artifacts are an architecture decision record covering where state lives and which systems the agent may reach, a permission matrix listing every tool with the identity that calls it and the actions that identity may take, a labeled evaluation set built from your own cases with the expected outcome for each, and the code from the prototype slice. Of those, the evaluation set holds its value longest, because it is written against your business outcomes and stays valid when the model, the framework or the vendor underneath changes.
Do we have to build MCP servers, or can we use ones that already exist?
Both happen. Vendors and open source projects publish servers for common systems, and an existing server can be reused if it already enforces authorization itself. The more frequent problem is scope: a published server often exposes the entire surface of an API because it was written for one trusted developer on a laptop, which is far more than an agent acting on your behalf should hold. The usual answer there is a thin server of your own that wraps the same API and exposes only the operations the workflow needs.
Where does the agent actually run?
The runtime and the MCP servers normally sit next to your systems, because that is where the credentials and the network routes are. The separable decision is where the model runs: a provider API called over the internet, a managed model endpoint inside your own cloud tenant, or an open-weight model you host yourself. That choice is usually made by your data classification and your list of approved processors rather than by engineering preference, and it is worth settling before the architecture, because a self-hosted model changes what tool-calling reliability you can assume.
How do we choose which model the agent runs on?
By the failure mode you care about, tested against your own evaluation set, rather than by published benchmark scores. What decides it in practice is tool-call reliability when there are many tools and nested argument structures, how much context window you need once tool results are landing in it, latency per step (an agent that makes eight calls pays the per-call latency eight times), and cost per completed run at realistic volume. It is common to end up with two models in one system, a cheaper one for retrieval and summarizing steps and a stronger one for the step that decides to act.
Can an agent work against a system that has no API?
Technically yes, through browser automation, and it is the most fragile option available. Page layouts change without notice, sessions expire, multi-factor prompts stop unattended runs, and some vendor terms prohibit automated access outright. A database view, a scheduled export or a supported integration is worth real effort to obtain first. If the UI genuinely is the only surface, treat the automation as a maintained component rather than a one-time build, and keep a human approval step in front of anything it submits.
What usually takes the longest to arrange?
The access requests, not the engineering. They are granted by security, identity and network teams who are not on the project, each with its own queue, approver and review cycle. The practical consequence is that they are worth starting when the use case is chosen, rather than when the prototype is otherwise ready to point at something real.
How do we know the agent still works after something changes?
The evaluation suite should re-run on a fixed trigger rather than on suspicion: any change to a model version, system prompt, tool description or upstream schema. Production is the other source of cases, and the most valuable ones are the runs where a person overrode the agent, rejected an approval, or corrected the output afterwards. Results have to be stored per run as well, so that "it got worse" can be shown as a specific case that used to pass and now does not.