02 / service
One workflow, done the same way every time
We build an agent for one specific job you already do by hand. Not a general assistant and not a chatbot that improvises a new answer every session.
A general-purpose assistant is easy to demo and hard to trust. An agent that does one job, the same way, with a record of what it did, is the opposite. So each agent we build is scoped to one job.
One agent is where we start, not where we stop. We take the workflow that hurts most, build for that, then move to the next one. Over a few rounds the repetitive work across a team ends up AI assisted, one reliable piece at a time, rather than in a single rewrite nobody trusts.
Reliability comes from the structure around the model: memory, defined steps and checks that fail loudly instead of quietly guessing. We don't start from an empty file either. Some of this is a workflow rather than an agent, and some of it we have already built and run ourselves.
What we start from
- Workflows, where a workflow is the honest answer. Plenty of jobs that feel like they need an agent are a fixed sequence of steps with a model doing 1 or 2 of them. That version is cheaper to run and far easier to trust.
- Plug and play agents we already run. Some jobs are common enough that we have built them before, so you pay for fitting them to your setup rather than for inventing them again.
- Custom builds for the repetitive work that is specific to you. This is where most of the value sits, because it is the part nobody can sell you off the shelf.
- Rules held in code, not in prompts. Anything that must never break becomes a hook or a gate that runs every time. Prompts are for tone and formatting, where being right most of the time is fine.
What gets built
- One agent, scoped to one workflow, running in your infrastructure
- Deterministic steps where determinism is possible, so the model only does the parts that need judgement
- Memory and context structured so runs stay consistent as the work grows
- Logging you can read, so a wrong answer can be traced instead of guessed at
- Handover documentation written for your developers, not for us
This fits if
- A specific task eats hours every week and follows roughly the same shape each time
- You can point at what a good result looks like
- Someone on your side can own it after handover
- You'd rather have one thing that works than 5 that demo well
This isn't for you if
- The workflow changes every time it runs. Automate the stable part first, or don't automate it.
- You want an agent that handles anything. That is the thing that makes them unreliable.
- Nobody internally has time to take it over. It will rot.
How a build runs
01
We scope one workflow
We watch how the job gets done now and agree what the agent will and won't handle.
02
We build and run it on real work
You see it working against your actual inputs, not a demo dataset, well before it goes live.
03
We hand it over
Documented, logged and explained to whoever is picking it up. Then it is yours.
Questions about builds
Where does it run?
Your infrastructure, your accounts, your API keys. We build it there so there is nothing to migrate later and no dependency on us.
What happens when it breaks?
It logs what it did and why, so your team can trace it. We'll agree a support window at the start, and after that you can call us or not.
Can it do more than one workflow?
Yes, as a separate agent. That is normally how this goes: one job, then the next, until most of the repetitive work is covered. Bolting a second job onto a working agent is the most common way a reliable one becomes unreliable, so we keep them apart.
Do we get the source?
Yes. All of it, from the first commit. It runs in your repo.
Got a job that runs the same way every week?
Tell us what it is. We'll say whether it's worth building and roughly what it takes.