What This Example Shows
- A real production DAG: an SDR (sales development) enrichment pipeline with three parallel research branches that converge into synthesis and scoring nodes
- How to express fan-out → fan-in graphs with
edges,entry_points, andend_points - Why this beats stacking
SequentialWorkflow+ConcurrentWorkflow(single round-trip, server-side concurrency, single billing event) - How to read per-node outputs from the response so you can persist branch outputs to your CRM
- Patterns for retries and conditional paths via downstream gating
Why This Matters
Sales teams burn the first 20 minutes of every cold outreach reading three different tabs — LinkedIn for the buyer, Crunchbase for the company, and a news search for the trigger event. Then somebody distills it into a one-line pitch hook, somebody else scores the lead, and only then does the SDR send. That sequence is a DAG, not a chain: the three lookups are independent of each other, but they all block the synthesis step, which blocks the scoring step. A Graph Workflow lets you describe that DAG once and have the platform run the three lookups in parallel, fan them into the synthesis node, then feed scoring — in a single API call with one billing event. You stop maintaining glue code that orchestrates async tasks, and your SDR pipeline runs 3-5x faster than the sequential version.Step 1: Setup
Step 2: Sketch the Graph Before You Code It
The graph for an SDR enrichment looks like this:Always draw the graph on paper before encoding it. The edges and
entry_points/end_points fields are mechanical once the picture is right — and almost always wrong when they aren’t.Step 3: Define the Agents
Each node is a specialist. Researchers are tuned low-temperature for factual recall; the synthesizer runs slightly warmer to write copy; the scorer is the coldest of all because we want a deterministic verdict.Step 4: Wire the Edges
Three fan-in edges, one straight edge. Theentry_points are the three researchers (no upstream dependencies); the end_point is the scorer (no downstream dependencies).
Step 5: Submit the Workflow
Step 6: Read the Per-Node Output
Every node’s output is keyed byagent_name under outputs. Persist them individually — the buyer profile belongs on the contact record, the company profile on the account record, the pitch in the sequencer, the score in the CRM lead-scoring column.
Why This Beats Sequential + Concurrent Stacking
You could build the same pipeline by callingConcurrentWorkflow for the three researchers, manually stitching their outputs into a prompt, then calling SequentialWorkflow for synthesis → scoring. That works. It’s also worse:
| Concern | Sequential + Concurrent (DIY) | Graph Workflow |
|---|---|---|
| API calls | 2 (concurrent, then sequential) | 1 |
| Billing events | 2 separate cost records | 1 unified record |
| Glue code you maintain | ”wait for all 3, then build prompt, then call next workflow” | None — declared in edges |
| Server-side parallelism | Yes for first hop only | Yes across the whole DAG |
| Wall clock | Sum of (slowest researcher + synth + scorer) plus 2 round-trips | Slowest researcher + synth + scorer, single round-trip |
| Failure handling | You retry whichever hop failed | Server-side retry on individual nodes |
| Auditability | Two job IDs in your logs | One job_id you can replay |
Adding Conditional Paths and Retries
Two production patterns to layer on top: Conditional gating (early exit on cold leads). Add aQualifier node before the heavy research and let the synthesizer’s prompt instruct it to output “SKIP” if the lead score’s company profile fails a hard filter (e.g., < 50 employees, US-only). Downstream nodes still run, but their prompts can be written to no-op when they see “SKIP” upstream.
Retries on a flaky node. The graph compiler retries failed nodes automatically when auto_compile: true. For nodes that touch external services (search, scrapers, CRM enrichment), set max_loops: 2 on just that node — the upstream and downstream nodes will only see the successful run.
Scaling the Pattern
Drop in any production DAG by swapping the node prompts:| Pipeline | Entry points (parallel) | Middle | End point |
|---|---|---|---|
| SDR enrichment | Buyer / Company / Trigger | Pitch Synth | Lead Scorer |
| Underwriting | Credit / Income / Collateral | Risk Synth | Approver |
| Incident response | Logs / Metrics / Alerts | Root-Cause Synth | Runbook Picker |
| CI/CD code review | Lint / Security / Perf | Review Synth | Merge Gate |
| Clinical triage | History / Vitals / Imaging | Differential Synth | Disposition |
Cost vs. Building It Yourself
Concrete numbers from a real SDR team enriching 1,000 leads per week:| Approach | Time per lead | Cost per lead | Engineering owned |
|---|---|---|---|
| Manual SDR research (LinkedIn + Crunchbase + news) | 18-25 min | ~$22 in SDR time | None |
| Custom async orchestration in-house (Lambda + Step Functions + LLM glue) | ~6-8 sec | ~$0.03 in API + ~$0.005 in infra | 2 engineers, ~$300k/yr to maintain |
| Graph Workflow endpoint | ~3-5 sec | ~$0.02-$0.04 in API | None — declared in JSON |
Next Steps
- Reasoning Agents for Hard Analytical Problems — when one node in your DAG needs deliberation instead of recall
- Graph Workflow Example — additional DAG shapes (content localization, due diligence, code review)