AI agent development built for production, not for the demo
Agents are easy to prototype and hard to keep running. The prototype works because you tried the three cases you had in mind. Production supplies the other forty, plus an API timeout, a malformed record, and a user who phrases things nothing like your test set. The engineering is almost entirely in that gap.
WHAT YOU GET
What separates a shipped agent from a demo
None of this is about model choice. It is about what happens when the model is wrong, which it will periodically be.
Tool design
Tools with narrow contracts and clear failure modes. Most agent misbehaviour traces back to a tool that was vaguer than it should have been.
Scope and permissions
The narrowest capability set that finishes the job. Destructive actions gated behind confirmation, irreversible ones behind a person.
Evaluation suites
Fixed scenarios with expected outcomes, run on every prompt and model change, so regressions surface before release rather than in support.
Config as code
Prompts and tool definitions live in the repo and deploy through CI. A dashboard edit that silently overwrites production config is a real failure mode.
Observability
Every run traced: what was called, what came back, what the agent decided. Debugging an agent without traces is guesswork.
Graceful failure
Knowing when to stop and hand to a human. An agent that admits it is stuck is more valuable than one that improvises.
Related: voice and chat agents, AI consulting, and on agent frameworks.
HOW IT WORKS
Scope, evaluate, harden, operate
A scoped build runs 4 to 8 weeks including evaluation and monitoring, which are part of the build rather than a later phase.
Scope
Define exactly what the agent may do and what it must never do. This conversation prevents most of the incidents.
Evaluate
Build the eval set before the agent. Knowing what good looks like first is what makes iteration measurable.
Harden
Guardrails, retries, timeouts, and fallbacks. Behaviour under a failing dependency is designed, not discovered.
Operate
Traces, alerting, and a regression suite on every change. Agents drift as models and data move underneath them.
We run this on ourselves
The voice and chat agent on this site is built the way described above. Its system prompt and knowledge base live in the repository rather than in a vendor dashboard, because a dashboard save re-serialises the whole assistant and can silently overwrite configuration managed elsewhere. Changes deploy through CI, and a drift check fails if the live agent stops matching the repo.
It is developed against a suite of conversation evals covering greeting, qualification, pricing questions, objection handling, booking, and the case where someone asks whether they are talking to a person. Those run on demand and after prompt changes, so a regression shows up as a failing scenario rather than as a lost lead.
That is not a claim to unusual sophistication. It is the minimum for an agent that talks to customers, and it is a reasonable thing to ask any firm to demonstrate before they build one for you.
- Prompts and tools in version control, deployed through CI
- Evaluation suite run on every prompt or model change
- Destructive actions gated, irreversible actions held for a human
- Full run traces retained for debugging
Frequently Asked Questions
Have a task an agent could own?
Book a free strategy session. We will scope what it may do, what it must not, and whether an existing product already does the job.
Book a Free AI Strategy Session