01Run
AI agents that do real work in the systems you already run
We build task-scoped and multi-step agents that reach your stack through tools and MCP servers, act on real records, and hand off to a person when the decision needs one.
-
Trigger A ticket lands in the support queue, tagged as a refund request.
-
Plan The agent reads the ticket, picks the three tools it needs, and orders the calls.
-
Tool calls Reads the order, the product record and the refund policy. No writes yet.
- orders.lookuporder #4471128 ms
- catalog.searchvariant match204 ms
- policy.retrievereturns, 30 day96 ms
-
Check The draft is tested against the refund rules and the eval cases for this task.
-
Human approval Refunds over the threshold you set wait for a person. This one cleared in the queue.
-
Result Refund issued, the order annotated, and the customer answered in your voice.
02Build
Three lines of work, one accountable team
Most jobs need two of the three. We scope which, and say plainly when a task does not need an agent at all.
03Trust
Reliability is the whole job
A demo agent works once. A production agent works on the hundredth run, on the input nobody planned for, at a cost you agreed in advance. That gap is where most of our engineering time goes.
We write the test cases before the agent, from real examples you give us, and run them on every change. A regression shows up in the suite, not in your inbox.
Every run records its plan, tool calls, inputs, outputs and cost. When someone asks why the agent did that, the trace answers it.
Write actions are checked against your rules before they execute, and an agent only ever holds the tools its task needs.
Cost and latency ceilings are set per task and enforced in the run. When a model or an API is down, the agent degrades to a defined path instead of guessing.
What each agent type touches
Read access is broad, write access is narrow, and every write has a gate until you decide otherwise.
| Agent | Reads | Writes | Human gate |
|---|---|---|---|
| Support triage | Tickets, orders, policy docs | ticket.reply, refund.create |
Refunds over your threshold |
| Catalogue enrichment | Product records, supplier feeds, images | product.update, metafield.set |
Price and title changes |
| Order operations | Orders, fulfilments, carrier status | fulfilment.create, note.add |
Cancellations, address edits |
| Lead qualification | Form fills, CRM records, call notes | contact.tag, pipeline.move |
Outbound sends |
| Content operations | Briefs, existing pages, brand rules | draft.create |
Anything that publishes |
04Ship
Agents inside the platform you already sell on
The same agent work, built against each platform's own APIs and admin, so it acts on live records rather than a copy of them.
Also here when you need them: web development and SEO, as supporting work around the agent build.
05Terms
What we commit to
Not results we cannot show you yet. These are the conditions we work under, on every engagement.
A single engagement told properly: the task we scoped, what the agent touches, the eval cases we agreed, and what changed for the team that runs it. Needs a real client and their sign-off before it goes here.
06Asked
Questions we get asked first
What counts as an agent, as opposed to an automation?
An automation follows a fixed path you wrote. An agent is given a goal and a set of tools, then decides which tools to call and in what order to reach it. We build both, and we say which one a job needs. Plenty of work that gets pitched as an agent is better and cheaper as a scripted workflow.
How do you stop an agent doing something wrong?
Four ways, layered. Scope: an agent only gets the tools it needs. Guardrails: write actions are checked against your rules before they run. Human gates: actions above a threshold you set wait for a person. Evals: we write test cases before the agent and run them on every change, so a regression shows up before it ships.
Can agents work inside our existing stack?
That is the point of the work. Agents reach your systems through tools and MCP servers we build against your APIs, so they read and write real records in Shopify, WordPress, HighLevel or whatever you run. Nothing has to move.
What does an engagement look like?
We start by scoping one task narrowly enough to be measured, agree the eval cases and the cost and latency budget for it, then build to those. You get the traces from day one, so you can see what the agent did and why before you widen its scope.
Do you still build websites and do SEO?
Yes, as supporting work. If an agent needs a front end, a storefront or content that ranks, we build it. It is no longer what we lead with. See web development and SEO.
Tell us the task, not the technology
Describe one job you would hand to a capable new starter. We will tell you whether an agent should do it, what it would touch, and what it would cost to run.