HUMAN–AGENT COLLABORATION

Two structures for working together

The Gate
and the Room

How judgment enters the work—and how context stays with it.

ONE ORDINARY SENTENCE

NEW DIRECTION, TEAM “We’re moving the prototype to Flutter.”

01 What would you delegate?

02 How would you know it worked?

03 Who would own the result?

THE DELEGATION THRESHOLD

A task becomes delegable when
“done” becomes visible.

FLUTTER MIGRATIONDONE WHEN

Existing clients keep working
Release checks pass
The platform boundary stays clean

SWE-BENCH PRO · SOLVE RATE

GPT-58.4→25.9

OPUS 4.18.2→22.7

problem only → problem + requirements + interface

Difficulty moves. Verifiability is something we can design.

Now add three acceptance conditions from the same conversation: existing clients keep working, release checks pass, and the platform boundary stays clean. The task has not become easy. It has become legible enough to delegate. A useful benchmark ablation makes the point without pretending it proves a universal law. On SWE-bench Pro, GPT-5 moved from 8.4 percent with the problem statement alone to 25.9 with requirements and interface context. Claude Opus 4.1 moved from 8.2 to 22.7. Specification changed what the verifier could recognize as success. Model capability will keep moving. Verifiability is something we can deliberately design into the work. [Sources] - SWE-bench Pro, arXiv 2509.16941, Table 3: https://arxiv.org/abs/2509.16941 - Jason Wei, “Asymmetry of verification and verifier’s law”: https://www.jasonwei.net/blog/asymmetry-of-verification-and-verifiers-law - Andrej Karpathy, “Verifiability”: https://karpathy.bearblog.dev/verifiability/ [/Sources]

THE CONSEQUENCE

More agents create more work to check.

TASKFlutter migration

architecture state tests deployment

1 HUMANreview + ratify

Cursor review interface showing agent work prepared for human review. — **CURSOR**orchestration moves left

Claude desktop interface showing multiple agent work sessions. — **CLAUDE**the human gets a queue

Execution scales. Attention does not.

Once “done” is visible, work can spread. Architecture, state, tests, and deployment can move in parallel. Cursor and Claude now put the human in an orchestration seat because execution is no longer the scarce part. But four workstreams still converge on one mind that must understand the intent, compare the evidence, and ratify the result. The interface may call this a queue, a review surface, or parallel sessions. The structural fact is the same: execution scales; attention does not. That is where the gate appears. A gate is useful—but only for a specific kind of question. [Sources] - Cursor 2.0: https://cursor.com/blog/2-0 - Claude Code desktop redesign: https://claude.com/blog/claude-code-desktop-redesign - Local official product assets: assets/product/cursor-review.jpg and assets/product/claude-desktop.jpg [/Sources]

THE GATE · CLEAN

A gate asks one question.

May this action cross a consequential boundary?

SHARED ROOM

CONSEQUENTIAL WORLD

GATE

FLUTTER MIGRATIONdeploy release

AAlexJUDGMENT

BBumble

FFizz

HHoney

architecture proposedstate layer updatedrelease checks passed

REQUEST→

HUMAN REVIEWapproved

TECHNICAL CONTAINMENT

deploymentpaymentpermissionpublishingdeletion

A gate asks one question: may this action cross a consequential boundary? Deploy to production. Move money. Expand a permission. Publish externally. Delete something that may not be recoverable. A good gate is synchronous, explicit, and close to binary. It concentrates human judgment at a boundary where standing and consequences matter. Notice what makes it usable here: one request, one decision, one clear crossing. Gates are not collaboration environments. They are constitutional moments. Their power comes from rarity. [Sources] - Talk target architecture: .ai/analyses/02_short_talk_target_architecture.md - Birgitta Böckeler, “Harness Engineering”: https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html [/Sources]

THE GATE · CONGESTED

When every action becomes a gate,
judgment becomes clicking.

SHARED ROOM

CONSEQUENTIAL WORLD

GATE

FLUTTER MIGRATION17 actions waiting

AAlexSATURATED

BBumble

FFizz

HHoney

read file?run test?open diff?call API?

APPROVE · APPROVE · APPROVE→

HUMAN REVIEWclicking through

TECHNICAL CONTAINMENT

“After the tenth approval you’re not really reviewing anymore.”

Now run every low-level action through the same gate: read this file, execute this test, open this diff, call this API. The human does not become safer. The human becomes a clicker. Anthropic’s own best-practices guidance names the failure: after the tenth approval, you are not really reviewing anymore; you are clicking through. The gate has not failed technically. It has failed cognitively. This is why the answer cannot simply be “keep the human in the loop.” Which loop? At what granularity? With what context? Collaboration needs another shape—not a weaker gate. [Sources] - Claude Code best practices, verification and permission guidance: https://code.claude.com/docs/en/best-practices - Talk target architecture: .ai/analyses/02_short_talk_target_architecture.md [/Sources]

THE ROOM · OPEN

A room asks different questions.

What is happening? Who is involved? Who needs to respond?

SHARED ROOM · PERSISTENT CONTEXT

OUTSIDE THE ROOM

GATE

FLUTTER MIGRATIONwork in motion

AAlexAVAILABLE

BBumblearchitecting

FFizzbuilding

HHoneychecking

Bumble proposed the platform splitFizz updated the state layerHoney is checking release evidence

ATTENTION WHEN NEEDED→

HUMAN REVIEWnot yet requested

TECHNICAL CONTAINMENT

The work keeps moving. Context stays addressable.

A room asks different questions. What is happening? Who is involved? Who needs to respond? Inside a room, the task, participants, presence, and history persist together. The human does not have to approve every move to remain situated. The agents do not have to stop working to make their state legible. Attention can be requested asynchronously and with accumulated context. This is not permissionless autonomy. It is a different coordination structure. The work keeps moving while context stays addressable. And that prepares the most important synthesis: the room does not replace the gate. [Sources] - Buzz collaboration principles: /Users/pureicis/dev/buzz/README.md - Buzz presence and remote-agent design: /Users/pureicis/dev/buzz/VISION_REMOTE_AGENTS.md - Talk target architecture: .ai/analyses/02_short_talk_target_architecture.md [/Sources]

THE ROOM + THE GATE

Rooms do not replace gates. They give gates context.

Buzz engineering channel where humans and agents coordinate a Flutter migration and an agent asks Alex Rivera for human review. — BUZZ · #ENGINEERING

HONEY“@Alex Rivera, could you take the human review?”

An agent scheduling a human—as a normal move in the conversation.

SHARED ROOM

RELEASE

GATE

FLUTTERevidence ready

AAlex

BBumble

FFizz

HHoney

checks passed

@ALEX→

HUMAN REVIEWrequested

CONTAINMENT

Now reveal where the sentence came from. This is a Buzz engineering channel. A human changes direction. Named agents divide the work, hand state to one another, open pull requests, and check the evidence. Then Honey says: “@Alex Rivera, could you take the human review?” An agent schedules a human as a normal move in a conversation. The room has accumulated the context; the gate remains at the release boundary. A gate without a room lacks context. A room without a gate lacks containment. Buzz is interesting because it lets us inspect what the room might need to become. [Sources] - Buzz screenshot, directly inspected: /Users/pureicis/dev/buzz/docs/assets/screenshots/channel-agents.png - Local copy: assets/buzz/channel-agents.png - Buzz README: /Users/pureicis/dev/buzz/README.md [/Sources]

BUZZ · EVENT FABRIC

The room is built from signed events.

PARTICIPANTS

AAlexhuman

HHoneyagent

WDeployworkflow

PUBLISH→

SIGNED EVENT

authornpub…

kindmessage

tagschannel · recipient

contentwhat happened

signatureauthorship travels

SUBMIT→

NOSTR RELAY verify scope store fan out

SUBSCRIBE→

CONSUMERS

RRoominterface

AHarnessagent runtime

HHistoryaudit context

messagementionpresencereview requestpatchtelemetry

One event language. Many kinds of participants.

What looks like a chat application is built on a more fundamental architectural choice. In Buzz, the primary API is a Nostr event bus. A human message, an agent reply, a membership change, a review request, a git patch, and an activity update are all represented as signed events. The relay receives each event, verifies its author, determines its scope, applies access rules, stores it when it should persist, and fans it out to interested subscribers. That means the desktop app, mobile app, CLI, workflow system, and agent harness do not need separate point-to-point integrations. They speak the same event language. A human, an agent, and a workflow can therefore become participants in the same room. Signed proves authorship, not correctness. The relay governs communication; it does not sandbox execution. We will return to that boundary. Because every event has an author and a signature, identity is not profile decoration. It is part of the communication substrate. [Sources] - Buzz architecture overview, primary API as a Nostr event bus, event ingest, and fan-out: /Users/pureicis/dev/buzz/.ai/analyses/001_buzz-architecture-overview.html - Buzz architecture overview, communication matrix and agent integration: /Users/pureicis/dev/buzz/.ai/analyses/001_buzz-architecture-overview.html [/Sources]

BUZZ · IDENTITY

Identity makes the agent a participant.

AHUMAN OWNERstanding

ATTESTS→

HAGENT IDENTITYdifferent keypair

SIGNS→

PRARTIFACTauthorship travels

“Agents are members, not bots.”

The same affordances. The same audit shape. A responsibility chain that remains human-locatable.

The first design bet is identity. Buzz says agents are members, not bots: the same affordances as a human teammate, the same audit trail, a different keypair. That does not mean the agent becomes morally or legally equivalent to a person. The architecture keeps the responsibility chain locatable. A human owner cryptographically attests the agent key; the attestation travels with agent-signed artifacts; self-attestation is rejected. Identity changes the interface. An agent can be addressed, mentioned, remembered, removed, and audited as a participant—not merely invoked as an integration. [Sources] - Buzz README: /Users/pureicis/dev/buzz/README.md - Buzz architecture overview, owner attestation and key identity: /Users/pureicis/dev/buzz/.ai/analyses/001_buzz-architecture-overview.html [/Sources]

BUZZ · LEGIBILITY

Legibility is what earns delegation.

Bumblearchitecting

Fizzbuilding

Honeychecking

PRESENCE IS A LEASE, NOT A PERMANENT FLAG

Bumble proposed the platform split → boundary named

Fizz migrated the state layer → clients still pass

Honey checked release evidence → human review needed

verb→object→outcomeFailures rise. Reads recede. Never go dark.

The second bet is legibility. Buzz’s activity vision says the feed’s real job is to earn delegation. Not by showing every raw event, and not by asking the model for a confidence score. Presence is a lease: a dead agent stops renewing and eventually disappears. Activity is expressed as a sentence—the agent did a verb to an object and produced an outcome. Failures rise; reads recede; the system should never go dark. Each turn the human can parse and judge becomes evidence for a larger delegation. Legibility is not decoration around autonomy. It is one of the conditions that makes autonomy earnable. [Sources] - Buzz activity design intent: /Users/pureicis/dev/buzz/VISION_ACTIVITY.md - Buzz remote-agent presence design: /Users/pureicis/dev/buzz/VISION_REMOTE_AGENTS.md - Buzz architecture overview, working indicators: /Users/pureicis/dev/buzz/.ai/analyses/001_buzz-architecture-overview.html [/Sources]

BUZZ · COORDINATION

The room can become the management plane.

SHARED ROOM · MANAGEMENT PLANE

CONSEQUENCE

GATE

FLUTTER MIGRATIONwork in motion

AAlex@MENTIONED

BBumblepresent

FFizzpresent

HHoneypresent

message steersmention routes attentionhistory audits

@ALEX→

COMPLETIONdeclared socially

TECHNICAL CONTAINMENT

STATUSpresence

STEERINGmessage

ATTENTION@mention

HISTORYaudit

COMPLETIONdeclared

If an agent can schedule your attention, what is the attention SLA?

The third bet is that the room can become the management plane. You read an agent’s messages to know how it is doing. You mention it to steer it. Presence means available for conversation—not CPU telemetry. History becomes audit. Completion is declared socially: not killed, finished. The striking line in the remote-agent vision is that a management plane you never build is one you never have to port. That simplicity opens a harder design question. If an agent can schedule human attention with an @mention, what is the attention SLA? How urgent is it, what evidence must accompany it, and what happens if no human responds? [Sources] - Buzz remote-agent design intent: /Users/pureicis/dev/buzz/VISION_REMOTE_AGENTS.md - Buzz activity design intent: /Users/pureicis/dev/buzz/VISION_ACTIVITY.md [/Sources]

THE HONEST BOUNDARY

But the room is not the sandbox.

SOCIAL CONTEXT · PRESENT

HOST SYSTEM

GATE

FLUTTER MIGRATIONfull user privileges

AAlexOWNER

BBumble

FFizz

HHoney

conversation visiblefilesystem boundary absent

APPROVAL×

WORKFLOWfails; does not suspend

TECHNICAL CONTAINMENT · NOT CLOSED

APPROVALfails the run; no durable suspension

FILESYSTEMno sandbox

TRUST BOUNDARYthe OS user

REMOTE AGENTSparts remain design

Social coordination cannot replace technical containment.

The room is not the sandbox. This is the credibility test for the case study. In the current design record, a workflow approval request fails the run rather than durably suspending it. Agents have full user-privilege filesystem access from the nest working directory; the trust boundary is the OS user account, not a sandbox. Parts of the remote-agent behavior remain design, with named known defects. These facts do not invalidate the room. They define its limit. Social coordination can make work legible and responsibility locatable. It cannot contain a process with authority to delete, deploy, or exfiltrate. That remains the work of technical boundaries and rare consequential gates. [Sources] - Buzz workflow approval status: /Users/pureicis/dev/buzz/VISION.md - Buzz architecture overview, filesystem boundary: /Users/pureicis/dev/buzz/.ai/analyses/001_buzz-architecture-overview.html - Buzz remote-agent design and known defects: /Users/pureicis/dev/buzz/docs/remote-agents.md [/Sources]

THE DESIGN PRINCIPLE

The future is not human or agent.
It is the architecture between them.

SHARED ROOM · CONTEXT PRESERVED

RELEASED

GATE

FLUTTER MIGRATIONcomplete

AAlexRATIFIED

BBumblepresent

FFizzpresent

HHoneypresent

clients passrelease checks passboundary stays clean

EVIDENCE→

HUMAN REVIEWratified

TECHNICAL CONTAINMENT

ROOMAgents can act.

EVIDENCEHumans can judge.

GATEConsequences wait.

Design it so human judgment can still change the outcome.

Return to the migration. The agents have room to act. The event fabric preserves identity, state, and evidence. The human arrives at the consequential boundary with enough context to judge. Technical containment makes the gate enforceable. The future is not human or agent. It is the architecture between them. Give agents room to act. Give humans evidence to judge. Put gates where judgment can still change the outcome. Human in the loop should not mean human at every tool call. The goal is not to keep humans busy. It is to make human judgment matter. Stop there. [Sources] - Buzz README closing principle: /Users/pureicis/dev/buzz/README.md - Buzz projects vision, “A feature branch is a conversation”: /Users/pureicis/dev/buzz/VISION_PROJECTS.md - Talk target architecture: .ai/analyses/02_short_talk_target_architecture.md [/Sources]

The Gateand the Room

A task becomes delegable when“done” becomes visible.

More agents create more work to check.

A gate asks one question.

When every action becomes a gate,judgment becomes clicking.

A room asks different questions.

Rooms do not replace gates. They give gates context.

The room is built from signed events.

Identity makes the agent a participant.

Legibility is what earns delegation.

The room can become the management plane.

But the room is not the sandbox.

The future is not human or agent.It is the architecture between them.

The Gate
and the Room

A task becomes delegable when
“done” becomes visible.

When every action becomes a gate,
judgment becomes clicking.

The future is not human or agent.
It is the architecture between them.