AI systems and agents
Most companies bought a chat window and discovered it could not actually do anything. We build systems that own a task end to end: read the request, look things up across your systems, decide, act, and stop for a person when the stakes are high. Running on the best frontier model for each step, and measured against cases from your own business long before it reaches a customer.
Signals
Every one of these is the same gap: a model that can talk about the work, sitting outside the systems where the work happens.
You bought an AI tool, everyone tried it for a week, and nothing about the work actually changed.
The answers are good until someone asks about your pricing, your policy, or last Tuesday's order.
The useful part of the job lives in four systems and the chat window can see none of them.
A person still has to copy the model's answer somewhere before anything happens.
Nobody can tell you whether it is right more often this month than it was last month.
It works beautifully in the demo and nobody trusts it with a real customer.
What we build
They share a spine — your data, your tools, evaluated before release — and differ in who they serve and how much they are trusted to do on their own.
Systems that own a task from start to finish. They plan, call your tools, handle the cases that do not fit the happy path, and escalate the ones that should never be automatic.
An assistant inside the tool your team already has open, that knows your accounts, your policies, and your history. It drafts, looks up, summarises, and prepares, and a person still presses send.
Retrieval that actually retrieves. Your contracts, tickets, wikis, and PDFs turned into something a model can answer from, with citations back to the source so an answer can be checked.
The intelligent part of the thing you sell: the assistant in your app, the automatic summary, the search that understands the question. Built to your latency, cost, and reliability budgets.
Custom agents
We do not sell one support bot and call it a platform. Each agent is scoped to a single job in your business, with the tools that job needs and the checks that job deserves.
Researches the account before the call, drafts the proposal from deals that closed, and keeps the CRM honest without a rep ever touching a field.
Resolves the tickets that follow a policy, end to end, and hands over the ones that do not with the history already summarised.
Chases documents, matches invoices to purchase orders, flags what does not reconcile, and prepares the exceptions for a human to rule on.
Watches the queue, spots the order about to miss its date, and does something about it before anyone thinks to open a dashboard.
Reads the market, the filings, and the competitor changes that somebody used to work through in twelve tabs on a Friday afternoon.
Triages issues, reproduces the bug, opens the pull request for the boring class of fix, and leaves the interesting ones to your engineers.
The model layer
Frontier models leapfrog each other every few months. We benchmark them on your cases, route each step to whichever one wins it, and keep the system loosely coupled so that swapping is a configuration change instead of a rewrite.
We are not a reseller for any model provider and we take no referral fees. This table gets rewritten whenever a new model beats the incumbent on your evals, which over the last two years has been every few months.
Where it lives
The system goes where the work already happens. No new tab to remember, no portal to log into, and no change management programme required to get somebody to try it.
Mentioned in the channel where the work is already being discussed.
Reads what arrives and answers, drafts, or escalates from the same thread.
Inside HubSpot, Salesforce, Zendesk, or Intercom, as part of the record.
An assistant, a smarter search, or a sidebar shipped as a feature customers use.
Where a great deal of business in Latin America is actually conducted.
For the internal system from 2011 that has no API and is not going anywhere.
Calls answered, qualified, and summarised into the record before anyone picks up.
Called by your own services when the agent is one step inside something larger.
Reliability
Anyone can get a good answer on the third attempt in a meeting. The engineering is in making the hundredth run as good as the first, and in knowing the moment it stops being.
A test suite of real examples with known right answers. Nothing ships unless it scores better than what it replaces, and the score is on a dashboard you can open.
What it must never do, say, or touch, enforced outside the prompt, because a prompt is a request and not a constraint.
You set the thresholds where a person signs off. Anything irreversible, anything above a limit, and anything going to a customer can stop for review.
Every run recorded with its steps, tool calls, inputs, and cost, so a wrong answer is something you can open and explain rather than argue about.
The agent sees what the person it acts for is allowed to see. Retention, residency, and what never leaves your network are decided up front.
Per-run cost ceilings, caching, and a smaller model wherever it wins, so the bill does not scale into a surprise.
How we work
The failure mode in this field is a six-month build of something nobody measured. We front-load the measurement, so by week three you know whether it works.
01Estimate: Week 1
We pick a single task with a clear owner, real volume, and a right answer we can agree on. Not a platform and not a strategy: one job that costs you hours every week.
DeliverableA scoped job with a defined right answer
02Estimate: Week 1–2
We collect real cases from your history alongside the outcome a good employee would produce. This becomes the thing every version is graded against, and it is yours regardless of what happens next.
DeliverableAn eval set and a measured baseline
03Estimate: Week 2–4
A working system wired to your real tools and scored on the eval set, with the model routing and the retrieval tuned until it clears the bar. This is where we find out a job needs a different approach, which is far cheaper to find out now.
DeliverableA scored prototype and a go or no-go
04Estimate: Week 4–7
It runs on live work with a person reviewing every case, so you see where it is wrong before it can cost anything. The review rate comes down only as the numbers earn it.
DeliverableA live pilot with review metrics
05Estimate: Week 7+
Full deployment with monitoring, cost controls, and alerting. New cases keep joining the eval set, so the system gets measurably better instead of quietly drifting.
DeliverableProduction deployment, monitoring, and a tuning cadence
The timings on this page are estimates drawn from past projects, not a quote. Yours depend on how many systems the agent has to touch, how clean the records are, and how fast decisions get made on your side.
Tools
Model providers are interchangeable on purpose. Everything else is chosen because it is stable, inspectable, and something the next engineer to touch it will recognise.
Engagement
Same team and same standards in all three. The difference is how much you commit to before the numbers exist.
One job, scoped and measured. Fixed price, a few weeks, and a number at the end that says whether to continue.
Best for
A first AI system, a board that wants evidence, or an idea that has been argued about for two quarters.
Includes
The full system: production deployment, integrations, guardrails, monitoring, and the handover that lets your own team run it.
Best for
A proven case, or a job so obviously painful that nobody needs convincing.
Includes
We keep it working as the models change, the volumes grow, and the edge cases arrive: monitoring, retuning, and new capabilities on a cadence.
Best for
Systems already in production, where quality drifting quietly is the thing that would actually hurt.
Includes
No lock-in
The code, the prompts, the retrieval index, the traces, and above all the eval set live in your accounts. That eval set is the real asset: it is what lets anyone, including a team that is not us, improve the system without guessing.
Proof
Products we run ourselves and systems we built for clients, with the decisions behind each one.
Questions
Your chatbot can read and write text. An agent can also look things up in your systems, take actions inside them, and know when to stop and ask a person. The difference shows up in whether anything changes without a human copying the answer somewhere.
They overlap, and the honest answer is that we would rather sell you the cheaper one. If a process is predictable and rule-shaped, automate it: faster to build, cheaper to run, and it never surprises you. Agents earn their cost where the input is messy or the step genuinely needs judgment, and most good systems are mostly automation with an agent in the two places that need one.
Usually later, not first. Start on a frontier model to find out whether the job is doable at all, then train a smaller model for the high-volume steps once the format is stable and the cost is real. Doing it the other way round means paying to train something before anyone knows what good looks like.
Three things, in order: grounding it in your actual records so a right answer is available, evals that catch a regression before release, and a human checkpoint on anything irreversible. We will also tell you when a job is a bad fit because being confidently wrong on it is unacceptable, and no amount of engineering fixes that.
Only where you allow it, and never for training. We use enterprise terms that exclude training by default, and anything that cannot leave your network runs on open-weight models inside your own infrastructure. Which data sits in which category is decided with you in week one, in writing.
Per-run cost is designed in, not discovered later. We route cheap steps to small models, cache what repeats, and put a ceiling on per-run spend. For most systems the running cost lands far below the salary cost of the work it takes over, and we show you that number before you commit to anything.
In the systems we have built, the pattern is that a team stops doing the tedious two thirds and starts handling the exceptions, which is the part that needed them anyway. Where a role genuinely changes we put it in the report, because it goes badly when people work it out before you tell them.
It will, sometimes. The design question is never whether it is ever wrong but what happens when it is. A wrong answer inside a review step costs a click; a wrong answer inside an irreversible action costs a customer. We put the checkpoints where the second kind lives, and the traces let you see exactly what it did.
Describe the task your team does most often and likes least. We will come back with whether an agent can own it, what it would have to be right about, and the cheapest way to find out for certain.
The first conversation is free. If the honest answer is that a script would do it, that is what you will hear.