Capstone project

The capstone project integrates every concept from this course into a single, coherent system. You will choose a real use case, gather requirements, design an architecture, implement the agent, and produce documentation that could be handed over to a new engineer on their first day. This module provides the project specification, acceptance criteria, and submission structure. Module 24 covers peer review.

The project is not graded on ambition. A simple agent that works reliably, is well-tested, and is clearly documented demonstrates more mastery than a complex agent that is brittle, untested, and undocumented. Choose a scope you can complete to high quality in your available time.

Select one of the following three project tracks based on your context and goals. Each track has minimum requirements that must all be met. You may extend beyond the minimum, but the minimum is non-negotiable for certification.

Track A: Internal process automation. Automate a repetitive internal workflow at a company or organisation. Example systems include a meeting notes summariser with action item extraction and CRM (Customer Relationship Management) update, an invoice processing agent that extracts data, validates against purchase orders, and routes for approval, or a compliance monitoring agent that reads new regulations and flags relevant policy gaps. Minimum requirements: reads from at least one external data source (email, file, database, or API); writes to at least one external destination; has a human approval gate for high-risk actions; processes at least three distinct task types.

Track B: Customer-facing agent. Build an agent that interacts directly with external users. Example systems include a technical support agent with knowledge base retrieval, an onboarding assistant for a software product, or a research assistant for a professional services firm. Minimum requirements: multi-turn conversation with memory between turns; RAG (Retrieval-Augmented Generation) pipeline retrieving from at least 50 documents; intent classification with appropriate routing; graceful handling of out-of-scope requests.

Track C: Technical research tool. Build an agent that performs autonomous research or analysis. Example systems include a competitive intelligence agent, a code review agent, a scientific literature summariser, or a market analysis tool. Minimum requirements: multi-source research across at least three different APIs or data sources; plan-and-execute pattern for structured research workflow; structured output (reports, data files) that could be consumed by another system; bias and hallucination mitigation documented.

Before writing any code, document your project charter. This document forces clarity about what you are building and for whom. It also becomes the reference your peer reviewer will use to assess whether your implementation matches your stated intentions.

Your requirements document must include six sections: a problem statement (one paragraph stating what problem the agent solves and for whom); a users and stakeholders table (listing each role, what they do, and what they need from the agent); functional requirements (each with a unique ID, priority, and verifiable acceptance criterion); non-functional requirements (latency, availability, and cost targets with measurement methods); security requirements (data classification, authentication, and authorisation controls); and an explicit out-of-scope list (what the agent will not do).

The out-of-scope list is as important as the requirements themselves. Agents without explicit boundaries tend to accumulate responsibilities that were never designed, tested, or documented. Writing the boundary explicitly before you start keeps it enforceable.

Use the decision tree from the Architecture Fundamentals module to select your agent pattern. Document that decision in an ADR (Architecture Decision Record). An ADR records what you decided, the context that drove the decision, the alternatives you considered, and the consequences you accept. ADRs are standard practice in professional software engineering because they make reasoning visible to future maintainers.

Your architecture documentation must include five artefacts. First, a system context diagram (C4 Level 1): shows your agent system as a single box with external users and external systems around it. Second, a component diagram (C4 Level 2 or equivalent): shows internal components including the agent loop, tools, memory, and external APIs. Third, a tool inventory: a table of every tool the agent uses, with schema, permission level, and error handling approach. Fourth, a data flow description: what data enters the system, what is stored, and what leaves. Fifth, security controls: how you implement input validation, output filtering, and access control.

Your implementation must demonstrate four capabilities. The core agent loop must return a structured response object containing the answer, the list of tool calls made, the total token count consumed, the number of loop iterations taken, and a status field with one of three values: success, failure, or partial.

Every tool must have a specific and unambiguous description (never a vague phrase such as "this tool does things"), validated inputs using Pydantic or an equivalent validation library, structured error returns rather than raw exceptions, and a unit test covering both correct and incorrect inputs.

Minimum test coverage requires unit tests for every tool (happy path plus at least two error cases), an integration test of the complete agent loop on five representative requests, and at least one bias or edge case test that documents a known failure mode and how it was mitigated.

Every tool call must emit structured log output with these fields: timestamp, request ID, tool name, input summary, result status, latency in milliseconds, and tokens used. This is not optional logging. It is the observability foundation that makes a production agent diagnosable when something goes wrong at 2am.

Before submission, work through this security checklist. Each item must be verifiable from your code or documentation. If you cannot point to evidence of a control, it is not implemented.

Secrets management. No API keys, passwords, or tokens in source code or version control. All credentials are loaded from environment variables or a secrets manager. A .env.example file documents required environment variables without containing actual values.

Input validation. Every tool input is validated before it reaches external systems or the agent loop. Validation errors return structured error objects, not raw exceptions or stack traces.

Least privilege. Tools have only the permissions they require. A tool that reads documents does not have write permission. A tool that queries a database does not have delete permission. These boundaries are documented in the tool inventory.

Code execution safety. If your agent runs code, execution must be sandboxed. Use a restricted evaluator such as simpleeval for arithmetic, or a Docker (containerisation) environment with no network access for more complex execution. Passing model-generated strings to Python's unrestricted dynamic evaluation functions is a critical security vulnerability that has appeared in real-world agent deployments.

Human approval gate. Any action with significant real-world consequences (sending an email to a customer, writing to a production database, making a financial transaction) requires explicit human approval before execution.

Your submission must include a README.md file that contains six sections. Setup instructions must be step-by-step and must have been verified by someone other than the author. An architecture overview must summarise the system and link to the full architecture documents. A tool reference must be a table of all tools with descriptions. A known limitations section must honestly assess what the agent cannot do reliably. A security notes section must state what credentials are needed and how they are managed. A runbook must provide step-by-step instructions for what to do when the agent fails, covering at least two failure scenarios.

The known limitations section is the hardest to write because it requires honest self-assessment. Deliberately test five adversarial or edge-case inputs before writing it. The agent will fail on some of them. Document those failures. A system whose limitations are unknown is more dangerous than one whose limitations are catalogued.

Your project passes when all eight criteria are met. The agent runs end-to-end on at least five representative inputs without crashing. All unit tests pass. No API keys or secrets appear in source code. No em dashes or AI-tell phrases appear in any documentation. Architecture artefacts match the implemented system. Security controls are documented and implemented. Another engineer could set up and run the agent following your README alone. At least one known limitation is honestly documented.

The peer reviewer in Module 24 (Peer Review and Certification) will check each of these criteria against a rubric. Partial credit is not available for the criteria marked "required" in the review rubric.