AI agents run most of my company. Here is what broke.

Tobo — Wed, 11 Nov 2026 14:09:43 +0000

I'm 16. I have no employees: I have Claude Code sessions. They write the code, answer suppliers, publish, and watch the sites while I'm in class. I measured 453 of those sessions and wrote down every failure the day it happened. Here are nine of them, with the numbers and the rule each one left behind.

Measured on November 11, 2026, on the transcripts on my laptop: 453 sessions between October 7 and November 11, 17,050 tool calls, 38.3 hours spent inside tools. Older incidents come from notes written the day they happened. The script is public, one file, and nothing leaves your machine: github.com/tobo-team/agent-audit.

1. It spent most of its time waiting, and so did I

Between October 7 and 27, my agents spent 22.5 hours inside tools. 13.4 of those hours, 60%, went into foreground commands that ran for a minute or more: builds, pushes, and 1,286 small loops of sleep and until. The longest single wait lasted 68 minutes. Each time, I was sitting in front of a frozen terminal.

The rule it left: Anything that can take more than a minute runs in the background, and the agent does something else or answers me meanwhile. No sleep in the foreground. A script that has timed out once is never run again as is. Since October 28 the share is 27% and the longest wait is 19 minutes. Better, not solved.

2. A monitor that worked perfectly let a site stay down for 33 days

A small script checks the sites I run. On August 1 it saw one of them go down, wrote a line in its log, and then said nothing more, because the state never changed again. I found out on September 3. The sensor did exactly what I had asked for: tell me when something changes.

The rule it left: A sensor repeats its alert for as long as the problem lasts, with the number of days. Silence must mean “all good”, never “nothing new”.

3. The retry was more dangerous than the failure

An agent sent a message to suppliers, then checked that it had gone out by comparing its text with what the platform returned. The platform turns line breaks into spaces, so the check failed on every message longer than one line. The agent concluded that the send had failed, and sent again. Three suppliers I was negotiating with received the same message twice.

The rule it left: Before a second attempt at anything that goes out, read the real state again, not the output of the first attempt. A failure is visible and can be replayed. A duplicate lands on a human.

4. “Upload complete” was not true

A deploy command printed its success line and exited with code 0 while one file had been rejected. The rejection was a few lines further down, and the agent was only reading the last two lines. Three pushes were lost that way. A fix that existed on my laptop stayed invisible online for hours, and we looked for the bug everywhere else.

The rule it left: A success message is a claim. After every push, search the whole output for errors and read the file back from the server.

5. 148 skills installed, 17 ever used

Skills are instruction packs the agent is supposed to load when a task matches. I have 148. In 453 sessions the agent loaded 17 of them, 81 times in total, and three skills account for more than half of those calls. In September I had measured the same thing (16 out of 106) and rewritten the descriptions so that they start with when to use the skill, in the words I actually type. A few dormant ones woke up. Most did not. The cost is not tokens: all the descriptions together weigh about 1% of the context. The cost is that I believed the agent knew how to do things it was never going to look up.

The rule it left: A skill that has not fired in a month gets rewritten or deleted. Count, don't assume.

6. Eight agents cost me my morning

I set up a small agency of eight agents to propose content every day. Its first full pass used the equivalent of $5.58 in API calls and, more to the point, the quota I needed to work that morning. The proposals were average.

The rule it left: No large model in automatic runs. A hard daily budget, $0.80 in my case. An agent runs again only if something new came in. And before adding any recurring agent: would a script with no model do the same job? Often, yes.

7. Three sessions, three status reports

Running several sessions in parallel works. What does not work is letting them talk, to each other and to me. In August, three sessions each sent me their progress, and delegated work turned into supervised work. The number of channels grows with the square of the number of sessions.

The rule it left: One BOARD.md per project, one line per lane: who holds what, where it stands, what comes next. A session reads it when it starts and writes one line when it ends. Lanes are split by the resource they touch (the theme, the API, the images), not by topic, so two sessions can never edit the same file. A message to another session is three lines at most and only ever says “I am blocked by you”.

8. 37,714 restarts

My laptop was hot and lasted two hours on battery. One background worker had been restarted 37,714 times in 19 days because of a missing module. Two others, 13,411 and 5,956 times. A forgotten game process had held a full CPU core for 14 days. The laptop drew 12.4 watts doing nothing. After the cleanup, 4.7. One of those jobs was my “assistant”. It had produced nothing for three weeks and I had not noticed.

The rule it left: Automation rots quietly. Every recurring job leaves a dated line somewhere I actually read, and a job that has produced nothing gets removed, not repaired.

9. My estimates were wrong in both directions

I had estimated that a medium task for our product would cost $0.90. Measured on five real tasks, it was $0.15 to $0.23. In the other direction, an agent once spent 25 minutes placing an object by trial and error; when it measured first, the same job took four tool calls. And on the morning I wrote this, three minutes of checking showed that a tool we were about to build already exists, with 629 stars.

The rule it left: Before working on a problem, check that it exists: twenty minutes before two days. And the first line of every task is “Done =”, followed by something I can observe.

What they have in common

None of these came from a model being stupid. The agent said “done” about a state nobody had read back. It acted twice. It waited without saying so. It spent without a ceiling. It reported instead of finishing.

Those are also the complaints people have about AI coworkers at work. So these rules are what my cofounder and I are building Tobo on: an AI teammate that checks before he says done, asks before anything he can't undo, works under a hard cap, and hands back a receipt for every task.

Measure your own

One Python file, standard library only. It reads the Claude Code transcripts already on your disk. No model is called and nothing leaves your machine.

curl -sO https://raw.githubusercontent.com/tobo-team/agent-audit/main/audit.py
python3 audit.py --by-month

agent-audit · 453 sessions · 2026-10-07 → 2026-11-11

WHERE THE TOOL TIME WENT
  tool calls                            17,050
  time inside tools                     38.3 h
  foreground commands ≥ 60 s     315 calls    17.7 h   46%
  sleep / poll loops           1,797 calls    13.7 h   36%
  longest single wait                    1.1 h

SKILLS
  installed                                148
  ever triggered by the agent               17   11%
  calls                                     81  top 3 = 54%

BY MONTH        tool time   ≥60 s   poll loops
  2026-10         26.8 h     59%     43%
  2026-11         11.6 h     17%     19%

The nine rules, ready to paste into a CLAUDE.md, and the two files my sessions coordinate with are in the same repository: github.com/tobo-team/agent-audit.

Limits, stated plainly

One person, one laptop, five weeks of transcripts. Claude Code keeps about a month of them by default.
“Tool time” is the time between a tool call and its result. Parallel calls are each counted in full, and the time the model spends thinking is not included.
The drop from 60% to 27% came after the rule, not necessarily because of it. The work changed too.
A long foreground command is not always waste. The question is whether the agent, and I, could have done something else meanwhile.
We build a product in this space, so read the section above for what it is.

I'm Camille, 16, cofounder of Tobo, an AI teammate for small teams. What is the worst thing an agent has told you was done?

A team burned a $2,500 AI budget in 4 days. So I read 1,165 reviews of AI coworkers.

Tobo — Wed, 11 Nov 2026 00:59:37 +0000

Two days ago our own app went offline. We had burned a month of usage credits in less than a day, and the host suspended the site.

I'm 16. My cofounder and I had spent three days building an AI teammate called Tobo. That night we deleted it.

Before writing a single new line, we did the boring thing: we collected every public review and discussion we could find about seven AI coworkers (Viktor, Claude Tag, Slackbot, Lindy, Dust, Glean, Notion AI). Reddit, Hacker News, Trustpilot, G2, Product Hunt, LinkedIn, review blogs. 1,165 items, 687 relevant. Then we sorted every complaint into 20 families.

Complaint #1 was exactly what had just happened to us.

The top of the list

#	Complaint	Threads
1	Bills nobody can predict	76
2	Bugs and instability	49
3	Hard to set up	49
4	Missing or weak integrations	49
5	Memory that is siloed and invisible	40
6	Limits and caps	39
7	Clients and outsiders left out	35
8	Permissions that are too wide	31
9	Wrong answers	29
10	Billing and cancellation	22

What people actually wrote

On cost:

"We had to abandon it internally due to hitting our $2500 spending limit in 4 days."

On memory:

"The disappointing part is not that memory is scoped; it is that the scope is invisible."

On reliability:

"It keeps saying the same response every time: 'I hit API rate limits and stopped after retry.'"

On duplicated work:

"People end up running the same tasks multiple times because they can't find previous results in threads."

On trust:

"Claude must not be able to send any emails without my explicit approval ever."

And my favorite, on the whole category:

"It feels like an LLM wrapper in search of a problem."

Three things that surprised me

1. Nobody complains that the AI is dumb. "Wrong answers" is only 9th. People are far angrier about the bill, the setup and the bugs than about the model. The intelligence is no longer the problem. The product around it is.

2. Credits are the most hated pricing model in the category. The pattern repeats in every tool that uses them: you cannot tell what a task will cost before you run it, so you either stop using the tool or you get a surprise. A capped, boring, flat price would beat a clever one.

3. Memory is a visibility problem, not a capacity problem. People do not ask for an AI that remembers more. They ask to see what it remembers, where it came from, and to fix it when it is wrong.

What we are doing with it

We threw away the first Tobo because it only watched. The new one does the work, and each of the 20 complaints is a design constraint:

one flat price per teammate, and a hard cap on every task, shown before big jobs
one memory for the whole team that anyone can read, fix and erase
one click before anything that cannot be undone
a receipt for every task: steps, tools touched, time, cost, files

It is not open yet. We apply to Techstars on November 18 and we are building in public until then.

Method, and its limits

Counts are distinct threads matched by keyword families, so treat them as orders of magnitude, not statistics. One thread can count in several families. The sample leans toward people who complain in public, which is the point, but it means happy users are underrepresented. Every quote links to its source on the full page.

All 20 complaints, with quotes and sources: heytobo.com/complaints. The raw list is on GitHub.

If you use an AI coworker at work: what is the one thing that made you stop trusting it?

DEV Community: Tobo