I have spent hundreds of hours, and thousands of dollars in tokens, working on creating custom agents using OpenClaw. Without being strategic in how you improve and customize the OpenClaw architecture, the agents you can create frankly suck.

Though frustrating, each rate limited, failing gateway, and agent failing at tasks have helped me iterate my approach and better understand the underlying architecture.

I wanted to share some of the things I have learned and the way I am approaching building agents moving forward. And unlike the tens of other OpenClaw guides out there, this wasn’t made by asking Claude to write a generic guide.

If you are trying to build agents, or just want to make informed decisions about it, and you don't know about:

The compaction problem — why your agent quietly becomes dumber the longer it works, and why the fix is architectural, not your prompts
Environmental cues shaping behavior — why naming a task "Research (10min)" makes an agent with a 1-hour timeout give up after 8 minutes
How to setup a inter-agent communication — when to Use sessions_send vs one-shot isolated crons for task dispatch

Keep reading. It will save you time, money, and put you ahead of 99% of people making AI agents.

Part 1: What Even is An Agent?

What everyone into AI is talking about right now is agents. Most of us aren't taking the time to clearly define what an agent is.
Without this, how can you be sure that what you are building exhibits agency, and it is not just another automation or chatbot that people have promised would completely change your industry but hasn't?

While it certainly can be many things, including a marketing buzz word that tech companies are slapping on anything related to AI, I wanted to think through a more concrete way to define agents.

The approach I chose starts not with defining what an agent is, rather trying to define the trait that could make anything an agent: agency.

I began thinking in the human domain, what traits does a human display that would lead us to label them high agency?

After a quick, and unfruitful, exploration into the world of philosophers, I turned away from the metaphysical arguments (Some believe we humans don't have agency).

Instead, I turned to trying to breakdown functional agency.

The Four Components of Functional Agency

Agency is the combination of Four things:

• Perception —Understanding the context without being told what to look for.

• Deliberation — Evaluating options and reasoning about what to do next.

• Capacity to act — Access to tools and authority to manipulate the world.

• Proactiveness — Owning outcomes and completing assigned tasks without human input.
Proactiveness is the strongest signal of functional agency, and it is what we want to build our agents around.

I don't claim this framework to be absolute or all in compassing, but it has guided my view on how to build agents.

How Does the Same AI Model Suddenly Become an Agent?

AI Models (think ChatGPT, Sonnet, Opus, Gemini) already have the ability perceive and deliberate, albeit to different degrees.

What's new is building an architecture around the model that extends these capacities and gives it the ability to manipulate the world and most importantly take initiative.

This guide is about how to build that architecture.

Part 2: The Machine You Are Tuning

Before diving into architecture tips, you need a mental model of how OpenClaw works.
If you already feel you mastered how OpenClaw works, skip to Part III.

Otherwise, I recommend opening up the OpenClaw folder (which contains its source code) into an AI IDE such as Cursor and using a model to explore the code base.

OpenClaw is an open-source software that lets you create and run AI. A gateway process manages everything, agents operate inside sessions that keep their context fresh, crons and heartbeats wake them up on schedules you define, and skills define procedures that the model should follow.

In plain English, It's a program that runs on your computer and lets you build AI agents that wake up on their own, follow detailed instructions, and work through tasks independently — without you having to prompt them every time.

The Gateway

OpenClaw runs as a background process on your computer called the Gateway. Think of it as the operating system for your AI agents. It manages all sessions, scheduling, browser automation, messaging channels, and tool execution. You can view your gateway in a browser, which is a great way to see how your files and agents are configured on your browser.

Agents and Workspaces

An agent is a persistent identity.

It has an ID, a workspace directory with files that defines who it is and how it behaves, a model assignment, and optionally a heartbeat schedule.

When the Gateway starts a session for an agent, it reads certain files in workspace and injects them into the agent's context.

The key files in the workspace are:

Every time the agent is about to respond, OpenClaw injects all of these workspace files + the conversation history so far and sends that along with your prompt to the AI model.

Every word in these files consumes tokens. Only essential operating rules belong here.

There are other files that live in the workspace but are not injected into the context window, rather made available to the agent who will decide to read the file if it believes it is pertinent:

Multiple agents can share the same workspace.

There is a system configuration file in the config directory that the openclaw onboard wizard generates — typically stored at ~/.openclaw/config.json which define your agents, model providers, channels, and gateway settings.

Multi-Agent Architecture

OpenClaw supports creating multi-agent systems through

Creating Different Full Agents
Setting up Inter-agent Communication
Allowing full agents to spawn temporary sub-agents.

Full Agents

Full agents are permanent entities defined in the system configuration file. Each has its own workspace, identity, memory, and skills. Agents are like employees on they persist across system restarts and maintain long-term knowledge. You can select which AI model you want each agent to default to, and you can use Agents.md to ask the model to switch to higher or lower performance models depending on the difficulty of the task in order to save on token consumption.

Inter-Agent Communication

There are three mechanisms for inter-agent communication, and each has different implications:

sessions_send sends a message to another agent's main session. Good for conversation and quick questions.
One-shot isolated crons create a fresh session for the target agent with a specific task. Good for delegating work.
Subagents (sessions_spawn) create temporary workers within a session, up to 8 concurrent. Good for parallelism within a single task.

The tradeoffs between these mechanisms have major consequences for agent reliability. You can instruct agents to use these explecitly it in AGENTS.md or in a skill. Ex: "When you finish analyzing an item, send a summary to the coordinator agent using sessions_send."

Part 3 will cover exactly when to use each one and why.

Sub-Agents

As mentioned, any full agent can spawn temporary sub-agents for short-lived tasks using the sessions_spawn tool.

Sub-agents are disposable workers that:

Receive reduced instructions (only AGENTS.md and TOOLS.md from parent)
Have restricted tool access (no coordination, no scheduling)
Auto-delete after approximately 60 minutes

Sessions: The Core Concept

A session is a conversation with an agent. There are two types, and understanding the difference between them is one of the most important thing for building reliable agents.

Main session is a persistent, long-running conversation. Every DM you send, every heartbeat, every message from another agent appends to the same growing thread. The agent has full history. This is good for coordination and short interactions.

Each agent has its own main session.

Isolated session is a fresh, disposable conversation. Zero prior history. The agent reads its workspace files fresh from disk, processes one unit of work, and the session ends

. The only way to create an isolated session is via a cron job with sessionTarget set to "isolated."

Why two types matter will become very clear in Part 3.

Compaction: Why Sessions Degrade

Every model has a fixed context window (maximum amount of information—measured in tokens (words/parts of words)—a model can process). As a session accumulates messages, tool calls, browser screenshots, and data, it fills up. When the model is close to max in its context, OpenClaw triggers compaction which prompts the model to summarize older messages and discard everything else.

The summary captures what happened but not how and you risk the agent not including important information in its summarization. After two or three compactions, it is working from a summary of a summary of a summary.

Skills: On-Demand Expertise

Skills are instruction manuals stored as Markdown files. The agent sees a short summary (about 100 words) of each skill at all times, just enough to know it exists. Full instructions load only when the agent decides it needs them.

This matters because skills live on disk, not in the session. They are always available in their complete form whenever the agent loads them, regardless of what has happened in the session history.

OpenClaw currently provides 58 skills that you can install during the initial onboarding or through your gateway, some examples:

Skill Creator — a meta-skill that teaches the agent how to build new skills. When you ask your agent to create a skill for a new workflow, it loads this skill and follows a structured process for writing the SKILL.md, organizing reference files, and packaging everything correctly.

Coding Agent — lets your agent delegate programming tasks to a separate coding tool (like Codex or Claude Code) running in the background.

Notion — connects the agent to the Notion API so it can create, read, and update pages, databases, and blocks. Requires a Notion integration key.

Things (Mac) — integrates with the Things task manager on macOS, letting the agent create, update, and check off tasks in your personal to-do system.

BlueBubbles — connects the agent to iMessage, so it can send and receive iMessages on non-Apple platforms.

You should also be developing your own custom skills. Custom skills encode your specific procedures such as the exact formats, schemas, and step-by-step workflows that are unique to your use case.

Examples of custom skills someone might set up:

A data entry skill with exact spreadsheet column layouts, write syntax, and verification steps so the agent always writes data in the correct format

A research skill with step-by-step instructions for how to search specific databases, what to extract, and how to structure findings

Cron Jobs: How Agents Wake Up

A cron (short for "chronos," the Greek word for time) is a scheduler, a system that runs a task automatically at a specified time or on a repeating schedule. Crons have been a standard tool in computing for decades; if you've ever set a recurring calendar reminder, it's the same idea. You define when something should happen, and the system handles triggering it without you being there.

In OpenClaw, cron jobs are the fundamental scheduling mechanism. Cron jobs are how agents get triggered without human prompting. They can fire on a schedule (every 10 minutes, every morning at 8 AM) or as one-shot timers that fire once and self-destruct.

Cron jobs are also the mechanism for creating isolated sessions. When you set a cron to target an isolated session, the agent gets a completely fresh context every time it fires.

Heartbeats: Periodic Check-ins

Heartbeats are an OpenClaw concept. It's their name for a recurring cron that's attached directly to an agent and always goes to the main session.

The agent reads its HEARTBEAT.md checklist and handles everything in one pass: check status, review output, send reports.

The heartbeats are what create the illusion that your agent is alive.

Memory

OpenClaw implements a file-based memory system where agents write important information to disk and retrieve it in future sessions.

Daily Logs

Each day, the agent maintains a log file (memory/YYYY-MM-DD.md) where it appends notes throughout its work: decisions made, tasks completed, anomalies encountered, and follow-up items. By default, agents read today's and yesterday's logs at session start, providing continuity.

Long-Term Memory

MEMORY.md serves as a curated knowledge base for facts that persist across weeks and months. Agents promote important learnings from daily logs into this file.

For security, MEMORY.md loads only in private sessions (one-on-one conversations), not in group chats where other users might see sensitive information.

Memory Search

As memory files accumulate, loading entire files becomes inefficient. OpenClaw provides semantic search across all memory files—both daily logs and long-term storage.

Part 3: Architecture Principles

This is what you have been waiting for.
I forsee these principles will have to constantly evolve as the models and the OpenClaw architecture itself changes.

Each section maps back to the agency framework: giving agents the capacity to act, organizing context for better perception and deliberation, encouraging initiative, and creating quality control.

The 12 Principles at a Glance

1. Build in Cursor: Open your OpenClaw folder in Cursor to scaffold workspaces, generate commands, test agents, and even modify the source code.

2. Optimize the context window: Know which files are injected every turn and keep them lean. Move procedures to skills

3. One task, one session to avoid compaction: Never let work accumulate in the main session which will lead to compaction. Isolated sessions avoid this drift.

4. Don't pressure your agents: Task names, schedule expressions, and tone all shape behavior. Remove urgency cues the agent shouldn't see.

5. Integrate into your company's workflow: The source of truth is your existing systems, not the agent's memory. Agents read and write where your team already works.

6. Leverage the logs: Use session history, cron list, and doctor for debugging and pattern recognition.

7. Inter-agent communication: Use sessions_send for conversation, one-shot isolated crons for delegating standalone work, and sessions_spawn only for short-lived parallel subtasks inside a single active session.

8. Skills give your agents superpowers.

9. Build dedicated QC agents: Separate agents at execution cadence, not a line on a coordinator's checklist.

10. Match cadence to the work: Daily tasks get daily dispatch. Continuous backlog gets continuous crons. Event-driven gets upstream triggers.

11. Encourage autonomy explicitly: Agents that complete missions end-to-end need instructions that say so, and clear escalation criteria for when to stop.

12. Parallelize with command lanes: Set maxConcurrentRuns to match your agent count so cron-triggered work runs simultaneously, not sequentially.

1. Use Cursor to Build

One of the biggest accelerators for building agents and implementing the other principles I explain below is opening your OpenClaw workspace folder directly in Cursor.

Cursor's coding LLMs can build and improve the files that you would otherwise rely on your interaction with the main agent to build out

But it goes further than that. Cursor has direct access to your terminal, which means it can run OpenClaw CLI commands for you.

And because OpenClaw is open source, you can open the source code itself in Cursor and modify it. Need a custom tool? Want to change how a built-in skill works? Cursor can navigate the codebase, understand the patterns, and help you make changes directly.

2. Optimize the Context Window

Every piece of information your agent sees costs something. It occupies space in the context window, and that space is finite. The art of agent architecture is putting the right information at the right layer.

Mistakes I Made

I stuffed detailed procedures into AGENTS.md instead of skills. Every single turn, the agent was spending context budget on instructions it only needed for one specific task type.

I also did not know that AGENTS.md is silently truncated at roughly 20,000 characters. The agent was losing the bottom of its own instructions without either of us knowing it.

And I let agents read full memory files instead of searching. Memory search returns just the relevant snippets (about 700 characters each) without loading everything into context.

The Fix

Keep instruction files lean. Move procedures to skills. Use memory search. Treat context like money. Every token spent on background information is a token not available for the actual task.

3. Beware of Compaction and Use Isolated Sessions

As sessions grow (your agent is working or you are prompting it over and over), the model’s context window is filled and compactions occur.

As compaction occurs, drift occurs naturally: the agent starts a session with precise instructions (formats, schemas, command syntax), executes the first items correctly, then gradually loses procedural detail after compaction and begins improvising.

A common failure pattern:

· Early items are correct

· Session accumulates tool output and messages

· Compaction fires

· Exact procedural details are lost

· Agent invents a "reasonable" format that downstream systems cannot parse

· Errors compound across later items

This problem is compounded when you have agents nudging each other to act, all on the same main session, adding new turns that accelerate the compaction.

The Fix: One Task Per Isolated Session

Each session handles exactly one unit of work. The skill instructions, syntax, and column schemas are in context the entire time.

• Zero prior history. No stale data from previous tasks. No compacted summaries drifting the agent off course.

• Instructions read fresh from disk. Skills, workspace files, and memory are loaded exactly as written.

• Maximum context available for the current task. No prior tool output consuming context budget.

• Disposable. When the task is done, the session is done. No accumulated cruft.

When to use isolated sessions: Any task that takes more than about 45 minutes, involves many tool calls, requires exact syntax or procedures, or is one unit in a repeating series.

When to use main sessions: Lightweight coordination, short conversations with the user, monitoring and status checks. Work where accumulated context is an asset, not a liability.

How to create them:

· Use cron with --session isolated

· Be aware that sessions_send will always have the agent working on the main session

4. Avoid Pressuring your Agents

AI models absorb its environment and considers it all as part of its instructions. Everything the agent can see shapes how it behaves: the names of tasks, the tone of its instructions, timestamps, schedule expressions, even how other agents talk to it. This is powerful when you design for it deliberately. It's dangerous when it happens by accident.

I had an agent running on a recurring schedule, every 10 minutes a cron would fire, from 6 AM to 2:50 PM. Each session had a 1-hour timeout. Architecturally, the agent had plenty of time to do thorough work (up to an hour per task). But it behaved as if it had a strict 10-minute deadline.

To understand why the agents reasoning went against the architecture, you need to understand what a cron does. A recurring cron firing every 10 minutes doesn't mean "you have 10 minutes to finish." It means "every 10 minutes, try to start a new task." If the agent is still working when the next fire comes, that fire is simply skipped, it doesn't interrupt the running session, and it doesn't impose a deadline.

The 10-minute interval was just my way of scheduling multiple tasks throughout the day: fire frequently, and whenever the agent finishes one task, the next one picks up within minutes. Each individual task could take up to an hour.

But the agent didn't know any of that.

Two cues drove its behavior:

· The cron job name included "(10min)", which appeared in the agent's context at the start of every session. The agent read that as a time limit.

· The agent's instruction file mentioned the schedule window ("6 AM – 2:50 PM"). Near the end of the day, the agent reasoned: "crons end at 2:50, I need to finish NOW.”

When I audited the logs, I found the phrase "Given time constraints" repeated 12+ times in a single day. Every incomplete item had the same pattern: the agent started the work correctly, hit a minor obstacle, inferred urgency from the environmental cues, and abandoned the task. In one case, the agent had found the exact information it needed but decided it was running out of time and moved on.

The Fix

You can't solve this by adding "don't rush" to the instructions (though that helps). You have to remove the pressure signals from the agent's visible context:

· Removed all schedule expressions and time windows from AGENTS.md

· Removed "(10min)" from all cron job names

• Added: "You have plenty of time to do thorough research. Do not rush. Do not cut corners or skip steps due to perceived time constraints." To AGENTS.md instructions.

Kept the actual scheduling infrastructure unchanged — just hid it from the agent

The broader principle: Everything the agent can see (file names, task names, timestamps, schedule expressions, even the tone of instructions) shapes its behavior.

5. Integrate Agents Into Your Company’s Workflow

The source of truth should be your company's existing systems, not the agent's memory. If you want agents to improve the productivity of your organization, it needs to be embedded into your team. That is the principle I am applying when I am building custom agents for others.

Agents should execute on the same documents your team already uses: spreadsheets, internal docs, tickets, databases, and workflows.

What This Means in Practice

• Use company systems (such as google sheets, docs, internal databases) as the place where work is stored. Have agents directly read and write here.

• What we have began doing internally is integrating our agents into Clickup – the agent is instructed to use the Clickup API to store and organize his work directly into tasks. And this enables some interesting collaboration between our agents and human employees as they can tag each other.

• Require read after write verification

Store in the agent workspace (AGENTS.MD or as a skill):

· Which sheet(s) the agent is authorized to operate on

· Which tab(s) it should use

· The schema for each tab (columns, allowed values, required fields)

· Quality checks before marking work complete

o Even better, I have separate agents with their own workspace and instruction files which go through the output and work of other agents and communicate with the other agent if there are errors (more on inter-agent communication and my quality control agents can be found later in the guide)

6. Leverage the Logs

OpenClaw provides great auditing mechanisms that most people never use:

• Openclaw sessions history: Review what an agent did in previous sessions

• Openclaw cron list: Check which crons are running, last status, next fire time

• Openclaw doctor: surfaces misconfigurations, risky policies, stale state. Run this frequently!

7. Inter-Agent Communication

After people first setup Openclaw, I have seen them get too excited and begin creating different agents.

How agents talk to each other is one of the most consequential architecture decisions, and most people get it wrong.

If you don’t understand the 3 different ways that an agent can communicate with another agent, go back to page 5 of this guide.

Practical Rule:

Use sessions_send for conversation, one-shot isolated crons for delegating standalone work, and sessions_spawn only for short-lived parallel subtasks inside a single active session.

If the work is a self-contained task, use an isolated cron; if it's a quick helper step inside your current task, use spawn.

Avoid setting up one agent to use session send to constantly check up on or nudge another agent. Each of these nudges is added to the worker’s main session and crowds out the context of the agent.

8. Giving Your Agents Superpowers: Skills That Actually Work

Building strong skills are what allows you to expand what your agent can do past the constraints of the chat interface. A skill is just a folder with a SKILL.md file containing step-by-step instructions on how your agent should achieve a specific task.

What Goes in a Skill

• Exact CLI command syntax and templates

• Data schemas (column layouts, field types, write formats)

• Step-by-step procedures with specific tool calls

• Domain-specific decision criteria

• Reference documents (loaded only when the skill instructions say to)

• APIs or sites you want the agent to explicitly use

Skill Sizing Tips

• The agent sees a roughly 100-word summary of each skill at all times. Full instructions load on demand.

• Each eligible skill adds about 24 tokens of overhead to the system prompt just from being listed.

• Use {baseDir} in skill instructions to reference scripts and data files stored alongside the SKILL.md.

• Workspace skills override managed skills, which override bundled skills. You can patch any bundled skill by placing your version in the workspace.

Why Skills Matter Architecturally

Skills are the mechanism that defeats compaction. Because sessions read skills fresh from disk when they are needed a smart model will invoke the skill each time it wants to perform the related action.

Skill Patterns From Our Architecture

For our real estate company, our agents have specific skills that instruct them how to properly perform:

1. Regulatory research:

· Find county ordinance text (Municode/site/PDF fallback chain)

· Use OCR when text is image-only

· Extract required fields in a fixed structure

· Write to spreadsheet with exact column mapping

· If source unavailable after retries, escalate (including contacting county if required by workflow)

2. Land Comping:

· Screen listings and run physical/regulatory viability checks

· Use FEMA API for flood zones

· Use county GIS for zoning/frontage constraints

· Classify only No Go / Go at this stage

· Dispatch downstream comp analysis only for Go

3. Land Comps Analysis

· Perform comp selection and valuation logic

· Apply standardized economics model

· Output in a fixed report template

· Classify into deal categories based on defined thresholds

4. Land Verification:

· Query FEMA NFHL + USFWS NWI

· Normalize geospatial output to required fields

· Return deterministic pass/fail criteria to upstream workflow

This separation is intentional: each skill encodes one domain deeply, and each agent invokes only the relevant procedure for its task.

9. Create Redundancy: Quality Control (QC) Agents

Although the new models are mindblowing, agents like humans still make mistakes. You want to build quality control into your architecture and a good way to do that is to have dedicated full agents whose only job running at execution cadence with a specific checklist of quality control.

The QC Pattern

QA Agent (isolated sessions, recurring cron at execution cadence)

> Read shared state (spreadsheet, database)

> Check data quality rules (exhaustive, specific checklist)

> Simple fixes: dispatch one-shot retry cron to worker

> Complex issues: alert human via messaging channel

Three Rules for QC Agents

• QC detects and dispatches, it never fixes directly. QA does not have the worker's tools, skills, or context. It finds the problem, describes it precisely, and creates a retry cron for a worker who can fix it.

• QC runs at execution cadence. If workers produce 10 items per day, QA reviews 10 items per day. A 30-minute heartbeat check is insufficient.

• QC reads the data store, not session histories. The data store is what actually happened. Agent self-reports come from possibly-compacted memory.

What Our Quality Control Agent Checks

• Field misalignment: did the write put data in the wrong columns?

• Data completeness: are all required fields filled? No placeholders?

• Classification validity: are status values exactly from the allowed set?

• Duplicate records

• Reference integrity: do linked URLs and documents exist?

10. Match Cadence to the Work

Not all work is the same, and the scheduling architecture should reflect that.

Daily cadence is for work that depends on external timing. Only a certain number of new land is listed everyday. A coordinator dispatches at a fixed time, workers execute in parallel, the system idles until tomorrow.

Continuous cadence is for work where the backlog is static and every idle hour is wasted. The agent reads shared state, picks the next unclaimed item, and works it.

Event-driven cadence is for work triggered by upstream output. When one agent marks a property as "Go," it dispatches a one-shot cron for the next agent with instructions. The downstream agent gets a fresh session with full context.

11. Encourage Autonomy Explicitly

The difference between an agent that asks "Should I proceed?" at every step and one that completes a full task end-to-end is primarily how its instructions are written.

Autonomy must be woven into the agent's identity:

• Instructions that emphasize independent decision-making. "You are an autonomous operator. Complete your work end-to-end without asking for permission at each step."

• Clear escalation criteria. Do not leave the agent guessing. "Escalate only when: (a) the data source is completely unavailable after 3 retries, (b) the regulations are genuinely ambiguous, (c) you discover a systemic issue affecting multiple items."

• The expectation of end-to-end completion. "Each session, you will research one county from start to finish. There is no partial credit."

12. Parallelization- How I Enabled Multiple Scheduled Agents To Work Simultaneously

Out of the box, OpenClaw defaults to running agents that are scheduled through chrons one at a time.

There's a config setting called maxConcurrentRuns (under the cron section of your openclaw.json config file) that controls how many cron jobs can execute simultaneously when multiple schedules fire at the same time. By default, this is effectively 1 — meaning if three agents all have crons due at the same moment, they run one after the other.

The change I made was setting maxConcurrentRuns to a higher number — matching the number of agents I wanted running in parallel.

With this set to 4, when the Gateway's timer ticks and finds four due jobs (one for each worker agent), it fires all four simultaneously instead of queuing them.

Each agent runs in its own execution lane. Within a single agent's lane, jobs still serialize (an agent won't start a second session while its first is still running), but across agents, everything runs in parallel.

Other Tips for Ongoing Development

• Build and iterate quickly. You can spend hours optimizing a setup only to realize the next day it does not work. Ship something, observe, adjust.

• Run openclaw doctor frequently. Especially after config changes and updates.

• Update regularly with openclaw update --channel stable (or beta for latest features).

• Have Cursor generates terminal commands. Instead of hand-typing long cron commands, ask Cursor to create them. It handles the escaping, quoting, and flag syntax.

Part 4: Architecture Patterns in Practice

The principles in Part 3 can be combined with reusable patterns that guides the architecture of how agents and groups of agents can complete tasks.

Each of these patterns I have used in my companies, and they are different approaches to answer the same architectural questions: who decides what work gets done, and when?

A coordinator agent decides (Pattern 1). The agents themselves decide (Pattern 2). The upstream output decides (Pattern 3).

Pattern 1: Coordinator + Worker Pool

When to use: Work list is known upfront, depends on external timing, and task count is bounded.

Pattern 2: Self-Driving Agents

Agents pick their own work from shared state. No coordinator in the throughput path.

When to use: Static backlog, no external timing dependency, every idle hour is wasted.

Pattern 3: Event-Driven Pipeline

One agent's output triggers another agent's work.

When to use: Downstream work depends on upstream decisions. Agent A handles screening. Agent B handles analysis. Neither sees the other's domain, preventing cross-contamination.

This guide will continue to evolve as OpenClaw evolves and as I discover new patterns. The architecture is an iterative process.

Model behavior changes as models change, bringing new challenges and new possibilities.

SINGULARITY