Custom Multi-Tiered Workflows:
Architecture & Design

What Multi-Tiered Workflows Are (And When You Need Them)

The Limitation of Linear Workflows

A standard workflow on CEO.ai is linear: Trigger → Agent A → Agent B → Agent C → Output. Data flows in one direction. Each step happens after the previous step completes. This covers a huge range of business processes — and most teams should start here.

But some processes don't fit a straight line.

Consider an inbound request processing system for a 60-person services company:

1. A request arrives (from a form, email, or messaging platform)
2. It needs to be classified: is it a sales inquiry, a support issue, a partnership request, or a job application?
3. Based on the classification, it routes to a completely different processing pipeline:
   • Sales inquiries get qualified, scored, and routed to the right rep
   • Support issues get triaged, prioritized, and either auto-resolved or escalated
   • Partnership requests get evaluated against criteria and forwarded to the BD team
   • Job applications get screened, scored, and entered into the hiring pipeline
4. At the end of the day, all processed requests — regardless of type — feed into a daily summary report

This isn't one workflow. It's a system of workflows with:

• Conditional branching — different paths based on classification
• Parallel processing — different pipelines running independently
• Convergence — results from all pipelines feeding into one report
• Human checkpoints — approvals at different points in different pipelines

This is what multi-tiered workflows are built for.

The Definition

A multi-tiered workflow is a system of interconnected workflow stages where outputs from one tier feed into the next, with support for conditional routing, parallel execution, nested workflows, and cross-tier data sharing.

Think of it as workflow architecture rather than workflow configuration. You're designing a system, not a sequence.

When You Need Multi-Tiered Workflows

The Four Execution Patterns

Every multi-tiered workflow is built from four fundamental patterns. Understanding these patterns — and knowing when to combine them — is the core skill of workflow architecture.

Pattern 1: Sequential

The foundation. Steps execute one after another. Output from step N becomes input for step N+1.

  
  ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐  
  │ Agent A  │────▶│ Agent B  │────▶│ Agent C  │────▶│  Output  │  
  │ (Extract)│     │(Validate)│     │(Transform)│     │  (Store) │  
  └──────────┘     └──────────┘     └──────────┘     └──────────┘  

When to use: When each step depends on the output of the previous step. Order matters. No step can start until the one before it finishes.

Example: Invoice processing — extract data from PDF → validate against PO → transform to accounting format → insert into accounting system.

Pattern 2: Parallel

Multiple steps execute simultaneously. A single input fans out to multiple agents, and the results are collected when all complete.

  
                    ┌──────────────┐  
               ┌───▶│   Agent A    │───┐  
               │    │  (Analyze)   │   │  
  ┌────────┐   │    └──────────────┘   │    ┌────────────┐  
  │  Input  │──┤                       ├───▶│  Collect   │  
  │ (Split) │  │    ┌──────────────┐   │    │  (Merge)   │  
  └────────┘   ├───▶│   Agent B    │───┤    └────────────┘  
               │    │  (Research)  │   │  
               │    └──────────────┘   │  
               │    ┌──────────────┐   │  
               └───▶│   Agent C    │───┘  
                    │  (Summarize) │  
                    └──────────────┘  

When to use: When multiple independent analyses or actions need to happen on the same input, and no step depends on another's output. All steps can start immediately.

Example: A new client project kickoff — simultaneously: Agent A creates the project workspace, Agent B generates the welcome email, Agent C produces the onboarding checklist, Agent D sets up billing. All four can happen at once because none depends on the others.

Pattern 3: Conditional

The input is evaluated and routed to different processing paths based on its content, category, or other criteria.

  
                              ┌──────────────┐  
                  condition A │   Pipeline A  │  
               ┌─────────────▶│  (Sales flow) │  
               │              └──────────────┘  
  ┌────────┐   │              ┌──────────────┐  
  │ Router │───┤  condition B │   Pipeline B  │  
  │ Agent  │   ├─────────────▶│(Support flow) │  
  └────────┘   │              └──────────────┘  
               │              ┌──────────────┐  
               │  condition C │   Pipeline C  │  
               └─────────────▶│  (HR flow)   │  
                              └──────────────┘  

When to use: When different types of input need fundamentally different processing. The router agent makes the classification decision, and each downstream pipeline is optimized for its specific input type.

Example: The inbound request system described in the introduction. A router agent classifies the request, then routes it to the appropriate department-specific pipeline.

Pattern 4: Hybrid

Real-world processes almost always combine patterns. A conditional branch may contain parallel sub-steps. A sequential pipeline may fan out at one point and converge later. Hybrid patterns are the norm, not the exception.

  
  ┌─────────┐     ┌────────┐  
  │ Trigger │────▶│ Router │──────────────────────────────┐  
  └─────────┘     └────────┘                              │  
                      │                                    │  
            ┌─────────┴──────────┐                        │  
            ▼                    ▼                        ▼  
  ┌──────────────┐     ┌──────────────┐          ┌──────────────┐  
  │  PIPELINE A  │     │  PIPELINE B  │          │  PIPELINE C  │  
  │              │     │              │          │              │  
  │ ┌────┐ ┌────┐│     │ ┌────┐       │          │ ┌────┐       │  
  │ │ A1 │ │ A2 ││     │ │ B1 │       │          │ │ C1 │       │  
  │ └──┬─┘ └──┬─┘│     │ └──┬─┘       │          │ └──┬─┘       │  
  │    └──┬───┘  │     │    ▼         │          │    ▼         │  
  │       ▼      │     │ ┌────┐       │          │ ┌─────┐      │  
  │    ┌────┐    │     │ │ B2 │       │          │ │Human│      │  
  │    │ A3 │    │     │ └──┬─┘       │          │ │Check│      │  
  │    └──┬─┘    │     │    ▼         │          │ └──┬──┘      │  
  │       ▼      │     │ ┌────┐       │          │    ▼         │  
  └───────┼──────┘     │ │ B3 │       │          │ ┌────┐       │  
          │            │ └──┬─┘       │          │ │ C2 │       │  
          │            └────┼─────────┘          │ └──┬─┘       │  
          │                 │                    └────┼─────────┘  
          │                 │                         │  
          └────────────┬────┴─────────────────────────┘  
                       ▼  
              ┌──────────────┐  
              │  AGGREGATION │  
              │  (Collect +  │  
              │   Report)    │  
              └──────────────┘  

In this hybrid:

• Conditional routing at the top (Router sends to Pipeline A, B, or C)
• Parallel execution within Pipeline A (A1 and A2 run simultaneously, then A3 collects their outputs)
• Sequential execution within Pipeline B (B1 → B2 → B3)
• Human-in-the-loop within Pipeline C (C1 → Human approval → C2)
• Convergence at the bottom (all pipeline outputs feed into an aggregation tier)

When to use: When your process genuinely requires this complexity. Don't build a hybrid workflow when a linear one will do — but don't force a complex process into a linear shape when it naturally branches and converges.

Designing Tier Boundaries: How to Decompose Complex Processes

The most important architectural decision in multi-tiered workflows is where to draw the boundaries between tiers. Get this right and your system is maintainable, debuggable, and extensible. Get it wrong and you have a tangled mess that's harder to fix than the manual process it replaced.

The Tier Boundary Principles

Example data contract between a classification tier and a processing tier:

{  
  "requestId": "req-12345",  
  "classification": "sales_inquiry",  
  "confidence": 0.94,  
  "extractedData": {  
    "contactName": "Sarah Chen",  
    "company": "Acme Manufacturing",  
    "interest": "workflow automation",  
    "urgency": "high"  
  },  
  "rawInput": "...",  
  "timestamp": "2025-01-15T09:30:00Z"  
}

When the processing tier receives this payload, it knows exactly what to expect. No ambiguity. No implicit assumptions.

A Decomposition Example

Business process: End-of-day operations close for an e-commerce company.

  
  TIER 1: TRIGGER & DATA COLLECTION  
  ┌─────────────────────────────────────────────┐  
  │ Schedule: 6pm daily                          │  
  │ Agent: Data Collector                        │  
  │ Responsibility: Pull all pending items from  │  
  │ all systems into a unified daily payload     │  
  │ Output: Structured daily data package        │  
  └─────────────────┬───────────────────────────┘  
                    │  
        ┌───────────┼───────────┐  
        ▼           ▼           ▼  
  TIER 2A:       TIER 2B:    TIER 2C:  
  FULFILLMENT    FINANCIAL    COMMUNICATION  
  ┌──────────┐  ┌──────────┐  ┌──────────┐  
  │Process   │  │Reconcile │  │Customer  │  
  │orders,   │  │payments, │  │notifs,   │  
  │shipping, │  │generate  │  │internal  │  
  │inventory │  │financial │  │alerts    │  
  └────┬─────┘  │summary   │  └────┬─────┘  
       │        └────┬─────┘       │  
       └─────────────┼─────────────┘  
                     ▼  
  TIER 3: AGGREGATION & REPORTING  
  ┌─────────────────────────────────────────────┐  
  │ Collect results from all Tier 2 pipelines    │  
  │ Generate daily close report                  │  
  │ Post to Slack, email to leadership           │  
  └─────────────────────────────────────────────┘  

Why this is better:

• Each tier has one job
• Tiers 2A, 2B, and 2C run in parallel — the close process finishes faster
• If fulfillment processing fails, financial reconciliation and customer communications still complete
• Each tier can be tested independently with sample data
• Adding a new Tier 2 pipeline (e.g., "Tier 2D: Analytics Update") requires no changes to existing tiers

Human-in-the-Loop Architecture: Approval Flows and Escalation

Human-in-the-loop (HITL) steps are where you insert human judgment, approval, or oversight into an automated workflow. In multi-tiered workflows, the design of these steps significantly impacts both the workflow's reliability and the humans' experience.

Placement Patterns

  
  TIER 1           HUMAN            TIER 2  
  ┌──────────┐    ┌──────────┐    ┌──────────┐  
  │ Generate │───▶│ Review & │───▶│ Send to  │  
  │ proposal │    │ approve  │    │ client   │  
  └──────────┘    └──────────┘    └──────────┘  

  
                              ┌──────────┐  
                  if flagged  │  Human   │  
               ┌─────────────▶│  Review  │──┐  
               │              └──────────┘  │  
  ┌──────────┐ │                            │  ┌──────────┐  
  │ Process  │─┤                            ├─▶│  Output  │  
  │ (Agent)  │ │                            │  └──────────┘  
  └──────────┘ │  if normal   ┌──────────┐  │  
               └─────────────▶│ Continue │──┘  
                              │ (auto)   │  
                              └──────────┘  

  
  ┌──────────┐     ┌──────────┐     ┌──────────┐  
  │ Process  │────▶│ Complete │────▶│  Output  │  
  │ (Agent)  │     │ (Agent)  │     │  (Store) │  
  └──────────┘     └─────┬────┘     └──────────┘  
                         │  
                         ▼  
                   ┌──────────┐  
                   │  Notify  │  
                   │  human   │  
                   │  (async) │  
                   └──────────┘  

HITL Design Best Practices

Event-Driven Design: Webhooks, Triggers, and Workflow Chaining

Multi-tiered workflows are inherently event-driven. Each tier fires based on an event — a schedule, a webhook, the completion of a previous tier, or an API call.

Webhook-Based Triggers

Webhooks are the backbone of event-driven workflows. An external system sends an HTTP request to a CEO.ai endpoint, and a workflow fires.

Common webhook sources:

Workflow Chaining

The most powerful pattern in multi-tiered design: the completion of one workflow triggers another.

  
  WORKFLOW 1                WORKFLOW 2                WORKFLOW 3  
  ┌──────────────┐         ┌──────────────┐         ┌──────────────┐  
  │ New lead     │  fires  │ Lead         │  fires  │ Welcome      │  
  │ capture      │────────▶│ qualification│────────▶│ sequence     │  
  └──────────────┘         └──────────────┘         └──────────────┘  

How it works: Workflow 1 completes and its output event triggers Workflow 2 via webhook or the Workflows API. Workflow 2 completes and triggers Workflow 3. Each workflow is independent — it can be tested, modified, and monitored without affecting the others.

Why chain instead of building one mega-workflow:

• Each workflow has a clear, single responsibility
• Failure in Workflow 2 doesn't affect Workflow 1 (the lead is already captured)
• You can update Workflow 2's logic without touching the others
• Different workflows can run on different schedules or triggers
• Monitoring and debugging are simpler — you can see exactly where in the chain something went wrong

The Workflows API (Enterprise)

For programmatic control, the Workflows API lets you trigger any workflow via HTTP:

// Trigger a workflow from your application  
const response = await fetch('https://api.ceo.ai/workflows/wf-12345/run', {  
  method: 'POST',  
  headers: {  
    'Authorization': 'Bearer YOUR_API_KEY',  
    'Content-Type': 'application/json'  
  },  
  body: JSON.stringify({  
    inputData: {  
      requestType: 'sales_inquiry',  
      contactName: 'Sarah Chen',  
      company: 'Acme Manufacturing',  
      message: 'Interested in automating our lead capture...'  
    }  
  })  
});

This enables:

• Your existing applications to trigger CEO.ai workflows as part of their logic
• External orchestration tools to manage workflow sequencing
• Custom dashboards that kick off workflows on demand
• Integration with existing event buses or message queues

Error Handling and Fallback Patterns

In a multi-tiered workflow, things will go wrong. An agent will produce unexpected output. An integration will time out. A human approver will be on vacation. Robust error handling is what separates a production system from a demo.

Pattern 1: Retry with Backoff

The simplest error handling. If a step fails, wait and try again.

  
  ┌──────────┐    fail     ┌────────────┐    retry    ┌──────────┐  
  │  Agent   │───────────▶│   Wait     │───────────▶│  Agent   │  
  │  Step    │            │  (backoff) │            │  Step    │  
  └──────────┘            └────────────┘            │ (retry)  │  
                                                     └──────────┘  

Configuration:

• Max retries: 2-3 (enough to handle transient failures; not so many that permanent failures burn credits)
• Backoff interval: exponential (5 seconds → 15 seconds → 45 seconds)
• After max retries: escalate to fallback pattern

Best for: Transient failures — API timeouts, temporary rate limits, momentary connectivity issues.

Pattern 2: Fallback Agent

If the primary agent fails, a simpler fallback agent handles the task with reduced functionality.

  
  ┌──────────┐    fail     ┌──────────────┐  
  │ Primary  │───────────▶│  Fallback    │  
  │ Agent    │            │  Agent       │  
  │ (complex)│            │  (simpler)   │  
  └──────────┘            └──────────────┘  

Example: Your primary classification agent uses a high-capability model with complex RAG knowledge. If it fails, a simpler fallback agent using a lighter model classifies the input into broad categories — less precise, but the workflow doesn't halt.

Best for: Steps where some output is better than no output, and a degraded response is acceptable.

Pattern 3: Dead Letter Queue

Failed items are saved for later reprocessing rather than dropped or blocking the pipeline.

  
  ┌──────────┐    fail     ┌──────────────┐  
  │  Agent   │───────────▶│  Dead Letter │  
  │  Step    │            │  Queue       │  
  └──────────┘            │  (store for  │  
       │                  │   later)     │  
       │ success          └──────┬───────┘  
       ▼                         │  
  ┌──────────┐              manual/scheduled  
  │  Next    │              reprocessing  
  │  Step    │                   │  
  └──────────┘                   ▼  
                          ┌──────────────┐  
                          │  Reprocess   │  
                          └──────────────┘  

Best for: High-volume workflows where you can't afford to hold up the pipeline for individual failures, but you can't afford to lose the failed items either. Invoice processing, lead capture, support ticket processing.

Pattern 4: Circuit Breaker

If a step fails repeatedly (indicating a systemic issue rather than a transient one), stop sending traffic to it and alert a human.

  
  ┌──────────┐                    ┌──────────────┐  
  │ Incoming │   5+ failures     │  CIRCUIT      │  
  │ requests │   in 10 minutes   │  OPEN         │  
  └──────┬───┘   ──────────▶     │  (stop all    │  
         │                       │   processing) │  
         │                       │  Alert human  │  
         ▼                       └──────────────┘  
  ┌──────────┐  
  │  Agent   │  
  │  Step    │  
  └──────────┘  

When to use: When a downstream system is down (Salesforce API is unreachable, an integration endpoint is returning 500s). Continuing to retry wastes credits and produces errors. Better to halt, alert, and wait for the system to recover.

Combining Error Patterns

In practice, you combine these patterns at different tiers:

Testing and Debugging Multi-Tiered Workflows

Testing a multi-tiered workflow is fundamentally different from testing a linear one. You can't just run it end-to-end and hope it works. You need a systematic approach.

Tier-by-Tier Testing

Test each tier in isolation before connecting them.

For each tier:

1. Define sample inputs — create 5-10 representative inputs that cover the common cases and 3-5 edge cases
2. Run the tier manually with each sample input
3. Verify the output matches what the next tier expects (check the data contract)
4. Test failure cases — what happens when the input is malformed? When an agent produces unexpected output? When an integration times out?
5. Document the results — expected inputs, actual outputs, any issues found

The Test Matrix

For a multi-tiered workflow with conditional branching, you need a test matrix that covers every path:

Debugging a Failed Workflow

When something goes wrong in production, use this diagnostic sequence:

Shadow Mode

For high-stakes multi-tiered workflows, run in shadow mode before going live:

1. Deploy the workflow with all automations active
2. Run it in parallel with the existing manual process
3. Compare outputs: does the automated workflow produce the same results as the manual process?
4. Monitor for 1-2 weeks
5. Once confidence is established, switch over

This is time-consuming but eliminates the risk of deploying a complex workflow that hasn't been validated against real production data.

Performance Considerations at Scale

Multi-tiered workflows running at volume require attention to credit consumption, execution time, and system design.

Credit Consumption

Each agent step in a workflow consumes credits. In a multi-tiered workflow with conditional branches and parallel execution, the total credit consumption per run can be significant.

How to estimate: Map every possible execution path and count the agent steps in each:

Optimization strategies:

• Use lighter/faster models for simple steps (classification, routing, data formatting)
• Reserve high-capability models for steps requiring complex reasoning (analysis, synthesis, content generation)
• Avoid redundant processing — if two branches need the same data transformation, do it once in Tier 1 before the branch point
• Monitor per-step credit consumption and identify disproportionately expensive steps

Execution Time

For time-sensitive workflows (real-time customer interactions, SLA-bound support processing), total execution time matters.

Optimization strategies:

• Parallelize wherever possible — if two steps don't depend on each other, run them simultaneously
• Use faster models for latency-sensitive steps
• Set timeouts on external integration calls (don't let a slow API block the entire pipeline)
• For HITL steps, set SLAs and escalation paths
• Pre-compute and cache data that multiple steps need

Monitoring at Scale

For workflows running hundreds of times per day, you need automated monitoring — not manual log review.

On Enterprise plans, CEO.ai provides workflow performance monitoring as part of ongoing optimization. Bring these metrics to your regular check-ins with the team.

Three Complete Architecture Examples

Each example below represents a real-world multi-tiered workflow pattern. These are the sections you'll want to reference — and share — when designing your own system.

  
  TIER 1: INTAKE  
  ┌────────────────────────────────────────────────────┐  
  │ Triggers: Webhook (form), Webhook (email parser),  │  
  │           Webhook (Slack)                           │  
  │ Agent: Format Normalizer                            │  
  │   → Converts all inputs to unified format           │  
  │ Agent: Classifier                                   │  
  │   → Categorizes: sales | support | partnership |    │  
  │     employment | other                              │  
  │ Output: Classified, normalized request object       │  
  └──────────────────────┬─────────────────────────────┘  
                         │  
       ┌─────────┬───────┼────────┬──────────┐  
       ▼         ▼       ▼        ▼          ▼  
  
  TIER 2A:   TIER 2B:  TIER 2C:  TIER 2D:  TIER 2E:  
  SALES      SUPPORT   PARTNER   HR        OTHER  
  ┌───────┐  ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐  
  │Qualify│  │Triage │ │Eval   │ │Screen │ │Route  │  
  │Score  │  │Draft  │ │Qualify│ │Score  │ │to     │  
  │Route  │  │Route  │ │Human  │ │Notify │ │admin  │  
  │to CRM │  │to rep │ │review │ │to HR  │ │team   │  
  └───┬───┘  └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘  
      └──────────┴────┬────┴─────────┴──────────┘  
                      ▼  
  
  TIER 3: DAILY AGGREGATION  
  ┌────────────────────────────────────────────────────┐  
  │ Trigger: Daily at 6pm                              │  
  │ Agent: Aggregator — collects all processed requests│  
  │ Agent: Analyst — identifies patterns and volumes   │  
  │ Agent: Report Writer — daily operations summary    │  
  │ Output: Report → Slack + Email to leadership       │  
  └────────────────────────────────────────────────────┘  

  
  TIER 1: TRIGGER & DATA ENRICHMENT  
  ┌────────────────────────────────────────────────────┐  
  │ Trigger: Webhook from CRM (deal status → Closed)   │  
  │ Agent: Data Enrichment                              │  
  │   → Pulls client details from CRM, contract system │  
  │   → Generates onboarding data package               │  
  │ Output: Complete client onboarding record           │  
  └──────────────────────┬─────────────────────────────┘  
                         │  
          ┌──────────────┼──────────────┐  
          ▼              ▼              ▼  
  
  TIER 2A:          TIER 2B:        TIER 2C:  
  PROVISIONING      COMMUNICATION   INTERNAL SETUP  
  ┌────────────┐    ┌────────────┐  ┌────────────┐  
  │Create      │    │Generate    │  │Create      │  
  │accounts    │    │welcome     │  │project in  │  
  │in all      │    │email       │  │PM tool     │  
  │systems     │    │  ↓         │  │  ↓         │  
  │  ↓         │    │Human:      │  │Assign      │  
  │Configure   │    │AM reviews  │  │team        │  
  │permissions │    │  ↓         │  │members     │  
  │& settings  │    │Send email  │  │  ↓         │  
  └─────┬──────┘    └─────┬──────┘  │Schedule    │  
        │                 │         │kickoff     │  
        │                 │         └─────┬──────┘  
        └─────────────────┼───────────────┘  
                          ▼  
  
  TIER 3: VERIFICATION & FOLLOW-UP  
  ┌────────────────────────────────────────────────────┐  
  │ Agent: Verification — confirms all systems         │  
  │   provisioned, email sent, project created         │  
  │ Agent: Follow-Up Scheduler                         │  
  │   → Queues check-in at Day 3, 7, 30               │  
  │ Agent: Handoff Summarizer                          │  
  │   → Generates AM briefing document                 │  
  │ Output: Onboarding complete status + briefing doc  │  
  └────────────────────────────────────────────────────┘  

  
  TIER 1: INITIALIZATION  
  ┌────────────────────────────────────────────────────┐  
  │ Trigger: Friday at 1pm                              │  
  │ Agent: Client Roster Loader                         │  
  │   → Loads active client list with configurations    │  
  │ Output: List of 20 client report jobs               │  
  └──────────────────────┬─────────────────────────────┘  
                         │  
                    Fan out to N parallel instances  
                         │  
    ┌───────┬───────┬────┴────┬───────┬───────┐  
    ▼       ▼       ▼         ▼       ▼       ▼  
  
  TIER 2: PER-CLIENT REPORT PIPELINE (×20, parallel)  
  ┌────────────────────────────────────────────────────┐  
  │ Agent: Data Collector (per-client data sources)     │  
  │   → Pulls from GA, social, ads — client-specific   │  
  │ Agent: Analyst (per-client KPIs and targets)        │  
  │   → Calculates metrics, compares to targets         │  
  │ Agent: Report Writer (per-client template & tone)   │  
  │   → Generates report in client's preferred format   │  
  │ HITL: Account Manager reviews before sending        │  
  │ Agent: Distributor                                  │  
  │   → Emails report to client + posts to client Slack │  
  │ Output: Report sent, status logged                  │  
  └──────────────────────┬─────────────────────────────┘  
                         │  
                    Fan in from all instances  
                         │  
                         ▼  
  
  TIER 3: AGENCY-LEVEL SUMMARY  
  ┌────────────────────────────────────────────────────┐  
  │ Agent: Cross-Client Analyzer                       │  
  │   → Identifies top performers, at-risk accounts    │  
  │ Agent: Agency Report Writer                        │  
  │   → Generates internal agency performance summary  │  
  │ Output: Agency summary → Slack + leadership email  │  
  └────────────────────────────────────────────────────┘  

Getting Started with Multi-Tiered Workflows

Multi-tiered workflows are powerful — and complex. Here's the recommended path:

What to Read Next