Research
Applied automation
Automation research that is mostly about restraint — knowing which steps should stay with a person.
The interesting part is the exceptions
The happy path in an automated process is straightforward to build and is not what determines whether the system survives contact with an operation. What matters is what happens when an API is down, a document is malformed, or a value falls outside every branch anyone designed.
Systems that fail silently get abandoned. Systems that fail loudly and recoverably get trusted, and trust is what determines whether people route work through them or around them.
What we have concluded so far
- Not every step should be automated. Steps requiring judgement should keep a person and get better information to decide with.
- Idempotency is not optional. Any step that cannot safely run twice will eventually run twice.
- An exception queue with enough context to resolve the item beats an alert that only says something failed.
- The process map is valuable on its own, whatever gets automated afterwards — it is usually the first time the real process has been written down.
- Automating a broken process makes it break faster. Fixing it first is often the cheaper project.
Open questions
How to decide when a human confirmation step has become a rubber stamp, and what to replace it with when it has.
How to measure the cost of an automation that works correctly but that nobody understands well enough to modify.
Start here
Tell us what is slow, manual, or breaking.
Answer a few questions and get a written brief back — scope, proposed architecture, and what it would take to build.