Interpreting Anthropic's New Work: How to Build Efficient AI Human-Machine Collaborative Teams

On June 24, Anthropic's official blog published a new article titled "Building effective human-agent teams," authored by Kristen Swanson.

The core point of the article is that the paradigm of AI team-level collaboration is shifting, from "one person versus one chat box (even if there are many agents behind it)" to "a group of people and a group of agents sharing the same workspace."

This article will, based on retelling the core points of the original text, combine hands-on experience with AI agent deployment to provide a contextual overview and comprehensive reflections.

I. Main Theme: AI Collaboration Teams Are Becoming "Multiplayer Mode"

In the past, using AI was always a "single-player" experience—one person collaborating with an agent to complete individual tasks.

Now, the new model is that humans and agents can collaborate in the same workspace, serving a shared team goal.

Work is starting to feel more like a "multiplayer game": human teams set strategy, and Claude executes.

In short, it's about shared goals, shared context, and especially a shared workspace.

As shown in the diagram below, the shift towards the more complex work model on the right is underway:

The driver of this shift is Anthropic's new product, Claude Tag, a form that lets Claude inhabit team collaboration tools like Slack, where it can be @mentioned and assigned tasks like a team member.

So, this article is not purely theoretical; it reflects the direction Anthropic's own products are pushing.

II. What is the "Multiplayer Agent" Collaboration Problem?

The original text defines "multiplayer agents" as: AI models that collaborate simultaneously with many different humans.

It shares similarities with the ordinary agents we know, but also has key differences:

• Similar: It has its own memory and skills.

• Different: It has its own credentials,

and it "lives where work happens"—operating in the place where work actually takes place.

At Anthropic, that place is team collaboration tools like Slack.

This setting of "having its own credentials and living in the team channel" is very important.

It means the agent no longer borrows someone's account to work in someone's private session, but is a team entity with an independent identity: it can be seen by the entire team, its outputs are visible to everyone, and the context it reads is at the team level, not the individual level. As shown below, it becomes a member of your office software.

So, for an agent to "effectively participate" in team channels, it needs a specific set of underlying capabilities (like the product form of Claude Tag) plus specially designed persistent memory, exclusive identity, information sourcing mechanisms, etc.

Furthermore, technical capabilities alone are not enough; for a human-machine team to "succeed," it relies on a set of working methods and shared norms.

Therefore, the remaining four pieces of experience in the article are all about designing "norms" for AI teams.

III. Four Lessons for AI Agent Teams

Lesson One: Reform Information Management, Give Agents as Broad Context as Possible

Anthropic believes that instead of deciding document by document, channel by channel, which information is visible to the agent, one should use clearly defined security boundaries that apply uniformly to the entire Slack workspace, meeting transcripts, and document libraries.

The original text specifically calls out the daily grind: "Should this channel be public or private? Can this document be shared with that person? Can this agent see that message?"

Within the boundaries, context should be visible to every team member—whether human or AI—and AI can even apply for document permissions just like a human.

The subtlety of this approach is that it simultaneously solves two problems:

1. Expands the context available to agents and humans;
2. Eliminates the decision fatigue from "item-by-item sharing."

The return on opening up permissions is tangible: no more loss from information relay, and because agents read text much faster than humans, they can "routinely surface relevant work that humans would otherwise have missed."

In my view, this is essentially a shift in organizational culture and permission mechanisms.

"Default internal openness" is a cultural change that would shake many companies to their core.

Because Anthropic was initially a company with high trust and flat information, it may not fully understand the bureaucratic disease common in large companies, especially the resource disparities formed by cross-level information gaps in traditional industries.

Moreover, for organizations with strong compliance and strict information isolation (finance, healthcare, cross-jurisdictional), a "workspace-level blanket approach" may not be feasible.

What is truly applicable is the streamlined approval mechanism behind it: as long as the agent is in a group, it can naturally read documents accessible to that group. Even with permission controls, batch management can be handled naturally, rather than first granting documents and then arranging quality checks.

Lesson Two: Every Person/Agent Has Clear Roles and Tools

The original text paints a vivid picture: the human-machine team shares one roster, one set of outputs, one workspace.

On top of this, agents have distinct divisions of labor:

• One agent owns the data analysis for a certain project;
• Another holds and executes design specifications;
• A third is responsible for research synthesis.

When a project starts, humans first talk to the agents to decide how to allocate roles and how humans and agents will collaborate.

Then, they produce a combination of roles, rules, and intervention triggers as shown below.

Once roles are clear, an agent can even "spin up" other agents, ensuring that each specific task is assigned to the agent with the correct memory and correct access rights.

The key is to equip them with the right tools: an agent doing data analysis might need BigQuery access; a QA agent might need Playwright MCP.

Humans hold roles that only humans can hold, ensuring that human judgment is applied to the most important decisions.

In my opinion, this is also the architecture of Anthropic's previous research on mechanism workflows.

Use a lead agent to coordinate globally and delegate tasks to specialized subagents running in parallel. This kind of mechanism is very practical, with quality metrics nearly doubling (90.2% higher), though at a cost of 15x tokens. However, "more agents equals stronger performance" is not a universal conclusion; it's an improvement on certain types of tasks, paid for with considerable computational cost.

Especially in breadth-first, parallelizable work, and due to stronger cross-validation mechanisms, information accuracy is better.

Also, the design must be fine-grained, with proper task decomposition and role isolation, rather than simply "piling on more agents."

Otherwise, it would be another generation of the "yield 18,000 jin per mu" misunderstanding.

Many of these views were also covered in the previous article on how to use Claude's Dynamic Workflows for deep research. ### Lesson Three: Set a North Star, Let Agents Proactively Solve Problems

The original text distinguishes two types of agents: one type merely completes assigned tasks. The most important type proactively proposes new projects and workflows.

The latter usually appears in a team that already has rich context and clear roles, combined with an additional directive—a north star.

The north star helps the team judge "which tasks and workflows are the right ones to pursue."

The original emphasizes several disciplines:

• The north star is always set by humans, grounded in the company's mission and business goals;
• Once the north star is clearly written down, humans share it with the agents in the team;
• Then—and this step is crucial—humans select which agents should proactively propose new workflows.

Assume a company driven by operations and products; then the operations role should be the lead agent, rather than product-driven, tech-driven, or finance-driven.

Just like in the routing pattern (Classify-And-Act) in how to use Claude's Dynamic Workflows for deep research, one agent first identifies the task type, then distributes the task to the most suitable specialized agent.

In my opinion, reading many of Anthropic's articles, they have a clear distinction between what is an agent and what is a workflow?

The former "dynamically governs its own process and tool usage, controlling how to complete tasks."

The latter is a deterministic system "orchestrated through predefined code paths."

So, to build an AI team, one should give agents a north star rather than a task list; this is deliberately pushing the system from workflow toward agent.

A team with a goal will bring some creativity, rather than finding things to do within a limited scope.

Of course, many AI teams we build today are actually programmatic or AI-powered workflows, which already solve many problems. If we later need creativity, self-direction, and proactive problem-solving ability, we must design such agent-based teams.

Lesson Four: Let Agents Grow Over Time

The official data here surprised me a lot: they said Anthropic's engineers have already enabled agents in their teams to independently handle 500 bug fixes—but immediately emphasized, "things certainly didn't start off that way."

They analogize agents to new human colleagues: it takes multiple rounds of feedback to externalize tacit knowledge like "how to best do the task."

Users must repeatedly probe the agent with various tasks to discover its capability boundaries, how to describe goals clearly, what skill files it needs, and which prompts elicit the desired behavior.

The original text also specifically reminds of a point easily overlooked: models upgrade, tasks must be retested—prompts may need rewriting, and past useful harnesses (Harness) may instead constrain a smarter model from finding more creative solutions.

The most valuable insight in this lesson is the discussion on verification:

We have found that the best long-duration agents have many ways to verify their own work before showing it to a human.

• Code has tests, of course;
• But most other work can also be verified: technical documentation can be checked against rubrics and style guides;
• When humans set clear standards and ensure all work given to the agent is reviewable, quality can be maintained and not drift from the original intent;
• Additionally, you can have one agent do the work and another agent check it—this is often called the "Doer-Verifier" agent harness.

The original text includes a complete example: a certain engineering lead took over a new team with a heavy backlog. They gathered a few people plus a few agents to prioritize together.

One group of agents read all backlog items, judged whether anyone was working on them, and assigned complexity scores to unowned items;

Another group filtered out low-to-medium complexity items from the list and directly produced code changes.

Initially, humans reviewed every agent decision and flagged those requiring human intervention; then, humans "taught" the agent to directly escalate such decisions to humans, ensuring that decisions involving difficult trade-offs always have a "human in the loop."

And each week, the team had the agent compile a weekly report containing "lessons & missteps," so the agent would remember errors and avoid repeating them. Over time, the lead could assign increasingly complex changes to the agent, spending less time on daily guidance, as shown below:

It's like raising smart lobsters.

The final paragraph contains my favorite insight in the whole article—when agents become more independent, the lead started teaching agents to treat "human attention" as a scarce resource:

For example, batching questions so humans can answer them all at once, repeating key context to get humans up to speed quickly, limiting the number of items thrown to humans at one time.

Some people even set up a dedicated agent whose sole responsibility is to decide how to batch and escalate only the most important communications to humans.

Others set guardrails for agents like "maximum number of tasks per day"—so humans have time to meaningfully participate and retain skills important to them from atrophying.

In my opinion, these lessons are the article's most profound points on the "human-machine relationship."

• First, Anthropic's thinking holds that effective oversight is not about approving every action, but "being in a position to intervene when it matters."
• Second, explicitly treating "human attention" as a scarce resource to be optimized is a severely undervalued design principle. Most discussions about agents focus on optimizing "agent capabilities," but the actual bottleneck on efficiency is already "human cognitive bandwidth."
• Third, harness engineering in human-machine teams should fully emulate the methods of effective human teams. After all, some good horses don't need reins, only a destination.

IV. The Era of Human-Machine Collaboration Will Ruthlessly Amplify the Organizational Quality of Original Teams

The most honest and easily overlooked statement in this article appears at the end:

He says that the four lessons above are actually not new; they existed long before AI. Strong teams need a powerful north star, clear roles, solid documentation, shared quality standards, and room to learn from mistakes—all healthy team habits we've known for decades.

AI agent teams simply make these fundamentals even more important.

Without proper mechanism building, AI will not automatically make a team stronger; it could even cause compression and ultimately lead to chaos. For example:

• Teams with scattered context (e.g., managing through information asymmetry) will only become more scattered after integrating agents (the greater the information silos, the more outputs deviate);
• Teams with confused role definitions will have agents replicate that confusion, with overlapping responsibilities and distorted judgment sources for decision-makers.
• Teams without a verification culture will see agent errors scale up faster, as AI code speed far exceeds human code review speed.

Therefore, in my view, "the teams that gain the most from this wave of agent dividends are those that most consciously practice these fundamentals."

For organizations betting on AI agents, the real homework this article provides might not be "how to use Claude," but rather to go back and seriously redo those four old things: the team's context, roles, goals, and quality standards.