Task Delegation Between Agents

How manager agents create subtasks and assign them downstream. Push delegation (manager assigns) vs. pull delegation (worker claims from open pool). Trade-offs and when to use each.

Task Delegation Patterns

What you'll learn

Three delegation patterns used in real Paperclip companies: fan-out, sequential pipeline, and manager-as-router.

Pattern 1: Fan-Out

One parent task splits into N parallel subtasks. All subtasks can run in the same or different heartbeat ticks (Paperclip processes multiple agents per tick).

Parent: "Write a complete technical blog post"
  ├── Subtask A: Research (→ Researcher)
  ├── Subtask B: SEO keywords (→ SEO Agent)
  └── Subtask C: Title options (→ Copywriter)

SQL seed:

DO $$
DECLARE parent_id uuid;
BEGIN
  INSERT INTO issues (company_id, title, assigned_agent_id, status)
  VALUES ('cid', 'Write blog post: Intro to RAG', 'manager-id', 'resolved')
  RETURNING id INTO parent_id;
  -- Manager is pre-resolved; subtasks are the real work

  INSERT INTO issues (company_id, title, parent_issue_id, assigned_agent_id, status)
  VALUES
    ('cid', 'Research: gather 5 RAG facts',   parent_id, 'researcher-id', 'open'),
    ('cid', 'SEO: find 10 keyword targets',    parent_id, 'seo-id',        'open'),
    ('cid', 'Copywriting: draft 5 title ideas', parent_id, 'writer-id',    'open');
END $$;

All three subtasks are open simultaneously — the heartbeat can claim them in parallel (one per tick if max_concurrent_agents = 3).

Pattern 2: Sequential Pipeline

Each step depends on the previous. Implemented by creating each subtask only after the previous resolves — either via a trigger or a coordinator agent.

Step 1: Researcher → result stored in issues.result
Step 2: Writer uses Researcher result (reads from parent/sibling)
Step 3: Editor uses Writer result

Trigger approach — create step 2 when step 1 resolves:

CREATE OR REPLACE FUNCTION create_pipeline_next()
RETURNS TRIGGER LANGUAGE plpgsql AS $$
BEGIN
  -- When step 1 resolves, create step 2
  IF NEW.title LIKE 'Step 1:%' AND NEW.status = 'resolved' THEN
    INSERT INTO issues (company_id, title, parent_issue_id, assigned_agent_id,
                        description, status)
    VALUES (
      NEW.company_id,
      'Step 2: Write draft from research',
      NEW.parent_issue_id,
      (SELECT id FROM agents WHERE role = 'Writer' AND company_id = NEW.company_id LIMIT 1),
      'Research notes: ' || LEFT(NEW.result, 500),
      'open'
    );
  END IF;
  RETURN NEW;
END;
$$;

Pattern 3: Manager as Router

A manager agent reads the incoming task and creates the right subtasks dynamically. The manager's system prompt tells it to output a JSON subtask list:

You are a Task Router. Given a high-level task, decompose it into specific subtasks.
Output ONLY valid JSON in this format:
{
  "subtasks": [
    {"title": "...", "agent_role": "...", "priority": "medium"}
  ]
}

Paperclip parses the JSON result and auto-creates issues for each subtask, assigned to agents matching agent_role.

Choosing a Pattern

Checkpoint ✓

• [ ] You can implement fan-out by seeding parallel subtasks
• [ ] You understand the sequential pipeline trigger approach
• [ ] You know when a manager-as-router is the right choice