I built a wildly over-engineered solution to a small problem. On purpose.
Our running group wanted to cover the distance from Manchester to Amsterdam. The previous challenge had been managed by hand: collect each run from the chat, convert miles where necessary, find the latest total and update it.
A spreadsheet would have worked.
I built Terry instead.
Terry is an AI agent that understands ordinary run reports, updates controlled records and tells the group how far we have left. By the end, the group had logged 938.20 km across 100 runs.
The engineering effort was out of proportion to the admin saved. That was partly the point.
A safe place to learn
I wanted to learn about agents on a real problem with real users. I did not want my first serious lessons to come from giving a model access to a payroll system, customer record or production workflow.
A running challenge had genuine ambiguity and social behaviour, while the consequences of a mistake were small and recoverable.
It became a useful training ground.
I had to decide how identity should work, how to handle miles and kilometres, where the model’s authority should end, how to prevent duplicate updates and how a person could correct the record.
I also saw how quickly a neat interaction breaks when people do not follow the imagined script. They change the word order, switch units, refer to another runner or reply with less context than the system expects.
Those are not edge cases once real people start using the thing. They are the product.
The model had one narrow job
Terry used AI for the part that benefited from it: understanding messy language.
The model turned a chat message into a structured proposal containing the runner, distance and unit. Its authority stopped there.
Ordinary code validated the proposal, converted miles to kilometres, checked the identity, wrote the ledger and recalculated the total. If the message was unclear, the update stopped so Terry could ask rather than guess.
The prompts mattered, but most of the reliability came from the surrounding system: limited permissions, validation, deterministic calculations, an auditable ledger, health checks and a recovery path.
That is difficult to learn from a demo where every input has been prepared in advance.
Over-engineering can be useful
I am comfortable over-engineering the occasional small internal tool because the value is not always the number of minutes that tool saves.
Sometimes the value is learning a difficult lesson where the blast radius is tiny.
That does not mean every experiment needs an agent. A spreadsheet, form or short script is often the right answer. The decision depends on what you are trying to learn as well as what you are trying to automate.
For Terry, the running admin was the immediate problem. The experiment taught me what happens when an agent leaves the demo and meets a group of actual humans.
My rule now is to learn risky patterns in low-risk settings. If an agent may eventually touch an important workflow, first give it a problem where mistakes are visible, reversible and boring.
