Multi-Human-in-the-Loop: Why AI Agents Need a Team, Not a Single Approver

Multi-human-in-the-loop is a way of designing AI agent work so that more than one person can steer it, review it, and approve it, each in their own role, inside the shared conversation where the work happens. The usual human-in-the-loop pattern puts one approver in front of one action. That works for a refund button. It doesn't fit the way teams actually make decisions.

Most writing about human-in-the-loop (HITL) for AI agents covers one question: how does the agent pause and ask a person? Every major framework has an answer by now: an interrupt, an approval decorator, a durable workflow that waits. Those are useful primitives. But they quietly assume there's exactly one human and that this human knows everything needed to say yes.

At work, that's rarely true.

The single-approver assumption

Look at how a normal piece of work moves through a team:

• Someone asks for it, often in a channel and often in passing.
• Someone else owns the system it touches.
• A third person has the context to know whether it's a good idea.
• A fourth person picks it up on Monday after the first three have logged off.

Now hand that work to an agent built on single-approver HITL. The agent pauses and routes an approval request to one person, usually whoever started it. That person approves something they can only half evaluate, because the owner and the person with context weren't in the loop. Or they don't approve at all, the request sits in a queue nobody else can see, and the work quietly dies.

Neither failure comes from the model. Both come from how the loop was shaped. A single approver is a single point of failure, and it's also a single point of context.

What multi-human-in-the-loop means

Multi-human-in-the-loop has three parts:

1. More than one human can be in the loop. The requester, the owner, the reviewer, and whoever comes next can all see the work and act on it.
2. Each human has a role, not just a button. Some people steer ("try the other repo"). Some review ("this PR is missing a test"). Some approve ("ship it"). Some only need to know it happened.
3. The loop lives where the team already talks. You don't need a separate approvals dashboard. The thread where the work started is also where questions get asked, answered, and recorded.

None of this means more people approving more things. A well-designed multi-human loop usually means fewer interruptions overall, because each question goes to the person best placed to answer it instead of to whoever happens to be holding the agent.

Why one approver breaks down for team agents

Context is spread across people

Agents have gotten very good at doing the work. The bottleneck has moved to judgment, and judgment is spread across a team. The engineer knows the code path. The PM knows the customer promise behind it. The ops lead knows what's frozen this week. An approval that only one of them can see gets judged on a third of the context.

Authority and context aren't always the same person

The person who can approve a change isn't always the person who understands it. In a shared conversation, the reviewer with context can say "this looks right" and the owner with authority can say "go." In a private approval queue, those two people never meet.

Work outlives a single session

Agent runs stop: they hit a login wall, wait on a decision, or reach the end of a turn. If the only human in the loop is offline, the work stalls. When the loop is the team, anyone with the right role can unblock it.

Accountability needs witnesses

When an agent takes a consequential action, the team should be able to answer who asked, who approved, and what they saw when they approved it. A one-on-one exchange between a single human and an agent is hard to audit. A thread that the right people can read is easy to audit.

Rubber-stamping is a solo-approver problem

When one person gets every approval request, approving becomes a reflex. Spreading review across the people who actually own each decision keeps every approval meaningful.

Human-in-the-loop vs. human-on-the-loop vs. multi-human-in-the-loop

These aren't mutually exclusive. A single workflow can have someone on the loop for routine steps and two people in the loop for the one irreversible action. The difference is that multi-human design starts by asking which people the decision belongs to, rather than which single approver to route it to.

Five principles for designing a multi-human loop

1. Put the loop in the conversation

The most important decision is where the loop lives. If an agent asks for approval in a private side channel, only one person can ever answer it. If it asks in the thread where the work started, everyone already involved can see the question, add context, and answer.

In Ando, this is the default behavior. When an agent needs a decision, a login, or an approval, it asks in the conversation or thread, and the person answers there. Ando's Tasks tie that reply back to the work, so it resumes without anyone re-briefing the agent.

2. Give agents real identities

You can't keep humans meaningfully in the loop if you can't tell who did what. An agent should be a named participant whose messages are attributed to it. It shouldn't be a shared bot token acting as whoever set it up.

In Ando, an agent that connects is a workspace member. Its messages are attributed to it, it can access only the conversations it has been added to, and each long-running agent gets its own identity and key. Ando doesn't issue workspace-wide service keys. (More on this in What "agents as teammates" actually means.)

3. Scope access to the people who should see it

Multi-human doesn't mean everyone. The loop should include the people with a stake in the decision, and the agent's access should match.

Ando handles this with two layers. Conversation membership decides which private context an agent can read. Key scopes, such as Read only, Read and reply, or Full access, decide what it can do. App connections add a third layer: a connection can belong to the workspace or to one person, and a personal connection can be set so an agent uses it only for its owner's requests ("Only when I ask") or for anyone allowed to talk to the agent ("Anyone who asks"). See Connecting apps to Ando. An agent can read a DM or private channel only when it's a participant; to share something from a DM, you forward the messages you choose.

4. Make the finish line and the open requests visible

When several people share a loop, everyone needs to see the same state. What's being asked? Who owns the next step? What does done look like? What is it waiting on, and from whom?

Ando records this in a Task: the objective, the completion criteria, the coordinator, the participants, the open requests (questions, approvals, decisions, connections, artifacts), the evidence (such as pull requests), and a shared note so the next person or agent can continue without a re-brief. Statuses like Waiting on a person, In review, and Blocked show the team at a glance where the loop is stuck. Anyone in the thread can manage it in plain words: "assign this to Alex," "close this," "what's blocking this?"

5. Protect attention

The obvious objection to multi-human loops is noise. If every agent pings every human about every step, people stop reading.

So the loop has to be selective. Ask the right person, at the right moment, about the concrete thing. One of Ando's founding tenets is that human attention is sacred: working with more agents shouldn't mean more noise. In practice, that means agents that default to responding when mentioned or messaged directly, wake policies that admins can tune, and lightweight answers. For example, an agent can treat a ✅ reaction on its plan as approval instead of needing a typed reply.

What a multi-human loop looks like in practice

Here's a plain example with nothing exotic in it.

1. A bug report lands in #bugs. An engineer mentions the team's coding agent and asks it to investigate and open a PR with a failing test.
2. The agent works, then asks in the same thread for access to a repository it can't reach. The engineer who owns the GitHub connection answers there.
3. The agent opens the PR and marks the work as ready for review. A second engineer who knows that code path reviews it in the thread and asks for one change.
4. The PM, who was already in the channel, sees that the fix changes a behavior customers rely on and adds a line for the changelog.
5. The first engineer has logged off. The reviewer approves, and the agent finishes. The Task records the PR as evidence and closes once the completion criteria are met.

Four people touched that loop, and none of them had to forward context to each other or to the agent. Nobody approved something they couldn't evaluate, and the work didn't stall when its requester went offline.

Run the same workflow through single-approver HITL and every question goes to the first engineer, including the ones they can't answer.

Where multi-human-in-the-loop is overkill

Not every action needs a committee. Keep it simple when:

• The action is reversible and low-stakes. Let the agent act and keep someone on the loop.
• One person owns all the context and all the authority. A single approver is fine. Make sure their approval is visible to the team.
• Speed matters more than review. An incident response channel needs fast action with a record afterward, not a quorum.

The goal isn't maximum oversight. It's oversight from the right people, placed where the work already happens.

Why the messenger matters

Most HITL tooling is built into the agent framework or into a separate approvals product. That makes sense if you're building one agent for one workflow. For teams that run several agents across many conversations, though, the loop is only as good as the place everyone already meets.

If your team chat treats agents as guest apps that post cards into an approvals channel, your loop will stay single-approver, however good the framework is. That's the question we keep coming back to in how to evaluate AI agents in Slack: how often does a person still have to carry context between the agent and the rest of the team? For the broader landscape, see messaging vs. orchestration and Slack AI vs. agent-native messaging.

Ando is team messaging built so that people and agents share the same rooms. Agents are members with their own identities and inboxes (Agent Inbox 101), work is tracked in the thread, and the people who should be in the loop already are. If your team is treating agents as collaborators and keeps running into single-approver bottlenecks, see how Ando compares to Slack or join the waitlist.

FAQ

What is multi-human-in-the-loop?

It's a design pattern for AI agent work in which several people, each with a distinct role (requester, owner, reviewer, approver), can steer and approve the agent's work in a shared conversation, instead of routing every decision to one approver.

How is it different from human-in-the-loop?

Standard human-in-the-loop pauses an agent and asks one person to approve a specific action. Multi-human-in-the-loop keeps that pause where it matters, but routes each question to the person best placed to answer it and keeps the whole loop visible to the team.

Doesn't more humans mean more bottlenecks?

Not if the loop is designed well. Single approvers become bottlenecks because they get every question, including the ones they can't answer. Routing questions by role, and letting anyone with the right role unblock the work, usually means fewer stalls.

Do I need a special approvals tool for this?

Not necessarily. The approval primitives in agent frameworks are fine. What's usually missing is a shared place where the right people can see the request, its context, and its history. For most teams, that place is the team chat.

Can several people in Ando approve or redirect the same agent's work?

Yes. Agents ask for approvals and decisions in the conversation or thread, and Ando ties replies there back to the Task. Anyone in that conversation can answer, reassign, or ask for status in plain words. Who can see the conversation is controlled by its membership.