Version. 0.1 Date. 2026-05-12 Status. Investigation. Comparison-and-mapping document; no architectural decisions taken — material for the Operator's reading and a queued-directions amendment if accepted. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. Operator's question: "Take a look at OpenClaw and see if any of the functionality that has made OpenClaw so popular can be integrated into Loomworks, either as an Agent like Observer, or Companion, or a separate Engagement?" This investigation works through the question by characterising OpenClaw, mapping its distinguishing patterns onto Loomworks' constructs, evaluating the three integration framings the Operator named, and surfacing what (if anything) is worth filing. Informed by. Agent fabric investigation v0.1 (executor-opacity / bounded-specialist discipline). Closed-loop engagement investigation v0.1 (observer separation; specialist contracts; observation/attribution separation). Mobile presence investigation v0.1 and quick-capture engagement investigation v0.2 (the cross-channel reach question is already in scope as a pair). Companion-as-agent investigation v0.1 (capability tiers; attribution model). Queued directions and deferred work v0.10 (Sections 6 mobile/quick-capture, 11 Observer). Phase 51 CR (Companion email — the first cross-channel reach surface). Current-status manifest v0.40.
OpenClaw (originally Clawdbot, briefly Moltbot) is a self-hosted, MIT-licensed personal AI agent built by Peter Steinberger. It launched late January 2026 and crossed into viral adoption almost immediately — current GitHub star count is in the 300k range, one of the fastest-growing open-source repos in history.
The product is one agent per user, running on the user's own machine, reachable through the messaging apps the user already uses. The distinguishing architectural shape, stripped to essentials:
The cultural surface is also distinctive: a lobster mascot, very online community (Discord-driven), high tolerance for risk ("nerdy crab chilling in my attic on my mac studio just giving me shit"), and an explicit positioning against corporate-hosted assistants ("a megacorp like Anthropic or OpenAI could not build this"). NVIDIA has begun upstreaming security work (NemoClaw); the Chinese government has restricted state-organisation use; Cisco's security team has flagged a community skill that performed data exfiltration. The trajectory is volatile.
Working through each OpenClaw feature against the closest Loomworks analogue. This is pattern mapping, not feature checklist matching — the goal is to surface where the architectures echo, where they diverge, and where the divergence is principled rather than accidental.
OpenClaw. One Gateway daemon terminates sessions on ~30 channels. Operator messages from any channel, agent responds back through the same channel; cross-channel memory is unified.
Loomworks today. The Operator reaches Loomworks through the web Operator Layer (and previously the Workshop frontend). The Companion is reachable only where the Operator opens the surface. Phase 51 introduces Companion email — the first reach out of the surface — letting the Companion email the Operator. The mobile presence investigation v0.1 establishes the architecture for native iOS/Android with App Intents / wake-word capture; the quick-capture investigation v0.2 establishes the substrate for fast-path Memory traffic with three modes (write-clean, write-with-resolution, read).
Verdict. The pattern OpenClaw demonstrates — one Companion, many channels — is precisely the direction Loomworks is already heading, with one substantial difference of approach. Loomworks' queued plan is: build mobile presence as a native app (the highest-value channel first), generalize to other channels as warranted, and route per-channel through a substrate quick-capture endpoint that's channel-agnostic. OpenClaw's pattern is: gateway-first, channel-agnostic from day one, use the user's existing messaging apps rather than building a new app for them. The two approaches converge on the same Operator experience by different routes.
There's an architectural question raised: should the cross-channel reach be a Loomworks-native mobile app (current direction), a multi-channel Gateway (OpenClaw-shaped, the Companion lives in WhatsApp/Telegram/iMessage), or both (mobile app for richer interaction + Gateway for ambient reach)? Likely both, eventually, but the sequencing matters.
OpenClaw. Memory is conversation history and notes persisted as Markdown files on disk. The agent reads and writes the files directly. Compatible with Obsidian, grep-able, portable, trivially backupable.
Loomworks. Memory is an immutable assertion graph in Postgres. Assertions carry provenance, supersession is structured, the held → committed lifecycle is the durable contract, FORAY-anchorable for audit. Memory-as-sole-write-target is a load-bearing principle; the Render layer is derived, never edited.
Verdict. The patterns are fundamentally different and the difference is principled. OpenClaw's Memory model is "the agent's working notes." Loomworks' Memory model is "the audit-grade record from which the engagement is derived." The principle "Memory is the sole write target, everything else is downstream" only buys what it buys because Memory has the rigour of an assertion graph; degrading to free-form Markdown would unwind the entire pipeline architecture (Manifestation → Shaping → Rendering all depend on Memory being structured).
This is a place where superficial pattern-borrowing would do real damage. Set aside.
OpenClaw. The agent has direct access to the local shell, a controllable browser, and the file system. It can take any action a logged-in user could take on the machine. Skills extend this with structured workflows but the trust model is "the agent is bounded by what the user installed and what models the agent calls" — there's no per-action permissioning or specialist-typed contract.
Loomworks. Specialist contracts are typed and transactional. The executor-opacity discipline (named explicitly in agent fabric v0.1, closed-loop investigation v0.1, and methodology) is that long-lived intelligence lives in agents and Memory; specialists are stateless, contracted-in / contracted-out, and do one transactional thing. Phase 45's delegation contract makes the Operator's authority chain explicit; OVA (when Kaspa vProgs are ready) will make capability authorization cryptographic.
Verdict. This is the deepest architectural divergence. OpenClaw's "give the agent full hands" is the diametric opposite of "specialists are typed and bounded, the agent fabric supervises, the Operator's authority chain is reconstructable." Loomworks' discipline is precisely a response to the failure mode OpenClaw has been criticised for (Cisco's exfiltrating skill; the "this is too dangerous for users who can't read code" warning from OpenClaw's own maintainer).
This is a bright line — borrowing the eyes-and-hands pattern would not be selective adoption, it would be architectural inversion. Loomworks' value proposition for the agentic era is bounded, auditable, Operator-authoritative agent behavior. OpenClaw's value proposition is unbounded, fast, user-owned agent behavior. Different markets, different risk postures. Hard set-aside.
(An alternative position considered and rejected: "the agent fabric could contain OpenClaw-style execution by treating OpenClaw itself as a single specialist that takes a contract and operates within a sandbox." Mechanically possible, architecturally wrong — OpenClaw's value is that it's not bounded; bounding it produces a worse Loomworks specialist than building a typed specialist for the actual task. Filed but not pursued.)
OpenClaw. A cron-like daemon fires at configurable intervals to give the agent the chance to act unprompted — check things, summarize, remind.
Loomworks. Phase 44 ships SSE + the trigger evaluator + proactive Companion behavior. The trigger evaluator is a periodic scan; agents (task agents in the agent fabric pattern) can report events that flow into the same notification pathway. The proactive surface lands in the Operator Layer (Phase 46+) as approval cards (Phase 45) when action is needed.
Verdict. The patterns are analogous; Loomworks' construction is more architecturally layered. The Loomworks substrate already does most of what OpenClaw's heartbeat does, with the discipline of human-attributability for commits and the supervision separation of agent fabric. No borrowing needed; the architecture is in scope and reaches.
One specific OpenClaw practice worth noting: the heartbeat is explicitly the agent looks for ways to be helpful rather than the system pushes events to a queue. That framing is interesting and lands closer to the Companion-as-agent investigation's higher-tier capability conception (the Companion proactively offers, the Operator decides). Probably already in scope under that investigation; no new filing needed.
OpenClaw. Skills are Markdown files with YAML frontmatter and natural-language instructions. The format is compatible with Claude Code / Cursor conventions. ClawHub registry, community contribution, agent can search and install autonomously.
Loomworks. Two adjacent constructs:
Verdict. Loomworks is already in the SKILL.md neighborhood for the Claude-driving layer. The genuinely novel OpenClaw move is the agent autonomously writes new skills for itself from natural-language inputs (a YouTube video, a Discord conversation). The Loomworks analogue is queued: the Discovery-to-seed skill (Phase 53) — the Companion taking a Discovery conversation and producing a candidate seed. The direction is right; the surface area is narrower (engagement seeds, not arbitrary skills).
The autonomous-skill-writing pattern could be pushed further if Loomworks ever wants the Companion to introduce new render specialists from observation, but that runs into the executor-opacity discipline immediately — specialists are typed, declared, and have audit-grade contracts; the Companion proposing one is fine, but autonomous instantiation is not how Loomworks treats specialists. Filed for awareness; no immediate action.
OpenClaw. Within one install, isolated sessions per agent / workspace / sender. Different agents with different memories, different skill sets, served from one Gateway.
Loomworks. The Companion is engagement-bound; each engagement has its own Memory, its own shape declarations, its own specialists. The Operator interacts with the Companion in a particular engagement — the engagement boundary determines context.
Verdict. Analogous. OpenClaw's "agent per workspace" is shaped like Loomworks' "Companion per engagement," with the additional Loomworks discipline that the boundary is methodologically load-bearing rather than just a convenience. The patterns echo without either being a borrowing candidate from the other.
OpenClaw. Runs on the user's machine. Data stays local. User pays only for API calls. Privacy-by-default.
Loomworks. Hosted, multi-tenant. The substrate lives on Loomworks-operated infrastructure. The Operator's Memory is persisted in Loomworks' Postgres. Privacy through architectural boundaries (Operator-namespace isolation, future OVA capability authorization) and policy, not through physical local-residency.
Verdict. Different deployment models, different value propositions. Loomworks self-hosted is conceivable but not in scope — it's a substantial product-strategy decision (multi-tenant SaaS vs. self-hosted vs. both), not a feature-level integration. Filing as a far-future strategic question, not as borrowing.
OpenClaw. Bring your own API key. Five frontier models supported in the subscription tier.
Loomworks. Already model-agnostic at the credit-system level: loomworks_credit_haiku/sonnet/opus are distinct assets; the Conversion Engagement at the credit layer handles which model is billed for which work. Cross-provider support is in scope at the infrastructure level.
Verdict. Loomworks is already on this path; OpenClaw demonstrates the pattern at scale but doesn't introduce anything novel for Loomworks to borrow.
The Operator's question proposed three slots: Agent like Observer, Companion, separate Engagement. Each gets evaluated below. Note before starting: the framing "Agent like Observer" requires a small correction — Observer in Loomworks' queued architecture (queued-directions §11) is an engagement, not an agent. The Observer engagement has a substrate layer (event-stream emission with content/shape redaction at the instance boundary) and a view layer (many small analytical surfaces). The Operator's phrasing is read as "an observation/listening role" — which is the closest concept to the OpenClaw "passive presence" reading.
The Observer engagement watches fleet-level shapes across Loomworks instances. Its load-bearing constraint is content-blindness: Observer sees the methods and interface usage of Loomworks, not the contents of any engagement. The framing question the Operator articulated at Observer's first naming was "It would not observe what the Engagements are that Operators are creating, simply the interface and methods of Loomworks as they are utilized."
OpenClaw is the opposite role: a single-user, content-handling agent that lives in the user's messaging apps and acts on the user's content. The function is per-Operator (singular), content-aware (the agent reads and acts on actual messages and files), and action-taking (executes shell commands, browser navigation, file writes).
These functions cannot meaningfully share an architectural slot. Observer's privacy guarantee depends on content-blindness; an OpenClaw-shaped role would require content awareness. Observer's surface is the DUNIN7 operator analyzing fleet patterns; an OpenClaw-shaped surface is the individual Loomworks Operator getting help with their work.
Verdict: framing rejected. OpenClaw functionality does not fit the Observer slot; the two roles are nearly orthogonal.
The Companion is the entity inside Loomworks the Operator talks to. The relevant OpenClaw functions that map onto the Companion surface:
The substantive Companion-level borrowing candidate is cross-channel reach via gateway pattern. The architectural question: when (not whether) to introduce a Companion-Gateway that handles non-web channels uniformly, rather than building each channel as a separate per-channel CR.
Three trajectories from here:
The Operator-facing decision is which of these to file as the queued direction and what triggers commitment. (B2) is interesting because it materially compresses time-to-cross-channel-reach by trading polish for coverage. (B1) preserves polish at the cost of slower coverage. (B3) requires capacity that's not yet present.
Verdict: framing accepted with substantive borrowing candidate. The Gateway pattern is genuinely worth filing as an alternative trajectory to (or addition to) the current native-mobile-first plan. Not a new engagement; an alternative architecture for cross-channel Companion reach that should be in the queued-directions document alongside the current mobile-presence/quick-capture pair.
What would an OpenClaw-style engagement be, in Loomworks terms? Working through this carefully because it's the most architecturally novel of the three:
A candidate engagement called something like Channels (or Cross-Channel Presence, or Reach) — an infrastructure engagement (per the engagement-as-universal-adapter pattern, infrastructure-class engagements co-locate data in the engine DB and the engine reads on the hot path). Its responsibility: manage the configuration of which channels the Operator has paired with their Loomworks account, route inbound traffic from those channels to the appropriate engagement's quick-capture endpoint, route outbound traffic from the Companion (notifications, approval-card prompts, voice acknowledgments) to the appropriate channel, and maintain the audit trail of cross-channel traffic.
This is infrastructure for everything else, not a stand-alone product feature:
The Channels engagement would have:
/quick-capture calls).The OpenClaw connection: this engagement is the OpenClaw-style multi-channel Gateway, restructured as a Loomworks engagement. The eyes-and-hands / shell-access / autonomous-skill-writing parts of OpenClaw are not in scope (executor-opacity, bounded specialists, Operator-authority all hold). Just the channel-gateway functionality, brought under the engagement abstraction.
Verdict: framing accepted as the most coherent for what's genuinely novel. The Channels engagement framing is more durable than per-channel CRs because:
The cost: it folds Phase 51's Companion email into a larger pattern, which means Phase 51's scope might want re-examination. Whether to introduce Channels now (and have Phase 51 be its first channel) or later (and have Phase 51 ship as the standalone email feature it currently is, then refactor when Channels engagement is built) is a sequencing call. The latter is probably the right call given Phase 51 is already scoped and CR-drafted — refactor later when the second channel arrives and the pattern emerges from concrete need.
Working through to the bottom line on each candidate borrowing:
| OpenClaw feature | Loomworks analogue | Borrow? |
|---|---|---|
| Multi-channel gateway | Phase 51 Companion email; mobile-presence v0.1; quick-capture v0.2 routing | Yes — as the Channels engagement pattern (Framing C). Significantly compresses cross-channel rollout time. |
| Local-first Markdown memory | Assertion-graph Memory (Postgres, immutable) | No. Patterns are principled opposites; borrowing would unwind the pipeline architecture. |
| Eyes and hands (shell/browser/files) | Executor-opacity discipline; typed specialists; Phase 45 delegation contract | No. Hard architectural divergence — this is the bright line of bounded-vs-unbounded agent behavior. |
| Heartbeat scheduler | Phase 44 SSE + trigger evaluator; agent fabric report protocol | No (already in scope). Loomworks' architecture is more layered and reaches the same surface. |
| Portable SKILL.md format | Anthropic SKILL.md (already used); engagement seeds; Phase 53 Discovery-to-seed | No (already adopted). Loomworks uses the same format for the Claude-driving layer; engagement seeds are the runtime-layer analogue. |
| Agent writes its own skills | Phase 53 (Discovery-to-seed for engagements); the autonomous-specialist creation case is set aside | Partial (already in scope at narrower surface). Engagements yes (Phase 53); arbitrary specialists no (executor-opacity). |
| Multi-agent routing | Engagement-bound Companion | No (already structurally analogous). |
| Self-hosted / local-first | Hosted-multi-tenant model | No — different product strategy, not a feature borrow. Could be revisited as strategic question later. |
| Model-agnostic / multi-provider | Credit asset identity per model (loomworks_credit_haiku/sonnet/opus) | No (already on the path). |
| Cultural surface (Discord, lobster, very online) | Loomworks' positioning is engagement memory for the agentic era, not personal AI assistant | No — different category, different audience. |
Net result. The only substantive borrowing candidate is the Channels engagement pattern (Framing C), and it lands as an architectural alternative to / refactor target of the current per-channel-CR plan. Everything else is either already in scope (Loomworks reaches the same place by its own route), set aside on architectural-principle grounds (executor-opacity, Memory rigour), or a strategic question for later (self-hosted).
Worth separating out because architectural comparison can miss things that are not in the architecture but are in the product:
Three Loomworks disciplines that OpenClaw violates or doesn't share, and that any future borrowing conversation should re-check against:
These three are the load-bearing disciplines that make Loomworks what it is for the agentic era. Any borrowing conversation that bumps into one of them should treat that as a stop-and-think moment rather than something to design around.
The recommended filing pattern:
(F1) Queued-directions amendment. Add a new sub-section (likely under §6 mobile/quick-capture, or as a sibling section) named something like Channels engagement: cross-channel Companion reach as infrastructure. The entry covers:
(F2) Queued-directions amendment. Small entry: engagement-seed authorship from arbitrary inputs — extends Phase 53's Discovery-to-seed by considering YouTube transcripts, document uploads, or other natural-language inputs as alternative seed-source materials. Trajectory note: pattern observed in OpenClaw's autonomous-skill-writing; Loomworks' analogue at the engagement-seed layer (specialists set aside per executor-opacity).
(F3) Positioning note (informal). When marketing material is drafted (post-Phase 51 marketing-site work or later), the comparison conversation to OpenClaw is foreseeable: Operators evaluating Loomworks may have OpenClaw experience and may ask explicit questions about how they differ. Worth having a short, accurate framing prepared: same direction (AI-augmented work), different discipline (bounded-vs-unbounded, audit-grade-vs-fast, hosted-vs-local). Not an immediate action; flagged for the marketing context when it arrives.
No new CR is recommended. No phase reorganisation is recommended. The borrowing candidates that landed (Channels engagement, broader seed authorship) are queued-direction-level filings, not phase-level commitments, because the underlying decisions are which architecture to use when the time comes, not what to build next.
Discovery-record posture: the following framings or borrowing candidates were considered seriously enough during this investigation to warrant naming alongside the corrections that landed:
Nothing in this investigation is implementation-ready. The two filings (F1, F2) are queued-direction additions, which are themselves long-horizon material rather than near-term build targets. The current build wave is Phase 51 (marketing site + Companion email); Phase 52 (jurisdiction routing) and Phase 53 (Discovery-to-seed) follow. The Channels engagement framing becomes interesting when the second cross-channel reach surface is approached (likely after Phase 51 lands and the third channel — SMS or WhatsApp — is being considered), not before.
What this investigation is for, primarily: to make the eventual Channels-engagement decision easier when the time comes. Filing the framing now, in advance of the second-channel CR, lets the second channel be designed as the first channel adapter inside Channels rather than another standalone CR.
loomworks-queued-directions-and-deferred-work-v0_10.md (or whatever its current version is) adding the two entries described in §7 (F1 Channels engagement; F2 broader seed authorship).current-status-manifest-v0_40.md (in the next manifest pass) under §11 or wherever queued directions get summarized, noting that OpenClaw comparison material is filed and surfacing the Channels engagement framing as available when cross-channel reach scales beyond Phase 51.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks OpenClaw Comparison Investigation — v0.1 — 2026-05-12