Common Workflow Patterns

Pipeline (sequential stages), parallel fan-out (N agents simultaneously), review gate (output must be approved before next step), and escalation (auto-escalate blocked tasks to manager).

Real-World Workflow Patterns

What you'll learn

Six proven workflow patterns that real Paperclip companies use, with SQL and configuration examples for each.

Pattern 1: The Research Pipeline

Input issue → Researcher → Writer → Editor → Final output

Each step reads the previous step's result and produces its own. Implemented as a sequential pipeline (trigger-based, covered in pcl-32).

Useful for: blog posts, reports, research briefs, documentation.

Pattern 2: The Review Loop

Writer creates draft → Editor reviews →
  approved: mark resolved
  rejected: Writer revises

-- Review loop: editor flags rejection in result JSON
-- {"status": "rejected", "feedback": "needs more examples"}
-- Trigger creates a revision issue

CREATE OR REPLACE FUNCTION handle_review_result() RETURNS TRIGGER AS $$
DECLARE
  result_json jsonb;
BEGIN
  result_json := NEW.result::jsonb;
  IF result_json->>'status' = 'rejected' THEN
    INSERT INTO issues (company_id, title, description, assigned_agent_id, parent_issue_id, status)
    VALUES (
      NEW.company_id,
      'Revision: ' || (SELECT title FROM issues WHERE id = NEW.parent_issue_id),
      'Editor feedback: ' || (result_json->>'feedback'),
      (SELECT assigned_agent_id FROM issues WHERE id = NEW.parent_issue_id),
      NEW.parent_issue_id,
      'open'
    );
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Pattern 3: The Quality Gate

Before any output is marked "done," it passes through a quality-check agent:

Worker resolves issue → Quality Agent checks result →
  pass: final status = 'verified'
  fail: back to worker as revision

Enable in Company Settings → Workflows → Quality gate agent.

Pattern 4: The Inbox Processor

A high-volume agent continuously processes a feed of incoming items (emails, support tickets, social mentions):

-- Feed items are inserted as issues by an external webhook
-- Processor agent claims them in FIFO order, classifies/responds
INSERT INTO issues (company_id, title, metadata, priority, assigned_agent_id)
VALUES (
  'cid',
  'Support ticket: ' || ticket_id,
  jsonb_build_object('ticket_id', ticket_id, 'channel', 'email'),
  'medium',
  'support-agent-id'
);

Pattern 5: The Monitoring Loop

An agent runs on a schedule, checks an external condition, and creates action issues when something needs attention:

Monitor Agent (every 5 min) → checks metrics API →
  if error_rate > 5%: create CRITICAL issue for On-Call Agent

Pattern 6: The Cost-Aware Downgrade

When budget is low, automatically switch from expensive to cheap models:

-- View: agents with <20% budget remaining
CREATE VIEW budget_strained_agents AS
SELECT a.id, a.name,
       SUM(ce.cost_usd) AS spent,
       a.monthly_budget_usd,
       ROUND(100 * SUM(ce.cost_usd) / a.monthly_budget_usd) AS pct_used
FROM agents a
JOIN cost_events ce ON ce.agent_id = a.id
WHERE ce.created_at >= date_trunc('month', now())
GROUP BY a.id
HAVING ROUND(100 * SUM(ce.cost_usd) / a.monthly_budget_usd) >= 80;

Pair with a shell agent that patches adapter_config.model to a cheaper model.

Checkpoint ✓

• [ ] You can describe at least three of the six workflow patterns
• [ ] You understand the review loop trigger pattern
• [ ] You know how the quality gate differs from the review loop