ADR-007 — External OpenClaw-hosted agents

Proposed 2026-05-25. Sprint 5 motion in the 2026-05-25 sprint plan. Scope is 4-5 phases over roughly 4 weeks of focused work — comparable scale to the Brand layer rollout.

Context

Every Agent today runs in Aroovo's runtime via runAgentLoop: the in-process loop that calls a ModelProvider, executes MCP tools, gates approvals, writes audit rows, and tracks usage. ADR-003 made the provider keys per-Brand so each Brand pays their own LLM bill. But the loop itself, the prompt assembly, the tool dispatch, the conversation history — all of it runs on Aroovo infrastructure.

Decision

Let a Brand register an Agent row that does not run on Aroovo's loop at all. Instead, the row points at an externally-hosted agent on OpenClaw, where the loop and the model live entirely outside Aroovo. Aroovo becomes the orchestration + identity + audit + approval + ingress layer over external agents.

The marketing pitch shifts from “white-label agent platform” to “white-label multi-tenant orchestration over OpenClaw agents,” which lands a different buyer: an OpenClaw shop that already has agents running on their own infrastructure and wants Aroovo for multi-tenant onboarding, Brand RBAC, Teams + Slack ingress, BYO Entra, HMAC-chained audit, per-Brand cost rollup, and approval gates — without rewriting their agents.

Why OpenClaw first

  • Already wired as a Provider. ADR-001 Phase 3 + ADR-003 Phase 6 treat OpenClaw as an OpenAI-compatible gateway with per-Brand BYO base URL + API key.
  • Self-hosted by its users. Neither Aroovo nor OpenClaw becomes a chokepoint for the Brand's data — matches the BYO philosophy exactly.
  • No competitor ships this. Per the 2026-05-25 competitor analysis, none of the top six (Botpress, Voiceflow, Copilot Studio MT preview, Agentforce, Stack AI, CustomGPT) ship per-agent runtime portability. The 12-18 month window before Copilot Studio MT hardens is the same window in which Aroovo can plant a flag.

Strategic shape

Aroovo's primitives stay the same; the value proposition broadens:

  • Identity. External agents still authenticate through the Brand's IdP via the same auth provider interface.
  • Approvals. Aroovo intercepts tool calls before they hit the external runtime when the policy says single or dual approval.
  • Audit. Every inbound chat, every outbound dispatch to OpenClaw, every approval resolution writes to the HMAC-chained log on the Aroovo side.
  • Ingress. The Brand's Teams or Slack surface stays unchanged — the customer doesn't see OpenClaw at all.

Phase plan (sketch)

  1. Phase 1 — Runtime indirection. Agent.runtime column (internal | openclaw); dispatcher branches on this; legacy agents stay internal.
  2. Phase 2 — OpenClaw dispatch path. Outbound call to the configured OpenClaw agent URL; in/out message translation; conversation thread continuity.
  3. Phase 3 — Audit + approvals on the external path. Hook the same intercepts that fire for internal tool calls; tool calls embedded in the external response surface in our approval queue.
  4. Phase 4 — Admin UI. “Use external runtime” toggle on agent settings; OpenClaw URL + key inputs scoped per-agent.
  5. Phase 5 — Cost rollup + provider attribution. OpenClaw usage data flows into /costs alongside native provider spend.

Open questions

  • Does Aroovo host the OpenClaw gateway, or does each Brand? Initial answer: each Brand — consistent with BYO LLM.
  • How are tool definitions reconciled when the OpenClaw agent declares its own tools and Aroovo also has an MCP catalogue? Phase 3 work.

References

Full markdown: adr-007-external-openclaw-agents.md.

Related: ADR-001 Self-hosted runtime, ADR-003 Brand layer.