--- title: "Your agents are giving you too much to manage because you’re doing it wrong" description: "Your agents should bring you decisions, not status updates." canonical: "https://www.rickblalock.dev/scratch-notes/your-agents-are-giving-you-too-much-to-manage-because-youre-doing-it-wrong/" date: "2026-11-13" updated: "2026-11-13" author: "Rick Blalock" --- # Your agents are giving you too much to manage because you’re doing it wrong > Your agents should bring you decisions, not status updates. Published: 2026-11-13 Catalog: SN-030 It's not uncommon for me to run more than ten agents at a time on a project. They can produce hundreds of updates in an hour. They open tasks, find dependencies, change statuses, leave comments, hand work off, and discover more work along the way. Sometimes several agents are updating related parts of the same project at once (don't get me started on how awful Git worktrees are when you have a Rust project with a big build cache). All of that activity might be necessary for the agents. It is not something I am going to read or frankly should read or care about. I keep telling my agents some version of the same thing: > I’m not going to read any of this. Surface what needs my attention. Tell me what mattered about the last hundred issues and ten hours of work. Tell me which decisions I need to review. Or in other words: Treat me like a VP, not a coworker who needs to review your work or code. The problem is not that I am running too many agents. It's that I fall into this trap a lot of us are falling into: managing status updates and not approaching it with a larger organizational theory towards agent management. I've also found it woefully inadequate to use things like Kanban, Linear/Jira-like lists, etc. ## Past: We built management software for people A project board makes sense for a human team. People create and update work at human speed. A task may change hands a few times. A status change communicates something useful. A manager can scan a board, notice what is blocked, and ask someone what happened. The people doing the work and the people managing it can share roughly the same view. Most of our management software assumes this. It gives everyone some version of the same tasks, statuses, comments, assignments, and notifications. That model also assumes an important idea about accountability. [Linear’s guidelines for agents](https://linear.app/developers/aig), for example, say that an agent cannot be held accountable. An agent can carry out a task, but final responsibility remains with a person. Linear represents this by treating the agent as a delegate while a human retains ownership. That *sounds* right and smart. Until an agent creates 100 commits and micro-updates and comments left for its next subagent to kick off. Sure, someone still needs to decide what good looks like, approve consequential choices, but "owning the result" I'd argue depends on which altitude of the results matter. If a swarm of agents is managing lots of tasks, their results should be owned by them. There's no way a human can manage the results of 1,000 tasks. Maybe another way of saying this: keeping a person accountable does not mean making that person consume the machine’s coordination feed and their micro-results. This isn't any different than human organizations. You can't expect a VP to be involved in every single hallway conversation. That's not effective or efficient. ## Present: We put agents inside the old model We started by giving one agent an issue. That works. A person describes the task, the agent does the work, and the person reviews the result. Then we add another agent. And another. Before long, a planning agent is breaking a project into tasks, worker agents are claiming pieces, and reviewer agents are sending work back for changes. We have changed the shape and speed of the work without changing how we expect a person to supervise it. The project board may still be accurate. It is no longer useful in the same way. A status update written by a person was communication. A hundred status changes produced by machines resemble telemetry. An agent also needs things a person rarely notices. This is why tools such as [Beads](https://www.thoughtworks.com/radar/tools/beads) are popping up *alongside* human project trackers. Thoughtworks describes the split like so: a system such as Linear can hold team plans and priorities while Beads tracks the finer-grained work agents create as they operate. The agents may need that detailed coordination system. I do not need to live in it. ## Future: More work underneath a smaller interface Mike Taylor recently wrote about [what might come after agent orchestration](https://every.to/also-true-for-humans/the-next-two-levels-of-ai-adoption). His next step is not one agent team carrying out one plan. It is several agent teams trying different plans and competing to find a better one. After that, he imagines repeating the competition under different conditions. One strategy may work because it is sound. Another may win because it got lucky. Running many versions could show which results hold up when the order, timing, or early reactions change. I am interested in that future. ***I am also certain that I do not want fifty dashboards showing me how it happened.*** If three agent teams try five strategies across fifty simulated versions of a business, their internal work will be enormous. There will be tasks, arguments, failed approaches, scores, revisions, and disagreements. The person should not receive all of that activity. They should receive something closer to: - what the agents recommend; - why they recommend it; - which alternatives they rejected; - which assumptions matter most; - what could change the answer; - where the agents still disagree; - what requires human approval. Let's take it to the "real world" of small business: Imagine a repair company trying to reduce late appointments without creating regular overtime. Underneath the surface, agents might test several scheduling policies against many different weeks. Parts arrive late. A technician calls out. An emergency job appears. A customer cancels. Another customer has already been rescheduled once. The owner should not receive fifty simulated calendars and five hundred machine-generated tasks. The owner needs to know that reserving one afternoon slot per crew reduced late appointments in most of the simulations, but left some capacity unused during quiet weeks. They need to know that the recommendation stops working when emergency jobs cross a certain threshold. Then the system should ask the actual question: Is the improvement in customer reliability worth the unused capacity? That is a decision. “Simulation 38 completed... (5,000 items on a dashboard to show everything done)” is a status update. ## Two systems, not one crowded board I think agentic work is separating into at least two views. The machine view contains every task, dependency, handoff, retry, claim, failure, and result. It needs enough detail for the agents to coordinate and for someone to reconstruct what happened later. The human view contains the decisions, exceptions, material changes, unresolved risks, and evidence that deserve attention. The detailed record should not disappear. If an agent exceeds its authority, a recommendation looks wrong, or a decision causes harm, someone needs to inspect the evidence. A concise summary is not a substitute for an audit trail. But the audit trail should not be the normal management experience. The principle is not “don’t show me the work.” It is “don’t make reviewing all the work my default job.” We are putting machines that operate at a completely different speed into software designed to coordinate people, then wondering why supervising them creates more work. The agents may need every task, dependency, handoff, retry, and status change. You, Mr. Human, do not. It might make you feel important or needed but it's wasting your value in this human <> agent relationship. They should bring you what changed, what they recommend, what could go wrong, and what requires your judgment. The proof should remain available when you want to inspect it. An AI team has not reduced your work if supervising it becomes the only work you do. --- [All Scratch Notes](https://www.rickblalock.dev/scratch-notes/)