Every agent framework gives you the same thing: a way to define agents and a way to call them. Tool registries, system prompts, model selection. The spawn problem is solved.

What none of them give you is the coordination layer. When Agent A completes a design task, who tells Agent B to upload it? When Agent B fails mid-upload, does Agent A's work just vanish? When Agent C needs context from A's output, how does it get that context without re-doing A's work?

This is the missing service layer. It's not the queue. It's not the scheduler. It's the 400 lines between "task complete" and "next task started" that nobody talks about because framework demos never get that far.

The Handoff Problem

Our designer finishes an illustration. The product agent needs to upload it. Simple pipeline, right?

Without a service layer, you get one of two patterns:

Pattern 1: Monolithic orchestrator. One mega-agent does everything sequentially. It generates the image, uploads to Printify, syncs the database, runs QA. This works until it hits a rate limit at step 3 of 7 and you lose all the work from steps 1-2.

Pattern 2: Fire-and-forget. Designer publishes to a shared filesystem. A cron job checks for new files. Maybe the product agent picks it up. Maybe it doesn't. When it fails, nobody knows until a human notices the product isn't on the site three days later.

The service layer is Pattern 3: explicit task chains with guaranteed delivery, failure tracking, and state propagation.

Task Chains: The Core Primitive

# WorkQueueTask model (simplified)
class WorkQueueTask < ApplicationRecord
  def complete!
    update_columns(status: "complete", completed_at: Time.current)
    spawn_next_tasks
  end

  private

  def spawn_next_tasks
    return unless next_tasks.present?
    next_tasks.each do |task_def|
      WorkQueueTask.create!(
        role: task_def["role"],
        subject: task_def["subject"],
        status: "ready",
        parent_task_id: id
      )
    end
  end
end

When the designer completes, spawn_next_tasks creates the product upload task automatically. The chain is declared, not implicit:

# Task definition with chain
role: designer
subject: "Create cyberpunk hoodie illustration"
next_tasks:
  - role: product
    subject: "Upload from {{parent_task_id}}"
  - role: qa
    subject: "QA Review: cyberpunk hoodie"

The product agent picks up its task. It knows who created it (parent_task_id) and can read the parent's output to find the file path. QA runs after product. The chain is deterministic — same completion always triggers the same downstream work.

Failure Propagation

Chains create a dependency graph. What happens when a node fails?

def fail!
  self.failure_count += 1
  if failure_count >= 3
    update_columns(status: "failed", failure_count: failure_count)
    # Chain stops here. No children spawned.
  else
    update_columns(status: "ready", failure_count: failure_count)
    # Retry. Children wait.
  end
end

Three retries, then permanent failure. Children never spawn from a failed parent. The chain doesn't cascade failures — it stops cleanly.

This sounds obvious. But without it, you get the 319-retry incident: a rate-limited agent retrying indefinitely because nothing counted failures or enforced a budget. The service layer's job is making "stop" the default, not "keep trying."

State Handoffs Without Shared Memory

Agents don't share memory. Designer's context window knows nothing about product upload. But they need to coordinate.

The service layer doesn't share context — it shares references:

# Product agent reads parent output
parent = WorkQueueTask.find(task.parent_task_id)
# Parent's completion output contains file path
file_path = parent.output.match(/OUTPUT_FILE: (.+)/)[1]

Each agent writes structured output (OUTPUT_FILE:, PRODUCT_ID:, ERROR:). Downstream agents parse what they need. No shared vector store. No cross-agent memory pollution. Each agent maintains its own namespace — the service layer just routes the pointers.

This is deliberate. When agents share memory pools, you get retrieval contamination — Agent A's debugging notes pollute Agent B's product descriptions. One of our competitors reported 22.8% cross-agent retrieval errors from a shared memory pool. Isolation at the service layer prevents this entirely.

Heartbeat and Stale Detection

Agents die. Rate limits, OOM, API timeouts. The service layer needs to know.

# Three-tier stale detection
STALE_THRESHOLDS = {
  never_started: 5.minutes,   # Claimed but never ran
  no_heartbeat: 15.minutes,   # Started but went silent
  overtime: 60.minutes         # Running too long
}

def detect_stale_tasks
  claimed_tasks.each do |task|
    threshold = determine_threshold(task)
    if task.last_heartbeat_at < threshold.ago
      task.update_columns(status: "ready", owner: nil)
    end
  end
end

Stale tasks get reset to ready for another agent to claim. No human intervention. The agent that died doesn't know it was replaced — it might even complete later. The service layer handles the dedup: if a task transitions to complete but was already re-claimed, the second completion is a no-op.

What This Replaces

Without this layer, you're writing ad-hoc coordination in every agent's prompt. "After completing the design, create a task for the product agent." That works until:

1. The agent forgets (stateless sessions)
2. The agent formats the task wrong (no schema enforcement)
3. The agent dies before creating the downstream task (fire-and-forget)
4. Two agents create the same downstream task (no dedup)

The service layer replaces trust-based coordination with structural coordination. Agents don't need to remember to chain work — the chain is declared in the task definition before the agent ever starts.

The Uncomfortable Truth

This isn't technically hard. It's a state machine, some ActiveRecord callbacks, a monitoring loop. Maybe 400 lines of real logic.

But every team building multi-agent systems skips it. They build the agents first — the interesting part. Then they wire them together with cron jobs and shared directories. Then they spend three months debugging silent failures, lost work, and duplicate processing.

The service layer isn't glamorous. It's plumbing. But it's the difference between a demo that works once and a system that runs unattended.

Previously: How We Orchestrate 10 AI Agents with Claude Code covers the spawn mechanism and daemon loop. How Agents Survive Rate Limits covers the retry budget that feeds into fail!. Next time: contract tests that verify agents honor these boundaries without testing their internals.