Use-case gallery: eight systems worth building
Architecture chapters risk floating free of any actual job. This one pins the six planes to eight concrete systems. For each: the job, why it deserves an agent at all, the AWS shape, the part that is genuinely hard, and which production gates dominate. Four of the eight become capstones; the other four are close cousins you can build on the same platform. The chapter ends with the cases where an agent is the wrong tool, which is knowledge worth as much as the rest.
1. The repository-audit fleet (Capstone A)
The job. Point the system at a large codebase overnight: find bugs, security smells, dead code, or migration targets; return a verified, deduplicated report with file-and-line provenance.
Why agentic. The task is judgment over an unbounded input, it parallelizes naturally by file group, and false positives are cheap to filter with a second layer of agents. This is the pattern behind real coding fleets: many finders, adversarial verifiers, one merger.
AWS shape. S3 for the repo snapshot and shards; Step Functions distributed map or an SQS-fed Fargate fleet for the workers; sandboxes for any "run the code to check" steps; DynamoDB for events and checkpoints; batch-tier Bedrock for the offline-friendly portions.
The hard part. Economics and dedup. A naive fleet re-reads the same context thousands of times; cache shaping and shard design decide whether the night costs tens of dollars or thousands. Gates 3, 6, 7.
2. The incident responder (Capstone B)
The job. An alarm fires; an agent investigates before a human is even awake: pulls logs and metrics, reconstructs a timeline, forms a hypothesis, proposes (never applies) remediation, and drafts the postmortem skeleton.
Why agentic. Investigation is iterative and hypothesis-driven; the tool sequence cannot be scripted in advance. The payoff is minutes of on-call time at exactly the worst hour.
AWS shape. EventBridge rule on the alarm; a Lambda- or AgentCore-hosted agent with strictly read-only tools (CloudWatch, X-Ray, deploy history); Step Functions callback for the "apply fix?" approval; the report lands in the incident channel.
The hard part. Trust boundaries. This agent reads production telemetry and must be constitutionally unable to write anything. Gates 1, 10, 11 dominate; a wrong action here costs more than the agent ever saves.
3. The document-intake swarm (Capstone C)
The job. Claims, invoices, KYC packets, or contracts arrive in bulk; extraction agents fan out per document, judge agents score each result against a rubric, low-confidence items route to humans, the rest flow straight through.
Why agentic. Real documents are messy enough that extraction plus self-checking beats one-shot extraction; the human-in-the-loop tail is a budgeting decision instead of a hardcoded workflow.
AWS shape. S3 event notifications into SQS; Lambda extraction workers; judge fleet on the batch tier where latency allows; DynamoDB for per-item state; an arbitration queue with a small UI for the human tail.
The hard part. Throughput economics and honest confidence. The rubric and its calibration (does 0.9 mean 90%?) matter more than the extraction prompt. Gates 5, 8, 9.
4. The research service (Capstone D)
The job. A deep-research API: given a question and a budget, fan out searchers, read sources, adversarially fact-check claims, and synthesize a cited report.
Why agentic. Coverage requires parallel exploration down different paths; quality requires verification agents that try to refute what the finders claim. Neither is expressible as a fixed pipeline.
AWS shape. The full Hive control plane; searcher and reader workers on Fargate; verifier panel with majority gates; per-request budget enforced at admission; the report assembled with citation provenance from the event log.
The hard part. The verification mesh: how many refuters, what majority threshold, and how to measure the false claims removed per dollar spent. Gates 3, 8.
5. The internal copilot mesh
The job. A company-internal assistant that can actually do things: query internal APIs, file tickets, look up customers, remember the user's context across sessions.
Why agentic. The value is tool breadth plus memory, both of which are agent-shaped by definition.
AWS shape. This is AgentCore's home turf: Runtime for per-user sessions, Gateway to turn internal APIs into MCP tools without rewriting them, Identity for OAuth so user credentials never enter prompts, Memory for cross-session context. Part 3 essentially builds this system while dissecting the components.
The hard part. Identity done right (the agent acts as the user, with the user's entitlements, not as a super-service) and memory hygiene. Gates 1, 11.
6. The pipeline babysitter
The job. Data platform triage: a dbt model fails or freshness slips; an agent diagnoses (schema drift? upstream nulls? a bad merge?), files a precise ticket, and for a whitelisted class of fixes opens the PR.
Why agentic. Failures are heterogeneous and log-shaped; the investigation is the same grind a data engineer does by hand at 9 a.m.
AWS shape. EventBridge from the orchestrator's failure events; a read-mostly agent with warehouse and git tools; the PR path behind an approval gate; one shared fleet serves all pipelines.
The hard part. Deciding the whitelist: which fixes are safe to propose as code versus describe in a ticket. Gates 10, 12.
7. Browser and workflow automation
The job. Tasks whose only interface is a website or legacy UI: portal filings, supplier lookups, systems with no API.
Why agentic. There is no API to call; acting through a browser demands perception and recovery from surprise, which is what models bring.
AWS shape. AgentCore Browser sessions (or a purpose-built browser action model, which we tour in Part 10) driven by a planning agent; artifacts and screenshots to S3 for audit; strict allowlists on reachable domains.
The hard part. Reliability and audit. UI automation fails in creative ways; every action needs a screenshot trail, and the domain allowlist is the real security boundary. Gates 2, 9, 11.
8. The back-office approvals agent
The job. Procurement, finance ops, access requests: an agent assembles the case (policy, budget, precedent), drafts the decision with citations to policy, and routes it through the human approval chain.
Why agentic. The reading and cross-referencing is judgment work, but the decision rights stay human; the agent compresses the packet-building.
AWS shape. Step Functions as the approval chain of record;
waitForTaskToken for each human step; the agent as one state among many;
every recommendation traceable to source documents in the event log.
The hard part. Resisting scope creep: the day someone suggests auto-approving "the easy ones" is the day gates 8 and 10 earn their keep, because you now need measured error rates and an audit trail that survives a regulator.
The gallery at a glance
| # | System | Fleet size | Latency shape | Dominant gates | Capstone |
|---|---|---|---|---|---|
| 1 | Repository-audit fleet | 100s | overnight batch | 3, 6, 7 | A |
| 2 | Incident responder | 1 to 3 | minutes, on event | 1, 10, 11 | B |
| 3 | Document-intake swarm | 10s to 100s | continuous stream | 5, 8, 9 | C |
| 4 | Research service | 10s | minutes, per request | 3, 8 | D |
| 5 | Internal copilot mesh | 1 per user | interactive | 1, 11 | (Part 3) |
| 6 | Pipeline babysitter | 1 to 5 | minutes, on event | 10, 12 | (cousin of B) |
| 7 | Browser automation | 1 to 10 | minutes per task | 2, 9, 11 | (Part 10 tour) |
| 8 | Approvals agent | 1 per case | hours, human-paced | 8, 10 | (cousin of C) |
Read the table columns as design inputs: fleet size drives the execution plane choice, latency shape drives queue-versus-state-machine, and the gate column tells you where the review effort goes.
When an agent is the wrong tool
The gallery earns credibility by naming its complement. Four honest anti-cases:
- High-volume, fixed-schema classification. A million sentiment labels a day is a single-call batch job with a cached prompt, not an agent. The loop adds latency and cost with no judgment to spend it on.
- Hot-path, latency-critical decisions. Anything inside a request path measured in tens of milliseconds. An agent's floor is a model round-trip; design the product so agents work ahead of or beside the hot path, not in it.
- Fully specifiable workflows. If you can draw the flowchart, build the flowchart. Step Functions with a model-call state where judgment is needed beats a free-running loop on cost, auditability, and sleep quality. (This is the "workflows versus agents" line, and it is the right default even though this is an agents book.)
- Exact arithmetic of record. Billing, payouts, regulatory numbers: agents may assemble and check these, but the calculation of record is deterministic code with tests. An agent that "usually gets the invoice right" is a liability with a chat interface.
Don't be confused: "the agent decides" vs "the agent recommends." Systems 2, 6, and 8 are recommendation-shaped: the agent's output is a proposal that a human or a deterministic gate converts into action. That one design choice moves them across the feasibility line. The same systems built as autonomous actors would fail gates 10 and 11 today, at least in most organizations' risk appetite.
👉 Next: the lab catalog, every lab in the book with its tier and price, plus the sizing math for planning a fleet before you spend a dollar.