Architecture
How it fits together
Written for whoever has to approve this. No diagrams of brains, no unexplained boxes — just the layers, what each one does, and where the failure modes are.
- 01
Business systems
Your CRM, ERP, HRIS, accounting package, databases and inboxes.
These stay exactly as they are. Nothing below replaces them, and nothing requires migrating off them.
- 02
Integration layer
APIs, webhooks, scheduled pulls, file drops and email ingestion.
Reads and writes through documented interfaces using credentials you own and can revoke. Designed for failure: retries with backoff, dead-letter handling, and alerts that reach a person rather than a log nobody reads.
- 03
Workflow engine
The sequence — what happens, in what order, and what waits for what.
Each run is a record: what triggered it, what it did, what it skipped and why. This is what makes the automation auditable rather than mysterious.
- 04
AI services
Extraction, classification, matching and summarisation.
Called for the specific steps where they beat rules, and nowhere else. Behind a provider abstraction, so the model can be changed without rewriting the workflow around it.
- 05
Business rules
Thresholds, routing, and what counts as an exception.
Explicit and configurable rather than buried in code. Confidence below a threshold stops and waits; so does anything matching an exception rule.
- 06
Human approval
The gate on anything consequential.
Which steps require a person is a decision made per workflow, reviewed as the measured error rate justifies it — not a default that quietly erodes.
- 07
Actions
Writing back, notifying, filing, posting.
The point where the automation changes something. Every action is logged with its inputs, so an unexpected outcome can be traced rather than guessed at.
- 08
Analytics
Volume, duration, error rate, exception rate.
Instrumented from the start. It is how you find out whether the thing was worth building, and the first place to look when something changes.
How we deliver
A delivery rhythm you can plan around
No black boxes. You see working software every two weeks, and you know what it costs before we start.
- 011–2 weeks
Sit with the team
We watch how the work actually happens — not how the process document says it does. You get a costed plan and an architecture at the end, yours to keep either way.
- 022–3 weeks
Prove the hard part
Every project has one piece that decides whether it works. We build that first, with your real data, before anyone commits to the rest.
- 03Ongoing
Build
Two-week sprints, a demo at the end of each one, and a staging environment your team can try. Automated tests and code review on every change.
- 04Post-launch
Run and scale
Monitoring, incident response and a roadmap that keeps moving after launch — or a clean handover to your own team, documented properly.
The questions we actually get
What a technical reviewer asks
- Where does our data go?
- Into the systems it already lives in. The integration layer moves what a workflow needs and no more, and we build inside your infrastructure and accounts wherever your environment allows it.
- What happens when the AI is wrong?
- It stops. Confidence below the threshold routes to a person instead of proceeding. The interesting design question in any of this work is not what happens when the model is right — it is what happens when it is not.
- Are we locked to one AI provider?
- No. Model calls sit behind an abstraction, so swapping providers is a configuration change rather than a rewrite. This matters more than it sounds: this part of the market is moving quickly.
- What happens if you disappear?
- You keep everything. Source code in your repositories under your licence, infrastructure in your accounts, documentation written for whoever comes next. We would rather be kept because the work is good than because leaving is painful.
- How do we know it is still working?
- Monitoring and alerting that reaches a human, plus the analytics layer. Silent failure is the failure mode that costs real money, and an automation that quietly stops is worse than one that never existed.
Security
Principles, not certifications
Security requirements are designed around your environment, data sensitivity and compliance obligations.
- Least-privilege access to every connected system
- Secure API authentication with credentials you own and can revoke
- Encryption in transit and at rest
- Audit logging of automated actions
- Role-based access control
- Human approval gates on consequential steps
- Separated development, staging and production environments
- Data minimisation — we move what the workflow needs, not everything
- Configurable retention, set to your policy
- Monitoring and alerting that reaches a person
We hold no security certifications and do not claim any. If your procurement process requires SOC 2, ISO 27001 or a signed BAA, say so early — it changes what we can responsibly take on, and finding out late wastes everyone’s time.
Bring us the workflow your team argues about
The ones with awkward systems and unclear ownership are usually the ones worth fixing.