Case study
Jarvis
Our own assistant system: driven by voice, working through longer jobs in the background, keeping an eye on itself. Built as an internal tool — and now the foundation of the automation work we do for clients.
- Type
- Own system
- Areas
- Software · Automation · Infrastructure
- Running
- Since 2026, extended continuously
- Scope
- Voice service, interface, two iPhone apps, background services
Internal system, not publicly accessible. We're happy to demo it in a conversation.
-
01
Where it startedRunning a company alone while also doing the development, you don't lose most of your time to hard problems. You lose it to small ones: pulling numbers together, sorting the inbox, checking whether a service is still up, running the same report again. Each takes five minutes. Together they take hours.
-
02
The ideaA system you talk to the way you'd talk to a colleague: it understands the job, does it, and tells you when it's done. Nothing you have to open a window for and click through menus — something that runs alongside while you keep working.
- Voice-driven, with no window that has to stay open
- Longer jobs keep running in the background, even when you walk away
- A memory that outlasts a single conversation
- The same state on the computer and on the phone
-
03
How it was builtIn stages, each one useful on its own: voice control on the computer first, then a secured interface with shared memory, then two native iPhone apps, then the background services, and finally a layer that watches the whole system. No big bang — each stage had to hold up in daily use before the next one started.
-
04
What was actually hardThe interesting problems weren't technical, they were behavioural. An assistant that talks too much is irritating. One that asks too little does things nobody wanted. One that confirms every action is slower than doing it yourself. Most of the work went into finding those boundaries — and pinning them down so they're testable rather than a matter of chance.
Architecture
How it's built.
Six layers, each with one job. What comes in at the top gets passed down — and any layer can be swapped without touching the others.
-
01
Speech recognition
Input
Picks up speech and turns it into text. Always running, but only responds to a wake word — and can be switched off entirely by saying so.
-
02
Language models with job routing
Decision
Works out the job and picks what to do: answer directly, use a tool, or hand the job to the background. It also picks how much computing power the job is worth.
-
03
Custom tool layer
Tools
What the system can actually do: read and write files, run commands, look things up online, work on the web server, sort mailboxes.
-
04
Rule set with its own tests
Guard
A fixed check before every action: a short list of genuinely critical things is refused outright — not queried, refused. Everything else runs through without interruption.
-
05
Long-running services with budget caps
Background
A separate long-running service picks up longer jobs and works through them while nobody is at the computer. With a cost ceiling per job and per day, and a notification when it's done.
-
06
Structured store
Memory
Keeps what mattered — not as a transcript, but broken into individual statements and linked together. That way it notices when something new contradicts an earlier decision.
Decisions
Why it's built this way.
The decisions that made the difference — and the case against each.
-
01
Not every job gets the biggest engine
A short command doesn't need a model built for architectural work. The system decides per job how much computing power is appropriate. That cuts running costs sharply without weakening the heavy jobs — and it's the same thinking we apply in client projects wherever AI is involved.
-
02
A short blocklist instead of constant confirmations
The first version asked before risky actions. In practice that was slower than doing everything by hand. Now there's a short, fixed list of things that are refused outright — spending money, touching credentials, sending anything outward. Everything else runs. Less friction, and a clearer line than a prompt you eventually dismiss on reflex.
-
03
Observe first, repair later
The self-monitoring layer continuously checks that every part is healthy, investigates anything unusual and proposes fixes — but it changes nothing. A system that repairs itself before anyone has checked its diagnoses will eventually repair the wrong thing. Repairing comes once the proposals have been right for a while.
-
04
Plan for failure rather than ruling it out
The interface runs on its own server, but the system works without it: if it goes down, it quietly falls back to local storage. One of the two phone apps works with no connection at all. The question is never whether a part fails, but what happens when it does.
-
05
The human keeps the last click
The system prepares — it finds things, compares them, sets them up. But anything that costs money or goes outward, the human does. For that the system deliberately has no tool, not merely a rule.
What came out of it
A system in daily use — whose building blocks now flow back into client projects.
- Recurring jobs run without anyone starting them
- Longer jobs get done while work continues elsewhere
- Problems surface before anyone notices them
- The same data on computer and phone, connection or not
- Over a thousand automated tests hold the behaviour in place
What we take from it
With automation, the technology is rarely the problem. The hard question is how far a system may decide on its own — and what happens when it gets it wrong. That's why every automation project with us starts there, not with the choice of tools.
Contact
Something similar for your business?
Automation doesn't have to start big. Usually one recurring job that runs by itself from now on is enough.