A line I saw this week was a little too accurate: the problem right now is not that we do not have enough agents. The problem is that we do not have enough work to give them.

The original post came from Zara Zhang: https://x.com/zarazhangrui/status/2046662237306421608

I laughed when I first read it, not because it was exaggerated, but because it felt uncomfortably close to the truth.

To avoid hiding the sources behind linked anchor text only, here are the primary source URLs up front:

Over the past few months, agent products have been multiplying fast. OpenAI is talking about Workspace Agents. Microsoft is pushing Bring your own Agent to MS Teams. Zed has put Parallel Agents directly into the IDE. Every even published a long discussion titled We Gave Every Employee an AI Agent. Here’s What Happened.

Looking at all of that, it is easy to get seduced by the same fantasy: give everyone a few agents and the office somehow becomes semi-autonomous.

But once these tools enter actual day-to-day work, a different problem shows up almost immediately. The issue is not that agents are too weak. It is that a lot of work inside real organizations has still not been shaped into forms that agents can reliably take over.

We are not short on agents. We are already a little overcrowded

This market no longer feels agent-starved. If anything, it feels oversupplied.

There are agents in office suites, agents in IDEs, agents in customer support tools, agents in research products, and agents standing next to code repositories. The open-source side is even noisier, with new harnesses, orchestration layers, and multi-agent frameworks showing up constantly. Everyone wants AI to look like a digital employee.

That is exciting on the surface. It does not automatically mean the tools are landing well.

A lot of teams now look roughly like this:

  • too many chat windows open
  • a few automation chains wired together
  • knowledge bases, MCP servers, and browser integrations all connected
  • meeting notes summarized automatically
  • and yet the important steps still depend on people copying, checking, repairing, and redoing work by hand

That is a useful signal.

If a team has already added plenty of agents but the work still does not feel lighter, the missing piece is probably not one more agent. It is that the work itself has not been broken down clearly enough.

What is actually scarce is handoff-ready work

The more I watch agent adoption, the more I think the hard part is not model intelligence. It is task design.

People say things like:

  • follow up on this project
  • organize this customer feedback
  • research this market
  • move this requirement forward

Those sound like tasks. Most of the time they are closer to wishes.

Ask an agent to “follow up on a project” and the ambiguity explodes immediately. Should it read internal docs? Should it inspect chat logs? Can it touch Jira? Is it allowed to message people? Is it only summarizing information, or can it make prioritization calls on its own? Every step drags in three very concrete questions: context, permissions, and review criteria.

If those three things are fuzzy, an agent stops feeling like leverage and starts feeling like a new person you have to supervise.

So when I look at an agent product now, I do not care first about how many skills it claims. I care about something more boring and more important: can it accept work in a stable way?

For a task to be truly handoff-ready, at least three things need to be clear:

  1. The input is clear: where the information comes from
  2. The boundary is clear: what the agent may do and what it must not touch
  3. The output is clear: how a human can review the result quickly

Miss any one of those, and things get messy fast.

These product launches are all trying to answer the same question

If you put the latest launches side by side, a pattern emerges. On the surface, they look like different products announcing different features. Underneath, they are all chasing the same prize: who can insert agents into real workflows in the most natural way.

1. Workspace Agents: trying to own information work

OpenAI’s Workspace Agents are clearly aimed at the flow of office knowledge work: reading documents, gathering context, connecting information across tools, and helping move analytical work forward.

That is a reasonable place to start, because knowledge work is exactly where agents can compress information before a human makes the call. It is also where the cracks show up fast. The information surface is huge, the boundaries are vague, and responsibility gets blurry very quickly.

In plain terms, Workspace Agents are trying to solve the question of whether an agent can help. What organizations care about just as much is what the agent is allowed to see, touch, change, and when it must stop.

If products like this want to become normal inside teams, sounding intelligent is not enough. They also need stronger permission models and much better traceability. The more an agent resembles a coworker, the more it also starts to resemble a risk surface.

2. Teams Agent: inserting agents into the collaboration layer itself

Microsoft’s Bring your own Agent to MS Teams is interesting for a slightly different reason. It is not just adding another chatbot. It is trying to place agents inside a system that already carries communication, collaboration, and organizational relationships.

That sounds convenient. It also raises the bar.

Once an agent enters the collaboration layer, it is no longer just a tool that answers questions. It becomes something that might participate in message flows, task flows, and approval flows. What it says, what it sees, and what actions it can trigger become much more sensitive than in a one-on-one chat box.

My read on this direction is that the upside is real, but the organizational homework is heavy. Companies may say they want agents in principle, then get a lot more cautious the moment real access control enters the conversation.

3. Zed Parallel Agents: turning multi-agent hype into a developer productivity test

Zed’s Parallel Agents represent a very typical product instinct right now. One agent is not enough. So why not run several at once and split the work across them?

The appeal is obvious. In software work especially, it sounds great to have multiple agents read the repository, inspect problems, and touch different parts of the codebase while you sit in the middle collecting results.

Still, I have one recurring reservation about parallel agents: parallelism does not just increase speed. It also increases review load.

If the boundaries are clean and the modules are well isolated, parallel work can be fantastic. If several agents are all touching a half-understood shared context, the result may not be higher throughput. It may just be more diffs, more conflicts, and more time spent auditing what happened.

So the real thing Zed and similar products need to prove is not that they can run multiple agents. It is that they can make the resulting work converge into something a human can control without drowning in cleanup.

4. Every’s employee-agent experiment: bringing the fantasy back down to earth

I like Every’s discussion, We Gave Every Employee an AI Agent. Here’s What Happened., because it drags the conversation out of launch-copy language and back into operational reality.

The idea of giving every employee an agent sounds futuristic and exciting. Real work, unfortunately, is rarely a neat row of API calls. It is full of temporary judgment, context switching, unwritten norms, permission boundaries, and responsibility questions.

If a company genuinely wants an agent sitting next to every employee, the deciding factor will not just be model quality. It will be whether the organization can answer questions like these:

  • What work should be delegated to an agent?
  • What work must stay with a human decision-maker?
  • Which systems may the agent access?
  • What is the rollback path when it gets something wrong?
  • Who reviews the output?
  • How detailed should the logs be?

If those questions remain unresolved, adding more agents just gives you a room full of eager interns with nobody coordinating them.

Why teams can buy agents and still not feel any lighter

My answer is pretty simple: they bought executors without building a dispatch system.

Imagine hiring five sharp new people at once. They are responsive, fast learners, and willing to help. That sounds great. But if nobody decomposes tasks, defines standards, or checks output, those five people do not automatically create leverage. They can just as easily create management overhead.

Agents are not different in that respect.

A lot of teams today do not need another smoother-talking agent. They need three more ordinary, less glamorous layers of infrastructure.

The next stage depends on three things

1. Task decomposition

A surprising number of organizations do not have an execution problem. They have a task-language problem.

A task that is suitable for an agent should usually specify things like:

  • where to find the material
  • what matters most
  • what must not be touched
  • what format to return
  • when to stop and hand the work back to a human

That is not really prompt engineering anymore. It is management quality.

2. Permissions and boundary systems

The moment an agent enters a real workflow, it stops being just a conversational model and starts becoming a potential operator.

Can it read internal documents? Can it send messages? Can it modify a database? Can it change code? Can it act on your behalf directly? None of that should be handled with a hand-wave.

Honestly, a lot of fear around agents is not fear that they are unintelligent. It is fear that they will be overconfident in places where they should have remained read-only.

3. Review and rollback

This is the layer people skip most often.

When an agent finishes something, what exactly counts as complete? Who verifies it? What happens when it is wrong? Is there a rollback path? Is there a log? Can you reconstruct which information it used, which tools it called, and where it made decisions?

Without those mechanisms, an agent is less like a dependable production tool and more like a highly variable contractor.

The framing I dislike most

One of my least favorite moves in this whole conversation is when every failure gets blamed on the user for not knowing how to use agents properly.

That is not completely false. I still do not like it.

If a product is actually maturing, it should help users clarify tasks, define boundaries, and structure outputs. It should not dump most of the systems burden back onto the user and then call the failure a skill issue.

That is a little like selling someone a very expensive pen and then explaining that the reason they cannot write a good essay is that they lack literary talent. The statement may contain some truth. It is also a very lazy dodge.

Good products reduce organizational friction. They do not rebrand friction as a learning curve.

One last thought

If you only watch launch velocity, the AI industry looks obsessed with creating digital employees.

Look one layer deeper, though, and what it really lacks is digital management.

Agents are not scarce. Work that has been structured, permissioned, defined, and made reviewable is scarce.

The teams that learn how to reshape work into forms machines can execute and humans can verify will capture the real upside. A lot of the rest, frankly, is still launch-event theater.