AI agents
AI agents and automated workflow
We build AI agents that do actual work — book, create, update, investigate — in your own systems. With structured tool use, sandboxing and human approval where things can go wrong.
Tools-first
How we build agents that hold up
- Least-privilege on every tool call
- Sandboxed
- Schema check before each execution
- Validated
- Every tool call logged with context
- Audited
- Approval on non-reversible actions
- Human-loop
How we build agents
Tools-first, not prompts-first.
An AI agent is a language model with tools — functions it can call to do real work in your systems. Pull data, update a case, send an email, create a booking. That's the difference between a chatbot that answers questions and a colleague that solves the task while you sleep. Built right, agents are one of the most valuable AI investments; built wrong, they're a security hole with a bill attached.
We build agents tools-first: we design the small, well-defined set of actions the agent is allowed to take, each with clear input/output contracts, audit logging and — where needed — human approval before execution. The model picks which tool to use; your system controls what those tools actually do.
We've built agents for back-office automation, customer support, internal search and research. The pattern is the same: start with a narrow use case, measure success concretely, build human-in-the-loop where actions are non-reversible, and expand scope only when the data shows it's worth it.
What we deliver
Agents that do real work.
With structured tool use, sandboxing and human-in-the-loop where required.
Tool design and contract
We design the agent's tools as ordinary software: clear input/output types, validation on both sides, idempotency where it makes sense, and audit logging on every call. The agent sees tools as a list; your backend controls what they do.
Sandboxing and least-privilege
The agent calls tools through a constrained set of permissions — typically a separate service account with only the privileges it needs. If the agent should be able to change data, it does so via a validating API, not directly against the database.
Human-in-the-loop where required
Non-reversible actions (sending email, creating a payment, deleting data) are approved by a human before execution. We design the approval flow so it feels like a natural step — not a popup that spams the user.
Evaluation and test suite
Agents are hard to test — we build an evaluation pipeline with scenarios (LangSmith, Braintrust or custom) that runs on every prompt change. You know whether a change improved or worsened the agent's behaviour before it hits production.
Observability and error handling
Every agent trace is logged: prompts, tool calls, errors, model version, latency. We use LangSmith, Helicone or our own stack — so you can debug why the agent did what it did, not just see that something went wrong.
Cost and rate-limit management
Agents can cost more than ordinary LLM features because they take multiple tool calls per task. We set spend budgets per agent and per user, monitor trends, and alert before you hit a surprise bill.
Before you start
What you should consider first.
Narrow scope beats wide ambition
The agent that 'handles everything' is rarely good at anything. We recommend starting with a narrow use case (intaking and routing tickets; gathering research about a customer before a meeting) where success can be measured. When that works, we expand — not before.
Frontier model or smaller
Tool-use quality scales with model size. For complex multi-step workflows, Claude Opus, GPT-5 or Gemini Pro are usually better. For simple classification agents, Claude Haiku or GPT-5 Mini do fine. We measure quality vs. cost and choose pragmatically.
Hallucinated tool calls
Models can invent tools that don't exist, or call them with strangely formatted arguments. We validate every tool call against a schema before executing, retry on errors with clear feedback to the model, and fall back to human-in-the-loop if validation fails three times.
Security: prompt injection and data exfiltration
Agents that read user input and call tools are an obvious prompt-injection vector. We design agents with PII redaction on input, clear system-prompt hierarchy, and output validation that catches attempts to exfiltrate data via tool calls. That's production discipline, not a nice-to-have.
FAQ
What people usually ask.
What's a good first use case for an agent?
A good first use case has three properties: 1) Clear output (we know what 'right' looks like), 2) Limited blast radius (it's OK if the agent gets it wrong 5% of the time), and 3) Repeatable structure (the same kind of input recurs many times). Classics: ticket routing, lead research before a meeting, automatic answers to FAQ questions with escalation. We do NOT recommend starting with agents that order something or send something that can't be pulled back.
Which agent frameworks do you use?
We most often build directly against the model provider's tool-use API (OpenAI function calling, Anthropic tool use, Gemini function calling) rather than using a heavy framework. That gives us full control and minimal dependencies. For more complex workflows we use LangGraph or our own state machines. Frameworks like CrewAI and AutoGen we rarely use in production.
How long does it take to build an agent?
A focused single-purpose agent (classification, routing, simple lookups) is typically 4–6 weeks to production. An agent with multiple tools, human-in-the-loop and a proper evaluation pipeline is typically 8–12 weeks. We always go live early with a focused version and expand based on how the agent actually performs in real usage.
How do we measure if the agent is actually working?
We define success criteria in discovery: average task resolution time, share that doesn't require human override, quality via sample review. We set up the measurement from day one. If the numbers don't move, we find out why — typically it's tool design (the agent doesn't have the right tool), prompt (the model doesn't understand the context) or use case (this wasn't a good agent problem to begin with).
What about GDPR and audit?
Every tool call is logged with: user, input, model output, tool output, timestamp and model version. We design for right-to-erasure (logs can be filtered per user) and for audit (an action can always be traced back to which agent instance did what and why). If you handle sensitive data, we run via EU-resident models or self-hosted.
Ready to get started?
Let's have a no-pressure conversation.
We'll get back within one business day with concrete input — not a stock proposal.