AI Agents
AI agents that do the work, not just the talking
Most “AI agents” are a chat box with a system prompt. We build the other kind: systems that hold context, call real tools, take real actions in your stack, and get evaluated on whether the work actually got done.
What this looks like
A trace, not a black box
Every run logs exactly what the agent reasoned, which tools it called, and why it either proceeded or stopped. Abbreviated here. The real trace carries full arguments and timings for every step.
The problem
The demo works. Production is a different problem.
Getting an agent to work once, on a happy path, in a notebook, is an afternoon. Getting one that behaves on the thousandth run, with messy inputs, partial API failures, and a human who needs to trust the output, that is the actual engineering. Most agent projects stall in exactly that gap.
Sound familiar?
- A prototype that impressed everyone and then never shipped
- No way to tell whether a change made the agent better or worse
- Costs that scale unpredictably with usage
- Silent failures nobody catches until a customer does
- An agent that can read your data but cannot act on anything
What we build
AI Agents, specifically
Tool-using agents
Agents wired into the systems you already run (CRM, database, billing, internal APIs, third-party services), with scoped permissions, typed tool schemas, and hard limits on what each agent is allowed to touch.
Research and analysis agents
The slow kind of work: gathering sources, cross-referencing them, and producing an answer with citations attached, for domains where getting it wrong actually costs something.
Document and intake agents
Contracts, RFPs, applications, filings, claims. Parsed into structured data, checked against your rules, and routed to whoever needs to act, with the reasoning attached.
Multi-agent orchestration
Where one model in a loop is the wrong shape: specialist agents with distinct tools and prompts, a coordinator that decomposes the task, and explicit handoffs you can trace.
Evaluation harnesses
A test suite for non-deterministic systems. Golden datasets, graded rubrics, regression runs on every prompt or model change, so 'is this better?' has an answer.
Guardrails and human handoff
Confidence thresholds, escalation paths, approval gates on irreversible actions, and full audit trails. The agent knows what it is not allowed to decide alone.
How we work
The sequence that makes this ship
Every engagement follows the same spine. The order matters more than any individual step.
- 01
Find the decision
We start from the judgement being made, not the technology. What decision is a person making today, on what inputs, and what does getting it wrong cost? That framing decides whether an agent is even the right tool.
- 02
Build the eval set first
Before any agent code, we assemble real examples with known-good outcomes. This is the single biggest predictor of whether an agent project ships, and the step almost everyone skips.
- 03
Thin vertical slice
One narrow path, working end to end against real data and real tools. Not a demo, a deployed slice you can put in front of someone whose opinion matters.
- 04
Harden and instrument
Retries, fallbacks, cost ceilings, timeouts, structured logging of every tool call and decision. Tracing so you can reconstruct any run after the fact.
- 05
Widen the scope
Extend to the edge cases the eval set exposed, measuring against the baseline each time. Scope grows only where the numbers justify it.
Stack
Tools chosen per problem, not per habit
What we reach for most often on this kind of work. The right answer changes with the problem, and we will argue for a different one when it fits better.
- Claude
- GPT
- Gemini
- Vercel AI SDK
- LangGraph
- MCP
- pgvector
- Temporal
- TypeScript
- Python
Evidence
Where we have done this
VetBid
An AI business-development platform that reads federal solicitations and tells veteran-owned firms which ones they can actually win.
Olim Paveway
An AI planning tool that turns a fragmented, high-stakes immigration process into a personalised, document-backed plan.
Email Automator
A multi-step email outreach engine (sequencing, A/B variants, send-window throttling) with an MCP interface so an AI agent can operate it directly.
Further reading
On this subject
Generating Into a Schema: When Prose Is the Wrong AI Output Format
Free prose is the easy AI output. When it needs to be rendered, stored, revised, or reproduced consistently, a schema is what makes it a product.
MCP Servers as the Access Control Layer Between an Agent and Your System
Giving an agent tools is not the same as giving it your API. An MCP server is where you decide, tool by tool, what it is actually allowed to do.
RFP Response Automation: What an Agent Actually Needs to Read a 200-Page Solicitation
Matching a solicitation against your own past performance, at the level of detail a real bid decision requires, is harder than reading it.
Multi-Agent Orchestration: When One Agent Is Not the Right Shape
Splitting a task across several specialist agents is a specific answer to a specific problem, and it is the wrong answer most of the time.
AI Agent Guardrails: What Actually Stops Something From Going Wrong
A real guardrail is a specific set of constraints enforced in code, not a polite request in a system prompt, and the two are not interchangeable.
AI Agents vs Chatbots: The Difference That Actually Matters
The distinction comes down to whether the system can take an action that changes something, not conversational quality or model size.
Why AI Agents Fail in Production (And What Actually Fixes It)
The prototype worked, then nothing shipped. The failure is almost never the model. It is five specific engineering gaps, and all are avoidable.
How to Evaluate an AI Agent Before You Trust It
You cannot ship what you cannot measure, and “it seemed good when I tried it” is not measurement. A practical method for testing non-deterministic systems.
Questions
Straight answers
What actually separates an AI agent from a chatbot?
Agency over tools and state. A chatbot answers within a conversation; an agent decides what to do next, calls tools to do it, observes the result, and keeps going until the task is complete or it hits a guardrail. The engineering difference is that an agent takes actions with consequences, which means it needs permissions, error handling, audit trails, and evaluation.
How do you keep an agent from doing something destructive?
Layered constraints. Tools are scoped so the agent can only reach what it needs. Irreversible actions (sending, paying, deleting, publishing) sit behind explicit approval gates. Every run is logged with its full tool-call trace, and confidence thresholds route uncertain cases to a human instead of guessing.
Which model do you build on?
Whichever fits the task, and we keep that swappable. We build against a provider-agnostic layer so a model change is a configuration change, not a rewrite. In practice we mix: a frontier model for hard reasoning, a cheap fast one for classification and routing.
How long does an agent project take?
A working vertical slice in production typically lands in three to five weeks. Full rollout depends on how many edge cases the evaluation set surfaces and how many systems the agent has to integrate with.
Do you work with an existing prototype?
Often, yes. A prototype that stalled is still useful, since it usually means the hard problem is already identified. We generally keep the domain logic and rebuild the execution layer around evaluation and observability.
Tell us what is slowing you down
A short conversation is usually enough to tell whether this is a build, an automation, or something you should not do at all. We will tell you which.