Agents that do the work, inside limits you set.
We build multi-step AI workflows that read what comes in, decide what to do, call your systems and hand the result back. Every step is bounded, logged and safe to retry. Where a fixed workflow with a model call at the right step is enough, that is what we build.
Who this is for, and who it is not.
A good fit if
- Someone on your team re-keys orders, emails or documents into another system every working day.
- Inbound records arrive incomplete, and a person enriches, checks and routes each one by hand.
- You have seen an agent demo work, but cannot tell what it would do with your real data.
- The process touches systems you already run, such as WooCommerce, a CRM or accounting software.
Probably not the right call if
- The task comes up a few times a month, so a person will always be cheaper than a pipeline.
- Nobody can say what a correct result looks like, so there is nothing to test the pipeline against.
- You want an agent with open access to act on anything, without approvals or limits.
What changes for your team.
People handle exceptions, not every case
The reading, re-keying and routing runs on a queue. Your team deals with approvals and the cases the pipeline flags, instead of working through the whole inbox.
Every action can be explained
Each run leaves a trace of what the model saw, what it decided and which tool it called. When a result looks wrong, you can find out why rather than guess.
Mistakes and costs have a ceiling
Step limits, spend caps and approval gates are part of the build, not an afterthought. A bad input or a provider outage stops a run instead of multiplying the damage.
The parts that make it hold up in production.
The workflow, written as code
Each step is defined explicitly: what it reads, whether it calls a model, and what it passes on. Most steps are plain logic, with model calls only where reading, classifying or drafting is needed.
Tools with scoped permissions
Every action the model can take is a named tool with validated inputs and its own credentials. A step can only reach the records and endpoints it actually needs.
Queued, idempotent execution
Steps run as background jobs with retries and backoff. Actions are designed to be idempotent, so a retry does not create a second order, email or invoice.
Human approval gates
Consequential actions such as refunds, payments or outbound emails wait for a person to approve them. The reviewer sees the input, the proposed action and the reason for it in one place.
Traces, logs and alerts
Every run records its inputs, model calls, tool calls, cost and outcome. Failed or stuck runs raise an alert instead of disappearing into a log file.
Evaluations, fallbacks and cost ceilings
A set of real past cases is replayed before any prompt, model or tool change ships. Provider failures fall back to another model or a safe stop, and each run has a spend limit.
It runs beside your systems, not instead of them.
Work arrives through the channels you already use, runs through a bounded pipeline, and lands back in the systems your team works in. Nothing gets replaced.
-
Where work comes in L4Inbound email Webhooks Uploaded documents Scheduled jobs
-
Pipeline and control L3Step orchestration Approval queue Traces and logs Spend limits
-
Models and tools L2Hosted models Scoped tools Fallback provider MCP servers
-
Your existing systems L1WooCommerce CRM or ERP Accounting Databases Shared inboxes
From first call to running in production.
Each step ends in something you can look at. Scope grows after something is live, not before.
-
01
Map the process as it runs today
We work through real cases with the people doing the job, including the awkward ones. We mark which steps need judgement and which are plain rules.
-
02
Design steps, tools and limits
We define the workflow, the tools each step may call, and which actions need approval. Anything a fixed rule can decide stays out of the model.
-
03
Run it in shadow first
The pipeline reads live input but only proposes actions, which we compare against what your team actually did. Real actions are switched on once the results hold up.
-
04
Launch behind approvals, then loosen
Consequential actions start behind approval gates. A gate is relaxed only where the traces show the pipeline gets it right, and the evaluation set keeps growing.
Published prices, fixed before we start.
€1,000
delivered within a week
We read the system you already have and tell you what is actually wrong with it, what it would take to fix, and what it would cost.
€5,000 – €20,000
typical project
Fixed scope, fixed price, agreed before anyone writes code. Most of what we do sits in this band.
from €750
per month
We take the system over and keep it alive. This is the part most people discover they needed about six months after launch.
What moves the price for Agent Pipelines
- How many systems the pipeline reads from and writes to, and how usable their APIs are.
- Whether inputs arrive as structured data or as messy emails and documents that need extraction.
- How many actions need approval screens, audit trails or sign-off rules around them.
- Whether the target systems tolerate safe retries, or we have to build deduplication around them.
What we work with
Questions we get asked.
Because most business processes do not need one, and an open-ended agent is harder to test, predict and budget for. If the steps are known, we build a fixed workflow and call a model only where it has to read, classify or draft. We use a looser agent loop only where the path cannot be decided in advance, and even then with step and spend limits.
Several layers. The model can only call tools we defined, with validated inputs and scoped credentials. Consequential actions wait for a person, every run stops at a step limit and a spend limit, and output that does not match the expected format fails the step rather than being guessed at.
Records stay in your systems, and only the fields a step needs are sent to the model provider. We agree which providers and regions are allowed before we build. The code, prompts and evaluation sets live in your repository from the first commit, and the credentials sit in your accounts.
Someone has to watch it, and on a Run plan that is us. We review failed and escalated runs, track spend, replay the evaluation set when a provider changes a model, and adjust prompts and rules as your process changes. If you would rather run it yourselves, we hand over with the documentation your team needs.
The job retries with backoff, then falls back to a second provider if one is configured for that step. If that fails too, the run pauses in the queue and an alert goes out. Steps are designed so a paused run resumes where it stopped rather than writing half a result into your systems.
