A workaround hides the error
A workaround hides the error.
Recently a tool belonging to one of my AI agents broke. It had been built on a silent assumption: it only ran on one particular computer. When it moved to the server, it stopped working.
The agent solved it cleverly and wrote its own little script around the problem. That looked like a nice solution. But I only heard about it a day later. The script did not have the checks of the real tool, and nobody knew the tool was broken. So the error simply stayed, only invisible.
Since then I have had a different agreement:
- If something does not work, you say so right away.
- You name exactly what is wrong, with the error message. "The credit is used up" is useful. "It doesn't work" is not.
- You repair the tool itself, and you do not build around it.
A good workaround feels like getting on with it. But with agents it is mostly expensive, because you only see the error when it pops up somewhere else. The same goes for people, by the way.
How do you handle it when an agent or an automation hits a wall: do you let it find its own way, or do you want it to raise the alarm first?
See also
One process, one task: how to choose where AI begins
The question many organisations start with when it comes to AI is: "What can it do?" The answer is almost everything. That is why it so often stays at a presentation, a trial account and a good conversation, while…
An idea no longer goes in the drawer
In the past an idea went into the drawer, to do something with it in a few years.
Start a booking app with the rules, not with code
Start a booking app with the rules, not with code.
