AI agents and orchestration
Production AI agents for intake, triage, quoting, and follow-up, plus multi-agent orchestration, MCP servers, evaluation and guardrails, knowledge systems, and human-in-the-loop review.
An AI agent is a program that uses a language model to work through a task over several steps, calling your systems as it goes. We build narrow agents for specific workflows, wire them into the tools you already run, measure their accuracy against your real cases, and keep a person in control of anything that reaches a customer. This is for teams where one workflow arrives constantly and takes judgment plus lookup every time.
The problem
Agent projects fail in a consistent pattern. The demo works, the pilot works, and then production volume arrives with input the prompt never anticipated. Nobody measured the error rate, so nobody knows whether it is one percent or fifteen, and the first real signal is a customer complaint.
- The agent has too many tools and picks the wrong one under pressure.
- Business rules live in the prompt, so the model can invent a price.
- There is no trace, so a wrong output cannot be diagnosed.
- Nothing caps spend, and a retry loop becomes an invoice.
- The underlying data is inconsistent, and no amount of prompting fixes that.
What we build
Business Agents
A business agent handles one job well: reading an inbound request, deciding what it is, gathering what it needs, and producing a result someone can approve.
Agent Orchestration
Orchestration is the layer that decides which agent or step handles what, what gets passed between them, and what happens when one fails.
MCP Servers
An MCP server is a standard way to give an AI assistant controlled access to a system, so the same integration works across the tools your team uses.
Evaluation and Guardrails
Evaluation is how you know whether an agent works. Guardrails are what keep it inside its limits when it does not.
Knowledge Systems
A knowledge system answers questions from your approved documents and cites which one it used, so answers can be checked rather than trusted blindly.
Human in the Loop
Human-in-the-loop means the AI does the assembly and a person makes the call, with review designed to be fast enough that people actually use it.
What you get at handoff
- Agent code in your repository, calling your own model accounts.
- The evaluation set built from your real cases, plus the scoring script.
- Traces and cost dashboards you can read without us.
- A runbook covering the review queue, escalation, and the manual fallback.
- Training for the people who review the output every day.
Stack
Models
Claude, OpenAI, tool use, structured outputs, smaller models for routing
Integration
Model Context Protocol, REST and GraphQL APIs, webhooks, internal services
Runtime
Python, TypeScript, AWS Lambda, Cloud Run, queues, Airflow
Data
Postgres, pgvector, Snowflake, BigQuery, hybrid search
Operations
Evaluation sets, run tracing, spend limits, approval queues, audit logging
Why this sits on data engineering
Agents fail on data far more often than they fail on prompts. An agent that cannot get a clean customer record, or that queries a system which times out under load, produces confident nonsense no prompt will fix. The connector, pipeline, and SQL work is the same engagement one layer down, which is why those services sit alongside this one rather than in a different company.
FAQ
What counts as an AI agent?
A program that uses a language model to work through a task over several steps, calling your systems as it goes, rather than answering one question. The model decides what to do next within limits you set. If the steps are always the same, that is an automation, not an agent, and it is usually the better choice.
Do we need agents, or would automation do?
Automation, most of the time. Agents earn their cost when inputs vary enough that a fixed path fails, and when the work needs judgment a rule cannot express. We ask that question during scoping and say so plainly when the simpler answer is right.
How do you keep an agent from doing damage?
Scoped tool permissions so the destructive operations are not available, business rules in code rather than in a prompt, step and spend limits so a confused agent stops, and a human approval step before anything reaches a customer or moves money.
How do we know whether it actually works?
An evaluation set built from your real historical cases, scored before the system touches live work and re-run on every change. Without that, quality is an impression, and impressions do not survive contact with production volume.
What does a first agent project look like?
One workflow, scoped narrowly, in production with a human approving output. That teaches you more about whether this fits your business than any pilot programme, and it is the version that keeps working after we leave.
Why does a data engineering shop build agents?
Because agents fail on data, not on prompts. They need clean records, reliable integrations, and systems that can be queried without falling over. The pipeline and connector work is the same work, one layer down.
Have a workflow that might be worth an agent?
Send the workflow and what makes it repetitive. We will tell you whether it wants an agent, an ordinary automation, or a fix further upstream.