How to Run a Team of Specialized AI Agents From One Chat

I spent the better part of a week reconstructing a setup that a solo founder named Trebuh posted on X in early 2026. Four AI agents — Milo (strategy), Josh (business), a marketing agent, and a dev agent — all running on a VPS, all reachable from a single Telegram chat. He called it ‘a real small team available 24/7.’ I wanted to see if the seams showed up close.

They didn’t. The setup held. And once I understood the architecture, I realized the interesting problem wasn’t spinning up four agents — it was making them feel like a team instead of four separate chat windows you have to babysit.

There’s a gap in every multi-agent setup that nobody talks about when they demo it. I’ll show you what it is after the framework — it changes how you structure the whole thing. For now, here’s how to build it from scratch.

If you want to understand the broader landscape before going deep here, the AI automation pillar is a good foundation. And if you’re still evaluating platforms, AI agent platforms breaks down your hosting options.

Why One Agent Can’t Run Your Whole Business

The single-agent approach breaks down fast. A single agent’s memory fills up quickly when it’s juggling strategy, code, marketing research, and business analysis at the same time. You end up with shallow answers across every domain instead of deep expertise in any one.

The underlying mechanics are straightforward. Multi-agent systems support two primary interaction patterns: sequential (agents hand off to each other in a defined order, each using the prior agent’s output) and hierarchical (a team lead agent delegates to specialists and synthesizes their results). Trebuh’s setup is hierarchical — Milo is the orchestrator, the rest are specialists.

The orchestrator’s job isn’t to do the work. It manages how agents interact, passes context between them, and decides what gets escalated. Think of it as the agent equivalent of a tech lead — mostly routing and unblocking, not coding.

Tool-specific chatbots can’t do this. They’re great inside one product but can’t collaborate across your CRM, project tracker, codebase, and marketing stack. A coordinated agent team can — because the coordination layer is the agents themselves, not a third-party integration hub.

How to Build Your Multi-Agent Team: The Full Setup

This is the actual configuration from the reference setup. Four agents, one Telegram group, one VPS. Here’s the structure and the decisions behind each piece.

Step 1: Define your agents and their roles

Each agent gets a SOUL.md file — a plain text document that defines who they are, what they own, and how they communicate. This isn’t just flavor text. Personality matters more than you’d expect: giving agents distinct names and communication styles makes it natural to ‘talk to your team’ instead of wrestling with a generic AI interface.

Here’s the four-agent configuration that works:

• Milo (Strategy Lead) — Claude Opus, big-picture thinker, handles OKRs, coordinates the other agents, runs morning standup at 8 AM and end-of-day recap at 6 PM
• Josh (Business & Growth) — Claude Sonnet, analytical, owns pricing strategy, KPI tracking, revenue modeling; pulls key metrics every morning at 9 AM
• Marketing Agent — Gemini (strong at web research and long-context analysis), owns content ideation, competitor monitoring, Reddit/X trend tracking; surfaces 3 content ideas daily at 10 AM
• Dev Agent — Claude Opus or a coding-optimized model, owns code review, architecture decisions, CI/CD health monitoring, technical documentation

Step 2: Set up shared memory with private agent contexts

This is the architectural decision that separates a real agent team from four disconnected chatbots. Every agent reads from shared project files. Every agent also has private storage for domain-specific notes.

team/
├── GOALS.md           # Current OKRs and priorities (all agents read)
├── DECISIONS.md       # Key decisions log (append-only)
├── PROJECT_STATUS.md  # Current project state (updated by all)
├── agents/
│   ├── milo/          # Milo's private context and notes
│   ├── josh/          # Josh's private context
│   ├── marketing/     # Marketing agent's research
│   └── dev/           # Dev agent's technical notes

The combination is what matters. Shared memory gives all agents common ground — goals, key decisions, current project state. Private context lets each agent accumulate domain expertise without that knowledge bleeding into other agents’ reasoning. When Josh pulls competitor pricing data, it doesn’t clutter Milo’s strategic context.

Step 3: Configure Telegram routing

Beacon says: one voice, many helpers — that’s not magic, that’s just good coordination.

One Telegram group. All four agents listen. Each responds only when tagged. Untagged messages go to Milo by default.

Each agent’s response loop is: read shared files → read private notes → process → respond → update shared files if needed. This is what keeps the team’s knowledge synchronized without manual bridging.

Step 4: Set the heartbeat schedule

Scheduled proactive tasks are the real flywheel. The value isn’t just in responding when you ask — it’s in agents surfacing insights before you think to ask. Here’s the schedule from the reference configuration:

• 8:00 AM — Milo posts morning standup (aggregates overnight agent activity)
• 9:00 AM — Josh pulls and summarizes key metrics
• 10:00 AM — Marketing agent surfaces 3 content ideas from trending topics
• Every 2 hours — Marketing agent monitors Reddit/X for relevant keyword mentions
• 6:00 PM — Milo posts end-of-day recap with progress toward weekly goals
• Weekly (Monday) — Milo drafts weekly priorities with input from all agents
• Weekly (Friday) — Josh compiles weekly metrics report

Step 5: Skills and infrastructure you need

• OpenClaw running on a VPS or always-on machine
• Telegram skill for the shared control interface
• sessions_spawn / sessions_send for multi-agent coordination
• Shared file system for team memory (the folder structure above)
• Individual API keys for each model provider if you’re using mixed models (Claude, Gemini, etc.)

The Gap Nobody Builds First (And Why You Should)

Here’s the thing I promised to come back to. When most people think about building a multi-agent team, they assume the hard part is coordination UI — some dashboard where you can see all four agents and what they’re doing. That’s the wrong problem.

What we assumed: better visualization solves the coordination problem. What we learned: the real bottlenecks are cross-context agent communication, mobile access, and agents that keep running when you’re not at your desk.

This comes directly from Dan Malone’s writeup on building a multi-agent setup in a Telegram forum. His conclusion: ‘The gap wasn’t coordination UI. What I actually lacked was a clean way for specialist contexts to talk to each other, access to those same contexts from my phone, and agents that keep running when I leave my desk.’

Telegram solves all three. It’s the interface you already have on your phone. The agents run on a VPS — they don’t stop when you close your laptop. And because they share files and respond to the same group, specialist context flows naturally without you bridging it manually.

This is also why the @jdrhyne setup — 15+ agents across 3 machines, all controlled from a single Discord server — works. The messaging interface isn’t the control plane as an afterthought. It IS the control plane. Build around that from day one.

For more examples of what this looks like in practice across different domains, agentic AI examples shows 15 real-world deployments worth studying before you finalize your own team structure.

Where This Setup Falls Apart

The most common failure mode I’ve seen: someone spins up all four agents on day one, gives them vague SOUL.md files, and wonders why every response feels like the same generic AI in a costume. The agents need distinct responsibilities with clear boundaries — not just different names.

• Overlapping roles cause conflicts. If both Milo and Josh can answer business strategy questions, you’ll get inconsistent advice and no clear owner. Define hard boundaries in each SOUL.md.
• Shared files go stale. If agents update PROJECT_STATUS.md with every minor action, it becomes noise. Set a rule: only decisions and meaningful status changes get written to shared files.
• Wrong model for the task. Using a reasoning-heavy model for a task like monitoring Reddit mentions every 2 hours will drain your API budget fast and add latency that makes the schedule slip.
• VPS goes down, team goes silent. The agents run on your VPS — if it’s not monitored with auto-restart, one crash means no morning standup, no metrics, no content ideas until you notice. Set up a watchdog.
• Heartbeat overload. If every agent sends a Telegram message every 2 hours, you’ll start ignoring the group. Tune the schedule so messages are signal, not noise.
• Starting with 4 when you should start with 2. Launch Milo and one specialist. Add agents when you hit an actual bottleneck, not because the configuration looks complete on paper.

Your Week-One Multi-Agent Team Checklist

This is the order that works. Don’t skip to step 4 because the infrastructure feels more exciting than the SOUL.md files — the configuration work is where teams succeed or fail.

1. Provision a VPS with at least 2 GB RAM and install OpenClaw. Budget $10-20/month for the VPS — this is the infrastructure cost that runs your whole team.
2. Write SOUL.md files for 2 agents only — your team lead (Milo pattern) and one specialist relevant to your biggest current bottleneck. Keep each SOUL.md under 300 words with hard boundaries on responsibilities.
3. Create the shared file structure — GOALS.md, DECISIONS.md, PROJECT_STATUS.md, and a private folder per agent. Write your current OKRs and top 3 project priorities into GOALS.md before launching.
4. Configure your Telegram group and routing — one group, both agents added, tag routing defined. Test with @lead and @specialist tags before scheduling anything.
5. Set a minimal heartbeat schedule — morning standup at 8 AM from the team lead, one scheduled task from your specialist. Run for 5 days before adding more scheduled tasks.
6. If you’re on Claude Opus for both agents, move the specialist to Claude Sonnet or your preferred fast model. The team lead needs deep reasoning; the specialist usually doesn’t for routine tasks. This typically reduces API costs by 40-60% for the specialist’s scheduled work.
7. Add API keys for a second model (e.g., Gemini for the marketing agent) only after the 2-agent setup is stable for at least a week.
8. Add agent 3 only when you hit a clear bottleneck — a consistent question type that neither current agent handles well, or a domain where you’re still doing the work yourself.
9. Verify VPS auto-restart is configured — your agents should survive a reboot without manual intervention. Test this in week one, not after your first outage.

What a Multi-Agent Team Actually Changes About Your Day

• Start your morning at your current role rather than context-switching — Milo’s 8 AM standup tells you what happened overnight and what needs attention
• Tag the right specialist for focused, deep answers instead of getting shallow responses from a generalist agent stretched across too many domains
• Insights from marketing research automatically inform dev priorities through shared files — no manual bridging
• Match model capability to task complexity — don’t overpay for simple scheduled tasks; reserve expensive models for strategy and complex code
• Start with 2 agents, not 4 — the flywheel starts on day one, and you’ll know what to add next because you’ll feel the gap
• The real value emerges from scheduled proactive tasks: agents surfacing information before you ask is a fundamentally different working pattern than querying an AI when you remember to

Frequently Asked Questions

What's the minimum setup to get started — do I need all four agents?

No. Start with a team lead and one specialist. Two agents that are well-configured outperform four agents with vague roles. Add agents when you identify a specific bottleneck — a question type neither current agent handles well, or a domain where you’re still doing the work manually.

Can I use different AI models for different agents?

Yes, and you should. Match model capability to task complexity: use reasoning-heavy models like Claude Opus for strategic synthesis and complex coding, and faster analytical models like Claude Sonnet for business metrics and routine analysis. Models with strong web research capabilities work well for marketing-style tasks involving long context. This keeps costs manageable without sacrificing quality where it matters.

Does this require coding experience to set up?

The configuration itself — SOUL.md files, shared folder structure, Telegram routing — is plain text. You’ll need to provision a VPS and install OpenClaw, which requires basic terminal comfort. The @jdrhyne report of 15+ agents across 3 machines notes that ‘IT built most of this, just by chatting’ — meaning the agent itself can help you configure the rest once the base is running.

What happens if two agents give conflicting advice?

This is what the team lead pattern solves. Milo’s role includes synthesizing insights from all agents into actionable decisions. If Josh and the marketing agent disagree on a product priority, you tag @milo and ask for a synthesis. Hard role boundaries in SOUL.md prevent most conflicts before they start — overlapping responsibilities are the root cause.

Can I use WhatsApp or Discord instead of Telegram?

Yes. The pattern works with any messaging platform that supports group chats and tagging. @danpeguine runs two agents collaborating in the same WhatsApp group. @jdrhyne uses Discord. Telegram is the reference configuration here, but the routing logic — tag to agent, no tag to team lead — works wherever your preferred messaging lives.

Sources

• Multi-Agent Specialized Team (Solo Founder Setup) — OpenClaw Use Cases
• Building a Multi-Agent AI Team in a Telegram Forum — Dan Malone
• The Complete Guide to Multi-Agent Platforms — Credal.ai
• AI Agents from Zero to Hero Part 3 — Towards Data Science
• Multi-Agent Systems: Coordinate AI Workers — Gantz.ai
• Building Effective Agents — Anthropic