Agentic AI and Workflow Automation

Executive summary

Agentic AI combines LLM reasoning with tool use, planning loops and optional multi-agent coordination to accomplish multi-step goals. Workflow automation orchestrates known steps deterministically. The AI Solution Engineer’s job is to split the problem: use workflows where the process is codified; use constrained agents where flexibility adds value—and always add human-in-the-loop (HITL) gates, budgets, allow-lists and kill-switches because agent risks include infinite loops, runaway spend, unauthorised tools, data leakage, goal drift and cascading failure across integrated systems.

When to use this page

• When a use case requires multiple steps across systems (CRM, ticketing, ERP) and pure RAG or single-shot generation is insufficient.
• When stakeholders ask for an “AI agent” but the process is actually a fixed approval chain—redirect to workflow first.
• When designing complaint handling, IT service desks, procurement intake, or research assistants with tool access.
• Before exposing mutating tools (payments, account changes, external email) to any autonomous loop.
• When evaluating multi-agent proposals (“researcher + writer + critic”) for marginal value vs operational cost.
• Pair with Prompt and Context Engineering for tool schemas and AI Evaluation and Quality Assurance for task-completion eval.

Executive view

Ask **why not a workflow** before funding agents. Demand named **approval gates**, **spend caps**, **allow-listed tools** and incident **kill-switches**. Challenge demos that hide human effort or skip audit logs.

Decision required: Which steps are deterministic, which need agent flexibility, and who is accountable when the agent chooses wrong?

Technical view

Model state machines with explicit transitions; cap steps and tokens; log every tool call with identity; use durable execution for long runs; separate read and write tools; test loop and injection scenarios in CI.

Multi-agent only when single-agent eval proves insufficient—operational complexity is real.

Why this matters

“Agent” has become a marketing label for anything involving an LLM and an API. In enterprise delivery, agent means a loop that observes, plans, invokes tools and repeats until a stop condition— with consequences in real systems. A loop that calls close_ticket incorrectly 140 times is not a prompt problem; it is an architecture and governance problem.

Many programmes should implement workflow automation (BPM, state machine, event-driven orchestration) with LLM steps as single nodes—classify intent here, draft text there—not an open-ended agent with twenty tools. Agents earn their place when branching is unpredictable but tools and bounds are known: research across three approved APIs, draft a memo from retrieved facts, propose ticket routing—but not when the business process is already written in a procedure manual with signatures.

Failure modes are predictable: infinite loops retrying failed tool calls; token spend exploding on “think harder” patterns; unauthorised tools exposed because dev left debug endpoints enabled; PII leakage through agent-assembled emails; goal drift where the agent optimises for “close case fast” instead of “resolve fairly”; cascading failure when upstream agent hallucinates an ID downstream agents trust.

The AI Solution Engineer produces an agent vs workflow decision, tool allow-list with authorisation model, HITL design, budget table, and failure runbooks. Weak designs demo well in sandbox with mocked tools. Strong designs survive red team, FinOps review and ops on-call at 2 a.m.

Connect to Agentic AI playbook, RAG for retrieval tools, and Evaluation and observability for task-completion metrics.

Learn

Agents vs workflows — decision first

Dimension	Deterministic workflow	Agent loop
Process definition	Known steps, stable	Branching emergent from context
Predictability	High	Medium–low
Audit	Easy step replay	Requires tool log + reasoning trace
Cost	Bounded per instance	Risk of runaway tokens/steps
Best for	Approvals, SLAs, compliance paths	Ambiguous intake, multi-source research
LLM role	Node-level assist	Planner + executor

Default to workflow. Add agentic sub-loop only where eval proves workflow maintenance cost exceeds bounded agent risk.

Hybrid pattern (common): Workflow state machine with agent slot for “gather evidence” step that may call read-only tools, then returns structured JSON to workflow for deterministic gate.

Tools — allow-list, schemas and side effects

Tools are functions the model may invoke: search, create record, send notification.

Enterprise rules:

1. Allow-list per workflow stage—not global catalog
2. Read vs write separation; writes need HITL or idempotent server guards
3. Schemas single-sourced from OpenAPI (see Prompt and context engineering)
4. Authorisation at execution server using user identity—not model honour system
5. Rate limits per tool and per session
6. Dry-run mode in non-prod with recorded fixtures

Side effect classes:

Class	Example	Gate
Read-only	search_kb	Log + ACL
Reversible write	draft_ticket	Auto with audit
Irreversible	payment, delete	HITL + second factor
External comms	email customer	HITL + template lock

Planning loops — ReAct, plan-and-execute, budgets

Common loop: Reason → Act (tool) → Observe → repeat until finish or cap.

Planner variants:

• ReAct — interleaved thought and tool call in one model stream
• Plan-and-execute — planner outputs step list; executor runs each (easier to audit)
• Router — classify to specialised sub-agent or workflow

Mandatory budgets:

Budget	Typical starter	On exceed
Max steps	8–15	Stop + escalate human
Max tool calls	10–20	Hard stop
Max tokens (session)	50k–150k	Stop + summarise for handoff
Max wall clock	60–120s	Timeout + partial result
Max cost	£0.50/session	Kill switch

Log budget consumption per session for FinOps tuning.

Memory and state — durable execution

Agents need session state: case IDs, prior tool results, user clarifications.

Patterns:

• Short-term: conversation buffer in Redis with TTL
• Working memory: structured JSON schema updated each step (case_state v3)
• Long-term: vector or DB only when product requires continuity—privacy review first

Durable execution: Use workflow engine (Temporal, Step Functions, Camunda) for steps that must survive restarts—don’t rely on LLM chat memory for financial transactions.

Checkpointing: After each HITL approval, persist state before next agent tranche.

Human-in-the-loop (HITL) — where humans must decide

HITL is not failure—it is design for high-risk domains.

HITL placement:

• Before irreversible tool execution
• When confidence below threshold
• When policy requires professional sign-off (clinical, legal, credit)
• When agent requests clarification outside allow-list
• Random audit sample for quality (e.g. 5% of drafts)

UX requirements: Show evidence pack (retrieval + tool outputs), diff for drafts, one-click approve/reject/edit, reason codes for rejections feeding eval.

SLA: Define queue wait impact—agent must not auto-escalate to customer while pending human.

Multi-agent — when multiple roles help

Multi-agent patterns: router + specialists (researcher, writer, critic); parallel gather + synthesiser; supervisor approving sub-agent outputs.

Benefits: Separation of concerns; smaller tool sets per agent; critic reduces obvious errors.

Costs: Latency multiply; debugging harder; inter-agent protocol drift; more tokens.

Adoption test: Single-agent with same tools must fail task-completion eval by ≥10 points before multi-agent justified.

Coordination rules:

• Shared state schema, not free-form chat between agents
• Supervisor has veto on external actions
• No agent-to-agent tool exposure—only through orchestrator

Workflow automation integration

Enterprise reality: Agents sit inside existing automation—ServiceNow, Salesforce Flow, Power Automate, custom BPM.

Integration patterns:

• Agent returns structured decision object consumed by workflow API
• Webhook triggers on HITL outcome
• Event bus publishes AgentStepCompleted for observability
• Idempotency keys on all mutating callbacks

Anti-pattern: Agent holds long-running process internally while business thinks workflow system is source of truth—state divergence guaranteed.

MCP and tool ecosystems

Model Context Protocol (MCP) standardises tool discovery and connection to data sources. Treat MCP servers like any API: auth, ACL, logging, rate limits, version pinning.

Governance: Approved MCP registry; no production connect to unvetted community servers; scan for excessive tool surface.

Risks — loops, spend, leakage, drift, cascade

Risk	Mechanism	Control
Loops	Retry same failing call	Dedupe detection; max identical calls = 2
Spend	Long reasoning chains	Token/cost budget; cheaper model for plan
Unauthorised tools	Over-broad registry	Stage-based allow-list
Leakage	Email tool exfiltrates retrieval	DLP on outbound; recipient allow-list
Goal drift	Optimises wrong objective	Explicit success criteria in system; critic step
Cascade	Bad ID passed downstream	Validate IDs against schema/server
Prompt injection via tools	Malicious webpage content	Tool output sanitisation; summarise don’t execute

Kill-switches: Feature flag per agent; global circuit breaker on error rate; manual ops dashboard “pause all write tools.”

Frameworks and methods

WORK-FLOW vs AGENT split canvas

For each process step, mark W (workflow deterministic), A (agent assist), H (human only):

Step: Intake email → [W classify] → [A gather context read-only] → [H approve draft] → [W send template]

Every A step lists tools, budgets, stop conditions.

Agent readiness checklist (ARC)

Item	Pass criteria
Allow-list	Tools enumerated per stage
Risk class	Mapped to HITL and budgets
Controls	Kill-switch, logging, eval task suite

Score ≤2 missing items before pilot; zero missing before write tools in prod.

Tool authorisation matrix

Tool	Identity check	HITL	Rate limit	Audit field
search_policy	User ACL	No	60/min	query_hash
create_ticket	Service + user	No	10/min	ticket_id
reset_mfa	User + HITL token	Yes	2/hour	approver_id

Fill for every production tool.

Loop detection policy

• Same tool + same args twice → block third; return error to model
• Same tool five times session → escalate human regardless of args
• No progress heuristic: state hash unchanged for 3 steps → stop

Incident severity for agents

Sev	Example	Response
1	Wrong payment executed	Pause writes; exec bridge
2	Mass ticket wrongful close	Pause agent; replay audit
3	Cost 10× daily budget	Rate limit; FinOps alert
4	Single PII leak attempt	Block session; log

Real-world scenarios

Scenario A — UK bank: complaint handling hybrid

Context: Retail bank complaints; regulatory timeline strict. Initial “full agent” prototype auto-sent responses—unacceptable.

Design:

• Workflow: classify → priority → SLA timer → regulatory bucket (deterministic rules)
• Agent (read-only): retrieve customer history + policy chunks; draft response from approved macro library
• HITL: mandatory human edit/approve before send_communication tool enabled
• Budget: 12 steps, 80k tokens, 90s wall clock

Measurable outcomes:

• Draft prep time −26 minutes/case (n=310)
• Auto-send incidents 0 (tool gated)
• SLA breach rate 8.1% → 3.4% over two quarters
• Agent cost £0.08/case average vs £12 human-only prep time equivalent

Lesson: Agent drafts; workflow owns timing and compliance; humans own send.

Scenario B — Telecom field dispatch: tool collision and loops

Context: Dispatcher assistant; agents closed work orders without technician confirmation; loops on bad GPS tool retry.

Intervention:

1. Split workflow for status updates vs agent for route suggestion (read-only maps)
2. close_work_order removed from agent; workflow node after technician mobile app signal
3. Loop detection on geocode_address failures max 2
4. Plan-and-execute planner for auditability

Measurable outcomes:

• Erroneous closes 140/week → 0 in agent path
• Infinite retry sessions ~40/day → 0
• Dispatcher handle time −4.2 minutes/job (n=1,800/week)
• Mean agent steps 6.1 → 4.4

Lesson: Mutations belong in workflow gates, not exploratory loops.

Scenario C — Global insurer FNOL: multi-agent research vs single-agent

Context: First notice of loss intake; proposal for researcher + assessor + composer agents. Eval showed single-agent with structured plan matched task completion 84%; multi-agent 86% at 2.3× latency and 1.8× cost.

Decision: Ship single plan-and-execute agent with read tools only; workflow triggers salvage and hire car APIs deterministically from extracted JSON.

Measurable outcomes:

• FNOL completion time 22 min → 14 min median
• Task completion eval 84% maintained at production scale
• Avoided £180k/year incremental inference vs multi-agent design
• Engineering maintenance one orchestration codebase

Lesson: Multi-agent needs quantified margin; default single agent + workflow.

Scenario D — Energy B2B: runaway spend on external web tool

Context: Sales research agent with web_search + crm_update. Marketing campaign spiked usage; agent iterated web searches; £47k monthly inference + search API vs £8k budget.

Intervention:

1. Per-session cost cap £2; degrade to cached internal corpus only on exceed
2. Web search allow-list domains; max 3 searches/session
3. Cheaper model for planning; premium model only for final client paragraph
4. FinOps dashboard daily with anomaly alert

Measurable outcomes:

• Monthly spend £47k → £11k while keeping task completion 79% → 77% (accepted trade)
• p95 latency −18% from fewer searches
• Zero budget overruns in following two quarters

Lesson: Agent spend is opex—budget like any API product.

Practice exercises

Primary exercise — Split “book travel” assistant (75 minutes)

Brief: Employee travel assistant: policy check, booking flights/hotels, manager approval over £800, expense export.

Tasks:

1. Mark each micro-step W / A / H on WORK-FLOW vs AGENT canvas.
2. List allow-listed tools per agent stage with authorisation matrix rows.
3. Define budgets (steps, tokens, cost) and three kill-switches.
4. Identify two injection scenarios via tool outputs and mitigations.
5. Write task-completion eval criteria for 8 test scenarios.

Acceptance criteria:

• No irreversible booking without HITL or workflow node
• Write tools ≤5 with side effect class labelled
• Loop detection policy stated
• Multi-agent not used unless justified with hypothetical eval gap

Stretch exercise — Complaint agent production pack (full day)

Brief: Regulated financial complaint agent as Scenario A; prepare for CISO and conduct review.

Tasks:

1. Architecture diagram: workflow engine + agent boundary + logging
2. Durable execution plan for 45-day SLA processes
3. HITL UX specification (evidence panel, reason codes)
4. Incident runbook Sev 1–4 with kill-switch owners
5. 30-case task-completion golden set with pass threshold
6. ARC checklist completed with sign-off roles

Acceptance criteria:

• Every tool row in authorisation matrix complete
• Audit log fields specified (who, what, when, input_hash, output_hash)
• Conduct: no auto outbound customer communication without HITL

Questions you should be able to answer

1. Why not a deterministic workflow for this whole process?
2. Which steps are workflow, which agent, which human-only?
3. What tools are allow-listed at each stage?
4. How is tool execution authorised with user identity?
5. What budgets cap steps, tokens, time and cost?
6. Where are HITL gates and what evidence is shown?
7. How do you detect and stop loops?
8. What kill-switches exist and who can trigger them?
9. How is state persisted across restarts and approvals?
10. Why single vs multi-agent—what eval justifies choice?
11. How are tool outputs sanitised against injection?
12. What audit log proves who approved external actions?
13. How does agent integrate with system of record workflow?
14. What task-completion threshold gates release?
15. What FinOps alerts fire on spend anomaly?

Negative cases — when agentic AI fails

Failure mode	Symptom	Prevention
Agent by default	Unauditable process	Workflow first
Tool soup	Wrong mutations	Stage allow-list
Honour-system auth	Model picks user	Server-side identity
No budgets	Token bill shock	Caps + alerts
Auto-send	Regulatory breach	HITL on outbound
Multi-agent vanity	2× cost, tiny gain	Eval justification
Memory as SOR	State divergence	Durable workflow store
Debug tools in prod	delete_all exposed	Registry governance
Silent degrade	Quality drop	Online task metrics
Cascade trust	Hallucinated ID propagated	Validate each step

Case study: the helpful auto-closer. Telecom agent optimised for “resolve ticket”; closed 140 incidents without fix verification. Customer churn tick up in region. Remediation: close tool removed from agent; workflow requires technician signal. Lesson: Align agent objective with business KPI, not proxy metric.

Case study: CRM exfiltration. Research agent with email tool instructed “send summary to my manager”; injection in webpage added BCC exfil address. DLP caught 3/3 test attacks after fix. Lesson: Outbound tools need DLP and recipient allow-list.

Case study: infinite apology loop. Customer service agent retried post_reply on 400 errors, generating duplicate public apologies. Loop detector + idempotency keys stopped after second identical call.

Operating-model notes

Function	Responsibility
Process owner	Defines W/A/H split; signs off HITL policy
Agent platform team	Orchestrator, budgets, logging infrastructure
Integration team	Tool APIs, idempotency, workflow callbacks
Security	Tool registry, penetration test on agent paths
FinOps	Cost caps, anomaly detection
Ops / on-call	Kill-switch execution, incident runbooks

Production readiness review (agents): Separate from generic app PRR—includes task-completion eval report, red-team tool misuse results, and proof of workflow SoR alignment.

Orchestration pattern catalogue

Pattern 1 — Supervisor workflow, agent worker

Workflow engine owns state; agent invoked as activity with timeout; result JSON schema validated before transition.

Pattern 2 — Router to specialist agents

Intent classifier routes to small agents (billing vs tech vs sales) with disjoint tool sets—reduces collision.

Pattern 3 — Plan-and-execute with frozen plan

Planner outputs steps; human approves plan for high-risk; executor runs without replanning unless step fails.

Pattern 4 — Critique loop (bounded)

Generator agent → critic agent scores; max 2 iterations; then HITL. Critic has read-only tools; cannot mutate.

Pattern 5 — Event-driven agent triggers

Kafka event CaseOpened triggers agent gather; completion event EvidenceReady wakes workflow—avoid polling loops.

Choose pattern in architecture decision record with eval evidence.

Observability for agent sessions

Log per session (not only per request):

• session_id, user_id, workflow_instance_id
• Each step: planner output hash, tool name, args hash, result hash, latency, tokens
• Budget consumption cumulative
• HITL wait duration
• Termination reason (success, budget, loop, human_reject, error)

Dashboards: tool error rate by tool; sessions hitting budget cap %; mean steps to success by intent.

Trace IDs must propagate into downstream systems for cascade debugging.

Testing pyramid for agents

Layer	Count	Environment
Unit: tool auth	All tools	Mock identity
Integration: single scenario	30–50 golden tasks	Mocked external APIs
E2E: staging	10–20 critical paths	Sandboxed real services
Red team	20+ misuse cases	Staging
Production sample	Continuous 1% human	Prod

Mock tools must match real API validation rules—mocks that accept anything hide schema drift.

Scenario E — Pharmaceutical compliance: agent banned from external write

Context: Medical information enquiry handling; agent proposed with web search + email to HCPs. Compliance rejected autonomous outbound.

Design:

• Agent: read-only internal corpus + approved label database
• Workflow: all drafts to medical reviewer queue
• Email tool absent from allow-list; export Word doc only via template API
• Session budget: 8 steps, 60k tokens

Measurable outcomes:

• Average medical review time −18 min vs manual draft from scratch (n=120)
• Zero unauthorised outbound (audit)
• Task completion on golden 82% (acceptable vs 88% target with HITL compensating)
• Compliance sign-off in 6 weeks vs 9 months for prior non-agent workflow-only attempt

Lesson: Compliance constraints shape agent surface—success is measured with gates, not autonomous completion.

Scenario F — Insurance claims: durable execution across 45-day SLA

Context: FNOL agent gathers evidence over days (photos, police report, garage estimate). Chat session model failed on day 3 resume.

Design:

• Workflow engine holds claim_id state; each user return starts new agent session loading persisted JSON state
• Agent read tools only until evidence_complete flag set by rules
• Timers for regulatory SLA managed by workflow, not LLM

Measurable outcomes:

• Session resume success 100% in UAT (n=500 scenarios)
• SLA breach attributable to tech 0 in pilot region
• Agent cost spread across claim lifetime £0.34 avg vs £4.10 single long session approach (failed prototype)

Lesson: Long-horizon processes are workflow problems with agent assist moments—not eternal chat threads.

Procurement and vendor agent claims

When vendors sell “autonomous agents,” demand:

• Task-completion eval on your golden tasks in your sandbox
• Proof of kill-switch and audit export
• Cost model at your QPS with budgets enabled
• Reference for workflow SoR integration—not only Slack demo

Human factors and agent UX

Agents fail adoption when users cannot see what happened:

• Show plan steps before execution (optional “preview plan” for high trust build)
• Display tool calls in plain language (“Searching policy library…”)
• On HITL queue, show diff not raw JSON
• Explain stop reasons (“Stopped: step budget reached—handed to human”)

Measure trust score and override rate alongside task completion.

Compliance mappings (illustrative)

Regulation theme	Agent control
Conduct / consumer duty	HITL on customer-facing outputs
GDPR	Data minimisation in agent state; retention TTL
SOX	Segregation of duties—agent cannot approve what it initiated
PCI	Payment tools in isolated workflow zone, no card data in prompts

Map controls in solution architecture document—not bolted on after audit finding.

Decommissioning agents

Sunset checklist:

• Disable write tools first; read-only grace period
• Archive session logs per retention policy
• Migrate open workflow instances to human queue
• Retain eval golden for regulatory lookback
• Communicate users: replacement process

Agents without decommission plan become zombie automation—still calling deprecated APIs.

Build vs buy for orchestration

Option	When
Workflow engine (existing enterprise)	Process already in Camunda/ServiceNow
Agent framework (LangGraph, etc.)	Need rapid iteration; strong eng team
Vendor agent platform	Speed; accept black-box limits; verify eval export

Buy scrutiny: Can you export tool logs? Set hard budgets? Run your golden tasks in tenant-isolated sandbox?

Detailed WORK-FLOW vs AGENT example — mortgage payment difficulty

Step	Type	Rationale
Authenticate customer	W	Deterministic identity; regulated
Classify hardship vs dispute	W + LLM node	Rules first; LLM only on ambiguous bucket
Retrieve account history	A (read tools)	Variable questions need flexible gather
Apply policy rules engine	W	Codified payment plan eligibility
Draft customer letter	A + schema	Language variation; macros insufficient
Approve letter	H	Conduct requirement
Send and log	W	Template mail merge; audit trail

Agent never calls payment reschedule API—workflow node after human sign on structured JSON from agent.

Token economics in agent loops

Typical session cost drivers:

• Planner verbosity — cap planner output tokens; structured plan JSON only
• Tool result bloat — paginate search results; summarise with citation IDs
• Re-planning every step — plan-and-execute cheaper than full ReAct on long tasks
• Model tiering — small model for tool selection; large for final user-facing text only

FinOps dashboard: cost per completed task vs human baseline—if agent costs 80% of human time value, redesign.

Security testing specific to agents

Beyond generic appsec:

• Tool injection via malicious retrieved HTML instructing tool calls
• Privilege escalation — can user A's session invoke tools with user B's scope via argument manipulation?
• Indirect prompt injection in email/calendar tools feeding agent
• Denial of wallet — attacker triggers expensive tool loop

Include in quarterly red team with agent-specific playbooks; track time-to-mitigate for Sev1 findings.

Migration from chatbot to agent — common path

Phase 1: Single-shot RAG with schema (no tools). Phase 2: Read-only tools (search, lookup). Phase 3: Draft actions with HITL. Phase 4: Limited writes with idempotency. Skip phases at your risk—teams that jump to Phase 4 recreate incident catalogues.

Each phase has eval gate before next funding tranche.

Agent programme steering metrics

Report monthly to steering—not only “sessions run”:

Metric	Why it matters
Task completion rate	Core value
HITL override rate	Trust and quality
Mean cost per completed task	FinOps sustainability
Sessions hitting budget cap %	Loop or planning issues
Tool error rate by tool	Integration health
Time saved vs baseline (sample)	Business case proof

Compare to workflow-only counterfactual where agent removed—proves agent ROI, not activity.

Playbook cross-links for delivery

Detailed workshop facilitation, reference architectures and control patterns live in Agentic AI playbook. This Learning Map topic defines competency; the playbook defines delivery. Bring both to client engagements: map for learning path, playbook for statements of work and review gates.

Summary — agent vs workflow decision tree

Is next action legally/financially irreversible?
  YES → Workflow + HITL (agent may draft only)
  NO → Is action set fixed and auditable?
    YES → Workflow with optional LLM node
    NO → Bounded agent (read tools first; writes gated)

When in doubt, prototype workflow-only baseline and measure task time before adding agent loop—proves incremental value of agent complexity.

On-call quick reference for agent incidents

Alert	First action
Tool error spike	Check downstream API; pause write tools if >5% errors
Budget cap hit rate high	Review loop detection logs; disable agent feature flag
HITL queue depth	Scale reviewers; extend SLA comms to users
Cost anomaly	Enable stricter caps; switch planner to smaller model

Post-incident: add failing scenario to task-completion golden within 48 hours.

Integration with enterprise service management

Map agent sessions to ITSM records:

• Create parent ticket or case record at session start
• Append tool call summary as work notes (not raw prompts with PII)
• Close loop when workflow reaches terminal state
• Link eval failures in non-prod to known problem records

Auditors prefer ITSM traceability over scattered application logs alone.

Competency signal for hiring and reviews

An engineer who has internalised this topic can whiteboard a W/A/H split, name three kill-switches, and explain why a travel-booking “agent” should not hold payment tools—without naming a vendor SDK. Use the practice exercises as interview or performance-review artefacts; file completed canvases in the personal pattern library referenced in How to use this Learning Map. Revisit this page when scoping any SOW that mentions “autonomous agent” in the title—default to workflow first unless eval proves otherwise in writing.

Related playbook content

• Agentic AI — patterns, workshops and governance templates
• Evaluation and observability — task completion and online monitoring
• Prompt and Context Engineering — tool schemas and injection
• Retrieval-Augmented Generation — retrieval as read-only tool
• AI Evaluation and Quality Assurance — golden tasks and regression
• Software Engineering — durable execution and API design
• Security Engineering — authorisation and DLP
• MLOps, LLMOps and Observability — logging and tracing agent steps
• Performance and FinOps — agent cost caps
• LLM Response Caching for RAG and Agents — tool, plan and node caches vs checkpoints
• Integration and Enterprise Systems — workflow and ERP boundaries
• How to use this Learning Map — reference depth standards
• 8D Framework — Deliver stage operational readiness

Output

Expected outputs for this topic:

• Agent vs workflow decision memo — step-level W/A/H canvas with rationale
• Tool allow-list — per stage with authorisation matrix
• HITL design — gates, UX evidence requirements, SLA impact
• Budget and kill-switch table — steps, tokens, cost, owners
• Loop detection and incident runbook — severities and pause procedures
• Task-completion eval set — ≥20 scenarios with thresholds
• Architecture diagram — orchestrator, workflow engine, logging, identity flow

Practice checklist

• I justified agent use vs workflow for each non-deterministic step
• I listed tools with side effect class and HITL requirements
• I defined budgets and at least three kill-switches with owners
• I documented loop detection and idempotency for mutating tools
• I specified audit log fields for tool calls and HITL decisions
• I completed task-completion eval criteria with pass threshold
• I reviewed multi-agent choice—deferred unless eval proves need
• I linked design to Agentic AI playbook

Supplemental scenario — insurance FNOL agent with HITL gates

Context: First-notification-of-loss intake; agent tools lookup_policy, create_claim_draft, schedule_adjuster; high risk on draft creation.

Workflow vs agent split:

Step	Pattern	Rationale
Identity verify	Workflow (rules)	Deterministic KBA
Policy lookup	Agent read tool	NL question variance
Coverage summary	Agent + schema	Structured output
Create draft claim	Workflow gate + HITL	Irreversible ID issued
Adjuster schedule	Workflow	Calendar API deterministic

Budget table: Max 12 tool steps/session; max €0.85 inference cost; kill-switch if create_claim_draft >15/min org-wide.

Pilot outcomes (4 weeks): Task completion on eval set 78% → 91% after shrinking tool allow-list from 9 to 5 tools; erroneous drafts 23/week → 1/week (caught at HITL).

Negative case: Early design used full agent for payment estimate—removed after red-team; estimates now read-only tool with disclaimer field in schema.

Key takeaways

• Default to workflow; agents are bounded sub-routines for flexible read/plan steps—not replacements for process engineering.
• Tool allow-lists, server-side auth and HITL on irreversible actions are non-negotiable.
• Budgets and loop detection prevent spend and ops incidents as much as prompt quality.
• Multi-agent needs measurable task-completion gain—not architecture fashion.
• Durable execution and workflow integration keep the system of record truthful.
• Kill-switches and runbooks must exist before write tools reach production.

What to do next

1. Complete the travel assistant split exercise and peer-review with a security lens on tool auth.
2. Continue to AI Evaluation and Quality Assurance for task-completion and regression gates.
3. Open Agentic AI playbook for orchestration patterns.
4. Revisit Retrieval-Augmented Generation if agents use retrieval tools heavily.