{"slug": "how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb", "title": "How Many LLM Agents Does It Take to Screw In a Lightbulb?", "summary": "A developer argues that stacking fallible LLM agents into reviewer, verifier, coordinator and supervisor roles produces \"distributed misunderstanding\" rather than reliability, since each added agent introduces another prompt, context window and set of assumptions. The post contrasts a five-agent deployment pipeline with a single deterministic deploy() function that runs configuration checks, tests, secret scanning, schema validation, artifact builds, health checks and returns structured status output an agent can act on directly.", "body_md": "Apparently, **MORE. EVERY. WEEK.**\n\nOne agent identifies that the room is dark.\n\nA second verifies that darkness is, in fact, undesirable.\n\nA third researches compatible lightbulbs.\n\nA fourth reviews the research.\n\nA fifth checks whether the reviewer hallucinated anything.\n\nA sixth creates a replacement plan.\n\nA seventh evaluates the plan for safety.\n\nAn eighth watches the seventh for prompt injection.\n\nA ninth summarizes everything so the tenth can finally walk over to the lamp.\n\nThen the tenth discovers nobody gave it access to the light switch.\n\nThis is obviously a joke.\n\nIt is also increasingly what AI architecture looks like.\n\nLLMs are fallible.\n\nShocking, I know.\n\nThey hallucinate. They misunderstand things. They lose context. They occasionally choose the wrong tool and confidently sprint in the wrong direction.\n\nSo what do we do?\n\nNaturally.\n\nThe first agent writes code, so we add a review agent.\n\nThe reviewer is also fallible, so we add a verifier.\n\nNow the agents need to communicate, so we add a coordinator.\n\nThe handoffs lose information, so we add schemas and filters.\n\nThe filters remove useful context, so we add adjudication.\n\nThen nobody really understands what the hell is happening.\n\nCongratulations. We have built middle management.\n\nThere are absolutely situations where multiple agents help.\n\nIndependent research can expose blind spots. Parallel workers can tackle genuinely separate problems.\n\nBut there is a weird assumption hiding inside a lot of multi-agent design:\n\nOne fallible agent is risky, therefore several fallible agents talking to each other must be reliable.\n\n...why?\n\nEvery new agent adds another prompt, another context window, another interpretation of the task, another set of assumptions, and another place where something can go sideways.\n\nThen you connect them.\n\nExcellent.\n\nNow you get **distributed misunderstanding**.\n\nInformation gets summarized badly.\n\nContext disappears during handoffs.\n\nAgents disagree about state.\n\nOne acts on stale output from another.\n\nAnother confidently verifies something that was already wrong.\n\nThen you need provenance, confidence scores, retries, consensus, monitoring, memory, cleanup, and eventually an agent to manage all the agents managing all the other agents.\n\nAt some point, maybe the problem is no longer the lightbulb.\n\nThis pattern should look familiar:\n\n```\nAgent makes mistakes\n        ↓\nAdd reviewer\n        ↓\nReviewer makes mistakes\n        ↓\nAdd verifier\n        ↓\nHandoffs are unreliable\n        ↓\nAdd protocol\n        ↓\nProtocol carries garbage\n        ↓\nAdd filtering\n        ↓\nSystem becomes incomprehensible\n        ↓\nAdd supervisor\n```\n\nThen someday:\n\n```\nSupervisor behaves strangely\n        ↓\n????\n```\n\nI think we all know what comes next.\n\n**Another fucking agent.**\n\nWe keep adding complexity to manage complexity that we added to manage complexity.\n\nSoftware has done this before.\n\nMicroservices had their version.\n\nEnterprise middleware had its version.\n\nNow AI gets to rediscover the ancient engineering tradition of building a giant machine to solve the problems caused by the previous giant machine.\n\nProgress!\n\nTake deployment.\n\nYou could build this:\n\n```\nPlanning Agent\n      ↓\nDeployment Agent\n      ↓\nSecurity Agent\n      ↓\nValidation Agent\n      ↓\nMonitoring Agent\n```\n\nVery futuristic.\n\nLook at all those boxes.\n\nOr you could build:\n\n```\ndeploy()\n```\n\nWild idea.\n\nAnd maybe `deploy()` could handle the repeatable shit computers have been pretty good at for several decades:\n\n```\ncheck configuration\nrun tests\nscan secrets\nvalidate schema\nbuild artifact\ndeploy\nrun health checks\nrecord result\n```\n\nThen return something structured:\n\n```\n{\n  \"status\": \"failed\",\n  \"stage\": \"health_check\",\n  \"service\": \"api\",\n  \"reason\": \"database migration 42 not applied\",\n  \"safe_to_retry\": true\n}\n```\n\nHoly shit.\n\nNow the agent immediately knows what happened.\n\nIt does not need a **Deployment Historian Agent** to interview the Security Agent about what the Validation Agent remembers seeing.\n\nIt reads the state.\n\nIt understands the failure.\n\nIt decides what to do next.\n\n**That is where I want to spend intelligence.**\n\nThis has become one of my favorite rules for agent systems:\n\n**Do not add intelligence where structure can remove the need for intelligence.**\n\nSoftware should handle the repeatable shit.\n\nAgents should handle ambiguity.\n\nIf a workflow always requires the same fifteen operations, do not make a language model rediscover those fifteen operations every single time just because it technically can.\n\nThat is not intelligence.\n\nThat is making your smartest component do clerical work.\n\nEncode the workflow.\n\nValidate it.\n\nTest it.\n\nTurn it into a tool.\n\nGive the agent the button.\n\nThen let the model reason about the things that actually require reasoning.\n\nShould we deploy?\n\nWhy did this fail?\n\nIs this exception safe?\n\nDoes the user's intent change the normal procedure?\n\nIs the situation genuinely novel?\n\n**Use intelligence where intelligence buys you something.**\n\nThe same problem shows up when agents cannot understand the systems we put them inside.\n\nRepository confusing?\n\nAdd a repository exploration agent.\n\nState scattered across six services?\n\nContext gathering agent.\n\nNobody knows what happened yesterday?\n\nSummarization agent.\n\nTasks have unclear ownership?\n\nOrchestration agent.\n\nOr...\n\nand stay with me here...\n\n**we could make the system less confusing.**\n\nExpose canonical state.\n\nUse stable names.\n\nGive tools clear contracts.\n\nProvide machine-readable indexes.\n\nRecord decisions somewhere predictable.\n\nMake failures explicit.\n\nAn agent entering a system cold should be able to quickly answer:\n\n```\nWhere am I?\n\nWhat is true right now?\n\nWhat happened before?\n\nWhat can I do?\n\nWhat should happen next?\n```\n\nIf answering those five questions requires consulting an autonomous workforce, **the environment might suck.**\n\nThat is not an agent-count problem.\n\nI have been thinking about this constantly while working on memory systems.\n\nThere are two broad ways to get sophisticated behavior.\n\nYou can keep adding systems that manage behavior from above.\n\nOr you can improve the rules underneath until useful behavior emerges naturally.\n\nWant important memories to survive?\n\nOne approach:\n\n```\nimportance classifier\nretention manager\nmemory reviewer\nstaleness detector\nconsolidation agent\ncleanup agent\n```\n\nVery impressive diagram.\n\nOr maybe:\n\n```\nuse it → strengthen it\nignore it → weaken it\nuse things together → associate them\nstop using the association → let it fade\n```\n\nThat second version interests me a hell of a lot more.\n\nFrequently useful structure survives because it is **frequently useful**.\n\nThe system does not need another model waking up at 3 AM to gaze deeply into a SQLite database and decide which memories feel spiritually significant today.\n\nSometimes the simple mechanism is the mechanism.\n\nThat does not mean every problem should be emergent.\n\nSecurity should not be vibes.\n\nPermissions should not emerge organically.\n\nCanonical truth sometimes needs explicit enforcement.\n\nBut that gives us a much better default:\n\n**Before adding another intelligent layer, ask whether a better primitive makes the layer unnecessary.**\n\nBefore somebody screenshots half this article and tells me I \"don't understand agents\":\n\nYes.\n\nMultiple agents can be useful.\n\nIf I want three independent interpretations of experimental results, that can make sense.\n\nIf five research tasks are genuinely independent, parallelize them.\n\nIf something deserves adversarial review because the judgment itself is difficult, great.\n\nUse another agent.\n\nBut the key is that there should be **another useful reasoning problem**.\n\nNot just a bad workflow.\n\nIf I need a file renamed, tests run, a manifest updated, validation performed, and the result committed, I probably do not need an AI project manager, AI developer, AI reviewer, AI release engineer, and AI compliance officer.\n\n**I need a good fucking tool.**\n\nThis is the part I think we have backwards.\n\nAgent demos often optimize for how much autonomous reasoning they can show.\n\nLook!\n\nThe model made a plan.\n\nThen it delegated.\n\nThen that model delegated.\n\nThen three models voted.\n\nThen the supervisor reconciled the results.\n\nThen another model summarized the reconciliation.\n\nAmazing.\n\nBut why did any of that need to happen?\n\nI think a better engineering target is:\n\n**How little reasoning does the agent need to reliably accomplish the work?**\n\nThat changes the architecture.\n\nInstead of another role, improve the tool.\n\nInstead of another reviewer, add a deterministic check.\n\nInstead of another coordinator, expose the state machine.\n\nInstead of another agent explaining the system to the first agent, **make the system understandable.**\n\nThe architecture diagram might have fewer boxes.\n\nThat is okay.\n\nYou do not get bonus points because your light switch requires Kubernetes.\n\nBefore adding another agent, ask:\n\n**Could I make the existing agent succeed by improving the environment instead?**\n\nCould the state be clearer?\n\nCould the workflow be encoded?\n\nCould the operation become a tool?\n\nCould validation be deterministic?\n\nCould the system expose something the agent currently has to infer?\n\nCould we, perhaps, just fix the workflow?\n\nIf yes, try that first.\n\nBecause every new agent adds more than compute.\n\nIt adds another mental model.\n\nAnother context boundary.\n\nAnother communication path.\n\nAnother place for information to mutate.\n\nAnother source of uncertainty.\n\nAnother thing somebody eventually has to understand.\n\nAnd when the whole machine finally becomes too complicated for anyone to reason about, somebody is inevitably going to walk into the meeting with the solution.\n\n*\"Hear me out.\"*\n\n*\"What if we add an agent to manage it?\"*\n\nOf course.\n\nIdeally?\n\n**One.**\n\nProvided somebody had the sense to give it a fucking light switch.", "url": "https://wpnews.pro/news/how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb", "canonical_source": "https://dev.to/constant_itis/how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb-5998", "published_at": "2026-09-24 06:15:16+00:00", "updated_at": "2026-09-24 06:30:02.098499+00:00", "lang": "en", "topics": ["ai-agents", "large-language-models", "ai-safety", "developer-tools"], "entities": [], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb", "markdown": "https://wpnews.pro/news/how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb.md", "text": "https://wpnews.pro/news/how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb.txt", "jsonld": "https://wpnews.pro/news/how-many-llm-agents-does-it-take-to-screw-in-a-lightbulb.jsonld"}}