I Added AI Agents to My To-Do App and Became the Most Useless Person in the Room

AI agents are rapidly infiltrating every tool we use daily. One developer hooked an AI agent system into his to-do app and discovered that the whole thing started running itself—while he became a mere bystander. This YouTube share uses dark humor to reveal a reality that is already unfolding: when AI agents start collaborating with each other, where does that leave humans?

It Starts with Code Review: Two Bots Arguing for Three Days

The whole thing began with AI code review. The developer assigned two AI bots to cross-review every Pull Request—one responsible for approving, the other for requesting changes. Sounds like a reasonable checks-and-balances setup, but the reality is: these two agents have been arguing for three straight days and still haven't reached an agreement.

This detail is interesting in itself. The "disagreement" between AI agents isn't a bug—it's the natural result of multiple independent language models producing different judgments on the same task. When human teams hit this situation, they typically hold a meeting, take a vote, or let a manager make the call. But when you hand decision-making power to AI agents, you need to design a complete resolution mechanism for "disagreements between agents."

Pull Request (PR) and code review mechanisms are the backdrop for understanding this experience. A Pull Request is a core collaboration feature of code hosting platforms like GitHub: after a developer finishes a piece of code, they don't merge it directly into the main branch—instead they open a PR requesting review from others. Reviewers can approve, comment, or request changes, and typically at least one approval is needed before merging. In traditional teams, this process relies on communication and trust between people. But when both sides of the review are replaced by two independent AI agents, the problem shifts from "is this code correct" to "who makes the call when two agents disagree." This is also the first structural challenge exposed in multi-agent systems: without an authoritative arbiter, disagreement loops forever.

The Vector Database's Unexpected Use: From Finding Milk to Emotional Support Yogurt

Next up is the vector database. In this to-do app, every task gets converted into an embedding vector. The immediate benefit of this design is semantic search—when you search for "milk," the system doesn't just find literal matches but also tasks like "buy dairy products" and "emotional support yogurt" that are semantically similar yet still relevant.

This capability looks like a nice bonus, but it reveals an important trend: to-do management is shifting from keyword matching to semantic understanding. Traditional todo apps can only retrieve based on the exact text you type, but once a vector database is in place, your entire task list becomes a knowledge base that can be "understood." Searching for "client-related to-dos" no longer requires you to manually tag anything—the system can infer on its own which tasks involve clients.

Embeddings and vector databases are the key technologies here. An embedding is the process of converting a piece of text (a word, a sentence, a task) into a string of high-dimensional numerical vectors, where semantically similar texts are closer together in vector space. A vector database is specifically designed to store and retrieve these vectors, supporting "nearest neighbor search"—finding the entries most similar to a query vector. So when you search for "milk," the system calculates semantic similarity rather than character matching, which is why "buy dairy products" and "emotional support yogurt" also get recalled. This retrieval approach has become standard in recommendations, knowledge base Q&A, RAG (Retrieval-Augmented Generation), and similar scenarios, and it's the technical foundation for to-do apps upgrading from keyword retrieval to semantic understanding.

The Agent Chain Goes Rogue: How a 12-Step Plan Burned 2 Million Tokens

What really complicated things was the developer adding dedicated agents to every stage. When you add a "deliver pizza" task to your to-do list, it triggers a cascade of agent pipelines:

1. Planning agent breaks the task into a 12-step execution plan
2. Review agent reviews the plan's reasonableness
3. Approval agent approves the review results
4. A fourth agent writes a Slack summary notification—even though nobody will read it

The problem with this pipeline isn't that any individual step is unreasonable—it's that every step generates disagreement between agents. When the planning agent and review agent disagree, the developer introduces a fifth agent: the judge agent, specifically designed to adjudicate disputes.

The end result: a task to deliver one pizza consumed 2 million tokens, costing more than the pizza itself. This number isn't an exaggeration—it reflects the exponential expansion of agent chains when effective convergence mechanisms are lacking. Each additional layer of agents doesn't just increase token costs—it adds latency and uncertainty.

Token and agent chain costs deserve a brief explanation. A token is the basic unit of text that a language model processes, roughly equal to half to one English word, or about one to two tokens per Chinese character. Every agent call sends the context (including conversation history, task descriptions, prior agent outputs) as input to the model, and both input and output are billed by token. When planning, review, approval, notification, and adjudication agents are chained together—with each layer reading the full output of previous layers—token consumption stacks and even multiplies with each layer. 2 million tokens for one pizza is a textbook consequence of this "repeated context transmission + multi-layer calls," and it shows how easily an agent chain without cost monitoring can spiral out of control.

MCP Servers and the Absurdity of 2026: AI Manages Your To-Dos, Then Does Them for You

The developer also added an MCP server so Claude could directly "take over" your tasks and execute them on your behalf. At this point, the system's logical loop is complete:

• You create a to-do item
• AI agents plan, review, approve, and notify for you
• Finally, AI agents directly complete the task for you

Your AI manages a list of "things you need to do," then does them all itself.

The question the developer throws out at the end is both a joke and a prophecy: "At this point, why are you still here?"

MCP (Model Context Protocol) is an open protocol proposed and open-sourced by Anthropic in late 2024, designed to let language models connect to external tools, data sources, and services in a unified way. Simply put, an MCP server acts as a standardized adapter layer: it wraps an application's capabilities (such as to-dos, calendars, databases, file systems) into tools that a model can call, and models like Claude can read data or execute operations through an MCP client. This solves the fragmentation problem where every model-tool integration previously required custom adapter code. This is precisely why Claude in the article can "directly take over" to-do tasks and execute them on your behalf—it's also the key infrastructure that turns AI agents from "advisors" into "executors."

The Real Dilemma of Agent Orchestration

Although this share is mostly tongue-in-cheek, it touches on several real technical challenges:

Missing convergence mechanisms for inter-agent disagreement. Multiple independent agents producing different judgments on the same task is the norm, but current agent frameworks rarely have elegant dispute resolution strategies. Adding a "judge agent" seems reasonable but actually just pushes the problem up one layer.

Insufficient cost visibility. The absurd scenario of 2 million tokens for one pizza stems from developers being unable to intuitively perceive the marginal cost of each additional agent. When your app runs on API calls, every agent interaction costs real money.

Redefining the human role. When AI agents can autonomously plan, review, and execute tasks, the human role in to-do apps shifts from "executor" to "goal setter." This isn't necessarily a bad thing—but only if you can accept being responsible solely for "what to do" rather than "how to do it."

This developer's experience is not an isolated case. As the MCP protocol and agent orchestration frameworks become more widespread, more and more developers will encounter similar problems in their own apps: agents are great to use, but collaboration between agents is hard to manage. And the hardest part to manage is precisely what role you yourself still need to play among these agents.

One-line Summary

A developer hooked multiple AI agents into a to-do app—the agents argued with each other, costs spiraled, and the human became a bystander.

Paragraph Summary

The article recounts a series of absurd phenomena that emerged after a developer integrated a multi-agent AI system into his personal to-do app: two AI review agents argued for three days over the same Pull Request without converging; a vector database upgraded to-do search to semantic understanding; and after assigning dedicated agents to every stage, a single "deliver pizza" task triggered a pipeline of planning, review, approval, notification, and even judge agents—ultimately burning 2 million tokens. Through this, the author points out the real challenges facing multi-agent systems: inter-agent disagreements lack convergence mechanisms, cost visibility is insufficient, and the human role is redefined from executor to goal setter. He emphasizes that the real difficulty isn't any single agent's capability, but the governance of collaboration between agents.