How OpenClaw and Donna solve the same problem with different architectures — and why the design decisions matter.
Every platform you use — Gmail, Salesforce, Instagram, Slack — holds a fragment of who you are. Your communication patterns, your business relationships, your interests, your decisions. No single platform has the complete picture. Only you do.
A user-first system assembles that complete picture. It connects to your platforms, pulls your data into a unified graph, and runs on infrastructure you control. No platform can build this for you — each one only sees its own slice. The only entity that can unify everything is the user.
In the context of AI, this unified graph unlocks two things. First, maximum leverage: a language model with your complete context produces dramatically better output than one with a fragment. Same model, full picture, different results. Second, coherence: when dozens of autonomous processes share a real identity anchor — who you are, what you value, what you’re working toward — they produce output that feels like one system, not fifty disconnected automations.
Manufacturing that coherence is hard. Anchoring to a real identity is structurally simpler and more durable. People detect inauthenticity quickly, whether it comes from a person or a system. A system grounded in real identity, real goals, and real accumulated experience doesn’t have to manufacture consistency. It inherits it.
For twenty years, software worked the other way around — you went to the platform, your data lived on their servers, your workflows ran on their terms. A new pattern inverts this: the software orbits you. The platforms become peripherals that your system connects to, reads from, and writes to. OpenClaw and Donna are two early examples of what this looks like.
Platform-Centric Systems
You're inside their walls. You power their system.
User-First Systems
They power your system.
How Donna Works
How OpenClaw Works
Key Concepts
Identity
The hierarchy that governs everything. Three layers: who the system is, what it's focused on (goals), and the rules for each area (domains). Queried live before every action.
Protocol
A set of step-by-step instructions stored as a JSON file. "Do this first, then this, then this." Like a recipe for the system — readable, portable, composable.
Primitive
A basic verb — the type of action, not the specific action. "Call an API," "query a database," "ask the AI to reason," "validate data." Specific actions like "send a Gmail" or "post a tweet" run through these primitives.
Domain
A layer in the identity hierarchy. Each domain — social media, client management, market research — has its own rules. The system knows what it can and can't do within each.
Registry
The approved list of specific API operations — "send a Gmail," "post a tweet," "query a CRM." Each operation runs through a primitive. If it's not registered, the system can't call it.
Trigger
What kicks off a protocol. A schedule ("every morning at 7am"), an event ("a meeting just ended"), or a manual request.
The Feedback Loop
Every autonomous process follows two interlocking cycles. This is what makes the system compound over time.
Identity Hierarchy
I
Identity
Who the system is. Values, voice, principles.
↓ grounds
G
Goals
What it's working toward. Objectives, priorities.
↓ drives
A
Actions
Protocols grouped by domain, each with its own rules.
↓ produces
L
Learnings
What happened, what worked, validated against identity.
↓ feeds back to
I
Identity
The system becomes what it learns.
Execution Cycle
OBSERVE
Scan external sources for raw signals — APIs, web, social platforms
↓
REFLECT
Score observations against identity, capabilities, and domain rules
Take action informed by accumulated learnings — engage, post, draft, notify
← cycle repeats with compounded knowledge
Reflect feeds quality scores back to Observe — source queries improve over time. Each cycle is better than the last because the Learn stage compounds.
Core Design Principles
Three principles that govern every architectural decision.
Self-Exposing
The system teaches you how to use it. Every component publishes its own interface — available primitives, schemas, composition rules, trust constraints. Any LLM or new user can operate the system without external documentation. The system IS its documentation.
Configuration Over Code
Instance-specific values live in configuration, never in logic. A protocol's steps describe what to do generically. Vars and registry entries describe who and where for a specific user. This is what makes any protocol portable to another user without rewriting it.
Pattern Over Instance
When you encounter a problem, solve the class of problems it belongs to. Don't build a one-off integration — build composable primitives that work for any data source. Six primitives handle 90% of all work across 50 live protocols. The abstraction pays for itself immediately.
Key Design Decisions
Six choices that shape how the system behaves when no one is watching.
Why This Matters
Try the runtime
Donna Runtime is in private beta. Drop your email and we'll reach out when it's your turn.