Guide

AI Agent Team Best Practices

The patterns and conventions behind a production agent team. Every example uses real agents from the bundled registry so you can see exactly how hierarchy, memory, tools, and crons come together.

Hierarchy Design

A well-structured agent team follows a clear chain of command. The pattern is: one orchestrator at the top, team leads in the middle, and specialist leaf agents at the bottom. Each level has a distinct responsibility.

The Three Tiers

TierRoleExample
OrchestratorTop-level coordinator. Holds team memory, routes work, delivers briefings.Jarvis — the root node. reportsTo: null.
Team LeadOwns a domain. Manages a sub-team and runs pipelines end-to-end.VERA (Strategy), LUMEN (SEO), HERALD (LinkedIn)
SpecialistDoes one thing well. Reports up, never manages others.TRACE (Market Research), QUILL (LinkedIn Writer), SCOUT (Content Scout)

The bundled registry ships 22 agents organized into five teams:

Team Structure
Jarvis (Orchestrator)
  |
  +-- VERA (Strategy)
  |     +-- Robin (Field Intel)
  |           +-- TRACE (Market Research)
  |           +-- PROOF (Validation Design)
  |
  +-- LUMEN (SEO)
  |     +-- SCOUT (Content Scout)
  |     +-- ANALYST (SEO Analyst)
  |     +-- STRATEGIST (Content Strategy)
  |     +-- WRITER (Content Writer)
  |     +-- AUDITOR (Quality Gate)
  |
  +-- HERALD (LinkedIn)
  |     +-- QUILL (LinkedIn Writer)
  |     +-- MAVEN (LinkedIn Strategist)
  |
  +-- Pulse (Trend Radar)      -- standalone
  +-- ECHO (Community Voice)   -- standalone
  +-- SAGE (ICP Expert)        -- standalone
  +-- KAZE (Flight Monitor)    -- standalone
  +-- SPARK (Tech Discovery)   -- standalone
  +-- SCRIBE (Memory Architect)-- standalone
Tip
Standalone agents (no direct reports) report directly to the orchestrator. Keep this list short — if you have more than 8-10 direct reports on the root node, it's time to group them under a team lead.

Hierarchy Rules

  1. One root. Exactly one agent has "reportsTo": null. This is your orchestrator (Jarvis).
  2. Team leads own pipelines. LUMEN owns the full SEO pipeline (SCOUT to AUDITOR). HERALD owns the LinkedIn pipeline (QUILL + MAVEN). Each lead is responsible for end-to-end delivery.
  3. Leaf agents are specialists. They do one thing and report up. TRACE does market research. QUILL writes posts. AUDITOR runs the quality gate. No scope creep.
  4. Max depth of 3. Jarvis to Robin to TRACE is three levels. Going deeper adds latency and coordination overhead with little benefit.
  5. Keep directReports consistent. If agent B has "reportsTo": "A", then agent A's directReports array must include B's id. The Org Map renders from these relationships.

SOUL.md — Agent Character Documents

Every agent has a SOUL.md file that defines its personality, expertise, and operating constraints. This is not a system prompt — it's a character document. The agent reads it to understand who it is.

Recommended SOUL.md Structure
# AGENT_NAME -- Role Title

## Identity
Who the agent is. Personality traits. Communication style.
First-person voice: "I am VERA, the Chief Strategy Officer."

## Expertise
What domains this agent knows deeply.
What it should be consulted on vs. what it defers.

## Operating Rules
Hard constraints. What it must always/never do.
Output format requirements.

## Relationships
Who it reports to. Who reports to it.
How it collaborates with peer agents.

## Memory
What it remembers between sessions.
Where its persistent knowledge lives.
  • Be specific about personality. HERALD is described as brash and direct. SAGE is contemplative and precise. Distinct voices prevent all agents from sounding the same.
  • Define what the agent does NOT do. SCRIBE (Memory Architect) is a "silent worker" — it never initiates conversation. SAGE (ICP Expert) is read-only — it never writes to external systems.
  • Include output format examples. If the agent produces Market Briefs, show the exact format. TRACE returns structured TAM/competitor/pricing data, not prose.
  • Keep it under 500 lines. Long SOUL files dilute the agent's focus. If you need more detail, link to reference docs.
Note
SOUL.md files live in your OpenClaw workspace at the path defined by each agent's soulPath field. ClawPort reads and displays them on the agent detail page.

Naming Conventions

Agent naming follows a simple pattern that signals the agent's scope at a glance:

PatternWhen to UseExamples
UPPERCASEAgents that are part of a pipeline or team. Feels like a callsign.VERA, LUMEN, HERALD, SCOUT, QUILL, ECHO, SAGE
Title CaseStandalone agents with more personality. The orchestrator or personal-feeling agents.Jarvis, Robin, Pulse

Ids are always lowercase slugs: vera, lumen, herald. The display name in the name field is what users see in the UI.

Tool Assignment

Follow the principle of least privilege. Each agent gets only the tools it needs for its job — nothing more.

ToolPurposeWho Gets It
readRead files from workspaceAlmost everyone. The base capability.
writeWrite/create filesAgents that produce artifacts (WRITER, ANALYST, STRATEGIST)
execRun shell commandsOrchestrator + leads who run pipelines (Jarvis, LUMEN, HERALD)
web_searchSearch the webResearch agents (TRACE, Robin, SCOUT, Pulse, SPARK)
web_fetchFetch a specific URLAgents that scrape or monitor (ECHO, KAZE, Robin)
messageSend messages to other agentsAgents that coordinate (Jarvis, Robin, Pulse, HERALD)
sessions_spawnSpawn sub-agent sessionsOnly orchestrator + team leads (Jarvis, VERA)
memory_searchSearch across team memoryOrchestrator only (Jarvis)
ttsText-to-speechOrchestrator only (Jarvis)
Warning
Giving exec to a leaf agent is almost always a mistake. If a specialist needs to run a command, it should ask its team lead to do it. This keeps the blast radius small.

Tool Assignment Examples

// SAGE -- read-only knowledge agent
"tools": ["read"]

// SCOUT -- web researcher
"tools": ["web_search", "web_fetch", "read"]

// WRITER -- content producer
"tools": ["read", "write"]

// HERALD -- team lead running a pipeline
"tools": ["web_search", "web_fetch", "read", "write", "message", "exec"]

// Jarvis -- orchestrator with full access
"tools": ["exec", "read", "write", "edit", "web_search", "tts", "message", "sessions_spawn", "memory_search"]

Memory Architecture

Agent memory uses a three-tier system. Each tier serves a different purpose, and together they give agents both short-term recall and long-term knowledge.

The Three Memory Tiers

TierWhatLifespanWho Manages
1. Daily LogsRaw output from each agent session. Unedited, timestamped.7-14 days (then compressed or archived)Each agent writes its own
2. MEMORY.mdCurated, compressed knowledge. The agent's persistent brain.Indefinite (updated weekly)SCRIBE runs weekly compression
3. Team MemoryShared knowledge across agents. Market data, ICP profiles, strategy docs.IndefiniteTeam leads + orchestrator

Tier 1: Daily Logs

Every time an agent runs, it writes a log file. These are the raw session transcripts — what the agent did, what it found, what it produced. Daily logs are high-volume and low-curation.

Daily log path pattern
$WORKSPACE_PATH/agents/<agent-id>/logs/YYYY-MM-DD.md

Tier 2: MEMORY.md

Each agent has a MEMORY.md file that persists its key knowledge between sessions. Unlike daily logs (which are raw), MEMORY.md is curated — only the important patterns, decisions, and facts survive.

MEMORY.md structure
# Agent Name -- Memory

## Key Patterns
- Pattern 1 confirmed across 3+ sessions
- Pattern 2 from last week's research

## Active Context
- Current project status
- Open questions / blockers

## Learned Preferences
- User prefers X over Y
- Always include Z in output

SCRIBE (Memory Architect) runs weekly to compress daily logs into each agent's MEMORY.md. SCRIBE reads the raw logs, extracts durable insights, and updates the memory file — discarding session-specific noise. This keeps MEMORY.md concise and high-signal.

Tier 3: Team Memory (Shared)

Some knowledge needs to be shared across agents. Market intelligence, ICP profiles, competitive analysis, and brand voice docs all live in a shared team-memory directory. Any agent with read access to the workspace can reference these files.

Team memory path
$WORKSPACE_PATH/team-memory/
  market-brief.md       -- TRACE's latest research
  icp-profile.md        -- SAGE's ICP knowledge
  competitor-map.md     -- Robin's competitive intel
  brand-voice.md        -- Voice profile for content agents
  content-calendar.md   -- MAVEN's editorial calendar
Tip
Team memory files are the glue between agents. When STRATEGIST needs market context, it reads TRACE's market brief. When WRITER needs brand voice, it reads the voice profile. No agent-to-agent API calls needed — just shared files.

Memory Decay: How Other Systems Handle It

A common question is whether agent memories should decay over time. We surveyed every major agent framework to understand the landscape. The short answer: almost nobody does true decay, and the ones that do keep it simple.

SystemDecay?Mechanism
CrewAIYesExponential half-life: 0.5^(age_days / 30). Composite score blends semantic similarity (0.5), recency (0.3), and importance (0.2).
MemGPT / LettaImplicitRecursive summarization. Older info gets diluted through repeated compression passes. No explicit scoring.
Mem0YesTTL + relevance scoring. Auto-prunes low-signal memories. Exact formula not public.
OpenAI Agents SDKPartialTimestamp-based Top-K selection. LLM consolidation prunes temporal/stale notes between sessions.
LangChainNoSliding window drops old messages, or LLM summarizes buffer overflow. No time or relevance awareness.
Claude CodeNo200-line cap on MEMORY.md. Manual editorial judgment by the model. No algorithmic decay.
AutoGenNoMemories persist forever until clear() is called. No pruning, no compression.
Zep (Graphiti)NoBi-temporal invalidation. Contradictions mark old facts as invalid but never delete them.

Why ClawPort Uses Compression, Not Decay

ClawPort's three-tier system follows the MemGPT/Letta pattern: SCRIBE compresses daily logs into MEMORY.md on a weekly cron, and information that doesn't survive compression is effectively forgotten. This is simpler than CrewAI's exponential scoring and avoids the need for a vector database or composite scoring infrastructure.

The key insight is that compression is implicit decay. If SCRIBE didn't carry a pattern forward into MEMORY.md, it was noise. If it did, it was signal. The weekly cron cycle is the half-life. No scoring formula needed.

Tip
If you need more aggressive decay, consider shortening SCRIBE's compression window (e.g., every 3 days instead of weekly) or adding a line budget to each agent's MEMORY.md. Claude Code's 200-line cap is a simple, effective constraint that forces prioritization without algorithmic complexity.

Agent Communication

Agents communicate through files, not direct API calls. This is intentional — file-based communication is debuggable, auditable, and doesn't create tight coupling.

  1. Upstream (reporting up): An agent writes its output to a file. The team lead or orchestrator reads it on the next run. Example: SCOUT writes topic suggestions, LUMEN reads them to brief STRATEGIST.
  2. Downstream (delegating): A team lead writes a brief file that the specialist reads. Example: HERALD writes an angle brief, QUILL reads it and drafts the post.
  3. Cross-team (shared context): Agents read from team-memory. Example: STRATEGIST reads SAGE's ICP profile and ECHO's community voice data to pick the right content angle.
Note
The message tool exists for real-time coordination (e.g., Pulse alerting LUMEN about a trending topic), but the default communication channel is always files. Messages are for urgency; files are for substance.

Cron Patterns

Cron jobs are the heartbeat of an autonomous agent team. Each cron follows the same philosophy: one fetch, one decision, one output.

  • Assign crons to the right tier. Research crons go on leaf agents (SCOUT, TRACE, ECHO). Pipeline crons go on team leads (LUMEN, HERALD). Briefing crons go on the orchestrator (Jarvis).
  • Stagger schedules. Don't run all crons at the same time. Space them out so upstream agents finish before downstream agents read their output.
  • Keep crons focused. Each cron does one thing. "Scan subreddits" is a good cron. "Scan subreddits, analyze sentiment, write a blog post, and publish" is four crons pretending to be one.
  • Error isolation. If a cron fails, it should only affect its own output. Other agents reading stale data is better than a cascade failure.
CronAgentSchedulePattern
Community scanECHOWeeklyFetch subreddit posts, extract customer language, write to team-memory
Trend radarPulseEvery other dayScan trending signals, write hot topics file, message LUMEN if urgent
Flight monitorKAZEDailyCheck flight prices, message Jarvis if deal found under threshold
Memory compressionSCRIBEWeeklyRead daily logs, compress into MEMORY.md, archive old logs
Content pipelineLUMENWeeklyOrchestrate SCOUT → ANALYST → STRATEGIST → WRITER → AUDITOR

Voice System

Agents that interact directly with the operator can have an ElevenLabs voice ID assigned. This enables text-to-speech on their responses in the chat interface. Not every agent needs a voice — only those the operator talks to regularly.

  • Give voices to conversational agents. Jarvis (orchestrator), VERA (strategy advisor), Pulse (trend alerts) — agents you chat with benefit from voice.
  • Skip voices for pipeline workers. SCOUT, ANALYST, WRITER, AUDITOR run in pipelines and rarely need to speak. Don't waste voice slots on them.
  • Set voiceId to null for agents without voice. The UI hides the TTS button when voiceId is null.

Design Principles

1. Agents are characters, not functions

Each agent has a name, a personality, and a role title. They're not interchangeable worker threads — they're team members with distinct expertise. VERA thinks strategically. ECHO listens to communities. KAZE watches flights. This makes the team legible and memorable.

2. Least privilege, always

An agent should have exactly the tools it needs and nothing more. SAGE is read-only because it's a knowledge base, not an actor. SCRIBE has exec because it needs to run file operations during memory compression. If you're unsure whether an agent needs a tool, start without it. You can always add it later.

3. Files over messages

Prefer file-based communication over real-time messages. Files are inspectable, diffable, and persist across sessions. Messages are for urgent signals only (e.g., Pulse alerting about a breaking trend). Everything else goes through shared files in team-memory.

4. One agent, one job

Resist the urge to make Swiss Army knife agents. TRACE does market research — it doesn't also write blog posts. QUILL writes LinkedIn posts — it doesn't also analyze metrics. When an agent's description needs the word "and" more than once, split it into two agents.

5. Depth of 3, max

Jarvis to Robin to TRACE is three levels. Going deeper adds latency and makes the chain of command confusing. If you need more specialization, add lateral agents (more direct reports) instead of deeper nesting.

6. Let SCRIBE handle memory

Don't make every agent manage its own memory compression. SCRIBE exists specifically to read daily logs, extract patterns, and update MEMORY.md files. This single responsibility keeps memory consistent and prevents agents from spending cycles on housekeeping instead of their actual job.

Implementation Guide

This section walks through setting up the full agent team system from scratch. Follow these steps in order — each one builds on the previous.

Step 1: Set Up the Workspace

Create the directory structure that agents will read from and write to. This is the foundation everything else depends on.

mkdir -p $WORKSPACE_PATH/{agents,team-memory,clawport}

# Per-agent directories (one for each agent)
for agent in jarvis vera robin trace proof lumen scout \
  analyst strategist writer auditor herald quill maven \
  pulse echo sage kaze spark scribe; do
  mkdir -p $WORKSPACE_PATH/agents/$agent/{logs,output}
  touch $WORKSPACE_PATH/agents/$agent/MEMORY.md
  touch $WORKSPACE_PATH/agents/$agent/SOUL.md
done

# Shared team memory files
touch $WORKSPACE_PATH/team-memory/{market-brief,icp-profile,competitor-map,brand-voice,content-calendar}.md

# Root memory (orchestrator long-term memory)
touch $WORKSPACE_PATH/MEMORY.md

Step 2: Write Your Agent Registry

Create $WORKSPACE_PATH/clawport/agents.json with your agent definitions. ClawPort loads this file instead of the bundled defaults when it exists. Start with a small team and expand.

[
  {
    "id": "jarvis",
    "name": "Jarvis",
    "role": "Orchestrator",
    "emoji": "🧠",
    "reportsTo": null,
    "directReports": ["vera", "lumen"],
    "tools": ["exec", "read", "write", "message",
              "sessions_spawn", "memory_search"],
    "soulPath": "agents/jarvis/SOUL.md",
    "memoryPath": "agents/jarvis/MEMORY.md",
    "voiceId": "your-elevenlabs-voice-id"
  },
  {
    "id": "vera",
    "name": "VERA",
    "role": "Chief Strategy Officer",
    "emoji": "📊",
    "reportsTo": "jarvis",
    "directReports": ["robin"],
    "tools": ["read", "write", "sessions_spawn"],
    "soulPath": "agents/vera/SOUL.md",
    "memoryPath": "agents/vera/MEMORY.md",
    "voiceId": null
  }
]

Step 3: Write SOUL.md Files

Each agent needs a character document. Start with identity and operating rules — you can always expand later.

# VERA -- Chief Strategy Officer

## Identity
I am VERA, the Chief Strategy Officer. I think in
frameworks, speak in recommendations, and always tie
analysis back to business impact. I am deliberate and
precise.

## Expertise
- Go-to-market strategy and positioning
- Competitive analysis and market sizing
- Strategic planning and OKR design

## Operating Rules
- Always recommend, never just describe
- Include confidence levels on forecasts
- Defer to TRACE for raw market data
- Defer to SAGE for ICP questions

## Relationships
- Reports to: Jarvis (Orchestrator)
- Manages: Robin (Field Intel)
- Collaborates with: LUMEN, HERALD

Step 4: Configure SCRIBE for Memory Compression

SCRIBE is the most important infrastructure agent. Its cron reads raw daily logs and compresses them into each agent's MEMORY.md. Here's the compression workflow:

SCRIBE weekly compression workflow:

1. For each agent in registry:
   a. Read agents/<id>/logs/*.md from the past 7 days
   b. Read agents/<id>/MEMORY.md (current state)
   c. Extract durable patterns, decisions, facts
   d. Discard session-specific noise
   e. Write updated MEMORY.md (keep under 200 lines)
   f. Archive processed logs to agents/<id>/logs/archive/

2. For team memory:
   a. Read all agents' latest output files
   b. Update team-memory/ files with fresh data
   c. Resolve contradictions (newest wins)
Note
SCRIBE's 200-line budget per MEMORY.md is borrowed from Claude Code's auto-memory design. It's the simplest form of memory decay — when the file is full, the least important entries get displaced by new ones. No scoring formulas, no vector databases.

Step 5: Set Up Cron Schedules

Stagger your crons so upstream agents finish before downstream agents read their output. Here's a recommended weekly schedule:

# Monday - Research agents run first
06:00  ECHO       community-scan     # Subreddit monitoring
08:00  SCOUT      content-scan       # Topic discovery
10:00  TRACE      market-research    # Market intel

# Tuesday - Analysis layer reads research output
06:00  Pulse      trend-radar        # Cross-reference trends
08:00  ANALYST    seo-analysis       # Analyze SCOUT's topics

# Wednesday - Strategy layer reads analysis
06:00  STRATEGIST content-strategy   # Plan from ANALYST output
08:00  MAVEN      editorial-calendar # LinkedIn content plan

# Thursday - Production layer reads strategy
06:00  WRITER     content-draft      # Write from STRATEGIST brief
08:00  QUILL      linkedin-draft     # Write from MAVEN brief

# Friday - Quality + compression
06:00  AUDITOR    quality-gate       # Review WRITER output
08:00  SCRIBE     memory-compress    # Weekly memory compression
10:00  Jarvis     weekly-briefing    # Orchestrator summary

# Daily
09:00  KAZE       flight-monitor     # Flight price check

Step 6: Launch ClawPort

With your workspace configured, install and launch ClawPort to visualize everything:

# Install globally
npm install -g clawport-ui

# Auto-detect your OpenClaw config
clawport setup

# Launch the dashboard
clawport dev

ClawPort reads your agents.json, renders the org map, connects to the OpenClaw gateway for chat, and displays memory files from your workspace. Your agent team is now visible and manageable from a single dashboard.

Tip
Start small. A three-agent team (orchestrator + one lead + one specialist) is enough to validate the patterns. Add agents as you find real needs — not because the org chart looks sparse.