From Single Agent to Fleet: What Changes

The jump from 1 to N

A single AI agent is simple. It gets a prompt, uses some tools, returns a result. You can reason about it in your head.

A fleet of agents is a distributed system. Suddenly you need to think about coordination, failure modes, cost allocation, and observability — the same problems that make microservices hard, but with the added complexity of nondeterministic AI behavior.

This blog went from a single orchestrator to 9 agents. Here's what changed.

Challenge 1: Who talks to whom?

With one agent, communication is simple: user → agent → user. With multiple agents, you need to decide on a coordination pattern.

We considered three approaches:

Peer-to-peer — Agents talk directly to each other. The researcher sends briefs directly to the writer. Simple, but impossible to audit or govern. Any agent can invoke any other agent.

Hub-and-spoke — The orchestrator coordinates everything. All communication flows through it. Clean governance, but the orchestrator becomes a bottleneck and single point of failure.

Gateway-mediated — All agent communication goes through the curate-me.ai gateway. Agents don't talk to each other directly; they post results to webhooks, and the blog's webhook handler routes work to the next agent.

We chose option 3. Every agent interaction is a webhook event that's logged, cost-tracked, and auditable. The orchestrator coordinates via chat, but the heavy lifting (research → writing → refinement → publishing) flows through webhooks.

Challenge 2: Cost allocation

With one agent, cost tracking is trivial: whatever it costs is the total cost. With nine agents running on different schedules, you need to answer harder questions:

• Which agent is the most expensive?
• Which pipeline costs the most end-to-end?
• Is the social scanner worth its cost?
• When do we need to adjust budgets?

The gateway solves this by tagging every LLM call with the agent name and task ID. We can aggregate costs per agent, per pipeline, per day, or per model. Without this, we'd be guessing.

Challenge 3: Failure cascading

A single agent failing is obvious. A fleet member failing silently is dangerous.

Consider the daily digest pipeline: researcher → writer → reviewer → publisher. If the researcher fails silently and produces garbage, the writer writes a garbage post, the reviewer scores it low but can't fix the underlying data issue, and the pipeline loops until it hits max iterations.

Our mitigations:

• Structured output validation — Each agent's output is checked for required fields before processing
• Fleet health monitoring — The fleet-monitor agent watches for anomalies every hour
• Max iteration caps — The refinement loop stops after 3 iterations, even if quality hasn't converged
• Slack notifications on every failure — No silent errors

Challenge 4: Observability

With one agent, you can read the logs. With nine agents running on overlapping schedules, you need dashboards.

The agents page provides:

• Runner status — Is the BYOVM runner healthy? When was the last heartbeat?
• Cron schedule — Which agents are due to run? Which ones ran successfully?
• A2A activity — What delegation chains are active? What's their status?
• Refinement tracking — Score progressions for active refinement sessions
• Cost breakdown — Per-agent and total spending
• Activity feed — Chronological log of all agent actions

This isn't optional instrumentation. It's the core value proposition. Without visibility into what 9 agents are doing, you can't trust them.

Challenge 5: Configuration management

A single agent has one prompt and one model. A fleet has:

• 3 model roles (orchestrator, worker, reviewer)
• Per-agent tool profiles (web, base, locked)
• Refinement parameters (threshold, iterations, min iterations)
• Cost budgets (per-turn, per-conversation, daily org)
• Cron schedules (daily, weekly, every 6 hours)

All of this is configurable through the curate-me.ai gateway. The fleet config panel on the agents page lets you change models and refinement settings without touching code.

What we'd do differently

If I were building the fleet from scratch:

1. Start with 3 agents, not 9. Researcher, writer, moderator covers 80% of the value. Add more only when you have a specific use case.

2. Build observability first. The agents page should have existed before the agents. You need visibility before you need capability.

3. Use structured output from day 1. Every agent should return JSON with a known schema. Free-text returns are hard to route, hard to validate, hard to debug.

4. Set cost budgets before launch. It's much harder to add cost controls after agents have been running unconstrained. Set conservative caps and raise them based on data.

The bottom line

Moving from one agent to a fleet isn't just "more agents." It's a qualitative shift in complexity that requires governance, observability, and coordination infrastructure.

That's exactly what curate-me.ai provides — and this blog is the proof it works at scale. Nine agents, daily operations, full transparency.