The first six lectures were channels and jobs: chat, support, search, documents, voice, email. Workflow automation is the product that sequences them: durable steps, retries, HITL gates, and systems of record. Vol. 15 agentic workflows / agent loops / HITL become an operations graph, not a chat demo.
Serving uses Vol. 18 FastAPI + Celery / Redis (or an equivalent orchestrator). Vol. 13 cost budgets cap every LLM step. Vol. 19 evals attach to step contracts, not only final prose. Vol. 20 security/governance: each tool remains allowlisted; residual risk covers the whole graph. Later Module 21.1 topics (coding, research, healthcare, finance, legal, education) reuse this orchestration pattern under stricter domains.
Learning Objectives
By the end of this lesson, students should be able to:
- Define workflow automation as a durable, permissioned graph of AI and non-AI steps.
- Contrast scripted workflows vs agents vs hybrid (LLM only where the contract is fuzzy).
- Place RAG, fine-tune, tools, and agents on individual steps—not on the whole company.
- Design HITL, idempotency, compensation, and kill switches.
- Sketch a FastAPI + Celery state machine with eval/cost per step.
- Reuse prior Module 21.1 products as workflow nodes.
Workflow automation is a product that runs a multi-step business process with explicit state, retries, timeouts, and human gates—where some steps may call LLMs, RAG, or tools. Durability (survive restart) and authorization (code, not the planner) distinguish it from a single agent loop in a notebook. The workflow engine is trusted; each LLM step is not.
Scripted Flow vs Agent vs Hybrid
Vol. 15 taught agent loops. Production workflows usually invert that: the graph is written by engineers; the LLM fills slots, classifies, or drafts inside a node. Full autonomy is a special case with tighter caps.
| Style | Who chooses the next step? | When to use |
|---|---|---|
| Deterministic BPM / state machine | Code / config | Known happy path + exceptions (invoice → approve → pay) |
| LLM inside a node | Code; LLM only produces typed output | Extract, classify, draft, summarize |
| Agentic subgraph | Model within max steps | Research-y subtask with tool allowlist |
| Free agent over the company | Model | Almost never in v1 |
Email, chat, cron, webhook.
Search, extract, decide, draft.
HITL / policy / budget.
Write systems of record; compensate on fail.
Architecture Choice: RAG vs Fine-Tune vs Tools vs Agents
| Pattern | Workflow placement | Anti-pattern |
|---|---|---|
| RAG | Policy/FAQ nodes; cite before a decision record | Retrieving then silently paying invoices |
| Fine-tune | High-volume classify/extract nodes | Fine-tune to “know how AP works” instead of a graph |
| Tools | Every side effect: ERP, CRM, mail, calendar | One god-tool run_business |
| Agents | Bounded subgraph (e.g. gather 3 quotes) | Agent owns global control flow and spend |
Trusted engine
- State in Redis/DB, not chat memory
- Idempotency keys on writes
- Timeouts and retry policies
- IR: pause workflow type X
Untrusted nodes
- Any LLM / RAG / web result
- Wrap inputs as data
- Validate JSON schemas
- Budget tokens per step (Vol. 13.4)
HITL nodes
- Money, legal, customer send
- Low confidence extracts
- Novel exception classes
- Residual risk owners
Why graphs beat mega-agents
- Observable step SLAs
- Eval per contract (field F1 vs faithfulness)
- Least privilege per tool
- Compensation / rollback is possible
Why naive agents fail ops
- No durable state across crashes
- Unclear who approved a write
- Cost and latency unbounded
- Hard to explain to Vol. 20 governance
Product Pattern: Durable Invoice → Pay Graph
Example composing Document AI + search + email + HITL. The LLM never calls pay() directly; the engine does after approval.
Eval & Cost at Graph Granularity
| Level | What you measure | Hook |
|---|---|---|
| Node | Schema valid %, field F1, faithfulness, latency | Vol. 19 + prior product lectures |
| Edge / gate | HITL catch rate; false auto-approve | Vol. 15 HITL, Vol. 20 residual risk |
| Run | End-to-end success, $/run, token budget hits, compensations | Vol. 13.4 cost dashboards |
| Fleet | Kill-switch drills; digest pins on indexes | Vol. 20 security / poisoning |
Composing Module 21.1 Siblings
| Node type | Reuse lecture |
|---|---|
| Conversational trigger / status | Chatbots, voice |
| Ticket exception path | Customer support |
| Lookup / policy / PO match | AI search |
| File / invoice / KYC packet | Document AI |
| Notify / collect missing info | Email automation |
Related Lectures
| Lecture | Role |
|---|---|
| Agentic workflow / agent loop / HITL | Control-flow theory |
| Celery / Redis / FastAPI | Durable execution |
| Security / governance | Tool auth + residual risk on the graph |
| Spend alerts / token usage | Per-run budgets |
| Chatbots … email | Nodes you just built |
“An agent is the workflow engine.” Agents plan; engines persist, authorize, and compensate. Second: RAG across the whole company replaces step-level ACL. Third: fine-tuning one model to run AP, support, and payroll. Fourth: HITL only at the end—money steps need gates where the write happens. Fifth: chat memory is durable enough for multi-day approvals. Sixth: Vol. 20 was finished before workflows, so graphs need no residual risk.
Knowledge Check
- Short Answer: What makes workflow automation different from a single agent loop? Answer: Durable explicit state, retries/timeouts, and authorization in the engine—not the planner.
- True/False: v1 should usually let a free agent choose every next enterprise step. Answer: False—prefer a scripted graph with LLM nodes.
- Multiple Choice: Invoice
pay()should be executed by: (a) application code after HITL, (b) the LLM directly, (c) an unbounded browse agent. Answer: (a). - Short Answer: Name two Module 21.1 products that become workflow nodes. Answer: Any two of chatbots, support, search, Document AI, voice, email.
- True/False: Token budgets belong per run/step, not only per chat turn. Answer: True.
- Multiple Choice: Extracting invoice fields in a graph is typically: (a) Document AI + schema validation, (b) fine-tune as AP oracle, (c) PCA. Answer: (a).
- Short Answer: Why store workflow state in Redis/DB instead of chat memory? Answer: Durability across crashes, multi-day HITL, and auditability.
- True/False: Eval should attach to step contracts (field F1 vs faithfulness) as well as end-to-end success. Answer: True.
- Multiple Choice: A kill switch that pauses workflow type X is primarily: (a) Vol. 20 IR, (b) a BLEU improvement, (c) a CNN layer. Answer: (a).
- Short Answer: Where do RAG vs fine-tune vs tools vs agents get chosen in this product? Answer: Per step/node—not as one global architecture for the whole company.
Key Takeaways
- Workflow automation orchestrates Module 21.1 channels into a durable, permissioned graph.
- Engine chooses control flow; LLMs fill typed nodes; agents are bounded subgraphs.
- HITL, idempotency, budgets, and kill switches are product features.
- Vol. 19 eval and Vol. 13 cost apply per step; Vol. 20 residual risk applies to the graph.
- You now have seven applied categories from chatbot through workflow—ready for later domain products in this module.
Capstone lab: Teams implement the AP tick graph (even in-memory). Required: schema extract node, ACL search stub, HITL before pay, idempotent pay, token budget, wrap-as-data on OCR text. Deliverable: sequence diagram mapping each node to a sibling lecture + a residual-risk paragraph for the board.
Exit ticket: “If marketing wants an agent that runs the whole workflow, which two controls do you refuse to remove?” (Expected: engine-owned writes + HITL on money / send.)
Recap: Workflow automation closes this seven-lecture arc by composing chat, support, search, Document AI, voice, and email into durable graphs. Control flow stays in code; models stay untrusted planners. Next in the module: coding assistants and domain products on the same skeleton.