How Many LLM Agents Does It Take to Screw In a Lightbulb?

Apparently, MORE. EVERY. WEEK.

One agent identifies that the room is dark.

A second verifies that darkness is, in fact, undesirable.

A third researches compatible lightbulbs.

A fourth reviews the research.

A fifth checks whether the reviewer hallucinated anything.

A sixth creates a replacement plan.

A seventh evaluates the plan for safety.

An eighth watches the seventh for prompt injection.

A ninth summarizes everything so the tenth can finally walk over to the lamp.

Then the tenth discovers nobody gave it access to the light switch.

Perfect... So we add a tooling agent.

This is obviously a joke.

It is also increasingly what AI architecture looks like.

We keep treating bad structure as an intelligence problem

LLMs are fallible.

Shocking, I know.

They hallucinate. They misunderstand things. They lose context. They occasionally choose the wrong tool and confidently sprint in the wrong direction.

So what do we do?

ADD ANOTHER LLM.

Naturally.

The first agent writes code, so we add a review agent.

The reviewer is also fallible, so we add a verifier.

Now the agents need to communicate, so we add a coordinator.

The handoffs lose information, so we add schemas and filters.

The filters remove useful context, so we add adjudication.

Then nobody really understands what the hell is happening.

Add a supervisor agent.

Congratulations. We have built middle management.

Another agent is not automatically a reliability primitive

There are absolutely situations where multiple agents help.

Independent research can expose blind spots. Parallel workers can tackle genuinely separate problems.

But there is a weird assumption hiding inside a lot of multi-agent design:

One fallible agent is risky, therefore several fallible agents talking to each other must be reliable.

...why?

Every 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.

Then you connect them.

Excellent.

Now you get distributed misunderstanding.

Information gets summarized badly.

Context disappears during handoffs.

Agents disagree about state.

One acts on stale output from another.

Another confidently verifies something that was already wrong.

Then you need provenance, confidence scores, retries, consensus, monitoring, memory, cleanup, and eventually an agent to manage all the agents managing all the other agents.

At some point, maybe the problem is no longer the lightbulb.

The bolt-on loop

This pattern should look familiar:

Agent makes mistakes
        ↓
Add reviewer
        ↓
Reviewer makes mistakes
        ↓
Add verifier
        ↓
Handoffs are unreliable
        ↓
Add protocol
        ↓
Protocol carries garbage
        ↓
Add filtering
        ↓
System becomes incomprehensible
        ↓
Add supervisor

Then someday:

Supervisor behaves strangely
        ↓
????

I think we all know what comes next.

Another fucking agent.

We keep adding complexity to manage complexity that we added to manage complexity.

Software has done this before.

Microservices had their version.

Enterprise middleware had its version.

Now AI gets to rediscover the ancient engineering tradition of building a giant machine to solve the problems caused by the previous giant machine.

Progress!

What if the agent could just push the button?

Take deployment.

You could build this:

Planning Agent
      ↓
Deployment Agent
      ↓
Security Agent
      ↓
Validation Agent
      ↓
Monitoring Agent

Very futuristic.

Look at all those boxes.

Or you could build:

deploy()

Wild idea.

And maybe deploy() could handle the repeatable shit computers have been pretty good at for several decades:

check configuration
run tests
scan secrets
validate schema
build artifact
deploy
run health checks
record result

Then return something structured:

{
  "status": "failed",
  "stage": "health_check",
  "service": "api",
  "reason": "database migration 42 not applied",
  "safe_to_retry": true
}

Holy shit.

Now the agent immediately knows what happened.

It does not need a Deployment Historian Agent to interview the Security Agent about what the Validation Agent remembers seeing.

It reads the state.

It understands the failure.

It decides what to do next.

That is where I want to spend intelligence.

Spend intelligence on the weird parts

This has become one of my favorite rules for agent systems:

Do not add intelligence where structure can remove the need for intelligence.

Software should handle the repeatable shit.

Agents should handle ambiguity.

If 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.

That is not intelligence.

That is making your smartest component do clerical work.

Encode the workflow.

Validate it.

Test it.

Turn it into a tool.

Give the agent the button.

Then let the model reason about the things that actually require reasoning.

Should we deploy?

Why did this fail?

Is this exception safe?

Does the user's intent change the normal procedure?

Is the situation genuinely novel?

Use intelligence where intelligence buys you something.

Make the environment legible

The same problem shows up when agents cannot understand the systems we put them inside.

Repository confusing?

Add a repository exploration agent.

State scattered across six services?

Context gathering agent.

Nobody knows what happened yesterday?

Summarization agent.

Tasks have unclear ownership?

Orchestration agent.

Or...

and stay with me here...

we could make the system less confusing.

Expose canonical state.

Use stable names.

Give tools clear contracts.

Provide machine-readable indexes.

Record decisions somewhere predictable.

Make failures explicit.

An agent entering a system cold should be able to quickly answer:

Where am I?

What is true right now?

What happened before?

What can I do?

What should happen next?

If answering those five questions requires consulting an autonomous workforce, the environment might suck.

That is not an agent-count problem.

Better primitives beat more personalities

I have been thinking about this constantly while working on memory systems.

There are two broad ways to get sophisticated behavior.

You can keep adding systems that manage behavior from above.

Or you can improve the rules underneath until useful behavior emerges naturally.

Want important memories to survive?

One approach:

importance classifier
retention manager
memory reviewer
staleness detector
consolidation agent
cleanup agent

Very impressive diagram.

Or maybe:

use it → strengthen it
ignore it → weaken it
use things together → associate them
stop using the association → let it fade

That second version interests me a hell of a lot more.

Frequently useful structure survives because it is frequently useful.

The 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.

Sometimes the simple mechanism is the mechanism.

That does not mean every problem should be emergent.

Security should not be vibes.

Permissions should not emerge organically.

Canonical truth sometimes needs explicit enforcement.

But that gives us a much better default:

Before adding another intelligent layer, ask whether a better primitive makes the layer unnecessary.

Multi-agent systems still have a place

Before somebody screenshots half this article and tells me I "don't understand agents":

Yes.

Multiple agents can be useful.

If I want three independent interpretations of experimental results, that can make sense.

If five research tasks are genuinely independent, parallelize them.

If something deserves adversarial review because the judgment itself is difficult, great.

Use another agent.

But the key is that there should be another useful reasoning problem.

Not just a bad workflow.

If 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.

I need a good fucking tool.

Maybe the goal should be LESS reasoning

This is the part I think we have backwards.

Agent demos often optimize for how much autonomous reasoning they can show.

Look!

The model made a plan.

Then it delegated.

Then that model delegated.

Then three models voted.

Then the supervisor reconciled the results.

Then another model summarized the reconciliation.

Amazing.

But why did any of that need to happen?

I think a better engineering target is:

How little reasoning does the agent need to reliably accomplish the work?

That changes the architecture.

Instead of another role, improve the tool.

Instead of another reviewer, add a deterministic check.

Instead of another coordinator, expose the state machine.

Instead of another agent explaining the system to the first agent, make the system understandable.

The architecture diagram might have fewer boxes.

That is okay.

You do not get bonus points because your light switch requires Kubernetes.

The lightbulb test

Before adding another agent, ask:

Could I make the existing agent succeed by improving the environment instead?

Could the state be clearer?

Could the workflow be encoded?

Could the operation become a tool?

Could validation be deterministic?

Could the system expose something the agent currently has to infer?

Could we, perhaps, just fix the workflow?

If yes, try that first.

Because every new agent adds more than compute.

It adds another mental model.

Another context boundary.

Another communication path.

Another place for information to mutate.

Another source of uncertainty.

Another thing somebody eventually has to understand.

And 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.

"Hear me out."

"What if we add an agent to manage it?"

Of course.

So how many LLM agents does it take to screw in a lightbulb?

Ideally?

One.

Provided somebody had the sense to give it a fucking light switch.