Capability 02
Automation
A process that runs itself — and says so when it cannot.
There is a large gap between a demo that works once and a process a business can depend on every day. Closing it is mostly unglamorous: deciding which steps genuinely need a model, making every external action idempotent, putting an approval gate in front of anything irreversible, and testing agent behaviour against real cases before it goes near production. That gap is the work we do.
How it works
What a project looks like.
The same order every time, so you always know which stage you are in and what comes out of it.
- 01
Map
The process is written down as it actually runs today, including the exceptions people currently handle by hand. This is usually the step that finds the real problem.
- 02
Decide
Steps are split into deterministic and judgement. Rules stay as code. Only genuine judgement gets a model, because models cost more and vary between runs.
- 03
Build
Deterministic steps become code or workflow nodes. Judgement steps get a constrained prompt, an explicit tool allow-list, and a schema their output must satisfy.
- 04
Guard
External actions are idempotent, retried with backoff, and logged. Anything irreversible — sending, paying, deleting, publishing — sits behind a human approval gate.
- 05
Evaluate
Behaviour is tested against a fixed set of real cases before launch, and re-tested whenever a prompt, tool, or model version changes. Accuracy is a number, not an impression.
- 06
Operate
Runs, spend, and failures are visible in one place. When the process stalls, a person is told which step failed and what it was holding.
Services and templates
Where to start.
Each one is scoped, priced, and run the same way.
What's included
Everything you get.
Each one lists how it is actually done, so you can check the claim rather than take it on trust.
Bounded blast radius
An agent should not be able to do anything you would not let a new hire do unsupervised on day one.
- Explicit tool allow-lists
- Approval gates on irreversible actions
- Spend caps and rate limits per run
- Full audit trail of every call
Evaluation before deployment
Prompt changes are code changes. They get tested the same way, against cases drawn from your real work.
- Golden case sets from production data
- Regression runs on prompt and model change
- Accuracy thresholds that block release
Deterministic by default
Most of a business process is rules, and rules belong in code. Using a model where an if-statement would do is how automation projects get expensive and flaky.
- Rules engine for the deterministic path
- Model calls scoped to judgement steps
- Structured output validated against a schema
Works with the tools you have
Automation that requires replacing your CRM is not automation, it is a migration project.
- Native API integrations
- n8n and Temporal for orchestration
- Queues and webhooks between systems
Human in the loop, on purpose
The goal is not to remove people. It is to remove the parts of their day that a machine does better, and to route the rest to them with context attached.
- Review queues with full run context
- Confidence thresholds that escalate
- One-click override and rollback
Cost and latency under control
Token spend is an operating cost. It gets designed, measured, and reduced like any other.
- Model routing by task difficulty
- Prompt caching and batching
- Per-run cost reporting
Honest limits
What we will not do.
Worth reading before you get in touch — it saves both of us a call.
- We do not put a model in a loop with your production database and hope for the best.
- We do not automate a process nobody has written down. Mapping comes first, and it is billable work because it is the hard part.
- We will not automate a process that is broken. Fixing it first is almost always cheaper than encoding the mess.
- We do not ship systems with no way to see what they did. If you cannot audit it, you cannot trust it.
- Python
- TypeScript
- Claude
- LangGraph
- n8n
- Temporal
- Postgres
- Redis
- Docker
- OpenTelemetry
Questions
Asked before.
Do we need AI for this at all?
Often not, and we will say so. A large share of what gets pitched as AI automation is a scheduled job with good error handling. That version is cheaper to run and easier to trust.
What does 'agentic' actually mean here?
A model that can choose which tool to call next, in a loop, until a goal is met. It is the right shape for open-ended tasks and the wrong shape for fixed sequences, which is why we scope it deliberately.
How do you stop it doing something expensive or wrong?
Tool allow-lists, spend caps, idempotent actions, and approval gates in front of anything irreversible. Every run is logged end to end.
Can you work inside our existing n8n or Make setup?
Yes. Taking over, hardening, and extending an automation estate somebody else built is a common engagement.
What happens when a model provider changes something?
The evaluation suite is re-run against the new version before anything moves. That is the entire reason it exists.
Next step
Describe the problem in your own words.
No brief required. Tell us what is slow, wrong, or manual today and we will tell you what it would take to fix — including when the answer is that you do not need us.