ForgeQubit.
← Engineering Blog/Case Learnings/FQ-05

IntroducingOpenClawAnOpenFrameworkforOperationsEngineering

A declarative framework for building, running, and observing operational systems. Open source. Opinionated. Production-shaped.

/published12 Apr 2026
/read-time8 min read
/byForgequbit Engineering

After building operations systems for logistics operators, DTC brands, agencies and SaaS platforms, one pattern refuses to change: the five-layer architecture keeps reappearing. Triggers. Decisions. Execution. Data. Observability. Every serious operational system we've shipped shares those bones. So does every serious system we've audited from other teams.

We have built that spine, from scratch, more times than is reasonable. Today we're opening it up.

What OpenClaw is#

OpenClaw is a declarative DSL and a runtime. You write a system description in a `.claw` file — triggers, decisions, executions, data, observability — and OpenClaw compiles it into the concrete infrastructure that runs it.

/yamlblock
system: dispatch
version: 1.0.0

triggers:
  - order_created:
      source: webhook
      idempotency: order.id

decisions:
  - carrier_selection:
      inputs: [order, carrier_rates, sla_policy]
      policy: ./policies/carrier.policy.ts
      emits: booking.decision

execution:
  - book_carrier:
      on: booking.decision
      action: carrier.book
      retries: 3
      dead_letter: queue://ops.dlq

data:
  events:
    store: event-log
    retention: 365d

observability:
  slo:
    dispatch_latency_p95: 500ms
    error_rate: <0.5%
  alerts:
    - on: error_rate > 1%
      route: slack://ops-oncall

Under the hood, OpenClaw compiles that description into workers, queues, durable state machines, OpenTelemetry spans, and dashboards. It runs on top of components you already know — Temporal, NATS, Postgres, Grafana — and stays out of the way of anything you want to replace.

Design principles#

Declarative, not procedural
You describe the system you want; the runtime works out how to realise it. The same description runs in staging, production, and replay.
Five layers, always
Every system has triggers, decisions, executions, data, and observability. OpenClaw refuses to compile a system that's missing one. Gaps are the most common cause of production drift — we'd rather the framework argue about them up front.
Observability is primary
Every node emits structured events, metrics, and traces by default. You don't instrument OpenClaw. It instruments itself.
Replay-safe by construction
Idempotency keys, append-only event logs, and deterministic decision policies are part of the model. Backfills are a first-class operation, not a recovery hack.
Vendor-neutral
Carriers, CRMs, warehouses, and models plug in as adapters. Swapping one is a config change, not a refactor.

Who it's for#

OpenClaw is for engineering teams inside operations-heavy organisations — logistics, DTC, SaaS, services, agencies — who are tired of treating their automation layer as a second-class citizen. It is also for the systems engineers at firms like ours, who are building similar infrastructure for multiple clients and would rather collaborate on the spine than rebuild it each time.

If your operations infrastructure is a pile of Zaps, scheduled cron jobs, and spreadsheets, OpenClaw is not going to be a drop-in replacement. But it is a coherent migration target. We are building documentation and example systems specifically for that path.

Roadmap#

  1. 01Alpha: core runtime, trigger + decision + execution layers, Temporal backend, Postgres event log.
  2. 02Beta: full observability layer (OpenTelemetry + Grafana bundle), adapter SDK, replay and backfill tooling.
  3. 031.0: production hardening, multi-tenant deployment patterns, formal SLO contracts, policy-as-code library.
  4. 04Post-1.0: adapters for common carriers, CRMs, ERPs, AI providers. Visual inspector for running systems.

How to get involved#

OpenClaw is developing in the open. If you operate an operations-heavy business, we want real systems to test against. If you are an engineer who wants to contribute adapters, policies, or docs, the repository will publish contribution guidelines alongside the alpha release.

  • Follow the project from the Field Notes feed for design posts and release notes.
  • If you want early access to the alpha, reach out through the Contact page.
  • If you already have an operational system you'd like modelled in OpenClaw, an Operations Audit is the fastest way in.

Operations engineering has been a discipline without a spine for too long. OpenClaw is our attempt to give it one — shaped by production, opinionated about the parts that matter, and open enough that the next team doesn't have to build it from scratch.

/filed-underCase Learnings · FQ-05
All articles
/keep-reading

Adjacent articles.

FQ-01Systems Thinking

Why Most Automations Fail at Scale

Every operations team eventually hits the wall: the automations that worked at 200 events a day collapse at 20,000. The reason is almost never the tool. It is the absence of four engineering primitives.

9 min readRead
FQ-02Operations Architecture

The Hidden Architecture Behind High-Performing Ops Teams

From the outside, two ops teams processing the same volume look identical. From the inside, one is running a hidden five-layer architecture and the other is holding the pipeline together with humans. This is the difference.

11 min readRead
/next

If this described a problem you actually have, the fastest next step is an Operations Audit.