ConfigurationOpenClawMarch 15, 2026·14 min read

OpenClaw AGENTS.md Guide: Configure Your Agent Team (2026)

AGENTS.md is the team-level configuration file that tells your OpenClaw agents how to work together. This guide covers every section of AGENTS.md, explains how it differs from SOUL.md, provides three complete production-ready templates, and shows you exactly when to use AGENTS.md versus config set.

What Is AGENTS.md and How Does It Differ from SOUL.md?

OpenClaw uses two configuration files that serve fundamentally different purposes. Understanding the boundary between them is the first step toward building reliable multi-agent teams.

SOUL.md defines who the agent is. It is the identity file. It lives inside each agent's directory and contains the agent's role, personality, rules, tools, and handoff instructions. Every agent has its own SOUL.md. Think of it as a job description written for one specific hire.

AGENTS.md defines how the team operates. It is the operational playbook. It lives at the workspace root and is read by every agent on startup. AGENTS.md contains workspace rules, communication protocols, tool access policies, handoff definitions, memory rules, and scheduling behavior. Think of it as the employee handbook that applies to the entire organization.

SOUL.md (Identity)

  • One per agent
  • Agent name and role
  • Personality and tone
  • Individual rules
  • Tool trigger conditions
  • Personal handoff instructions

AGENTS.md (Operations)

  • One per workspace
  • Team roster and responsibilities
  • Communication rules
  • Shared workspace paths
  • Cross-agent tool access
  • Team-wide handoff definitions

The key insight: SOUL.md instructions are scoped to one agent. AGENTS.md instructions are inherited by all agents. If you put a rule in AGENTS.md, every agent in your workspace follows it. If you put it in SOUL.md, only that specific agent follows it.

Where to Place AGENTS.md

AGENTS.md lives at the workspace root. In a standard OpenClaw setup, that means it sits directly inside the agents directory, alongside the individual agent folders:

File placement
~/.openclaw/
└── agents/
    ├── AGENTS.md              # Team config (read by ALL agents)
    ├── orion/
    │   ├── SOUL.md            # Orion's identity
    │   └── MEMORY.md          # Orion's persistent context
    ├── echo/
    │   ├── SOUL.md            # Echo's identity
    │   └── MEMORY.md          # Echo's persistent context
    └── radar/
        ├── SOUL.md            # Radar's identity
        ├── HEARTBEAT.md       # Radar's scheduled tasks
        └── MEMORY.md          # Radar's persistent context

When OpenClaw starts, it reads AGENTS.md first to understand the team structure and shared rules. Then it loads each agent's individual SOUL.md. The agent's final context is the combination of both files: team rules from AGENTS.md plus individual identity from SOUL.md.

If you are running a single agent without a team, AGENTS.md is optional. You only need SOUL.md. But even solo agents benefit from AGENTS.md when you want to define workspace paths, memory rules, or scheduling behavior that lives outside the agent's identity.

The Complete AGENTS.md Template

A well-structured AGENTS.md contains six sections. Each section addresses a specific aspect of team coordination. Here is the full template with explanations:

## Workspace Rules

Define file paths, project directories, output locations, and memory file locations. This tells every agent where things live. Without this, agents guess at paths and create files in inconsistent locations.

## Communication Rules

Define when agents should speak, how they reference each other with @mentions, which channels they use, and when they should stay silent. This prevents noise and ensures agents only communicate when they have something actionable to say.

## Tool Access

Define which tools each agent can use. Not every agent needs every tool. An SEO analyst needs Search Console access but does not need deployment tools. Restricting tool access prevents agents from overstepping their scope.

## Handoff Rules

Define the exact conditions under which one agent passes work to another. Handoff rules are the connective tissue of a multi-agent team. Without them, agents either duplicate work or drop tasks between handoffs.

## Memory Rules

Define what agents should persist between sessions, where they write it, and what format to use. Without memory rules, agents either forget everything or write unstructured notes that are useless on the next session.

## Scheduling Rules

Define recurring tasks and their cadence. This works in conjunction with HEARTBEAT.md but at the team level. It establishes which agents run on schedules and how their outputs feed into other agents' workflows.

AGENTS.md - Base Template
# AGENTS

## Team
- @[AgentOne]: [Role description]
- @[AgentTwo]: [Role description]
- @[AgentThree]: [Role description]

## Workspace Rules
- Project root: [/path/to/project]
- Output directory: [/path/to/output]
- Memory files: [/path/to/memory/]
- Logs: [/path/to/logs/]
- ALWAYS use absolute paths
- NEVER write outside the project root

## Communication Rules
- Use @mentions to address specific agents
- ONLY speak when you have actionable output
- Do NOT repeat information another agent has
  already delivered
- Report format: bullet points, data first,
  commentary second
- Primary channel: [Slack / Telegram / terminal]

## Tool Access
- @[AgentOne]: Search, Browser, Slack
- @[AgentTwo]: CMS API, Slack, File System
- @[AgentThree]: Analytics API, Search Console, Slack
- All agents: File System (read only for shared docs)

## Handoff Rules
- WHEN @[AgentOne] completes [task], hand off to
  @[AgentTwo] with [required context]
- WHEN @[AgentTwo] completes [task], hand off to
  @[AgentThree] for [next step]
- WHEN any agent is blocked for more than [time],
  escalate to @[AgentOne]

## Memory Rules
- ALWAYS write important findings to MEMORY.md
  immediately. Do NOT wait until end of session.
- Format: markdown with dated headers
- Each agent writes to its own MEMORY.md
- Shared facts go in [/path/to/shared/MEMORY.md]

## Scheduling Rules
- @[AgentOne]: Daily standup at 9:00 AM
- @[AgentThree]: Weekly report every Monday at 8:00 AM
- Scheduled outputs are delivered to [channel]

## Shared Context
- Company: [Your company name]
- Product: [One-sentence product description]
- Audience: [Target audience]
- Tone: [Brand tone of voice]
- Language: English only

Example 1: Solo Agent Setup

Even a single agent benefits from AGENTS.md. It gives you a clean separation between the agent's identity (SOUL.md) and its operating environment (AGENTS.md). This setup is ideal for a personal assistant agent, a research agent, or a monitoring bot.

AGENTS.md - Solo DevOps Monitor
# AGENTS

## Team
- @InfraWatch: DevOps monitoring agent. Tracks uptime,
  response times, error rates, and deployment health.

## Workspace Rules
- Project root: /home/deploy/infra-monitor
- Logs directory: /home/deploy/infra-monitor/logs/
- Memory file: /home/deploy/infra-monitor/MEMORY.md
- Config files: /home/deploy/infra-monitor/config/
- ALWAYS use absolute paths in all commands
- NEVER modify production config files directly

## Communication Rules
- Report to Telegram for all alerts and summaries
- Use severity levels: SEV1 (immediate), SEV2
  (investigate within 1 hour), SEV3 (log and review)
- SEV1: send immediately, include error details and
  affected endpoint
- SEV2: batch with other SEV2 alerts, send every
  15 minutes
- SEV3: include in daily summary only
- Do NOT send alerts for known maintenance windows

## Tool Access
- @InfraWatch: Shell, HTTP, Telegram, File System
- Shell: ONLY for read-only diagnostic commands
  (curl, ping, top, df). NEVER for write operations.
- HTTP: health check endpoints only

## Handoff Rules
- No handoffs (solo agent)
- WHEN a SEV1 issue persists for more than 10 minutes
  after alert, re-alert with escalation tag

## Memory Rules
- Log every SEV1 and SEV2 incident to MEMORY.md
  with timestamp, duration, and resolution
- Track recurring issues: if the same endpoint fails
  3 times in 7 days, flag as chronic in MEMORY.md
- Update MEMORY.md immediately when new information
  is discovered. Do NOT wait for session end.

## Scheduling Rules
- Health check: every 5 minutes
- Daily summary: 8:00 AM, sent to Telegram
- Weekly capacity report: Friday 9:00 AM

Example 2: 3-Agent Content Team

This is the most common multi-agent setup: a project manager, a content writer, and an SEO analyst working together on a content pipeline. The PM coordinates, the SEO analyst researches keywords, and the writer produces content based on the briefs.

AGENTS.md - 3-Agent Content Team
# AGENTS

## Team
- @Orion: Project manager. Coordinates content
  pipeline, tracks deadlines, assigns tasks, and
  reports team progress.
- @Echo: Content writer. Produces blog posts, guides,
  and landing page copy based on keyword briefs from
  @Radar.
- @Radar: SEO analyst. Conducts keyword research,
  audits content for on-page optimization, and
  tracks ranking performance.

## Workspace Rules
- Project root: /home/user/content-team
- Blog drafts: /home/user/content-team/drafts/
- Published content: /home/user/content-team/published/
- Keyword briefs: /home/user/content-team/briefs/
- Memory files: each agent's own directory
- Shared memory: /home/user/content-team/SHARED_MEMORY.md
- ALWAYS use absolute paths
- NEVER overwrite files in published/ without
  @Orion approval

## Communication Rules
- Use @mentions when addressing a specific agent
- @Orion speaks when assigning tasks, reporting
  progress, or resolving blockers
- @Echo speaks when a draft is ready for review or
  when requesting clarification on a brief
- @Radar speaks when a keyword brief is complete or
  when ranking changes are detected
- Daily standup: each agent posts a 3-line update
  (done, doing, blocked)
- Do NOT repeat information already shared by another
  agent in the same thread
- Primary channel: Slack (#content-pipeline)
- Alerts channel: Slack (#content-alerts)

## Tool Access
- @Orion: Slack, File System, Task Tracker
- @Echo: Slack, Browser, CMS API, File System
- @Radar: Slack, Search, Google Search Console,
  Browser, File System
- All agents: File System (read access to shared
  directories)

## Handoff Rules
- WHEN @Orion assigns a new content topic, @Radar
  produces a keyword brief within 24 hours. Brief
  must include: primary keyword, 3-5 secondaries,
  search intent, top 3 competitor URLs, and
  recommended word count.
- WHEN @Radar completes a keyword brief, hand off
  to @Echo with the brief file path. @Echo confirms
  receipt within 1 hour.
- WHEN @Echo completes a draft, hand off to @Radar
  for on-page SEO review. @Radar returns feedback
  within 4 hours.
- WHEN @Radar approves the draft, hand off to @Orion
  for final review and publish scheduling.
- WHEN any agent is blocked for more than 8 hours,
  escalate to @Orion with blocker details.
- WHEN a draft is rejected twice, @Orion reviews the
  brief and reassigns or rewrites requirements.

## Memory Rules
- @Orion: track all task assignments, deadlines,
  and completion dates in MEMORY.md
- @Echo: track style notes, user feedback on past
  content, and recurring edit requests in MEMORY.md
- @Radar: track target keywords, current rankings,
  and cannibalization issues in MEMORY.md
- Shared memory: brand voice guidelines, content
  calendar, and editorial decisions that all agents
  must follow
- ALWAYS write to MEMORY.md immediately when new
  information is discovered. Do NOT wait until the
  end of the session.
- Delete outdated information by replacing it with
  the current correct information. Never leave stale
  data in memory files.

## Scheduling Rules
- @Orion: Daily standup summary at 9:00 AM
- @Radar: Daily rankings check at 8:00 AM, weekly
  performance report every Monday at 9:00 AM
- @Echo: No scheduled tasks (triggered by handoffs)

## Shared Context
- Company: [Your company name]
- Product: [One-sentence product description]
- Target audience: [Audience description]
- Brand tone: Professional, clear, evidence-based
- Language: English only
- Blog post length: 1,200 to 1,800 words
- Publication frequency: 3 posts per week
- Internal links: minimum 2 per post

Example 3: 5-Agent Full Stack Team

A full stack team handles content creation, SEO, development, DevOps monitoring, and social media distribution. This is the setup for teams that want end-to-end automation from keyword research through content publishing to performance tracking.

AGENTS.md - 5-Agent Full Stack Team
# AGENTS

## Team
- @Commander: Project manager. Owns the task board,
  assigns work, tracks deadlines, and resolves
  cross-agent blockers.
- @Scribe: Content writer. Produces blog posts,
  documentation, changelogs, and email campaigns.
- @Scout: SEO analyst. Keyword research, content
  audits, ranking tracking, and competitor analysis.
- @Forge: Developer agent. Builds features, fixes
  bugs, writes tests, and manages deployments.
- @Beacon: Social media and distribution agent.
  Creates social posts, schedules distribution,
  tracks engagement, and identifies trending topics.

## Workspace Rules
- Project root: /home/user/fullstack-team
- Content: /home/user/fullstack-team/content/
- Code: /home/user/fullstack-team/src/
- Deploys: /home/user/fullstack-team/deploy/
- Analytics: /home/user/fullstack-team/analytics/
- Memory: each agent's own directory
- Shared context: /home/user/fullstack-team/SHARED.md
- ALWAYS use absolute paths
- NEVER push to main branch without @Commander
  approval
- NEVER publish content without @Scout on-page review
- NEVER deploy without @Forge running the test suite

## Communication Rules
- Use @mentions when addressing a specific agent
- Each agent speaks ONLY about their domain
- @Commander is the only agent that can reassign
  tasks between agents
- Cross-domain requests go through @Commander
- Urgent alerts: prefix with [URGENT] in message
- Daily standup: 9:00 AM, each agent posts status
  (done, doing, blocked)
- Primary channel: Slack (#team-ops)
- Content channel: Slack (#content)
- Dev channel: Slack (#engineering)
- Social channel: Slack (#social)

## Tool Access
- @Commander: Slack, Task Tracker, File System,
  Calendar API
- @Scribe: Slack, Browser, CMS API, File System
- @Scout: Slack, Search, Google Search Console,
  Browser, Analytics API, File System
- @Forge: Slack, Shell, Git, CI/CD API, Docker,
  File System, Browser
- @Beacon: Slack, Twitter API, LinkedIn API,
  Buffer API, Analytics API, File System

## Handoff Rules

### Content Pipeline
1. @Commander assigns topic to @Scout
2. @Scout produces keyword brief (24h), hands off
   to @Scribe with brief file path
3. @Scribe writes draft (48h), hands off to @Scout
   for on-page review
4. @Scout reviews and returns feedback or approval
   (4h)
5. If approved: @Commander schedules publish date,
   @Scribe publishes via CMS API
6. After publish: @Beacon creates social posts and
   schedules distribution
7. After 7 days: @Scout reports initial ranking data

### Development Pipeline
1. @Commander assigns feature or bug to @Forge
2. @Forge implements, writes tests, opens PR
3. @Forge runs test suite. If passing, requests
   @Commander review.
4. @Commander approves, @Forge merges and deploys
5. @Forge monitors deploy health for 30 minutes
   post-deploy

### Escalation Rules
- Task blocked more than 12 hours: escalate to
  @Commander
- Draft rejected 3 times: @Commander reviews brief
  and resets requirements
- Deploy failure: @Forge rolls back immediately,
  then investigates. @Commander notified within
  5 minutes.
- Ranking drop greater than 15 positions on a
  target keyword: @Scout runs immediate audit and
  notifies @Commander

## Memory Rules
- Each agent writes to its own MEMORY.md
- Shared facts and decisions go in SHARED.md
- ALWAYS write to memory immediately when new
  information is discovered
- Memory format: markdown, dated headers, bullet
  points
- @Commander: tracks all task states, deadlines,
  and team velocity
- @Scribe: tracks content style feedback, rejected
  drafts reasons, and word count targets
- @Scout: tracks keyword rankings, cannibalization
  issues, and competitor moves
- @Forge: tracks deployment history, known bugs,
  and technical debt items
- @Beacon: tracks engagement metrics, best posting
  times, and high-performing post formats
- Replace outdated info with current info. Never
  leave stale data.

## Scheduling Rules
- @Commander: Daily standup at 9:00 AM, weekly
  progress report Friday 5:00 PM
- @Scout: Daily rankings at 8:00 AM, weekly SEO
  report Monday 9:00 AM
- @Forge: Daily deploy health check at 8:30 AM
- @Beacon: Daily engagement summary at 6:00 PM,
  schedule posts for next day at 7:00 PM
- @Scribe: No scheduled tasks (triggered by
  pipeline handoffs)

## Shared Context
- Company: [Your company name]
- Product: [One-sentence product description]
- Target audience: [Audience description]
- Brand tone: [Your brand voice]
- Language: English only
- Content cadence: 3 blog posts, 1 changelog,
  5 social posts per week
- Tech stack: [Your tech stack]
- Deployment target: [Production URL]

AGENTS.md vs Config Set: When to Use Which

OpenClaw has two configuration systems, and using the wrong one for a given setting is a common source of confusion. Here is the clear boundary between them.

AGENTS.md (Behavioral)

  • Team roster and responsibilities
  • Communication and handoff rules
  • Memory and scheduling policies
  • Shared context and brand guidelines
  • Tool access restrictions
  • Escalation procedures

Read by the LLM. Shapes agent reasoning.

openclaw config set (Runtime)

  • Model selection (claude, gpt, ollama)
  • Temperature and token limits
  • API keys and credentials
  • Gateway port and host settings
  • Provider configuration
  • Logging verbosity

Consumed by runtime. Never reaches the LLM.

The rule of thumb: if the setting tells agents what to do or how to behave, it belongs in AGENTS.md. If the setting tells the runtime how to execute, it belongs in config set. Mixing these up leads to either wasted context tokens (putting runtime settings in AGENTS.md where the LLM reads but cannot act on them) or invisible rules (putting behavioral instructions in config set where the LLM never sees them).

Quick reference
# These belong in AGENTS.md:
"ALWAYS respond in English"
"@Echo hands off to @Radar after draft completion"
"Write to MEMORY.md immediately on new findings"
"Use Slack for team communication"

# These belong in config set:
openclaw config set model claude-sonnet-4-20250514
openclaw config set temperature 0.3
openclaw config set max_tokens 4096
openclaw config set gateway.port 18789

Common Mistakes in AGENTS.md Configuration

These are the mistakes that cause multi-agent teams to produce inconsistent, duplicated, or dropped work. Every one of them is fixable with more specific instructions.

Too vague

Communication: Agents should coordinate with each other.

Specific and reliable

Communication: @Radar speaks when keyword brief is complete. @Echo speaks when draft is ready for review. @Orion speaks when assigning tasks or resolving blockers. No other communication unless requested.

Too vague

Handoffs: Pass work to the next agent when done.

Specific and reliable

Handoffs: WHEN @Radar completes keyword brief, hand off to @Echo with file path to brief. @Echo confirms receipt within 1 hour. WHEN @Echo completes draft, hand off to @Radar for on-page review.

Too vague

Memory: Save important things.

Specific and reliable

Memory: ALWAYS write findings to MEMORY.md immediately. Format: dated markdown headers, bullet points. Replace outdated info with current info. Never leave stale data in memory files.

Too vague

Tools: All agents can use all tools.

Specific and reliable

Tools: @Orion: Slack, Task Tracker. @Echo: Browser, CMS API, Slack. @Radar: Search Console, Search, Slack. No agent uses tools outside their listed set.

Two more mistakes worth highlighting:

Missing handoff context

Telling an agent to 'hand off to @Echo' without specifying what context to pass is like forwarding an email without the attachment. Always define what data, file path, or summary the receiving agent needs to pick up the task without asking questions.

Duplicated rules between SOUL.md and AGENTS.md

If the same rule appears in both files, you have a maintenance problem. When you update one, you will forget to update the other. Team-wide rules go in AGENTS.md. Agent-specific rules go in SOUL.md. No overlap.

Related Guides

Frequently Asked Questions

What is AGENTS.md in OpenClaw?

AGENTS.md is the team-level configuration file in OpenClaw that defines how multiple agents work together. It lives at the workspace root (~/.openclaw/agents/AGENTS.md) and is read by every agent on startup. AGENTS.md contains workspace rules, communication rules, tool access definitions, handoff rules, memory rules, and scheduling rules. While SOUL.md defines who an individual agent is, AGENTS.md defines how the entire team operates as a unit.

What is a good AGENTS.md example for OpenClaw?

A good AGENTS.md example includes six sections: workspace rules (file paths and memory locations), communication rules (when agents should speak and how they reference each other with @mentions), tool access (which tools each agent is allowed to use), handoff rules (specific conditions for passing work between agents), memory rules (what to persist and where to write it), and scheduling rules (heartbeat behavior for recurring tasks). The key is specificity. Every rule should be concrete and verifiable, not vague like 'coordinate well.'

Where can I find an AGENTS.md template for OpenClaw?

This guide includes three complete AGENTS.md templates you can copy and customize: a solo agent setup, a 3-agent content team, and a 5-agent full stack team. Each template covers workspace rules, communication, tool access, handoffs, and memory. CrewClaw also ships pre-configured AGENTS.md files with every deploy package. You can browse 103 agent templates at crewclaw.com/agents, and each one includes the matching AGENTS.md configuration for its team setup.

Should I use AGENTS.md or openclaw config set for team configuration?

Use AGENTS.md for behavioral rules that shape how agents think and interact: communication patterns, handoff conditions, shared context, memory policies, and team workflows. Use openclaw config set for runtime settings that control how agents execute: model selection, temperature, token limits, API keys, and gateway ports. AGENTS.md is read by the LLM as part of its context window, so it influences agent reasoning. Config set values are consumed by the OpenClaw runtime and never reach the LLM directly. If the rule affects agent behavior, put it in AGENTS.md. If it affects infrastructure, use config set.

Skip the configuration from scratch

Every CrewClaw deploy package includes a pre-configured AGENTS.md. 103 templates ready to go, with workspace rules, handoffs, and memory already defined.

Browse 103 Agent Templates

Deploy a Ready-Made AI Agent

Skip the setup. Pick a template and deploy in 60 seconds.

Get a Working AI Employee

Pick a role. Your AI employee starts working in 60 seconds. WhatsApp, Telegram, Slack & Discord. No setup required.

Get Your AI Employee
One-time payment Own the code Money-back guarantee