Coach: Architecture of a Multi-Agent AI Platform

In Part 1 I covered what OpenClaw taught me about building a secure AI platform. This article goes deeper into what Coach actually is — the architecture, the layers, and how we can extend it.

What Coach Is

Coach is a background service that runs on your machine, and it works with any AI — Claude, GPT, Ollama, local models. Right now I run it with Claude. It's one process, always running, no cold start. You talk to it from your terminal or your phone, and both share the same conversation.

It isn't a chatbot. It's a multi-agent platform — an orchestrator that routes work to specialized agents, each with its own workspace and tools. What those agents do depends on what you plug in. Career management, codebase navigation, research, home automation — Coach doesn't care. The plugin is the domain. Coach is the infrastructure.

Architecture

Coach has five main layers, and everything is interchangeable. You can swap the LLM, add a new chat interface, plug in a different domain tool, define a new workspace agent, or schedule a new job — all without touching the rest of the system. Most of this is configuration, not code.

Providers — The AI Backend

The provider is the LLM connection, and it's the first thing you can swap. Claude, GPT, Ollama, a local model — Coach doesn't care. You change one line in the config to switch.

Right now I run it with Claude as a persistent subprocess. It starts once and stays alive — 10 seconds warm response vs 21 seconds if you spawn a new process each time. Switch to an API provider or a local model and the behavior changes, but you're still talking to Coach the same way. The rest of the system doesn't know or care which provider is active.

Transports — How You Talk to It

So what's a transport? It's an input channel — terminal, Telegram, Slack, Discord — however you want to talk to Coach.

Right now I use terminal and Telegram, and both share the same conversation. Telegram polls every 10 seconds. No webhook, no open ports. Messages over 4096 characters get split automatically, and markdown converts to Telegram-safe HTML.

Plugins — Domain Logic

Plugins bridge Coach to your actual tools. Each plugin registers commands and optionally intercepts messages. The interface is 39 lines.

A plugin could connect Coach to a CI/CD pipeline, a customer support queue, a research database, or a smart home controller. You write a Python module, register it in config, and Coach handles the routing.

Data commands query the database directly — 200ms, no LLM involved. You type the command and get the answer. Heavier tasks go through the LLM for reasoning.

Agents — Workspace Routing

This is where it gets interesting. Coach supports multiple agents, each with its own workspace, tools, and permissions.

So how does routing work? When you type a message, Coach routes it to the right agent based on deterministic rules (keyword matching, patterns, command prefixes). No LLM needed for the routing itself. "Fix the auth bug" goes to the codebase agent with access to that repo. "Check the deployment status" goes to the ops agent with access to infrastructure tools. No ambiguity, no delay.

Each agent operates in its own working directory, and the LLM only sees what that agent's workspace contains. Switch agents and the context switches with it — different files, different tools, different permissions.

Scheduler — Built-in Automation

No external cron. The scheduler is built in.

Jobs are defined in the config file:

jobs:
  - id: daily-report
    schedule: "08:00"
    command: "/report"
    notify: false

  - id: morning-brief
    schedule: "08:25"
    command: "/brief"
    notify: true

  - id: deploy-reminder
    schedule: "09:03"
    run_date: "2026-03-13"
    command: "Reminder: Push release to staging"
    notify: true

Recurring jobs fire daily. One-time reminders fire once and disappear. If your laptop was asleep when something was due, Coach catches up when it wakes — it runs what it missed but skips the notifications so your phone doesn't buzz 5 times at once.

Memory System

Coach remembers things across sessions. There are three layers:

• 👤 Shared memory — identity, preferences, timezone. Loaded every session. This is who you are and how you work.
• 🤖 Agent memory — per-agent context. Each agent accumulates its own patterns, decisions, and domain knowledge. The codebase agent remembers architectural decisions. A research agent remembers what sources you trust. They don't leak into each other.
• 📋 Checkpoints — every 10 messages, Coach saves a summary of what happened: topics discussed, decisions made, key exchanges. These get indexed for search, so Coach can find relevant past conversations when it needs context.

When a new session starts, Coach loads relevant memory based on what you're working on. Instead of replaying entire past conversations, it pulls just the pieces that matter.

Sessions rotate every 20 messages or 12 hours. Before rotating, Coach saves what matters. The next session starts clean but with context — so you never have to repeat yourself.

Security

Coach has no open ports, no public endpoints, nothing exposed to the internet. Everything runs on your machine, for you only.

Messages from untrusted channels like Telegram go through a filter before they reach anything — dangerous characters get stripped, length gets capped. Terminal input skips that because you already have full access to your own machine.

Each channel has a permission level. Telegram can ask questions and run commands but can't edit your files. Terminal has full access. You can also set the LLM itself to read-only mode, where it suggests changes but waits for your approval before touching anything.

Secrets never touch the codebase. API keys stay in a separate file that never gets committed. No keys in logs, no keys in error messages.

The security standards come from production healthcare and multi-org SaaS systems — adapted for a single-user context. Tests cover injection, access control, and common attack patterns, and they run on every change.

Self-Healing

Coach is designed to keep running without you babysitting it.

If the AI crashes, it restarts automatically on the next message. If Telegram loses its connection, Coach backs off and retries until it reconnects. Scheduled jobs are isolated — if one fails, the rest still run. No domino effect.

Memory saves every 10 messages. If Coach crashes between saves, you lose at most 10 messages of context. Session rotation extracts key decisions before clearing — so the next session picks up where you left off, not from zero.

If the entire daemon dies, macOS restarts it within seconds. Everything important is saved to disk, so recovery is seamless. You don't notice unless you're watching the logs.

Coach also maintains its own coding standards. When it writes code for itself — fixing bugs, adding features — it follows a set of rules embedded in its own instructions. Security checklist, testing requirements, architecture patterns. Self-reinforcing.

How to Extend It

Most customization is just editing the config file, no code required.

Add a new agent

Add a block to the config:

- id: writing
  workspace: ~/writing
  description: "Blog posts, articles, drafts"
  bindings:
    keywords: [article, draft, blog, publish, write]

Restart the daemon, and messages with those keywords now route to the ~/writing workspace.

Add a scheduled job

Add a few lines to the config. No code, no external tools, no separate service.

Switch AI providers

Change one setting in the config. Claude, GPT, Ollama — pick one. Everything else stays the same.

Go deeper

For developers who want to build custom plugins, add new chat interfaces, or write their own AI provider — the extension points are documented in the README and the project docs. But most users won't ever need to touch code. The config handles it.

Using Coach

You interact with Coach two ways. Type coach "question" for a quick one-off answer, or type coach to open an interactive session. Both work from your terminal. From Telegram, just send a message — Coach is always listening.

Under the hood, the CLI talks to the daemon through a local API. For developers who want to build on top of Coach, the full API reference is in the documentation.

What Is Next

More AI providers. Claude is the current default. GPT, Ollama, and local models are next. When those land, Coach can run entirely offline — no internet, no subscription, no external dependencies.

More ways to talk to it. Slack and Discord are obvious next steps. Same routing, same memory, different app.

Voice input. Telegram supports voice messages. Say something on your phone, get a text response.

Skills replacing plugins. Right now adding domain tools requires Python code. Skills would be config-only — describe what the tool does, and Coach handles the rest.

The plugin is the domain. Coach is the infrastructure. Hope this helps.

Read the Series

• Part 1: What OpenClaw Taught Me About Building a Multi-Agent AI Platform — security lessons, cost analysis, and the five iterations that shaped the architecture.
• Part 2 (this article): five layers, each one replaceable.
• Part 3: Five Stages to One Brain — from Groq hallucinations to a single-brain multi-interface agent.
• Part 4: From No Memory to Semantic Search — four memory iterations, temporal decay, and the unsolved pre-compaction problem.
• Part 5: Coach Six Weeks Later — redaction, multi-instance, code review, and 556 tests.