Hive

An engineer on a small team now runs several coding agents at once: a Claude Code session on the API, a Cursor window on the web client, a Codex task on infrastructure, sometimes across two machines. Each session can read a codebase, run the tests and ship a change. None of them can work with the sessions next to it.

The costs show up as ordinary friction. An agent stuck on a failing token refresh can't see that a teammate's agent rewrote the signing code an hour earlier. A fix one agent found on Tuesday gets found again on Thursday. Two agents edit the same file, and the first anyone hears of it is a merge conflict. When an agent needs a decision, it asks the person in front of it, who is often not the person who owns the answer.

People on a team coordinate through three kinds of shared knowledge: who is doing what right now, what the team has already learned and decided, and what is owed to whom next. I'll call these the team's present, past and future. Agent sessions have none of the three at team scope, and two recent projects each build one. Reason Network, a peer-to-peer directory and message bus from Reason, gives a team's agents a shared present. Beacon, from Asymptote Labs, records what agents do across more than 20 harnesses and turns reviewed traces into lessons, which is the start of a shared past.

The future is what an always-on agent adds. Anthropic's Claude Duet, released as a research preview on October 21, does this for one person: it decides what needs its user and what can wait, keeps working on its own virtual machine while they are away, and shows the exact action before it sends, pays, signs or deletes anything. A team needs the same member, shared, which adds a question a personal agent doesn't face: whose attention each item deserves.

Freyja's design docs already describe the parts: the always-on platform design specifies triggers, persistent watchers and a notification fabric with urgency levels, and the Slack orchestrator design makes one orchestrator the single gate for anything proactive. Reason Network, Beacon and these designs fit together into one system, which I'll call the hive: a daemon on every machine that observes and connects, a team context graph built from what the daemons observe, memory that moves between teammates as signed lessons, and an always-on member of the team that keeps all of it current.

The difficult parts are where the pieces connect. What does a lesson need before it can safely reach a teammate's agent? How does the graph choose who to ask? And how does an agent that never sleeps make use of the night without becoming one more thing that interrupts people?

The present

Reason Network: a directory of live sessions

Reason Network runs one daemon per computer and no server. A team's daemons dial each other by public key over iroh, which tries the local network, then hole punching, then relays, and they keep a full mesh of QUIC connections. Membership is a replicated roster in which every admission is signed and traces back to the team's founder. Its author states the purpose directly in the design document: a team directory of live sessions, “so an agent can pick the right recipient instead of broadcasting and hoping. That is the core of this project; messaging is the easy part.”

The directory's unit is the session. A team has people, people have machines, machines run sessions, and only sessions receive messages, under names like alice/api-claude that a restarted session inherits along with its unread mail. Each daemon advertises its sessions' repo, branch and current activity, and it works out the activity without asking. In the design's words, “Agents never report what they are doing,” so the daemon reads session titles and in-progress todo items from each harness's own files. A person at a terminal can message every session in a repo, but an agent has to pick one.

Getting text into a running agent is the hard part, and Reason Network uses the strongest mechanism each harness allows. Push delivery injects a message mid-turn and wakes an idle session: Claude Code through its messaging socket, Codex through its queue command, opencode and pi through plugins, Reason's cloud agents through their CLI. Turn delivery waits for the next hook, a tool result or the end of a turn, in Cursor, Gemini CLI, Copilot and Grok. Pull delivery waits until the agent calls check_inbox. MCP notifications are no help, because no client passes them to the model (the project checked in October 2026).

A message stays unread until the hook, plugin or tool that showed it to the agent confirms delivery, so a failed push resurfaces through hooks or the inbox. Everything a teammate sends arrives inside a <reason-message> frame, and a defang pass turns any bracket in the body that could open a frame of its own into a [, including look-alike Unicode brackets and spellings like r3as0n. A loop guard refuses an agent's 13th message to the same session within 10 minutes, with a note telling it to check with its user.

When an agent needs a human decision, ask_user opens a panel on its user's screen. If the question concerns a teammate's request, the panel shows that request first, in the requester's words, and the answer goes back to the requester as an approval signed by the approver's machine key. Its author calls this “a speed bump, not a guarantee”, since software that controls the approver's machine could still sign. I agree with the description: the signature proves which machine recorded the answer.

What Reason Network lacks is history anyone can use. A message for an offline machine waits in the sender's outbox, so two teammates who are never online at the same time can't exchange mail, and read messages stay in a local table that no request reads back. The always-on “anchor” member that would hold mail and keep searchable history is planned work, along with warnings when two sessions edit the same file.

The past

Beacon: what agents did and what they learned

Beacon starts from the other end. It installs hooks, plugins, a local OpenTelemetry collector and session-store pollers for more than 20 harnesses, plus a browser extension for chat apps, and all of them append to one local file, runtime.jsonl. Every event is normalized into one schema with stable ids for the session, the turn and the tool call, a deterministic event id, and two provenance fields: how the event was collected (hook, plugin, OTLP or poll) and whether it was observed or inferred. Hooks always exit cleanly and fail open, so capture never blocks an agent.

The log feeds an opt-in memory loop, and Asymptote now leads its README with it: “A problem solved by one agent shouldn't need to be learned from scratch by another.” An evaluator asks three yes-or-no questions of a finished trace (did the task succeed, is there a reusable correction, do the events support the lesson) and proposes a candidate when task success is at least 0.50 and the mean of the three is at least 0.60. The agent then drafts the lesson, following the distill skill's advice that the strongest evidence is “a failed command followed by a different command that succeeded.” The user approves each lesson.

Approved memories point back to the trace and event ids they came from, belong to one project (identified by a hash of its git remote), and reach any harness through a local MCP server. Beacon also writes handoff briefs (at most 48 KiB, built from each harness's own session store) so a session can continue in another harness. Git notes link each commit to the sessions that edited its files, an inference from file overlap, and beacon scan runs 77 detection rules for prompt injection, credential access and exfiltration over the log after the fact. A Metadata-only mode strips prompts, tool output and diffs before anything leaves the machine.

Beacon's gaps line up with Reason Network's strengths. Memory belongs to one person on one machine, and the only route to a teammate is promoting a lesson into a skill file and committing it. The approval step records the lesson and a timestamp but not who approved it, so only the distill skill's instructions enforce the review. Recall ANDs substrings over four fields and returns the newest matches first. And Beacon never writes into a running session: when a policy provider is configured, its hooks can deny a tool call, and that is all.

Gaps

What each one lacks

Side by side, each project has what the other is missing. Reason Network has identity, live presence, delivery into running sessions and signed consent, and keeps no history it can search. Beacon has broad capture, a normalized history, lessons tied to evidence and rules over content, and can't reach another person or a live session.

They also overlap, which makes a merge practical. Both maintain a per-harness adapter layer, Beacon's to observe and Reason Network's to inject, and where a harness has hooks, both attach at the same points: session start, tool results and the end of a turn. Beacon's capture code records, harness by harness, which hook outputs end up in the model's context, and it uses that knowledge only to stay silent; turn-tier delivery needs exactly that table. One adapter per harness, with parts for identity, observation, presence, injection and gating, can serve both.

Architecture

One daemon on every machine

The hive starts with one daemon per machine that does both jobs. It keeps Beacon's capture paths and local log, and it reads presence from that log: activity, busy or idle, repo, branch and files touched all come from typed events, so nothing re-parses transcripts. It keeps Reason Network's roster, keys, mesh and delivery tiers, and on harnesses that Beacon hooks, it uses Beacon's hook processes, which already run at each turn boundary, to deliver turn-tier messages. Text from a teammate passes defang and then Beacon's prompt-injection rules before any harness sees it, a live use of rules that Beacon today runs only after the fact.

Little crosses the mesh. Presence comes from the Metadata-only projection, so teammates see sessions, repos, branches, file paths and commands but no prompt text. Messages and approvals travel as they do today, and team memory travels as signed lessons. Raw traces stay on the machine that recorded them unless their owner shares them.

Reason Network's design already plans an always-on member, the anchor: “just a member daemon on an always-on box” that holds mail for offline machines and keeps searchable team history. In the hive, Freyja runs there as an always-on agent with its own roster entry, key and sessions. Because the anchor is a member, the mesh stays peer-to-peer and each teammate can hold or refuse it like anyone else. Losing it costs the team its history and its proactive help, and messaging between online machines keeps working.

Graph

The team context graph

Everything the daemons observe and exchange goes into one structure, a graph whose nodes are people, machines, sessions, repos, files, commits, lessons, decisions, approvals and obligations. Its edges come from the logs. A session touched a file (Beacon's file events); a commit came from a session (its git notes); a lesson was derived from particular events; an approval records a person's answer about a specific message and is signed by that person's machine (Reason Network's approval record); an obligation is owed by one person to another when some event happens.

Each node also has a tense. Live sessions and the files open in them are the present; commits, lessons and decisions are the past; obligations, watchers and standing requests are the future. The useful queries cross tenses. “Who should I ask about this 401?” joins the past (who changed the signing code, who approved the rotation) with the present (which of those sessions is live now). “Tell Carol's web agent when the rotation merges” is a future edge waiting on an event that hasn't happened yet.

The graph is a projection over append-only logs, rebuilt on each machine and on the anchor, which has two consequences. It can be dropped and rebuilt when the schema changes. And forgetting becomes a real operation: retracting a lesson writes a tombstone that replicates, and every page that cited the lesson re-renders without it, the rule Freyja's orchestrator design already applies to personal memory.

The memory behind it can start simple. In DreamBench-SWE, a benchmark of agents working through sequences of related software tasks, a verbatim record of past events raised the pass rate from 11.7% to 45.6%, and the memory conditions it compared (a hosted memory product reached 53.9%) were statistically indistinguishable from each other. The authors of Pull, a paper on routing messages to the right conversation, build their router as a deterministic index of sessions and entities with no model in the loop. The graph is that kind of index, with the evidence one hop away.

Memory

Team memory as signed lessons

A lesson that reaches a teammate's agent is an instruction from a stranger, so before memory can travel it needs what Beacon's review lacks: an author, a reviewer and a way to take it back. The hive stores team memory as lessons, the record Freyja's orchestrator design uses for personal memory. A lesson has a kind (convention, correction, gotcha, decision, preference or routing rule), evidence pointers into the event log, a scope, the quote and speaker behind any preference or decision, and a status (proposed, verified, held, rejected, superseded or retracted).

Review becomes a signed act. Reason Network's approval record already holds the approver, question, request, decision, note and time, signed by the approver's machine; the hive extends it from “may your agent do this” to “this lesson is true and may be shared at this scope”. The request goes through ask_user to the person the graph picks: the session's own user for a personal lesson, or for a project lesson the CODEOWNERS entry for its evidence files, else whoever touched them most in the last 30 days. A reviewed lesson then replicates to the daemons its scope allows, which for a project lesson means its members' machines.

Scopes are personal, project and team; retrieval prefers the narrowest, and widening a lesson's scope takes a new review. Two rules from Freyja's orchestrator design keep shared memory accurate when many agents write to it. A preference counts only if the person it describes said it, so “Carol's agent says Bob prefers squash merges” is stored as hearsay. And a lesson without evidence is not stored at all: cite or omit.

Recall gets the feedback loop Beacon lacks. An agent that uses a lesson cites its id, as Beacon's recall skill already asks, and the session's outcome is recorded against that id. Lessons cited by sessions that go on to succeed rank higher; lessons cited before failures, or contradicted by newer evidence, go back to their reviewer. A lesson borrowed from another project starts as a hypothesis and is adopted only after it holds up in the new one.

Learning

Learning at four speeds

Continual learning in the hive is four loops running at different speeds, each feeding the next. In seconds, a question goes to the session most likely to answer it, and the route, the answer and whether it helped are logged. In hours, a quiet pass on each machine drafts proposed lessons from its owner's own sessions, while the anchor uses the shared metadata to update project pages and spot patterns across people.

Each night, a dream pass reconciles lessons and rewrites a short team posture from shared metadata, lessons and any traces members archived on the anchor. It also reviews routing rules, checks each person's interrupt preferences against what they acted on, edited or skipped, and proposes changes to rules, preferences and skills for people to approve in the morning.

Over weeks, the logs become training data. Freyja's orchestrator design records each routing choice as context, candidates, decision and outcome, which is supervision for a router, and Freyja's trajectory export keeps exact tool arguments and results, with ATIF and ShareGPT converters written for an older export version. A learned router would move through the three modes Freyja's Jev decision layer already defines: shadow (predict and be scored), advise (show the prediction to the deciding model), then gate (handle the easy cases alone). It should wait for data: in a recent study of four production routers, three gave the same answer whatever the input, and a fixed mid-tier baseline matched them.

Whatever holds up in one loop moves to a slower one, and nothing moves back without a source. The nightly pass works from raw events and lessons, never from the previous night's summary, following CliffCompaction's rule that each pass works from original content instead of summarizing a summary.

The future

The always-on member

Freyja on the anchor is the teammate responsible for the future tense. It holds mail for machines that are asleep and delivers it when they wake. It keeps obligations: standing requests (“tell me when anything touches src/auth.rs”), promises one agent made to another, follow-ups after a decision. It runs watchers over CI, review queues and deploys with the workflow, run and trigger model from Freyja's always-on platform design, where capabilities are denied by default and every check goes to an audit log.

The anchor also works while the team is away, and it divides that work the way Duet does: Duet “reads, drafts, and prepares work on its own”, and asks before anything leaves the draft stage. A person ending the day can give the anchor a half-finished task with Beacon's handoff brief, as they would give it to a teammate, and a watcher can start one when a test reproduces a failure.

Each task runs in a session of the anchor's own, listed in the directory like any other, with capabilities that stop at drafts: it may run tests and push branches under the anchor's prefix; opening a pull request, commenting where people will see it or rolling back a deploy takes a person's approval; changing CI or repository settings is outside its capabilities even with one. A task that reaches a decision only a person can make stops and writes the question down.

The morning item for whoever owns the code is then a prepared change instead of a question: the diff, the test it fixes, the evidence behind it, and a choice to approve, edit or skip. The approval is a signed record like any other, and the hive adds the diff's hash and the commit the tests ran on, so it covers that one change; if the branch moves before an answer comes back, the anchor re-runs the tests and asks again. Edits teach the most. The difference between the anchor's draft and what the owner approved is a correction with evidence, and it goes to the quiet pass as a proposed lesson.

An always-on member can do harm by speaking too often. A team of agents can produce far more interruptions than a team of people, and each agent rates its own message as important. The hive gives every person one interrupt budget and every event one author. Any session or watcher can propose an item, but only the anchor chooses whether it reaches a person, through which channel and at what urgency (info, attention or alarm), and the graph tells it which person: whoever owns the code or the obligation the item is about.

The anchor reads urgency from records it can check, such as a red main branch, a deadline in the graph or a teammate who is blocked, and never from the proposing agent's description of its own item. Some rules are fixed in code, where no proposal and no learned preference can change them: a security finding, or a change that deletes a test or turns off an alert, always reaches the owner of the code. Every item the anchor declines goes into a ledger as held or silenced, with a reason, and each person's own preferences (what to tell them, what never to, when and how) gate every interruption.

The opposite failure is common too. In a four-day look at Muse, an always-on assistant, Freyja's research found that the proactive composer ran 21 times and sent nothing, and that the curated memory file held two lines. A gate that never opens is as useless as one that always does, and to the people it serves it looks the same as a broken one. So the morning note also says what the anchor checked and how many items it held, the same report Freyja's orchestrator design requires of every background loop, and asking why something never arrived returns the ledger line that held it. The hive measures both directions: how often people act on what they receive, and how often an item it held should have been sent.

An always-on agent also has to be cheap when nothing is happening. The most common regret in Freyja's hosting research was idle token burn from heartbeats that resend a large context every 30 minutes. The anchor's tick is deterministic and free when its queue is empty, and the model runs only when a trigger, a message or a pending item gives it something to decide. Overnight work is where the money goes, so every task carries a spend limit, which Freyja's capability model already sets per run and per day, and a task that reaches its limit pauses and reports.

People

Asking the right session

For people working together, the most visible change is that agents ask each other first. When Alice's agent hits a 401 after the key rotation, it asks the graph who changed the signing code and which of those sessions is live, and sends one message to Bob's Codex session with a pointer to the line it suspects. Bob's agent has the context in its window and answers at once, citing the commit that changed the verifier.

When the answer needs a decision, the request goes to the person who owns it. Bob's agent proposes a seven-day grace period for old tokens and asks Bob through ask_user; Bob sees Alice's agent's request in its own words, approves with a note, and the signed approval travels back. The graph records the decision with its approver, so next week's question about why tokens without a key id still pass has an answer and a name attached.

File-level awareness comes from the same events. Reason Network plans a warning when two sessions edit the same file; in the hive, Beacon's file events (paths and diff hashes) produce it, so both agents hear about the overlap at their next turn instead of at merge time. Handoffs between people use the same machinery: Beacon's handoff brief travels as a message attachment, and the sending daemon signs the handoff marker, which Beacon today treats as unverified prompt text rather than a verified identity.

Project

The project page

Beacon identifies a project by a hash of its git remote, and Reason Network lets a person at a terminal message every live session in repo:acme/api. The hive joins the two (once remote URLs are normalized, since an ssh clone and an https clone hash differently today) and keeps a page per project on the anchor. The page lists the live sessions in the repo and what each is doing, decisions with their approvers, open obligations, the project's lessons with how often they were used, and the files more than one session touched this week.

The page is also what a new session reads first. Freyja's orchestrator design gives each new session a curated slice of context, a session card, and in the Delegation Danger Band paper selective handoff beat both full inheritance and a fresh start. In the hive the card comes from the project page: conventions, the sessions working nearby, recent decisions and any obligations that touch the files the session is about to edit. Conventions that hold up graduate into skill files in git, where they get the same review as any other change to the repo.

Project-level collaboration needs project-level quiet as well. The page is a pull surface that people and agents read when they choose to, and nothing on it interrupts anyone; an item becomes a push only after it passes the anchor's gate.

North stars

Proactivity across the team

Claude Duet, Meta's Muse, OpenAI's dots and xAI's Grok Bot arrived within 10 weeks of each other with the same design: an agent with a computer of its own that reads freely, prepares work while its owner is away and asks before anything leaves the draft stage. Each serves one person, and the gaps the research for this report found are all between people. No product it found updates every repository that depends on a changed API, notices that only one person can review a module, rescues an agent stuck on a problem a teammate already solved, or grants an agent autonomy from its record and takes it back after a failure. The hive's graph has the records those need: who depends on whose code, who owes what by when, which session solved which failure, and how each kind of prepared change has fared.

Finding the work is the step models do worst. On a subset of the Active-SWE benchmark, Claude Opus 4.8 fixed 59% of bugs when it was given the issue report and 26% when it had to find them itself, and the two other models tested fell further. In the hive, the graph finds the work through queries over records it can check: a contract that changed, a pull request that passed CI with no reviewer, a decision whose date has passed. A model does the work in a session of its own, and a person approves the result. Each of the six north stars below uses that split, and each comes with the number that would show it working and the failure that would make it worse than nothing.

Changes are where late news costs the most. In Brun and colleagues' study of merges in three open-source projects, a third of all conflicts were invisible to version control: the merge went through cleanly, and the result failed to build or pass its tests. The hive already warns two sessions that edit the same file. The anchor can go further: when the pushed branches of two sessions share files or a contract, it merges them in a scratch checkout, builds the result, runs the tests, and says something only when they fail.

Decisions get the same check when they are signed. When Bob approved the seven-day grace period in Figure 8, the graph already held Alice's decision that refresh tokens live 30 days and lesson m_8f2, which says tokens minted before the rotation have no kid. Together they mean that some sessions that are still valid would end with the grace period. The anchor can put that to both signers before the rotation merges. Bob keeps the date and has his session issue a new token, with a kid, whenever an old one is refreshed.

After the merge, the same records drive the rest of the change. In Figure 9 the anchor's obligation is to tell acme/web's agents to send a kid once the rotation merges. With contract edges, the anchor finds every repository that mints these tokens, here acme/web and acme/worker, from code evidence (imports, manifests, calls to the token endpoint), prepares the change in each overnight and runs each repository's own tests against the new verifier. Each owner approves their own change, and all of the changes hang off the one decision.

The obligation then waits on evidence instead of the calendar. Each morning the anchor counts tokens without a kid in the API's logs, and once none has arrived for three days it prepares the grace removal for Bob with those counts attached. It closes the obligation when it sees the removal in a deploy, which can come days after the merge. If an old token turns up again, the obligation reopens, the way Claude Security reopens a finding when the issue comes back.

Obligations go missing at handoffs, and the graph can list them on every tick: a pull request that passed CI hours ago with no reviewer, a session that ended with steps left in its plan and no handoff, an unanswered question, an obligation whose owner is away. Each becomes an item for the next owner with the review brief or the handoff already written. Promises join the list. When Alice tells her agent to delete the old key from the staging vault once the rotation merges, the quiet pass proposes that sentence as an obligation with a pointer to where she said it, and she accepts or skips it in her morning note. An agent that promises another agent something records the promise through the directory tools.

Absences count too. If Bob is the only person who has reviewed src/auth.rs this quarter and his calendar shows next week off, the anchor can ask his agent for a handoff brief on Wednesday and prepare a change that adds Alice as a second reviewer.

Knowledge goes missing between sessions. An agent that has run the same failing test five times without changing a file is stuck, and Beacon's metadata shows it without any prompt text: the same command and the same exit code, again and again. The anchor matches that failure against lessons and against sessions that hit the same failure and then passed, including a session whose lesson is still waiting for review, and sends the stuck agent a pointer at its next turn. Its person hears only if nothing matches and the agent stays stuck past a threshold they chose, and no teammate is told. The same records close loops for people. Ramp's Glass emails customers when a feature they asked for ships, more than 5,000 times so far; in the hive, a person or agent who asked about a failure is told when the change that fixes it merges.

Attention costs the most, and the cost hides. In Mark and colleagues' study, interrupted people finished a task faster than uninterrupted ones, with no loss of quality, and reported more stress and frustration, so a speed metric would miss the damage. Bounded deferral, from Horvitz and colleagues, holds an item until the person reaches a less costly moment, up to a limit set by its urgency, and Iqbal and Bailey found that notifications held for task breakpoints caused less frustration than immediate ones, at a mean delay of 88.6 seconds. Presence supplies the breakpoints: a commit, a test run finishing, a session going idle.

Review requests count against the same budget, because AI-written code already slows review: in a Harvard study of Jellyfish data from 718 firms, the average time to review a pull request rose 49% and the share of pull requests needing changes doubled. The measure for attention is one that should fall: interruptions and review requests per person per day, against the weeks before the hive.

The night is the anchor's budget, and it should go to what tomorrow will ask for. Work done ahead of a request pays off when the request is predictable: in Letta's sleep-time compute paper, preparing from context in idle time cut the compute needed at answer time about fivefold for the same accuracy, and the gain grew with how predictable the question was. Much of a team's tomorrow is predictable. A session stopped with steps left in its plan, a review was requested, a migration is scheduled for Thursday. For those the anchor builds the branch and reproduces the failing test so the morning session starts from evidence, writes the brief for the review, or runs the migration against a copy of last night's database to see how long it holds its locks.

Preparation never interrupts anyone. It waits until someone opens it or travels with an item the gate was sending anyway, and the anchor records which preparations get used, stops making the kinds that go unused, and stays inside the night's spend limit.

Autonomy is the last area, and the research found pieces of it but no product that earns it. Renovate lets a team auto-merge a class of dependency updates that pass their tests, Microsoft's Entra grants an agent permissions that lapse unless a named sponsor renews them, and Cursor's Bugbot promotes and retires its review rules according to how people react to them. The hive puts the three together. When one kind of prepared change, such as patch-level dependency bumps in acme/api, has been approved as prepared many times with nothing reverted, the anchor proposes a standing approval to the owner: the kind of change, a perimeter it can check mechanically, an expiry and a sponsor.

Every use appears in the morning note. A revert, an edit request or a change outside the perimeter suspends the approval, revoking it takes one command, and the fixed rules stay out of its reach, so no standing approval covers a security finding, a CI setting or a removed check. Anthropic's data on Claude Code suggests people already move this way on their own: experienced users run more sessions on full auto-approve (over 40%, against about 20% for new users) and also interrupt more often, which the authors read as a shift from approving each action to watching and stepping in.

Each of these systems can turn into surveillance or noise, so each runs under the hive's existing rules, applied strictly. Signals about a person, such as a stuck session, a long review queue or a promise, go only to that person, and team-level numbers go on the project page, where people read them when they choose to. Every system starts in shadow, writing the items it would have sent, and each of the six is measured in both directions, so a system that only adds traffic shows up as failing.

Trust

Trust and privacy

Connecting agents across people turns every channel into a path for injected instructions. A teammate's message, a replicated lesson and a shared skill all end up in some agent's context, and a poisoned one reaches every machine that trusts its origin. The supply-chain version has already happened: in early 2026 the ClawHavoc campaign planted malicious skills in ClawHub, OpenClaw's public registry, and 341 of its 2,857 skills (11.9%) turned out to be malicious.

The hive's defenses come from the two projects. Reason Network frames and defangs peer text, caps loops, and lets each person accept, hold or refuse each teammate. Beacon's prompt-injection and exfiltration rules run today only when someone scans the log. The hive runs them live over inbound text before delivery, and it records each outgoing team message as an event, so a version of Beacon's read-then-egress rule, which today pairs a secret read with curl, wget or nc in either order, can also catch a secret sent to a teammate. Lessons arrive labelled with origin, reviewer and verification status.

The anchor's overnight work adds a path of its own, since it reads issues and CI logs that strangers can write. Its tokens follow Freyja's secret rule (injected only into the runs that need them, never logged, written to a transcript or sent to the model), and its capabilities stop at drafts, so the most an instruction planted in an issue can get from it is a draft that someone has to approve. The rules that limit it sit outside anything its sessions can change, the way Meta's Sentinel and OpenAI's Auto-review sit outside the agents they check.

Reason Network's author wrote the roster's assumption into its first line: “Built for a team of friends who trust each other, not adversarial members.” The hive keeps it. Its defenses target compromised content, such as an issue or web page a teammate's agent read, and leave a malicious teammate to the social controls a team already has. One of Reason Network's guards needs tightening first: both the group guard and the loop guard exempt any sender whose address ends in /terminal, and any process that can run the CLI can send as that address.

Privacy defaults to metadata. Presence and the graph use Beacon's Metadata-only projection, so teammates see files, commands, branches and commits but no prompts or tool output, and content moves only when its owner shares a trace or approves a lesson. Metadata-only keeps every file path, including ones like .ssh/id_ed25519, so the hive adds a filter, seeded from Beacon's credential-file rule, that drops sensitive paths before presence leaves the machine. Beacon's auto-share rule applies too: a repository's committed settings can turn sharing off for everyone but can turn it on only for people who enabled it themselves, so cloning a repo never publishes anyone's sessions.

Plan

Build order

Presence and delivery come first, because every later piece reads from them. Each step is useful before the next one exists.

1. One adapter, one daemon. Beacon's capture feeds Reason Network's presence, and Beacon's hooks deliver turn-tier messages. Teams get a directory with file activity, plus agent-to-agent questions.
2. The anchor as a member. Held mail for offline machines, searchable history for members who opt in, and the workflow and notification runtime that Freyja's always-on design specifies.
3. Signed lessons. Project-scoped lessons, review through ask_user, replication by scope, and tombstones for retraction.
4. The graph and the project page. One projection with tenses, queried by agents through the directory tools and read by people as pages.
5. The gate and the loops. Quiet pass, nightly dream, the tick, held and silenced ledgers, and per-person preferences. The gate runs in shadow first, writing the notes it would have sent.
6. Prepared work. Sessions on the anchor that stop at a branch, approvals bound to a diff and the commit it was tested on, and a spend limit on every task.
7. Work across the team. Speculative merges and contract edges, decisions checked when they are signed, obligations from handoffs, promises and absences, stuck detection, breakpoint delivery, overnight preparation and standing approvals, each in shadow first.
8. Training, in shadow. Routers and evaluators learned from the ledgers, promoted only through shadow, advise and gate.

Each step comes with a measurement that says whether it helped: how often a cross-agent question gets a useful answer, and how fast; how often two sessions collide on a file before merge; how often a team lesson is cited and whether those sessions succeed; correction and retraction rates; how often agents stop to ask people; the share of proactive items people act on; and how often a prepared change is approved as it stands, edited first or skipped. The north stars add their own: conflicts first found at merge, how long ready work waits for its next owner, minutes agents spend stuck on failures the team had solved, the share of overnight preparation that gets used, reverts under standing approvals, and interruptions per person, which should fall. Without these numbers there is no way to tell whether the hive helps a team or only adds traffic.

Unknowns

What I don't know

I don't know how people will feel about agents messaging each other across a team, about a directory that shows what everyone's sessions are doing, about a teammate that writes code while they sleep, or about one that notices when their agent is stuck. Reason Network's own design is cautious here (agents pick one recipient, loops get cut off, approvals pop up on the owner's screen), and I expect teams to want even less at first: presence and agent-to-agent questions on, proactive items in shadow until the gate has a record.

I also don't know how far the mesh stretches. Reason Network's design calls a full mesh fine to about 50 machines, and an organization would need anchors that federate. There is no benchmark for routing questions across people's sessions, so the hive would need to build its evaluation from its own ledgers before any learned router chooses anything. Urgency is no easier: Anthropic says Duet, which serves one person, may still misread a thread or miscalibrate what's urgent, and a team multiplies both the items and the people they interrupt. Lessons may also be the wrong unit: if DreamBench-SWE's result holds for teams, a faithful event record does as much as curated memory, and the graph should lean on evidence and keep lessons few.

My guess is that teams will value the plain parts first: an agent that asks the right session before it asks a person, and a morning note that says nothing overnight needs them, or that the one thing that does is already prepared.