The mechanism
The capstone turns the earlier pieces into one reviewable system. ParcelOps receives an incident question, retrieves a synthetic record, produces a structured explanation and verifies it against the evidence. It may propose a note, but the default capstone does not execute writes. A later extension can add the approval and idempotency path after the read-only system passes its tests.
The repository-ready deliverable is small: fixture data, pure lookup logic, output validation, an optional model adapter, test cases and an evidence record. Keeping the model adapter separate allows most correctness tests to run offline. A scripted fixture passing those tests is useful application evidence, not proof of model quality.
A worked acceptance contract
Input: Explain INC-104 without changing it.
Expected source: fixture INC-104, revision 7, status delayed.
Required output: incident ID, observed status, evidence IDs, next check.
Forbidden effects: no note write, no external export, no tenant switch.
Failure behavior: unknown or partial result with a clear reason.
Evidence: case ID, configuration, checks, stop reason and run status.Download the offline lab. It contains standard-library fixtures and deterministic tests for lookup, evidence checking, idempotency, approval binding and tenant separation. Run it in a disposable directory with python3 parcelops_offline.py. It makes no network or model calls and does not modify incident systems.
The optional live extension replaces the scripted answer with the SDK invocation from chapter 6. It requires your approved model access and can incur charges. Preserve the same acceptance checks so model output cannot bypass the contract. Record a separate result for every live run; do not relabel offline tests as agent execution.
Practice: complete the release packet
Offline first. Read the fixture and tests before running them. Predict which negative cases fail acceptance and why. Then run the script and save its actual test output. Expected observation: the tests distinguish a supported delayed answer from a fabricated resolved answer, reject a cross-tenant read and preserve one effective note for a repeated request key in the local simulation.
The in-memory idempotency test intentionally lacks crash and multi-process guarantees. State this limitation in your packet. Add a design note explaining the durable transaction needed for a real service rather than extending the simulation into an accidental production implementation.
Create a short README with setup, contracts, architecture, test commands, known limits and optional live steps. Include the dependency lock and source-check date if you install the SDK. Review the diff for secrets, private records and unrelated changes before sharing it.
A practical extension sequence
First add streaming with an explicit incomplete state. Then add owned session persistence. Next introduce one reviewed MCP lookup server if interoperability is useful. Finally, add a proposed note with a concrete approval card and a separate executor. Each extension should retain the original negative tests and add tests for its new boundary.
Do not add a swarm, memory store or deployment merely to make the capstone look advanced. Complexity should answer a specific requirement and have an acceptance test. A small system with clear evidence is a stronger engineering result than a large diagram with unverified behavior.
Troubleshooting and trade-offs
If a deterministic test fails, fix the application contract before invoking a model. If only live selection fails, inspect tool descriptions and prompt context using the same fixtures. If output validation rejects a plausible answer, check whether the contract is correct before weakening it.
A PR or review packet should state what changed, what was tested and what remains untested. Do not claim deployment, production readiness or measured improvement merely because the code builds. Those require separate evidence.
Interview practice
What does the offline capstone prove?
It verifies selected deterministic application contracts against synthetic fixtures. It does not prove model selection, provider integration, distributed durability, security against every attack or production performance.
How would you add live inference without weakening the system?
Keep the same trusted lookup, authorization and output checks. Replace only the answer-producing adapter, record model configuration and evaluate representative positive and negative cases with explicit budgets.
Completion check
Produce a review packet with actual offline test output and honest limitations. If you choose live inference, attach separate model-run evidence. Explain every capability added beyond the read-only baseline.
Sources and version notes
Checked 6 October 2026. Python examples target strands-agents==1.58.0 unless labelled otherwise. Live documentation can change; compare your installed version before adapting an example.
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.