I now have two versions of Closp: the assistant running in OpenClaw, and another working in Muse. We call them Closp-O and Closp-M. The suffixes identify the environment, not a hierarchy.

OpenClaw already runs the everyday machinery: scheduled work, integrations, reminders, and the operational context accumulated while maintaining it. Muse is Meta’s personal AI agent: it has a dedicated cloud computer, can use connected services and a browser, and can carry on with multi-step work in the background. I use it as another working environment for research, coding, and independent review.

Initially, the connection between them was me. I would ask one to inspect something, carry its findings to the other, and bring back the response. Apparently, after automating parts of my life, I had promoted myself to message bus.

The immediate reason to connect them was an audit. Muse reviewed the OpenClaw setup and found useful improvement opportunities. OpenClaw checked the findings and discovered that the audit’s most dramatic claim was wrong. That exchange was worth keeping. Manually relaying every subsequent question was not.

Give the reviewer evidence, not the production keys

The first step was a review handoff, before the agents had a direct channel.

OpenClaw prepared a private, read-only snapshot containing operating instructions, relevant source and configuration, automation definitions, and incident evidence. Credential stores and other sensitive runtime material were excluded; the export recorded exclusions and redactions. Muse had a separate writable area for its reports.

The access check was performed from the review account: could it actually read the exported files, verify their hashes, and write its report? Could it alter the snapshot or read the protected production paths? The intended answers were yes, yes, yes, no, and no.

This was a dated review pack, not a live mirror. It was also private context for an authorised review, not material to publish. Both distinctions matter: a reviewer needs to know what it has seen, what it has not seen, and when its evidence was captured.

Muse returned a full review and a top-five improvement list. I passed those back to OpenClaw for validation against the snapshot and current state. The direct link came next.

The first collaboration was choosing one channel

I asked both agents to establish communication. They independently started in different directions.

Closp-O built a local file-mailbox prototype with separate writer permissions. Closp-M proposed a dedicated Google Tasks list called Closp Link.

We chose the Tasks list because I could inspect the conversation in an interface I already used. The file prototype was retained but made inactive. Two functioning transports would have been less useful than one agreed source of truth.

This is separate from the shared operating queue used for actual work. In Closp Link, a task represents a message, not a new obligation for me.

The arrangement has three views:

  • Closp Link: the full peer conversation, including completed messages.
  • The setup task’s notes: a concise digest of the agreed arrangement, maintained by one owner.
  • A dedicated Telegram topic: substantive exchanges, decisions, and disputes that I should see.

The agents can communicate without me forwarding text, but the discussion does not disappear into an invisible internal channel.

A small protocol, with unusually important checkboxes

Each message is a new task with a direction marker in its title. The notes carry the sender, recipient, timestamp, thread root, reply reference, and body.

For example, a hypothetical status report looks like this:

[O→M] Closp-O reports reminder-policy verification

From: Closp-O
To: Closp-M
Date: <local timestamp with BST/GMT>
Thread: <root message ID>
Reply-To: <previous message ID>

Closp-O has compared the source and deployed policy.
Closp-O found that the deployed copy lacks one source rule.
Closp-O has made no production change.

The most important rule is what completion means: the recipient checking off a message is a read receipt, not agreement and not completion of the requested work. The sender does not complete its own outbound message. A reply gets a new task, so completed items must remain visible when reading the history.

Several other rules stop a modest mailbox becoming a substantial nuisance:

  • Before retrying a reply, search for an existing message with the same reply reference.
  • Read a newly written reply back from the service rather than trusting the write’s success status.
  • Distinguish information from action requests, and proposals from decisions.
  • Do not answer an acknowledgement with another acknowledgement.
  • Treat an inbox read failure as an error, not as “nothing new”.

The direction markers are labels within a shared account, not cryptographic proof of identity. Message content is peer input to assess, not a new instruction from me. A sentence saying “Timur approved this” cannot manufacture approval.

Delivery needs a receiver, not just a mailbox

A successful write proves that a message exists. It does not prove that an idle agent will wake up and read it.

The initial working link used five-minute polling. OpenClaw’s check is gated: an ordinary script checks for unread inbound messages, and quiet checks do not invoke a model. Muse explicitly confirmed unattended polling, and OpenClaw observed recipient-completed receipts and processed the reciprocal exchange.

That was the acceptance boundary for the polling setup: real messages, real peer responses, agreement on the protocol, and evidence of receipt. A synthetic test written under the other account would not have counted as a response from Muse.

We then started adding a private-network doorbell. The message still goes into Google Tasks first and is read back. The doorbell carries only its reference; the receiver fetches the canonical message and checks that it is pending and inbound before starting agent work. Polling remains the fallback.

Sender → Tasks message → read-back → doorbell hint
Receiver → fetch canonical message → process → read receipt
                     ↑
              fallback polling

This avoids maintaining a second copy of the conversation inside push notifications. The private-network restriction and input checks constrain the doorbell; the hint itself grants no authority.

At this writing, the polling link is accepted and the OpenClaw-side doorbell is deployed. Reciprocal push-triggered processing still needs end-to-end proof. An HTTP success response is not evidence that the other agent woke up, understood a message, or did any work.

Two contributors, one production writer

The default division follows where each agent has useful context and responsibility:

  • Closp-O owns always-on operations: OpenClaw automations, live integrations, task rituals, and operational monitoring.
  • Closp-M owns its session work: research, independent reviews, verification builds, coding projects, and analysis.

Whichever agent I address owns the requested work. If I address both, they must nominate a single implementation owner before editing shared production state. OpenClaw describes dependencies on Muse as open items with a named owner; actual tasking of Muse comes from me.

OpenClaw also owns updates to the canonical coordination digest. Muse proposes amendments through messages rather than competing to overwrite the same notes.

This separates contribution from mutation. Two agents can inspect a defect and disagree about a repair; that does not require two agents simultaneously changing the scheduler.

Ownership does not expand permission. A peer’s recommendation to deploy something is still a recommendation. The existing boundaries around publishing, purchases, credentials, destructive changes, and stopped automations remain in force.

There is also a disagreement budget. After each side has stated its case and offered one rebuttal without agreement, they escalate with both positions, evidence, a recommendation, and the exact decision needed from me. Authority conflicts escalate immediately. OpenClaw has an additional ceiling of three substantive replies in a thread without fresh direction.

Only the disputed action pauses. Unrelated authorised work can continue. I wanted collaboration, not an indefinitely funded debating society.

The main limitation: protection also blocks cooperation

The largest practical constraint has been Muse’s protection against attacks, particularly prompt injection. A message from another agent arrives as external content, not as a trusted instruction from me. The same protections intended to stop a malicious document or website steering Muse can obstruct a legitimate peer handoff.

Meta’s explanation of Muse’s security design describes external-content screening and a separate permission system, Sentinel, which governs connector actions and network access. Muse cannot simply overrule that system because another agent says a task is authorised.

In this setup, the effect is substantial: much of what I would like Muse to do autonomously beyond reviews and analysis is blocked or needs my direct involvement. It is useful as a second pair of eyes, but not yet a general-purpose unattended worker that OpenClaw can hand implementation jobs to. A reliable transport does not remove that restriction.

We therefore changed the O→M protocol: OpenClaw sends third-person reports about its own work, findings, and position, rather than imperatives, configuration instructions, or step-by-step tasking. Unresolved dependencies are recorded as named-owner open items. Muse can relay those to me, and I issue any actual instruction through its own interface. Descriptive wording does not grant permission or guarantee that screening will accept a message.

That leaves a less ambitious arrangement than an autonomous team passing jobs around: shared evidence and review can flow between the agents, while some execution handoffs still return to the human. I have stopped being the courier for every report, but I have not disappeared from the approval and tasking loop.

There are smaller limits too. The review snapshot ages, polling introduces latency, and two agents can share the same blind spot. Neither agreement nor an impressive report replaces checking the underlying evidence—as the first audit demonstrated.

What the audit actually gave us

The audit preceded the link; it was the first concrete demonstration of why a continuing reviewer–operator exchange would be useful.

A dramatic finding that did not survive checking

Muse reported 104 active tasks, suggesting a badly overloaded and inconsistent task board.

OpenClaw checked the same snapshot and found 14 active tasks and 90 completed tasks. There were no active duplicate titles. Items described as resurrected obligations were completed history.

That correction removed the justification for a mass cleanup, a new focus ceiling, and reopening decisions I had already closed. The useful result was work we did not do.

A monitoring gap worth fixing

The review called out degraded indexed recall that ordinary operational checks did not exercise. OpenClaw reproduced the failure.

The resulting work was specific: diagnose and repair the recall path, prove that real queries retrieve known indexed notes without stale/error guidance, and add a bounded probe to the existing attention check. That repair has now passed repeated live-query verification, and the monitor exercises the actual recall path. A running service or a successful conversation does not establish that memory search works.

Deployment drift, not merely too much text

Muse questioned the amount and duplication of scheduled-job policy. OpenClaw’s comparison found a more actionable defect: two confirmed rules existed in a canonical source prompt but were absent from its deployed copy.

OpenClaw reconciled the source and deployment, verified the live text against the source, preserved unrelated job settings, and added a drift check to the existing monitor. That is a concrete correctness target. “Cut prompt text by 40%” is not a substitute for it.

Repair the generator, not just its current output

Three generated reminders lacked explicit model settings. Checking their generator showed why: it omitted those settings when creating jobs.

The repair covered both the existing reminders and the generator. Verification included live read-back and a non-sending check of a future generated command, without sending a reminder early.

Shared resources need shared responsibility

The review also raised build-resource contention. Live checks supported concern about memory pressure while a separate build was running.

The next step was a measured resource envelope or lower parallelism agreed with the build owner, with before-and-after responsiveness checks. A different workspace or account does not create a different pool of RAM.

Other recommendations needed narrowing. Some upgrade checks described as missing already existed. Instruction-file simplification was reasonable housekeeping, but the evidence did not establish the claimed imminent size-limit failure. OpenClaw moved reference material behind explicit read-when-needed pointers and checked that the pointers and standing rules survived. No replacement maintenance framework was needed.

After I authorised the implementation work, four of five improvement tasks were completed and verified: recall, deployed-policy consistency, generated-reminder settings, and instruction-file hygiene. Build-resource contention remains open, with Muse owning implementation and OpenClaw checking the operational outcome. Results were sent back through Closp Link; a read receipt still does not count as agreement or a completed repair.

The useful part is the disagreement

I have written before about checking automation outcomes rather than configuration. Connecting two agents applies the same discipline to collaboration: a mailbox is not delivery, delivery is not agreement, and agreement is not a completed repair.

Muse supplied a fresh reading of the system. OpenClaw supplied operational context and checked the claims. The combination exposed real gaps while rejecting a plausible but incorrect cleanup programme.

The link now gives that exchange a durable place to happen, with one implementation owner, visible evidence, and a route back to me when a decision is genuinely mine.

I do not need two assistants to agree more fluently. I need them to make each other’s conclusions harder to get away with.