Agent Control Loops: From OpenClaw to Alternative Architectures

How OpenClaw works today

OpenClaw (formerly Clawdbot/Moltbot) is a self-hosted, open-source personal AI agent created by Peter Steinberger. It runs as a long-lived Node.js process (the Gateway) on your own hardware and connects to messaging channels (WhatsApp, Telegram, Slack, Discord, iMessage, etc.) on one side and an LLM provider (Claude, GPT-4, DeepSeek, or a local model via Ollama) on the other.

The core execution engine is a single-model agentic loop. OpenClaw wraps the Pi agent core library (@mariozechner/pi-agent-core) and communicates with it via RPC. The architecture places all decision authority—reasoning, action selection, and stopping—inside one model invocation per turn. Tools execute opportunistically, and the model sees their results in the next iteration.

The agentic loop

OpenClaw’s loop follows a fixed pipeline for every inbound message:

In more detail:

1. A channel adapter normalizes the inbound message (from Discord, WhatsApp, etc.) into a unified format.
2. The Gateway assigns the message to a session and places it in a lane queue. Lanes default to serial execution per session, which prevents race conditions on shared state. Parallel execution is opt-in for explicitly marked low-risk tasks.
3. The agent runner selects the model, assembles the prompt (user message + tool schemas + session history + memory), and manages the context window.
4. The model emits either a tool-call proposal or a final user-facing response.
5. If a tool call is proposed, the tool runtime executes it (file I/O, shell commands, browser control, etc.) and appends the result back into context.
6. The loop repeats until the model emits a final response or a hard limit is hit (default timeout: 600 seconds).
7. Session state and JSONL transcripts are persisted.

Memory and state

OpenClaw avoids complex memory architectures. It uses three complementary systems:

• JSONL transcripts — a line-by-line audit log of every user message, tool call, and execution result. This is the factual record of what happened.
• Markdown memory (MEMORY.md) — a curated file of summaries, preferences, and distilled knowledge. The model reads this on every turn and can write to it.
• SOUL.md — defines the agent’s personality and communication style. The model can also modify this file, enabling a form of self-improvement over time.

For retrieval, OpenClaw combines vector search (broad semantic recall) with SQLite FTS5 keyword matching (precision). This hybrid approach reduces the “semantic noise” problem where vector search retrieves similar-looking but irrelevant information.

When the context window approaches its limit, OpenClaw triggers auto-compaction: it summarizes older messages and prunes them while preserving critical context.

What this architecture gets right

• Simplicity. One model, one loop, serialized execution. Easy to reason about and debug.
• Lane queues. Serial-by-default execution prevents the concurrency bugs that plague other agent frameworks.
• File-based memory. Human-auditable, version-controllable, portable between setups.
• Hybrid retrieval. Combining vector and keyword search produces better recall than either alone.

What this architecture lacks

• Stopping is implicit. The model decides when a task is done. There is no external verifier, no postcondition check, no formal completion criterion. If the model hallucinates success, nothing catches it.
• Goals are not represented as objects. The system has no data structure for “what the user wants.” The goal lives only in the model’s context window as natural language.
• Verification is absent. The same model that acts also judges whether its actions succeeded. This is the classic marker-grader conflation problem.
• Error recovery is heuristic. If a tool call fails, the model sees the error text and tries something else. There is no structured retry policy, no escalation path, no circuit breaker.

These gaps are acceptable for a personal assistant doing low-to-medium-stakes tasks (email triage, file management, web lookups). They become dangerous for high-stakes automation (financial transactions, system administration, anything with irreversible side effects).

Security considerations

OpenClaw’s power comes from broad system access: it can read/write files, run shell commands, and control browsers. Cisco’s AI security team tested a third-party OpenClaw skill and found it performed data exfiltration and prompt injection without user awareness. CrowdStrike has published detection guidance for OpenClaw deployments on enterprise networks. The skill ecosystem currently lacks adequate vetting for malicious submissions.

A gallery of agent control-loop architectures

The architectures below represent distinct design choices about where decision authority lives. Each answers the question: who decides what to do next, and who decides when to stop?

The key design variable is the locus of control—whether it sits in the model, in code, or is split between them.

A1. ReAct loop — single model owns everything

ReAct’s core contribution is interleaving explicit reasoning traces (Thought) with actions (Act) and observations (Obs) in a single model’s output. This distinguishes it from plain tool-calling loops, where the model emits tool calls without articulating its reasoning.

The Thought trace is what makes ReAct interesting: it forces the model to verbalize its plan, track subgoal completion, and handle exceptions in natural language. This makes the agent’s decision process inspectable (you can read the Thought steps) at the cost of consuming extra tokens.

When to use it: ad-hoc assistants, research prototypes, single-session data tasks, interactive debugging. Anywhere the stakes are low and you want maximum flexibility with minimum engineering.

Why it works for these cases: you need tool access, you don’t need persistent state, and you can tolerate occasional failure. The model’s built-in world knowledge handles most of the planning.

Failure modes: The model can loop silently (repeating the same failed action), stop prematurely (declaring success without verifying), or hallucinate observations. There is no external check on any of these.

A2. Planner–executor loop — two models, role-separated

One model (the Planner) produces an abstract plan as a sequence of steps. A second model (the Executor) carries out each step by making tool calls. The Planner never touches tools directly. The Executor never decides what to do next at a high level.

When to use it: multi-step task automation, document workflows, API orchestration, research pipelines. Cases where you want a stable plan that survives tool-level hiccups.

Why it works for these cases: separating planning from execution means you can swap executors (or use a cheaper, faster model for execution) without destabilizing the plan. You can also inspect and approve the plan before execution begins.

Failure modes: Bad plans (the Planner misunderstands the task or produces an infeasible sequence). Executor drift (the Executor interprets a step differently than the Planner intended). Replanning overhead (if the Planner must revise after every step, you lose the cost advantage of using a cheaper Executor).

Key design question: How much authority does the Executor have to deviate from the plan? Strict adherence makes the system predictable but brittle. Loose adherence makes it adaptive but harder to audit.

A3. Controller-driven loop — code owns decisions, models propose

This architecture moves the locus of control from the model into deterministic code. The model proposes actions, but a code-based controller decides whether to execute them, tracks state explicitly, and determines when the task is complete.

When to use it: safety-critical automation, financial operations, compliance-heavy systems, any domain where you need deterministic stopping conditions and an audit trail.

Why it works for these cases: the controller enforces invariants that the model cannot violate. The model’s role is reduced to “suggest what to do next”—it does not decide whether to do it or whether the task is done.

Failure modes: Controller bugs. If the controller’s state machine or verification logic is wrong, the system will fail deterministically and confidently. You’ve traded model uncertainty for code correctness requirements. This is usually a good trade for high-stakes systems, but it requires real engineering investment in the controller.

Key design question: How much of the task logic should live in the controller vs. the model? Too much in the controller and you’ve built a traditional workflow engine that happens to use an LLM for text generation. Too little and you’re back to a ReAct loop with extra steps.

A4. Workflow / DAG-based loop — model authors the graph, code runs it

The model’s role is pushed even further from execution: it authors a directed acyclic graph (DAG) of steps, and a deterministic executor runs the graph. The model may also fill in parameters for individual nodes, but it does not control execution order or stopping.

When to use it: data pipelines, ETL, CI/CD, document processing, robotic process automation. Any task that is repetitive, well-structured, and benefits from checkpointing and partial re-execution.

Why it works for these cases: the DAG makes dependencies explicit, enables parallel execution of independent branches, supports checkpointing, and provides clear progress tracking.

Failure modes: DAG design errors (the model produces a graph with missing dependencies or impossible nodes). Rigid structure (if the task requires dynamic replanning mid-execution, a DAG is the wrong abstraction). Over-engineering (for simple sequential tasks, a DAG adds complexity without benefit).

Comparison

Proactive agent architecture

Every architecture above is reactive: the user sends a message, and the agent responds. A proactive agent inverts this. It monitors external context continuously and surfaces candidate intents—things the user might want to do—without being asked.

The core design principle

A proactive agent should surface intents, not execute actions. It observes state, generates suggestions, and requires explicit human approval before anything happens. It must never plan, call tools, or execute on its own.

This separation is critical for trust. If a proactive agent can act autonomously, it becomes an unsupervised automation system with access to your calendar, email, and files. The human approval gate is what makes it a useful assistant rather than a liability.

Related work

• Lu et al., “Proactive Agent,” ICLR 2025 (arXiv:2410.12361) — data-driven approach to training proactive agents. Builds ProactiveBench (6,790 events) and trains a reward model to evaluate suggestion quality. Their fine-tuned model achieves 66.47% F1 on proactive assistance. Key insight: proactive behavior can be trained with human preference data.
• Gao et al., “Proactive Conversational Agents with Inner Thoughts,” 2025 (arXiv:2501.00383) — the agent maintains a continuous, parallel stream of internal thoughts and autonomously decides when to contribute. Five stages: trigger → retrieval → thought formation → evaluation → participation. Inspired by SOAR and ACT-R.
• Google Research, “Sensible Agent,” UIST 2025 — proactive AR agents that model not just what to suggest but how and when to deliver the suggestion, using gaze, gesture, and environmental noise.
• OpenClaw’s cron system supports a basic form of proactivity (scheduled tasks at defined intervals), but this is timer-triggered automation, not context-aware intent prediction.

The suggestion spam problem

The hardest design challenge for proactive agents is salience filtering: deciding which suggestions are worth surfacing and when. A proactive agent that suggests too often trains users to ignore it. One that suggests too rarely provides no value.

Lu et al.’s reward model approach is promising: train a classifier on human accept/reject decisions to predict whether a suggestion will be welcomed. Their reward model achieved 0.918 F1 on a test set, suggesting that salience prediction is tractable.

Other mitigation strategies:

• Frequency caps. Limit suggestions to N per hour/day.
• Confidence thresholds. Only surface suggestions above a model confidence score.
• User feedback loops. Track accept/dismiss rates and adjust thresholds over time.
• Context-aware timing. Don’t suggest during meetings, late at night, or when the user is visibly busy (the Sensible Agent approach).

Further reading

• Yao et al., 2023. “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023. arXiv:2210.03629
• Sumers et al., 2023. “Cognitive Architectures for Language Agents.” arXiv:2309.02427
• Lu et al., 2024. “Proactive Agent: Shifting LLM Agents from Reactive Responses to Active Assistance.” ICLR 2025. arXiv:2410.12361
• Gao et al., 2025. “Proactive Conversational Agents with Inner Thoughts.” arXiv:2501.00383
• Shen et al., 2023. “HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face.” NeurIPS 2023. arXiv:2303.17580
• Huang et al., 2022. “Inner Monologue: Embodied Reasoning through Planning with Language Models.” arXiv:2207.05608
• Park et al., 2023. “Generative Agents: Interactive Simulacra of Human Behavior.” UIST 2023. arXiv:2304.03442
• Shinn et al., 2023. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366
• OpenClaw Architecture Docs: docs.openclaw.ai/concepts/agent-loop
• Cisco AI Security Blog: “Personal AI Agents like OpenClaw Are a Security Nightmare”