A demo answers questions. A production agent takes actions, and stops before the consequential ones.
Multi-step agents that hold state, call your systems with typed arguments, and pause for a person where you decide it matters. Built on LangGraph and MCP. When a full agent is more than the job needs, the same machinery runs lighter automations.
Five components of an agentic AI system
Each one lands in your repository as it is built, not in one handover at the end.
Agent graph and state model
The control flow is an explicit LangGraph graph, not a prompt, because a graph can be read, tested and argued with. State is checkpointed, so an interrupted run resumes from the last completed step.
The graph in your repository, the state schema, and a diagram that matches the code.
Tool layer
Every action the agent can take, defined with a schema and a permission. MCP servers where you want one shared interface; direct adapters where that is all the job needs. Read and write tools are kept apart.
Tool definitions and schemas, plus a written list of what the agent may and may not touch.
Human-in-the-loop checkpoints
The graph interrupts before any step you have marked consequential. A person approves, edits or rejects; the run resumes from that same step. Which steps qualify is decided in scoping, not after the first incident.
An agreed checkpoint list and an approval path your team will actually use.
Evaluation and traces
An evaluation set built from real cases, run on every change. Per-run traces record each prompt, tool call and result, so a failure is something you open and read, not something you try to reproduce.
The evaluation set, the harness that runs it, and traces you can search when a run goes wrong.
Deployment and handover
Docker images, deployment onto your infrastructure, monitoring wired up before go-live, and a walkthrough that ends when your engineers can change the graph without us.
A running system, the documentation to operate it, and no dependency on us.
What one request actually does
The shape of every agent we build; the node names change with the work.
Request · FastAPI
An authenticated call starts a run. The caller identity travels with it and decides which tools that run is allowed to use.
Reads the state, decides the next step. One decision per pass, not a plan followed off a cliff.
Reranked search over your documents, only on the steps that need it. A tool the graph chooses, not a prefix on every prompt.
One tool call: typed arguments, scoped permissions, result written back into the state.
Conditional edge · back to plan while the exit condition is unmet.
A step cap in the graph means a stuck run fails visibly instead of looping.
Checkpointer · every step is written to the store before the next one starts, so a paused, failed or approved-later run resumes from the last completed step.
Human checkpoint · graph interrupt
Before a consequential step the run pauses. Approve, edit the arguments, or reject; it resumes from that same step.
Response + run trace
The answer goes back to the caller. Every prompt, tool call, argument, result, latency and cost is recorded against the run id.
- Persisted
- Graph state, step checkpoints, approvals and who gave them.
- Recorded
- Prompts, tool calls and arguments, results, latency, cost per run.
- Replayable
- The evaluation set runs the same graph over known cases on every change.
fig. 01 · the tool layer sits behind act: MCP servers or direct API adapters,
each with a schema and a permission scope.
How the work is structured
Fixed scope, priced before the build. A retainer afterwards is optional, never assumed.
Scoping
We walk the workflow, mark where a wrong action is expensive, and test whether this needs an agent at all. Scope and price are agreed here.
One real path, built
A single path end to end on your data: retrieve, act, checkpoint, respond. It proves the approach or changes it while changing is still cheap.
Build
The remaining paths, tools and evaluations, in slices you can run as they land. A weekly demo of what works, not a report about what will.
Deploy and handover
Onto your infrastructure, with monitoring, traces and cost tracking in place before go-live, then a recorded walkthrough with your engineers.
- Architecture, the graph, the tool layer and the evaluation harness
- The build, in your repository, on your stack
- Deployment onto your infrastructure and the monitoring around it
- Runbook, architecture documentation, and a handover session with your engineers
- A named technical contact who can answer questions the same day
- Access to the systems the agent has to reach, or someone who can grant it
- The decision on which steps count as consequential (we advise, you decide)
- A person on the approval path, and sign-off before go-live
The day-by-day version is on the process page.
When you need a script, not an agent
An agent is the right answer less often than the noise suggests. These are the cases where we say so.
If the workflow always runs the same way, an agent is a slow, expensive script. A queue and a scheduled job beat it, and we will say so.
Classification, extraction or summarising one document is a single model call behind an API. We will happily build that; it just is not this.
An agent is only as capable as its tools. If the systems in scope have no API, the first project is integration work, and the agent comes after.
If every action must be provably correct with no human review, language models cannot guarantee that. Rules can, and we would rather point you at rules.
A multi-step run costs several model calls plus retries. If the work is worth less than that, the honest answer is no, and the first call is a better place to hear it than the first invoice.
Tell us the workflow.
Describe the steps and the point where a wrong action would hurt. If it needs a script rather than an agent, that is the first thing we will say back.