← Back to blog

launchthatbot

Multi-Agent Squads: Shared Memory, Message Passing, and Workflow Chaining

Your agents should not operate in isolation. We are building squad orchestration into LaunchThatBot -- powered by Convex, configurable through the dashboard, and owned entirely by you.

Feb 20, 2026LaunchThatBot Team
MOFUIndie Devs

Ready to apply this in your own deployment?

Join the Discord

A single AI agent is useful. A group of agents that can share context, pass work between each other, and coordinate on complex tasks is a different category of useful entirely.

Right now, most OpenClaw users run agents in isolation. Each agent has its own memory, its own tools, its own context. If you want Agent A to hand off work to Agent B, you build that integration yourself -- custom code, manual coordination, and no built-in tooling to help.

We are building squad orchestration directly into LaunchThatBot. Not as a custom solution you have to code. As a set of pre-built patterns that you configure through the dashboard and that run on your own Convex instance.

What a squad is

A squad is a named group of agents that operate as a team. Each agent in the squad retains its own personality, tools, and capabilities. What the squad adds is a shared operational layer: ways for agents to communicate, share knowledge, and coordinate work.

You define squads through the LaunchThatBot dashboard. Assign agents to a squad, configure the orchestration patterns you want, and the underlying Convex tables and functions handle the rest.

Every squad's data lives in your Convex instance. You own it, you can query it, and you can detach from LaunchThatBot and keep using it independently. The same portability principle that applies to everything in LaunchThatBot applies to squads.

The three orchestration patterns

We are building squad orchestration around three core patterns. Each pattern solves a different coordination problem, and they compose naturally -- a squad can use all three simultaneously.

Shared memory tables

The simplest pattern: a shared knowledge base that every agent in the squad can read from and write to.

The problem it solves: Agent A learns something useful. Agent B needs that same information but has no way to access it. Without shared memory, you either duplicate the knowledge manually or accept that each agent operates with an incomplete picture.

How it works: Each squad gets a shared memory table in your Convex instance. Any agent in the squad can write observations, facts, or context to the table. Any agent in the squad can query it. The memory is structured, timestamped, and queryable -- not a flat text dump.

Example: You run a squad of agents that help you monitor your industry. Agent A tracks competitor pricing and writes price changes to shared memory. Agent B tracks industry news and writes relevant articles. Agent C generates weekly briefings by reading everything both agents have contributed. Each agent focuses on its specialty, and the shared memory means none of them operate in a vacuum.

Message passing

Direct communication between agents: one agent sends a message (with data) to another agent, triggering it to act.

The problem it solves: You want Agent A to hand off work to Agent B. Without message passing, this requires an external integration -- a webhook, a queue, a manual trigger. Each integration is custom-built and fragile.

How it works: Agents in a squad can send structured messages to each other through Convex. A message includes a type, a payload, and routing information. The receiving agent picks up the message and acts on it. Messages are persisted, so you have an audit trail of inter-agent communication.

Example: Agent A monitors an RSS feed of data sources relevant to your business. When it finds something interesting, it sends a message to Agent B with the raw content. Agent B is a specialist at summarization -- it processes the content and sends a structured summary to Agent C. Agent C takes the summary and posts it to your team's Slack channel and schedules a social media post. Three agents, each doing one thing well, connected by messages.

Workflow chaining

Defined sequences of agent actions that execute in order, with the output of each step feeding into the next.

The problem it solves: Many useful multi-agent workflows are sequential. Step 1 produces output. Step 2 uses that output as input. Step 3 uses Step 2's output. Without workflow chaining, you orchestrate this manually or build custom pipelines.

How it works: You define a workflow as an ordered chain of agent actions through the dashboard. Each step specifies which agent performs the action, what input it receives, and how its output maps to the next step's input. The workflow engine in Convex handles execution, retry logic, and state management.

Example: A content production workflow. Step 1: a research agent gathers information on a topic you specify. Step 2: a writing agent produces a draft from the research. Step 3: an editing agent reviews the draft for tone, accuracy, and formatting. Step 4: a publishing agent posts the final version to your blog or CMS. You define this chain once, trigger it with a topic, and four agents execute sequentially without manual intervention.

Configured through the dashboard, not code

A critical design decision: squad orchestration is configured through the LaunchThatBot dashboard, not through custom Convex functions you have to write.

This matters because the target audience for LaunchThatBot includes builders who chose OpenClaw specifically because they want to work at the agent level -- defining personalities, connecting tools, building workflows. They do not necessarily want to write database schemas and serverless functions to make their agents coordinate.

The dashboard provides:

  • Squad creation and management -- define squads, assign agents, set permissions
  • Shared memory configuration -- choose what types of data agents can share, set retention policies, define access patterns
  • Message routing rules -- configure which agents can message which, define message types, set up dead-letter handling for failed deliveries
  • Workflow designer -- build chains visually, define step inputs and outputs, configure retry and error handling

Under the hood, all of this translates to Convex tables, scheduled functions, and queries in your instance. If you want to customize beyond what the dashboard offers, you can -- it is your Convex instance. But you should not have to.

Why Convex makes this possible

Squad orchestration requires real-time state, reliable message delivery, and scheduled execution. These are exactly the things Convex was built for:

  • Real-time queries mean the dashboard shows live squad activity, not a snapshot from the last poll. When Agent A writes to shared memory, Agent B sees it immediately.
  • Transactional writes mean message passing is reliable. A message is either delivered or it is not -- no partial states, no lost messages in a queue somewhere.
  • Scheduled functions mean workflow chains execute reliably. If Step 2 needs to wait for Step 1 to complete, the scheduling engine handles it. If a step fails, retry logic kicks in automatically.
  • User-owned instances mean all of this runs in your Convex project. Your squad data, your inter-agent messages, your workflow history -- all queryable, all yours.

This is the same Convex backbone that already powers LaunchThatBot's deployment engine, agent sync, and operational state. Squad orchestration is an extension of the infrastructure that already exists.

The bigger picture

Shared memory, message passing, and workflow chaining are the foundation. They solve the most common coordination problems and they compose into sophisticated multi-agent systems.

But they are also the building blocks for patterns we have not thought of yet. When your agents can share knowledge, communicate directly, and execute coordinated workflows -- all through structured, queryable, real-time infrastructure on your own Convex instance -- the design space for what you can build opens up significantly.

That is the point. LaunchThatBot handles the infrastructure so you can explore what is possible when agents work together, not what is possible when you have spare time to build coordination plumbing.

Squad orchestration is in active development. If you are already on LaunchThatBot, it will be available as a new capability for your existing deployments. If you are not on LaunchThatBot yet, here is how to get started -- and your agents will be ready for squads when the feature ships.

Ready to apply this in your own deployment?

Join the Discord

Related articles

Feb 19, 2026

Managing Your Agent Squad From Your Phone

Push notifications when an agent goes down. Customizable alerts for CPU spikes and expiring keys. A real dashboard that works on a 6-inch screen. The PWA is coming.

Feb 18, 2026

How to Build an MCP Server with Cloudflare and Convex

We built an MCP server that lets AI coding agents manage LaunchThatBot deployments from inside Cursor. Here is the architecture: a TypeScript MCP server, a Cloudflare Worker proxy, and Convex as the backend. No REST API required.