The problem I solve
The problem
Someone on your team repeats the same work every week by hand. It follows rules you could write down if somebody made you. It eats hours you are paying for, and nobody has time to stop and fix it.
What I do
Scope one task end to end. Decide what the system may never do without asking first. Break it on purpose before your clients can. Then measure it against a fixed set of test cases, so we both know how often it is right.
The result
The task runs without you. You know its failure rate as a number, you know exactly what it will never do on its own, and you get the hours back. If it is not worth building, I tell you before you pay.
Start with one boring task
The automation that succeeds is almost never the exciting one. It is the thing you or someone on your team does every week, by hand, that follows rules you could write down if somebody made you.
Boring is the point. You will notice immediately when a boring task is done wrong, which means you find out in week one rather than month six.
Anyone can build the demo
A demo has one path, input you chose, and as many takes as you need. It proves the model can. It proves nothing about a Tuesday afternoon.
What breaks when real people arrive is not model quality. It is inputs nobody imagined, a tool that hangs instead of failing cleanly, the same request arriving twice and doing the thing twice, and a cost nobody modelled. All of that is engineering, and it is the reason most pilots quietly stop.
How I build it
Scope one task
Not a platform. One thing that starts, finishes, and repeats often enough to be worth the money.
Fence what it may do
Reading your calendar and sending an email are not the same risk, and they should never share a permission.
Break it on purpose
Unplug the tool. Feed it nonsense. Run it twice. Write down what it did each time, before your clients find out for you.
Score it, then hand it over
A fixed set of test cases, run again after every change, so its failure rate is a number you own rather than a feeling.
The detail underneath each step:
- Scope one task end to end. Not a platform. One thing that finishes.
- Decide what it must never do without asking. Reading your calendar and sending an email are not the same risk, and they should never share a permission.
- Break it on purpose. Unplug the tool. Feed it nonsense. Run it twice. Write down what it did each time.
- Make it survive. Timeouts on everything, backoff rather than a retry loop, and a defined behaviour for the empty result.
- Measure it. A fixed set of test cases, run, scored, and run again after every change, so you know whether it improved or regressed.
- Show its work. Anything over a second gets progress, anything over ten seconds gets a way out. A silent agent that is correct still feels broken.
When I will tell you not to
Some work should not be automated. If a mistake is expensive and hard to detect, if the rules change faster than they can be written down, or if the task happens twice a year, the honest answer is that software will cost you more than the problem does.
I would rather say that in the first conversation than build something you quietly stop using.