Gobii vs OpenClaw: Timeline, Architecture, and Always-On Agents

OpenClaw is good software. The adoption curve reflects that.

If you look closely at the technical shape of both systems, though, you can see that many of the patterns people now associate with OpenClaw were already present in Gobii months earlier: persistent always-on agents, schedule and event trigger loops, webhook-driven integrations, memory-backed automation, browser control, and multi-agent coordination.

The interesting part is not "who has feature X" in isolation. The interesting part is the implementation style and operational assumptions underneath each feature.

The Builders Behind the Architectures

OpenClaw is led by Peter Steinberger, a long-time OSS builder and founder of PSPDFKit. In his own profile he says he came back from retirement to build OpenClaw in 2025, and his writing about that return to building explains a lot about the project's velocity and product feel: highly operator-centric, fast-moving, and local-first.

Gobii came from a different lineage. My background includes staff-level engineering roles at Hortonworks, Cloudera, and FOSSA, plus nearly a decade as an NSA contractor. From 2021 to early 2025, I was in a semi-retired builder phase that included launching Alwrite, an AI content repurposing platform for content creators, and Fictie, an AI interactive audiobook platform.

Our team now also includes two other former defense contractors: Will and Matt.

RA.Aid came out of that Fictie period. While building Fictie, I had already seen how powerful coding agents could be. I knew Aider well, but it was not agentic enough for what I wanted, so I built RA.Aid and released it as open source because my primary company focus at the time was still Fictie. RA.Aid went on to be discovered and sponsored by Open Core Ventures as the first product in its Catalyst program; OpenCore's write-up reports 9x growth in RA.Aid's inaugural Catalyst run.

In 2024, I also launched a personal builder brand, A.I. Christianson (my actual initials), and rapidly grew it to 60K+ combined followers across TikTok, Instagram, X, YouTube, and other channels.

The deep systems lineage is also visible in Apache history: I am an emeritus NiFi committer (aichrist), and NiFi itself traces to NSA's release of NiagaraFiles into open source. When you zoom out, Gobii's cloud-first, policy-heavy, always-on runtime posture makes sense in that context.

How Similar Are They, Really?

High level: pretty similar in concept.

Both systems clearly care about:

• agents that run continuously, not only on demand
• trigger-driven automation
• browser-enabled real-world work
• tool orchestration across multiple contexts
• memory that survives beyond a single turn

The real differences show up in runtime architecture and security defaults.

Timeline in One View

Gobii's private repo starts 2025-05-01 (3f3b9e89).

June 2025 is the core moment: Gobii launched as always-on AI employees (OpenCore launch post), and the first always-on MVP landed in the same window with a 10-day commit run from 2025-06-20 to 2025-06-29 (a36f7e1e, 77393150, b34eb616, 56b19631, 0148663c, 6d48d601).

The public MIT repo (gobii-platform) opened on 2025-08-30 (f596424e), and OpenClaw's repo began on 2025-11-24 (f6dd362d3).

Always-On Model: Heartbeat vs Schedule + Event Queue

OpenClaw's "always-on" center of gravity is heartbeat-driven main-session turns.

• docs/gateway/heartbeat.md:13 defines periodic main-session heartbeat turns.
• docs/gateway/heartbeat.md:69 defines HEARTBEAT_OK suppression/ack behavior.
• docs/automation/cron-vs-heartbeat.md:27 frames heartbeat as periodic awareness.

Gobii's "always-on" center of gravity is per-agent schedule state plus event triggers into a durable processing loop.

• api/models.py:5130 stores schedule on each PersistentAgent.
• api/models.py:5731 syncs per-agent beat task state.
• api/models.py:5764 binds api.agent.tasks.process_agent_cron_trigger.
• api/agent/tasks/process_events.py:334 handles cron triggers.
• api/agent/tasks/process_events.py:114 is the core per-agent processing task.

The practical feel is different:

• OpenClaw heartbeat feels conversational and operator-friendly.
• Gobii schedule+event processing feels like running autonomous service instances with strict lifecycle semantics.

Event Triggers: Wakeups vs Unified Ingress

In OpenClaw, webhook ingress deliberately splits into wake-mode and agent-run mode:

• POST /hooks/wake (docs/automation/webhook.md:44)
• POST /hooks/agent (docs/automation/webhook.md:60)
• dispatch logic at src/gateway/server/hooks.ts:24 and src/gateway/server/hooks.ts:32

In Gobii, external events and scheduled events converge into one loop.

• inbound message ingestion: api/agent/comms/message_service.py:729
• queue handoff into processing: api/agent/comms/message_service.py:1032
• scheduled cron trigger also feeds the same processor: api/agent/tasks/process_events.py:334

That unification is one of Gobii's strongest architectural choices for reliability and state continuity.

Webhooks: Ingress Surface vs Agent Integration Primitive

OpenClaw webhook design is a robust ingress policy surface:

• hooks config resolution and validation: src/gateway/hooks.ts:36
• request auth extraction: src/gateway/hooks.ts:158
• routing policies for agent/session: src/gateway/hooks.ts:24

Gobii treats webhooks as part of the agent toolchain, not only ingress:

• inbound SMS/email webhook handlers: api/webhooks.py:38, api/webhooks.py:389, api/webhooks.py:439
• outbound webhook model on agent: api/models.py:6697
• outbound webhook tool for agents: api/agent/tools/webhook_sender.py:26
• execution path for outbound delivery: api/agent/tools/webhook_sender.py:169

That outbound piece landed in public Gobii on 2025-10-17 (39bfb8d4), well before OpenClaw's gateway webhook commit on 2025-12-24 (1ed5ca3fd).

Orchestration: Explicit Nested Subagents vs Native A2A

OpenClaw has a very clear orchestrator pattern and deserves credit there.

• nested orchestration docs: docs/tools/subagents.md:72
• orchestration depth controls in code: src/agents/tools/subagents-tool.ts:248
• milestone commit: b8f66c260 on 2026-02-14

Gobii took a different route: durable event-loop orchestration plus native agent-to-agent messaging.

• peer link model: api/models.py:8039
• native A2A tool: api/agent/tools/peer_dm.py:27 (send_agent_message)
• peer DM runtime, quotas, debounce, wake behavior: api/agent/peer_comm.py:60
• receiver wake on commit: api/agent/peer_comm.py:215

Gobii's native A2A landed publicly on 2025-10-02 (0130b607), about 135 days before OpenClaw's nested orchestration controls commit.

Memory: Markdown-First vs SQLite-First

OpenClaw memory model:

• Markdown is source of truth (docs/concepts/memory.md:11)
• canonical files: MEMORY.md and memory/YYYY-MM-DD.md (docs/concepts/memory.md:21)
• vector acceleration via SQLite (docs/concepts/memory.md:97)

Gobii memory model:

• SQLite-backed runtime substrate via api/agent/tools/sqlite_state.py:1
• built-in state tables (__agent_config, __messages, etc.) at api/agent/tools/sqlite_state.py:33
• charter/schedule synchronization path through SQLite tooling (api/agent/tools/sqlite_agent_config.py:23)

OpenClaw's approach is very legible to users. Gobii's approach is very strong for agentic state mutation and structured tool workflows.

Browser Runtime, State, Proxies, and Secrets

Both projects do real browser work, not toy wrappers, and both can run headed sessions.

OpenClaw headed/browser control path:

• headed default in sandbox browser entrypoint (HEADLESS default 0): scripts/sandbox-browser-entrypoint.sh:13
• Xvfb-backed headed runtime and optional noVNC: scripts/sandbox-browser-entrypoint.sh:17, scripts/sandbox-browser-entrypoint.sh:62
• browser routing across host/sandbox/node targets: src/agents/tools/browser-tool.ts:81
• local profile user-data dir per browser profile: src/browser/chrome.ts:62, src/browser/chrome.ts:192

Gobii headed/browser control path:

• headed default in runtime settings (BROWSER_HEADLESS=False): config/settings.py:884
• dedicated Xvfb lifecycle manager with DISPLAY swap/restore: util/ephemeral_xvfb.py:94, util/ephemeral_xvfb.py:176
• browser profile injected directly into runtime session: api/tasks/browser_agent_tasks.py:1024, api/tasks/browser_agent_tasks.py:1027

The timeline is clear in git history: Gobii's headed cloud-worker architecture is already present in public commit f596424e on 2025-08-30; OpenClaw's browser control lands later in 208ba02a4 on 2025-12-13, sandbox browser support in d8a417f7f on 2026-01-03, and node browser proxy routing in c3cb26f7c on 2026-01-24.

Proxy Rotation: Transport Proxy vs Browser Control Proxy

This is one of the more important architectural differences.

In OpenClaw, "browser proxy" is a control-plane proxy command between gateway and node-host browser services:

• browser proxy capability check: src/agents/tools/browser-tool.ts:78
• node-host browser proxy config (enabled, allowProfiles): src/config/types.node-host.ts:1
• node-host browser proxy dispatcher: src/node-host/invoke-browser.ts:38, src/node-host/invoke-browser.ts:128
• docs describe proxying browser actions to node-host, not rotating outbound browser egress: docs/tools/browser.md:146

In Gobii, proxies are a first-class egress and reliability layer for agent actions:

• health-aware proxy selection with recent-pass preference: api/proxy_selection.py:19, api/proxy_selection.py:102
• proxy prioritization logic (healthy static IP -> healthy any -> static IP -> fallback): api/models.py:1746
• per-task browser proxy attachment: api/tasks/browser_agent_tasks.py:1000, api/tasks/browser_agent_tasks.py:1032
• dedicated proxy inventory allocation/release: api/services/dedicated_proxy_service.py:24, api/services/dedicated_proxy_service.py:60
• proprietary mode requiring proxy for outbound HTTP: api/agent/tools/http_request.py:306, api/agent/tools/http_request.py:323

OpenClaw can absolutely drive remote browsers, but the codebase today does not expose a built-in browser egress proxy rotation model comparable to Gobii's health-scored and dedicated-IP-aware proxy selection.

Persistent Browser State: Local Profile Persistence vs Distributed Worker Persistence

OpenClaw persists browser state primarily as local profile data where the browser runs:

• persistent profile user-data dir pathing: src/browser/chrome.ts:62
• profile launch uses persistent --user-data-dir: src/browser/chrome.ts:192
• storage APIs for cookies/localStorage/sessionStorage and related session state operations: src/browser/routes/agent.storage.ts:10, src/browser/routes/agent.storage.ts:99

Gobii persists state as portable per-agent profile archives designed for stateless workers:

• deterministic object-store key layout for profile archives: api/tasks/browser_agent_tasks.py:774
• secure tar extraction guard on restore: api/tasks/browser_agent_tasks.py:810
• profile restore from compressed archive before run: api/tasks/browser_agent_tasks.py:892, api/tasks/browser_agent_tasks.py:929
• profile save/compress/upload after run (tar + zstd): api/tasks/browser_agent_tasks.py:1288, api/tasks/browser_agent_tasks.py:1352, api/tasks/browser_agent_tasks.py:1385

That is a major cloud-native distinction: local profile persistence is strong for a single host workflow, while Gobii's archive-restore-save loop is engineered for distributed worker fleets and continuity across pod/task boundaries.

Credentials Security Around Browser and API Automation

OpenClaw has typed auth-profile storage and file-permission hardening:

• token-bearing auth profile type: src/agents/auth-profiles/types.ts:13
• auth profile persistence into JSON-backed store: src/agents/auth-profiles/store.ts:223
• JSON store writes with 0600 permissions: src/infra/json-file.ts:16, src/infra/json-file.ts:22

OpenClaw's own threat model explicitly documents residual token-at-rest risk:

• token theft entry marks residual risk as high with plaintext token note: docs/security/THREAT-MODEL-ATLAS.md:194, docs/security/THREAT-MODEL-ATLAS.md:203
• recommendation calls for encryption at rest: docs/security/THREAT-MODEL-ATLAS.md:204, docs/security/THREAT-MODEL-ATLAS.md:545

Gobii's credential path is encrypted-at-rest and domain-scoped in the runtime model:

• AES-256-GCM secret encryption utilities: api/encryption.py:3, api/encryption.py:23
• encrypted binary field on per-agent secret records: api/models.py:6556, api/models.py:6583
• request-time secure credential workflow: api/agent/tools/secure_credentials_request.py:17
• domain-scoped secret placeholder substitution during outbound calls: api/agent/tools/http_request.py:347, api/agent/tools/http_request.py:351

For production automation with persistent browser and API credentials, Gobii's default architecture is closer to a cloud security baseline.

Identity Model: Endpoint-Addressable Agents

Gobii agents can have unique communication identities like [email protected].

• endpoint name generation: console/agent_creation.py:57
• first.last normalization: console/agent_creation.py:61
• endpoint provisioning flow: console/agent_creation.py:233
• default proprietary domain: config/settings.py:1335

OpenClaw's identity system leans on workspace-level identity files and session behavior:

• bootstrap filenames include SOUL.md: src/agents/workspace.ts:24
• SOUL template semantics: docs/reference/templates/SOUL.md:8

Both are valid designs. Gobii's is more endpoint-native; OpenClaw's is more workspace/operator-native.

SOUL.md vs Charter

OpenClaw's SOUL.md is an editable identity/personality contract in workspace files.

Gobii's charter is model-backed operational state:

• charter field: api/models.py:5039
• update tool schema: api/agent/tools/charter_updater.py:31
• update execution: api/agent/tools/charter_updater.py:53
• downstream metadata generation from charter changes: api/agent/tools/charter_updater.py:76

So the practical split is:

• OpenClaw: identity as editable workspace artifact.
• Gobii: identity/mission as runtime-backed structured state.

Channels: Breadth vs Depth

OpenClaw has very wide channel coverage:

• broad channel list in README.md:124
• expansive integration inventory in README.md:148

Gobii is deeper on a smaller core set (especially SMS/email/web + agent-to-agent), with policy controls tightly coupled to agent lifecycle:

• inbound webhook adapters in api/webhooks.py:10
• sender verification and allowlist checks in api/webhooks.py:85 and api/webhooks.py:95
• comms policy model behavior in api/models.py:5439

The simplest way to frame it:

• OpenClaw: more channels, thinner per-channel depth by design.
• Gobii: fewer core channels, deeper runtime and policy integration.

Security and Cloud-Native Posture

OpenClaw is explicit that sandboxing is optional and host execution remains a normal default path:

• optional sandboxing: docs/gateway/sandboxing.md:10
• host-default security model note: README.md:329

Gobii's production posture is explicitly Kubernetes-native:

• env-level backend selection to Kubernetes: ../gobii/infra/platform/argo/base/platform-common-env.yaml:35
• backend resolver chooses k8s path: api/services/sandbox_compute.py:525
• default runtime class set to gVisor: config/settings.py:1112
• pod manifest runtime class: api/services/sandbox_kubernetes.py:766
• seccomp runtime default on pod spec: api/services/sandbox_kubernetes.py:771
• egress-only network policy for sandbox pods: ../gobii/infra/platform/argo/base/sandbox-egress-networkpolicy.yaml:1

For cloud multitenant agent execution, these defaults matter a lot.

Private Gobii to Public MIT Gobii Platform

The public OSS repo is a direct lineage continuation, not a fresh concept reboot.

You can see it in the private history:

• 352a1fb6 (2025-06-21) package rename (platform evolution)
• 44a4ccb6 and db5a9d36 (2025-06-24) package-move corrections
• 61c3f3fd (2025-08-30) explicit move marker: gobii_platform moved to gobii-platform
• f596424e (2025-08-30) first commit in public gobii-platform

That lineage is why the concept continuity is so obvious when you compare systems at code level.

Creator Timelines and Product Shape

The creator timelines map cleanly to how each project feels in use.

Peter's OpenClaw arc is a return-to-building story: deep product craftsmanship, extremely broad channel surface, and fast local-first operator UX loops. You can see that directly in the documentation density and release tempo in the OpenClaw ecosystem.

My Gobii arc is a systems-operator story: from Alwrite and Fictie into RA.Aid, then a hard turn into always-on autonomous agents and browser-use workflows in 2025. Since then the product has shipped and iterated at a very fast pace. The architecture reflects that background: durable schedules, event-queue continuity, strict sandbox boundaries, and Kubernetes-native runtime controls by default.

Both are high-output builders. The difference is where depth is concentrated.

Where OpenClaw Is Excellent

OpenClaw is strong on:

• local-first operator experience
• ecosystem/channel velocity
• documentation clarity and discoverability
• rapid experimentation in orchestration surfaces

Those are real strengths, and they are part of why the project is resonating.

Where Gobii Is Stronger

Gobii stands out on:

• earlier implementation of core always-on architecture
• schedule + event trigger convergence as a first-class runtime model
• endpoint-addressable agent identity and native A2A
• SQLite-native internal state for structured tool workflows
• health-aware proxy rotation with dedicated proxy inventory support
• portable browser profile persistence across distributed workers
• encrypted-at-rest credential handling integrated into agent tooling
• cloud-native production posture (k8s, gVisor, network policies)
• practical headed browser execution in worker fleets

Final Take

If OpenClaw's direction clicks for you, Gobii should feel very familiar, and in several areas it should feel more production-ready.

The overlap in concepts is real. The timeline evidence is also real. Gobii implemented much of this architecture earlier, then carried it forward from private code into the public MIT repo lineage.

For people deciding where to build serious always-on agent workloads, the biggest differentiator is less "feature checklist" and more runtime posture: security boundaries, cloud execution assumptions, lifecycle consistency, and operational depth.

Source Notes

Repo timestamps in this post were pulled from git history on 2026-02-16, including private Gobii history before OSS publishing and public history after the MIT transition.

Commit anchors referenced in this post:

• Gobii private always-on foundation: 3f3b9e89, a36f7e1e, 77393150, b34eb616, 56b19631, 0148663c, 6d48d601
• Gobii private-to-public MIT transition: 352a1fb6, 44a4ccb6, db5a9d36, 61c3f3fd, f596424e
• Gobii public OSS milestones: f596424e, 0130b607, 39bfb8d4, 8d44c2bb, c5e5de26
• OpenClaw milestones: f6dd362d3, 208ba02a4, d8a417f7f, c3cb26f7c, 1ed5ca3fd, 0d8e0ddc4, b8f66c260, 74fbbda28

External context links:

• Peter Steinberger GitHub profile
• OpenCore Ventures on Gobii launch and always-on AI employees
• OpenCore Ventures on RA.Aid Catalyst (9x growth)
• Apache NiFi community roster
• NSA NiagaraFiles to open source story