DEV Community

ClawGear
ClawGear

Posted on • Originally published at clawgear.io

I built a fully autonomous agent that manages 4 business projects simultaneously — here's the system

Eight months ago I was manually checking in on four different projects every morning. Slack updates, GitHub issues, email threads, client messages — all in different places, all demanding context-switching that cost more energy than the work itself.

Now an AI agent does the morning check-in. It reads the email, scans the projects, updates the task files, and sends me a tight summary before I've finished my coffee.

This isn't a demo. It's what I run in production, today. Here's the actual system.


The Core Problem: Context Switching Kills Throughput

Running multiple projects isn't just a time problem — it's a memory problem. Every time you switch from project A to project B, you have to rebuild context. What was the last decision? What's blocked? What did the other person say last week?

I was doing that 15-20 times a day. By 2 PM I was exhausted from the overhead, not the actual work.

The naive solution is better note-taking. The real solution is externalizing memory to something that never forgets.


The System: Four Layers

Layer 1: Workspace Structure

Every project lives in a structured folder:

projects/
  clawarmor/
    PROJECT.md     ← what it is, current status, goals
    TASKS.md       ← active tasks, in-progress, done (with dates)
    MEMORY.md      ← key decisions, credentials refs, context
  comfy/
    PROJECT.md
    TASKS.md
    MEMORY.md
  clawgear/
    ...
Enter fullscreen mode Exit fullscreen mode

This sounds obvious. The non-obvious part: these files are the agent's memory. Every session, the agent reads them before doing anything else. Every session, it writes back before closing. Memory isn't stored in the AI — it's stored in files.

Layer 2: Identity Files

The agent has three identity files it reads at startup:

SOUL.md — how it communicates, what it won't do without asking, what "done" means, when to push back
USER.md — who I am, my timezone, how I like updates delivered, what channels to use
AGENTS.md — the operating rules: memory sync, safety, cross-project structure, heartbeat behavior

These files transform a stateless model into something with consistent behavior. Without them, you get drift — the agent's personality and judgment changes session to session. With them, it behaves like a real team member who knows your working style.

Layer 3: Multi-Channel Routing

Different projects live in different Telegram groups. The agent knows which project belongs to which group:

{
  "-5066079193": "projects/clawarmor",
  "-5267334417": "projects/comfy",
  "-3869908995": "projects/clawgear"
}
Enter fullscreen mode Exit fullscreen mode

When I'm in the ClawArmor group, the agent reads that project's files and stays scoped to that context. When I'm in the Comfy group, same thing. The main DM is cross-project meta.

This prevents context bleed — one of the messiest failure modes I've seen in multi-project agent setups.

Layer 4: Memory Sync Rules

This is the layer most people skip and the one that breaks everything.

I lost state three times before I got this right:

  • Feb 28: Got an npm token + made a decision. Neither was written to file. Both lost until I reconstructed from git log.
  • Mar 1: A sub-agent finished research work. Daily notes updated. Project TASKS.md/MEMORY.md: untouched.
  • Mar 1: Full day of work on Comfy project in main session. Project files still said "Phase: Research & Setup."

The fix: a write-through rule. Any session that changes project state writes that project's files in that same turn. Not later. Not at nightly heartbeat. Now.

I also built a validator script (memory-sync.sh) that runs before every git commit. It compares daily notes against project file freshness. If it detects drift, the commit is blocked.


The Tools That Make It Work

The system above is the architecture. These are the specific tools I use:

OpenClaw — the runtime. It's the agent platform that handles sessions, Telegram channels, tool availability, and cron scheduling. My agent runs as a persistent process on a Mac mini.

Claude (Anthropic) — the model. I use claude-sonnet-4-6 for most tasks. It's fast enough for real-time Telegram responses and smart enough for complex reasoning.

Skill: ClawGear Persona — the identity layer. SOUL.md, USER.md, communication rules, the whole persona setup packaged as an installable skill.

Skill: Agent Ops Playbook Pro — the memory architecture. The multi-project structure, write-through rules, validator script, and pre-commit hooks.

Skill: CDP Browser Automation — for web tasks. The agent can log into dashboards, scrape data, fill forms. This killed about 45 minutes of daily manual work.

Skill: Notion Workspace — external memory + documentation. Project status pages, decision logs, research dumps. Anything that needs to outlast a conversation goes in Notion.

All of these are on clawgear.io — I built the store specifically because these were the tools I needed and couldn't find packaged anywhere.


What the Agent Actually Does Daily

Here's a real morning session:

  1. Reads daily note from yesterday — what was worked on, what was left open
  2. Reads each project's TASKS.md — identifies anything past due or blocked
  3. Checks email — flags anything that needs attention, categorizes the rest
  4. Runs heartbeat — delivers a 3-5 line summary to my Telegram DM
  5. Waits — responds to project group messages as they come in

When I message a project group, it already has context. No "last time we talked about..." — it picks up where we left off.

When I say "go" on something, it does it in that turn and reports back. Not "I'll look into it" — actual output.


The Failure Modes (Because You Should Know)

Memory drift — when the agent's understanding of project state diverges from reality. Fixed by write-through rules and the validator script.

Scope creep — when an agent given broad access starts doing things adjacent to what you asked. Fixed by clear channel routing and explicit scope in PROJECT.md files.

Silent completion — agent finishes a task but doesn't report back. You don't know if it worked. Fixed by mandatory close-the-loop rules in SOUL.md.

Over-asking — agent interrupts constantly for permission on obvious calls. Fixed by clearly defining what it can do vs what needs approval.

The pattern: most agent problems are configuration problems, not model problems. The model is good enough. The operating rules aren't.


Is This Hard to Set Up?

Honest answer: the architecture took me about two weeks to design and refine. A lot of trial and error.

The packaged version (what's on clawgear.io) takes about an hour to install and configure. The hard thinking is done — you're applying it to your context.

If you're already running OpenClaw, the skills drop in and work. If you're not, OpenClaw is where I'd start.


What's Next

I'm working on:

  • A browser recording tool so the agent can learn new UI flows from watching you do it once
  • Better cross-project summaries (weekly digest, not just daily)
  • Voice-based status updates via TTS

The system is stable enough to run autonomously. Now I'm compounding.


If you're building something similar or have questions about any of this, I'm @ClawGearAI on X. I post real agent work, not hype.

Skills mentioned in this post: clawgear.io

Top comments (0)