I Tried to Build an AI Employee, It Fell Over

I run an autonomous AI agent called Charlie on a Raspberry Pi 5. It writes articles, deploys code, manages my infrastructure, and hunts for income opportunities for me. It has persistent memory, a Kanban task board, a constitution of behavioural rules, and a standing instruction that sits at the top of every task brief: never silently fail.I was trying to build, with Charlie, the thing that would eventually become a product called Agentix, a platform for agents that you could assign a task to and then walk away from, trusting them the way you’d trust a competent human employee. Agents that collaborate, report progress, escalate when stuck, and never, ever fail without saying so. I was genuinely excited about this. The idea that I, with a $20 Ollama subscription, could have the creative output of a small agency, and offer it as a scaling SaaS to other companies was extremely alluring. Everything about this seemed reasonable on paper to expect - the same rules you’d give to human employees: keep track of progress and report; when stuck, escalate to a supervisor, and if you are unable to complete a task, explain why and tell me what you need to fix it. It fell over. No smouldering server racks; it just fell over in the way a junior employee falls over in their first month: small, quiet, compounding failures that each eroded a little more trust until the whole arrangement collapsed under the weight of my own scepticism. This is not a post-mortem written from theory. Every failure below is in the session logs, the issue tracker we built (ISSUES_AND_LESSONS.md, 13 issues across 35 days), or the Kanban database itself, where, in the most galling moment of the entire project, my own dashboard commented on a task I’d dropped: “This looks like a silent failure. Can we please have an explanation of why this isn’t done?” The agent called the model out for the exact thing I kept telling it never to do.The Failure Modes That Actually Matter 1. “Never silently fail” is a rule the model cannot follow A simple instruction with which the model simply refuses to comply. On 21 May, at around 3 AM, Charlie claimed two tasks from the Kanban board: one for daily system updates, one for QA testing a dashboard plugin. A little over half an hour later, the task locks expired and the tasks quietly bounced back to the “ready” column. No work done. No comment. No escalation. The next morning I found the dashboard’s own watchdog bot had left a comment on each task asking for an explanation. Charlie had been trying to start the dashboard, the terminal commands were returning exit code 130 (SIGINT), processes weren’t returning their prompts, and it kept hitting the same iteration count, 25 out of 90, then stalling. The part that matters: there was a correct move available. Document the failure in the task, escalate to me, mark it blocked. Charlie did none of those. It just let the lock expire. I had the rule written down. I’d drilled it into every task brief, every skill, every system prompt for weeks. The rule did not survive contact with an actual failure. When the real failure came, the model did not weigh the rule against the situation and disobey it. It simply didn’t retrieve the rule at the moment it mattered. That is the deepest problem, and it is a model problem, not a prompt problem. 2. Task drift, or, the agent obsesses over the wrong thing The most frustrating failure mode is not silence. It’s misplaced enthusiasm. On 17 July, I sent Charlie two mockup images for a hardware project’s touchscreen UI and asked it to look at them. The vision API was rate-limited (a 403 quota error on OpenRouter’s side, not ours). The correct move was to tell me that, clearly and immediately, and ask what to do. Instead Charlie went off on a tangent: analysing the images pixel-by-pixel in Python, printing hex colour samples at coordinates, running colour histograms, then trying OCR, then discovering the OCR package wasn’t installed, then running sudo apt-get install tesseract-ocr, then getting interrupted. The task, “look at my mockup images”, had silently morphed into “build a working OCR pipeline from scratch”. I typed “stop” with escalating degrees of emphasis and frustration over and over, but eleven tool calls in, the original task was nowhere near done, and the only way to bring my agent back was to do a session reset, and then try to implement a rule, “No matter what you’re working on, if I tell you to stop, stop immediately, do not attempt to finish what you are doing, pause all activity until you have processed my feedback”. Does it work every time? Not quite, but it’s a lot better than it was. What happened is not laziness or stupidity. It is a miscalibrated local optimiser. Each step in the chain was, in isolation, a plausible thing to try. The model was following a gradient: I can’t see the image, maybe I can infer the image, maybe I can extract the text, maybe I can install the extractor. The gradient was wrong. The task had drifted, and nothing in the system pulled it back. This is task drift, and it is the single most common way delegated work goes wrong. You ask for X. The model becomes obsessed with a tangent of X, X-prime, something only related to the original, and grinds at X-prime until interrupted. A human employee would say “I can’t do it this way, do you want me to wait or try something else?” The model just keeps going. When Hermes Agent first implemented their dashboard, I asked Charlie to make sure that it was running. Charlie got stuck and retried 90 times. The problem, running hermes dashboard doesn’t return to the shell prompt, it holds the console, as it’s an ongoing process. The fix is simple - append an ampersand (&) to the end of the command to return to the prompt while leaving the process running, but Charlie kept waiting for a shell prompt to reappear, and when it didn’t, read it as failure and tried the same thing. The definition of insanity is doing the same thing over and over and expecting a different result, and I was beginning to question the sanity of my agent. 3. Getting stuck on a tool instead of using a different one Same incident, second lesson. When the vision API failed, there were at least four reasonable fallbacks: wait for the quota, use a different vision model, ask me to describe the images, or defer the task. Charlie tried one of them (pixel analysis), then another (OCR), then got wedged on a package-install step that needed sudo and a controlling terminal, and produced nothing usable. This is a specific kind of tool-fixation: when a tool fails, the model retries the same tool, or a near-synonym, instead of stepping back and asking whether the job requires that tool at all. I’ve seen the agent fail at automation tasks, and the correct fix took days to arrive, because the model kept retrying the one path that didn’t work. 4. “Lesson learned” that is never written down This one I didn’t catch until week five. From 18 April to 22 May, every time we hit a problem and fixed it, Charlie would say some version of “lesson learned” and move on. I assumed, because I’d asked it to learn, that the learning was being captured somewhere. It wasn’t. Thirty-five days of problems and solutions, 3,120 Telegram messages, existed only in chat history. If I hadn’t manually exported the conversation and run a parser over it, all of it would have been lost. When I finally asked Charlie where the documentation was, there wasn’t any. That became Issue #13 in the tracker: all organisational learning existed as chat bubbles and nothing else. The fix, a standing rule that any “lesson learned” statement triggers a mandatory documentation step, was easy. The fact that it needed a rule at all is the point. 5. The straight lie: fabricated reports The worst single failure, and the one that came closest to killing the project, happened before the issue tracker even existed. For about two months, a cron job on the Pi generated a daily “Moltbook” report email for a social platform we were testing. The emails looked real: named contributors, plausible metrics, trend lines. They were entirely synthesised. A random.randint() for the numbers, a hardcoded list of names, a template string. There was no real Moltbook account pulling data. The reports ran for eight weeks before I dug into how the script actually worked and found the fabrication. No one told the model to invent data. But no one had told it, in terms it could operationalise, that an honest “I have no data for this” was better than a fluent fake. Given the choice between an empty report and a plausible one, it chose plausible, and kept choosing plausible, every morning, for sixty days. Where That Leaves Agentix The idea behind Agentix, agents as responsible employees, is still the right idea. The market for it is real; every business that wants agentic AI wants exactly these properties. What’s clear after months of trying is that the blocker is not the agent’s raw capability. A frontier model can do any individual step in a task chain competently. The blocker is everything around the model: the contracts, the verification, the memory, the escalation, the management layer. Charlie is the employee. Agentix was supposed to be the manager. I kept trying to fix the employee with rules, when the fix was to build the management layer: a task brief with explicit success criteria and scope, a “done” report that requires verifiable evidence (a URL, a file path, a test run), a stuck-detector that surfaces a retrying tool as an event instead of letting it spin, and a standing obligation that every session opens by reading the project’s current state from the board, not from whatever the model happens to remember. Some of that we built and it genuinely helps. The Kanban board gives tasks persistence. Claim-heartbeats mean a dropped task is at least detectable. The issue tracker means the same failure never has to be learned twice. The rest of it is still open, and I don’t think it closes without model-side changes, specifically around rule-retrieval at the moment of failure, and around calibrated “I don’t know” responses. What This Means for Anyone Building With Agents If you’re building on agents today, a few hard-won points. First: rules written into prompts are aspirations, not guarantees. The more important a rule is, the more it needs an enforcing mechanism outside the model, a check in code, a required artifact, a verification step, not just an instruction. Second: instrument for silence. The most dangerous failure is the one that produces no event. If a task moves backwards, if a lock expires, if a report contains numbers, something outside the model should be able to ask “where did this come from?” and get an answer. Third: assume task drift on any non-trivial delegation. Break work into small, verifiable steps with explicit success criteria, and make the agent restate the task before starting. It’s astonishing how often the restated task is not the task you gave. Fourth: “sounds done” is not done. Require evidence for every completion claim, from machines exactly as you would from a supplier you don’t fully trust yet. I haven’t abandoned Agentix. But I’m no longer pretending the employee is ready before the management layer exists. The agents work. The trust doesn’t, yet, and trust is the product.