Build an Agentic Sales Team with OpenClaw

Before installing anything, know the shape of the system. It's not one assistant — it's five specialized agents that pass work to each other through files. Scout researches, Writer drafts copy, Rep runs outreach, Closer manages deals, and Mission Control coordinates the fleet and reviews security. Every agent wakes on a staggered heartbeat so they don't collide, checks its checklist, does real work or replies HEARTBEAT_OK, and goes back to sleep. Cost is roughly $15-30/month to run all five agents 24/7 (mostly Haiku-tier API usage).

┌─────────────────────────────────────────────────────────────────┐
│                      MISSION CONTROL                             │
│                    (Chief of Staff)                              │
└─────────────────────────────────────────────────────────────────┘
                              │
           ┌──────────────────┼──────────────────┐
           ▼                  ▼                  ▼
     ┌──────────┐      ┌──────────┐      ┌──────────┐
     │  SCOUT   │ ───▶ │  WRITER  │ ───▶ │   REP    │ ───▶ CLOSER
     │ Research │      │   Copy   │      │ Outreach │      Deals
     └──────────┘      └──────────┘      └──────────┘

Heartbeats (staggered so agents don't collide):
:00,:30  Mission Control     :00,:15,:30,:45  Scout
:02,:17,:32,:47  Writer      :04,:19,:34,:49  Rep
:06,:21,:36,:51  Closer

Each agent's personality lives in `openclaw-skills/<agent>/SKILL.md`. Open `scout/SKILL.md` and you'll see it's not a generic prompt — it defines Scout's exact response format (a research brief with SIGNALS, KEY CONTACTS, and a "MY TAKE" opinion section), its golden rule ("never end a response without a question or suggestion"), and how it hands work to Rep. `writer/`, `rep/`, and `closer/` follow the same pattern for their respective roles.

git clone https://github.com/gtm-skills/gtm.git
cd gtm/openclaw-skills
ls
# closer/  deployment/  mission-control/  rep/  scout/  writer/

The `deployment/setup.sh` script does the real work: it creates the workspace, copies every agent's `SKILL.md` into place (renamed to `SCOUT.md`, `WRITER.md`, etc.), copies the shared memory files (`MEMORY.md`, `HEARTBEAT.md`, `WORKING.md`, `PROGRESS.md`) and strategy playbooks, then registers five cron heartbeat jobs with `clawdbot` — one per agent plus a nightly daily-standup job. Run it against `localhost` to set up locally, or pass a server IP to deploy remotely over SSH.

cd deployment
./setup.sh your-server-ip
# or, to set up locally:
./setup.sh localhost

The setup script copies `config.template.json` conventions into `~/.clawdbot/clawdbot.json`. Set your model aliases, then lock the Telegram channel down before you turn anything on: restrict `allowedGroups` and `allowedUsers` to your own IDs, keep `groupPolicy` as `allowlist`, and set `mentionOnly: true` so the bot only responds when @mentioned. API keys go in environment variables, never in the config file itself.

export ANTHROPIC_API_KEY=sk-ant-...
export HUBSPOT_API_KEY=pat-na1-...   # optional, enables CRM logging

{
  "channels": {
    "telegram": {
      "botToken": "YOUR_BOT_TOKEN",
      "dmPolicy": "pairing",
      "groupPolicy": "allowlist",
      "allowedGroups": ["YOUR_GROUP_CHAT_ID"],
      "allowedUsers": ["YOUR_USER_ID"],
      "mentionOnly": true,
      "streamMode": "partial"
    }
  }
}

Once credentials are set, start the OpenClaw gateway and confirm all six cron jobs registered correctly: `mission-control-heartbeat`, `scout-heartbeat`, `writer-heartbeat`, `rep-heartbeat`, `closer-heartbeat`, and `daily-standup` (which fires nightly at 23:30 and compiles a report from `WORKING.md`, `PROGRESS.md`, and the day's memory file).

clawdbot gateway start
clawdbot cron list

Once the fleet is running, address agents directly — they're designed to ask clarifying questions before acting, not execute blindly. Scout will push back for scope ("What size? What stage?") before returning a list. Every response ends with a question or suggested next step; that's a deliberate rule baked into each agent's SKILL.md, not a formatting accident.

You: "Find me SaaS companies hiring SDRs"
Scout: "On it. What size? What stage? VP level or Director?"

You: "Series B, VP of Sales"
Scout: "Found 10. Top pick is Sarah Chen at Acme - just raised $25M.
        Want me to brief Writer?"

You → Writer: "Email Sarah"
Writer: "Got the briefing. What tone - direct or challenger?"

[Email written, sent by Rep, meeting booked]

You → Closer: "She wants a proposal"
Closer: "Great. Who else needs to approve? What's the main pain?"

There's no database. All coordination happens through `WORKING.md` in the shared workspace: Scout writes a research briefing there, Writer reads it and drafts copy, Rep reads the copy and executes outreach, and Closer picks up qualified deals. Because it's a plain file, you can read it, edit it, or intervene manually at any point — the fleet is transparent by design, not a black box.

Check `PROGRESS.md` for metrics and `memory/YYYY-MM-DD.md` for daily logs. Mission Control reviews changes and enforces the security model on every heartbeat: workspace isolation (agents only touch their own files), no sudo or system access, and scoped permissions throughout. Read `deployment/ARCHITECTURE.md` in the repo for the full technical breakdown if you want to extend the fleet with a new agent role.