The Work Should Define the Agent

Eno Reyes posted a question that has been stuck in my head:

Which agent boundaries survive? Agent “teams” split context, tools, and permissions. Once one system can delegate + parallelize on its own, why should separation live at the task level? Feels like end state is a single system plus interface that makes the delegation legible.

I had not thought about it exactly that way before.

A lot of current agent products organize around the idea of a team. There is a researcher, a coder, a reviewer, a product manager, maybe a designer. It makes sense as an interface because it borrows from the way companies already work. If there are multiple humans involved, categorizing the system into roles and teams is immediately understandable.

But I think that model can hide the more important object.

The important object is not the agent.

It is the work.

The Inversion

Most multi-agent systems seem to start from the worker:

research agent
coding agent
review agent

Each worker has a role, a prompt, a tool set, some memory, some permissions, and a loop. The work is then routed through the workers.

That feels natural because it looks like an org chart. But it also means the loop lives inside the worker.

The better shape may be the opposite:

work container
  -> chooses the loop
  -> chooses the tools
  -> chooses the permissions
  -> chooses the workers

In other words, the work should define the agents, not the other way around.

That is the thing I like about the soul-cli direction. It is not really about building a team of named bots. The stable thing is a work container: task, run, workspace, evidence, review, handoff.

The agent is just one way of moving the work forward.

What I Mean by a Work Container

A normal task is thin:

Fix login.

A work container is thicker. It carries the context needed to actually make that work accountable:

What should become true?
What is in scope?
What is out of scope?
What can the system touch?
Which workspace is safe?
What evidence proves it worked?
Who or what reviewed it?
What changed?
What is still open?

That sounds like process, but I think it is really memory.

Without that container, all of this ends up in a chat transcript. The agent says it made the change. Maybe it pasted the test output. Maybe a second agent reviewed it. Maybe I remember the branch. Maybe I don’t.

The human becomes the database.

That is fine for small things. It breaks down when the work spans more than one session, one model, one checkout, or one person.

A work container gives the work somewhere to live outside the conversation.

Why the Agent Team Metaphor Leaks

I understand why people reach for agent teams. They make delegation visible.

If I see a research agent hand something to a coding agent and then a review agent, I can follow the story. It is much more legible than an opaque box saying “AI is working.”

But the metaphor starts leaking when the named agent becomes the source of truth.

If the backend agent owns the backend task, then the boundary is attached to the agent. Its prompt, tools, context, and habits start to define what the work is.

I would rather have the boundary attached to the work:

This work touches these files.
This work has this authority.
This work needs this evidence.
This work requires this review.

Then it matters much less whether the system used one model, three subagents, a shell command, or a human reviewer.

The work stays the same work.

The Boundaries That Still Matter

Eno’s question is useful because it separates the boundaries that are probably temporary from the ones that are durable.

The persona boundary feels temporary. “Researcher” and “coder” are helpful labels, but I do not think they are deep system boundaries. As the general system gets better, these roles become more like runtime modes.

The context boundary may change too. We use task splits today partly because context windows and attention are limited. That will keep improving, even if relevance will still matter.

But some boundaries do not go away.

Authority does not go away. Reading a file, editing a repo, sending a message, using a credential, publishing a post, or deploying code are not the same kind of action.

Scope does not go away. The system needs to know what it is allowed to touch.

Evidence does not go away. I need to know what actually happened, not just that the model is confident.

State does not go away. Real work can be pending, running, blocked, verified, reviewed, merged, abandoned, or closed.

Handoff does not go away. Tomorrow’s session needs to know where to pick up.

Those are work boundaries, not persona boundaries.

How This Maps to Soul CLI

This is the part that made the Eno tweet click for me.

In soul-cli, the useful shape is closer to:

task -> run -> workspace -> verifier -> review -> closeout

The task says what should become true.

The run says which attempt tried to make it true.

The workspace says where it happened.

The verifier says what proof exists.

The review says what another pass found.

The closeout says what changed and what should happen next.

Codex, Gemini, Hermes, shell scripts, browser checks, and human review can all participate. But none of them owns the meaning of the work.

That is the important distinction.

The provider is an execution surface.

The agent is a worker.

The work container is the thing I want to preserve.

Delegation Should Be Visible, Not Primary

I do not think the final interface should hide delegation. I want to see what the system is doing. I want to know when it split the problem, when it ran things in parallel, when it called a reviewer, and when it needs me.

But I do not want to manage an org chart of bots.

I want the interface to say something more like:

Work: draft the blog post
Status: ready for review
Scope: src/content/blog
Workers used: writer, build verifier
Evidence: markdown exists, local build passed
Blocked on: human edit pass

The workers are still visible. They are just not the product.

The product is the accountable unit of work.

The Thing That Survives

The topology of agents is going to keep changing.

Today it looks like named teams.

Tomorrow it might be one general agent with internal branches.

Later it might be an orchestrator spawning dozens of short-lived workers with scoped tools.

That is all implementation detail.

The thing I think survives is the container around the work:

What is this work?
What can it touch?
What happened?
What evidence exists?
What is still unresolved?

So I would phrase the inversion this way:

Agent-team systems put work loops inside workers.

The better architecture puts workers inside accountable work.

That is a much more stable boundary for the kind of systems I want to build.