Capstone and certification stage summary

The project integrates the course into one coherent system. You choose a real use case, gather requirements, design an architecture, implement the agent and produce documentation that could be handed to a new engineer on their first day. The module supplies the specification, the acceptance criteria and the submission structure; peer review is handled by the module that follows. The judgement is stated plainly: 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.

Three tracks are offered and each carries minimum requirements that all have to be met. Track A, internal process automation, covers work such as a meeting notes summariser that extracts action items, an invoice agent that validates extracted data against purchase orders, or a compliance agent that flags policy gaps; it must read from at least one external data source, write to at least one external destination, carry a human approval gate for high-risk actions and process at least three distinct task types. Track B, a customer-facing agent, must hold a multi-turn conversation with memory between turns, retrieve from at least fifty documents through a retrieval-augmented pipeline, classify intent and route accordingly, and handle out-of-scope requests gracefully. Track C, a technical research tool, must research across at least three different interfaces or data sources, use a plan-and-execute structure, emit structured output another system could consume, and document its bias and fabrication mitigations.

The tracks are not three flavours of the same exercise. Each set of minimums forces a different part of the course into the build: Track A forces external reads and writes and an approval boundary, Track B forces memory across turns and a retrieval pipeline whose quality you have to measure, and Track C forces multi-source planning and an honest account of where the output cannot be trusted. You may extend beyond the minimum, but the minimum is non-negotiable for certification, so choose on the basis of which set you can meet to a high standard in the time you have.

Before any code is written, the module asks for a project charter in six parts. A problem statement of one paragraph saying what the agent solves and for whom. A users and stakeholders table listing each role, what that role does and what it needs from the agent. Functional requirements, each with a unique identifier, a priority and a verifiable acceptance criterion. Non-functional requirements covering latency, availability and cost targets, each with the method by which it will be measured. Security requirements naming data classification, authentication and authorisation controls. And an explicit out-of-scope list.

The words verifiable and measurable are doing the work. A requirement with an identifier and an acceptance criterion can be checked against the implementation by somebody who did not write either, which is exactly what your reviewer will do; a requirement phrased as an aspiration cannot. The same applies to the non-functional set, where a latency or cost target without a stated measurement method is a preference rather than a requirement. This document is also the reference the reviewer uses to judge whether what you built matches what you said you were building, so vagueness here does not protect you, it removes the standard you would have been judged against.

The out-of-scope list is as important as the requirements themselves. Agents without explicit boundaries accumulate responsibilities that were never designed, tested or documented, and once the boundary is only implicit there is nothing to enforce. Writing it before you start keeps it enforceable. The stage's blunt version of the argument is that changing an architecture is cheaper than rewriting an implementation, which is why the requirements and architecture documents come first and why an hour spent on a one-page charter and a context diagram routinely saves days of rework.

The architecture documentation has five required pieces. A system context diagram at C4 Level 1, showing the agent system as a single box with the external users and external systems around it. An internal view showing the agent loop, the tools, memory and the external interfaces. A tool inventory: a table of every tool with its schema, its permission level and its error handling approach. A data flow description saying what enters the system, what is stored and what leaves. And a statement of the security controls: how input validation, output filtering and access control are implemented. One caution on the notation: the module labels the internal view as C4 Level 2 or equivalent, while the C4 site itself sets out the hierarchy as software systems, containers, components and code, so a view of the agent loop, its tools and its memory is a component diagram in C4's own vocabulary, one level below containers.

The decision itself belongs in an architecture decision record. The module asks it to carry what you decided, the context that drove the decision, the alternatives you considered and the consequences you accept. That maps closely onto the form the practice is usually taught in, where a record has a short title, a context section describing the forces at play, a decision written in full sentences and active voice, a status such as proposed or accepted, and a consequences section describing the resulting context after the decision is applied. The consequences section is the one people skip and the one a reviewer scores, because it is where the cost of the choice is written down while it is still cheap to change your mind.

The claim that diagrams are only worth drawing for complex systems does not survive contact with a review. A single-agent system still has external dependencies, data flows and permission boundaries that are invisible without a diagram, the context diagram takes about twenty minutes, and it is the first thing a new engineer should read. The acceptance criteria then close the loop by requiring that the architecture artefacts match the implemented system, so a diagram that drifted away from the code during the build is a defect in its own right rather than a cosmetic issue.

The rule at the top of the checklist sets the standard for the whole stage: each item must be verifiable from your code or your documentation, and if you cannot point to evidence of a control, it is not implemented. Secrets management means no keys, passwords or tokens in source code or version control, credentials loaded from environment variables or a secrets manager, and an example environment file that documents the required variables without containing any values. Input validation means every tool input is validated before it reaches an external system or the agent loop, and that validation failures return structured error objects rather than raw exceptions or stack traces.

Least privilege is checked against the tool inventory rather than asserted in prose. A tool that reads documents does not hold write permission; a tool that queries a database does not hold delete permission; and those boundaries are written into the inventory so a reviewer can compare them with the credentials the code actually uses. Code execution safety is the item with the sharpest edge: if the agent runs code, the execution has to be sandboxed, using a restricted evaluator for arithmetic or a container with no network access for anything larger. Passing model-generated strings to an unrestricted dynamic evaluation function is a critical vulnerability, and the module notes that it has turned up in real agent deployments rather than only in exercises.

The last item is the human approval gate. Any action with significant real-world consequences, such as sending an email to a customer, writing to a production database or making a financial transaction, requires explicit human approval before it executes. In the review rubric this is scored twice over, once under architecture, where controls have to be implemented rather than mentioned, and once under ethics and safety, where the gate has to be implemented and tested rather than planned. That doubling is deliberate: an approval gate that has never been exercised is an assumption, not a control.

The core agent loop has to return a structured response object rather than a bare string: the answer, the list of tool calls made, the total token count consumed, the number of loop iterations taken, and a status field carrying one of success, failure or partial. Each field earns its place. Partial is the status that stops a half-finished run being reported as a success. The iteration count is the number a step limit is enforced against, and the review rubric asks explicitly whether a step limit exists to stop the loop running indefinitely. The token count is what makes a cost target measurable rather than aspirational.

Every tool carries a four-part contract: a specific and unambiguous description rather than a vague phrase, inputs validated through a schema validation library, structured error returns rather than raised exceptions, and a unit test covering both correct and incorrect inputs. The test floors are stated as minimums. Unit tests for every tool, covering the happy path plus at least two error cases. One integration test that exercises the complete agent loop on five representative requests. And at least one bias or edge-case test that documents a known failure mode and the mitigation applied to it, which is the test that turns an uncomfortable discovery into a documented limitation.

Observability is specified at the level of the individual log line. Every tool call emits a structured record carrying a timestamp, a request identifier, the tool name, a summary of the input, the result status, the latency in milliseconds and the tokens used. The module is explicit that this is not general-purpose logging but the foundation that makes a production agent diagnosable when it fails at an inconvenient hour, and the self-assessment later asks whether you could trace a bug through the loop from log output alone. That question is the real test of whether the fields you chose were the right ones.

The review cycle has five steps. You submit the project as a repository with its documentation. Two reviewers are assigned and assess it independently against the five categories. Each returns written feedback within three working days. You then either revise the submission or write a considered response explaining why you disagree, which is a legitimate outcome rather than a failure to comply. The coordinator reads the feedback and your response and marks the module complete. You are also required to review at least one peer project against the same rubric, and that is not the lighter half of the obligation: the review you give is itself evidence of your competence.

The five categories each carry a required minimum. Functionality, at adequate or strong, asks whether the agent runs end-to-end on five test inputs without crashing, whether unit tests pass, whether tools return structured errors rather than raw exceptions, and whether a step limit exists. Architecture, at adequate or strong, asks whether the pattern matches the stated requirements with a justification rather than a default, whether the tool inventory is complete with schemas and permission levels, whether there is a decision record, and whether security controls are implemented rather than mentioned. Code quality, at adequate, asks about secrets, tool description specificity, input validation, structured logging and sandboxing. Documentation, at adequate or strong, asks whether setup instructions have been verified, whether at least one limitation is stated honestly, whether the runbook covers at least two failure scenarios and whether the architecture documents match the build. Ethics and safety, at adequate or strong, asks about least privilege, the approval gate, a bias or edge-case test and data handling including retention. Needs work in a required category means revision before certification.

Three habits separate a professional review from a general comment. Reference the code or documentation directly, citing the file and the line rather than describing the issue in the abstract. Separate the observation from the recommendation: state what you saw, then what could be improved and why. And acknowledge two or three things that are working, which shows you read the whole submission and makes the critique easier to receive. The module's own contrast is the clearest statement of the rule: saying the security is not good and pointing at a named tool whose description gives the model no basis for choosing it, with a suggested revision, describe the same defect, and only the second gives the author something to do. Reviewing at the same level of experience as the author is not a limitation either, because familiarity blindness affects every author: a fresh reader sees the confusing naming, the implicit assumption and the setup step that was skipped because it seemed obvious.

The self-assessment runs before submission and is organised in three competency groups. The technical group asks whether you can explain what a context window is and why it limits agent memory, write a tool description that makes the agent select the tool correctly in a test, trace a bug through the loop from log output, implement exponential backoff against a rate-limited interface, and distinguish prompt injection from jailbreaking. The architecture group asks whether you can justify your pattern choice against the specific requirements you documented, draw a context diagram without a template, name two trade-offs you accepted and write a decision record for your most significant choice. The professional group asks whether another engineer could set the project up from the README alone, whether two failure modes and their recovery steps are documented, and whether you have tested at least one input you expected the agent to handle badly and recorded what happened.

Three gaps appear most often in submitted projects, and knowing them in advance lets you close them before a reviewer finds them. The first is vague tool descriptions, which is the most common reason agent behaviour is hard to control: a description saying the tool searches the database gives the model no basis for choosing between it and an alternative. The fix is to rewrite every description with a use-when clause, a do-not-use-when clause and at least one example trigger phrase, then test it by asking whether another engineer reading only that description would route requests the way you do.

The second gap is tools that raise raw exceptions, which crash the loop instead of letting it recover; the fix is to wrap each tool function and return a structured error object carrying at minimum a message and an error type, so the loop can retry, escalate or stop cleanly. The third is a missing limitations section. Nearly every project has limitations, so a submission without them is more likely to be unaware of them than free of them, which is the more concerning of the two conditions. The fix is procedural: deliberately test five adversarial or unusual inputs before writing the README, record which produce incorrect or incomplete results, and state what an operator should do in each case.

The evidence package has six items and all six are required. The capstone project as a repository, public or shared with your reviewer. Architecture documents in the repository, including a context diagram, a tool inventory and at least one decision record. Test results showing the unit tests passing, either as continuous integration output or as verified screenshots. The written peer review feedback you received, covering at least two review categories. The written peer review feedback you gave on at least one peer project. And a signed self-assessment checklist with every item answered.

The package is built the way it is because continuing professional development is a documented, structured approach to learning that is planned, recorded and evaluated, and because the evidence has to show that learning was applied rather than that a course was attended. That is the standard the module attributes to the CPD Standards Office. It is also why both directions of review count: the review you gave is evidence of evaluation skill, and the review you received and responded to is evidence of professional receptivity to feedback. Neither substitutes for the other.

It is worth being precise about what the resulting certificate claims. It documents that specific learning outcomes were achieved and evidenced at a point in time. Competence is demonstrated through repeated application over a longer period, which no certificate can assert on your behalf, so the sensible use of one is as a foundation rather than a finish line. Note also what this module does and does not contain: it supplies the rubric, the self-assessment and the evidence package, and it describes the certification process, but the certifying assessment itself sits outside the module page, so treat the checklists here as preparation for it rather than as the assessment.

Every architecture decision accepts a trade-off, and four axes cover most agent work. Cost against reliability: redundancy, resilience testing and circuit breakers all cost more to build and operate, so state the reliability level the requirements actually demand and then meet it at minimum cost rather than buying the highest available. Speed against accuracy: reflection passes and multi-step verification improve answers and add latency, and the latency budget comes from the requirements rather than from the pattern. Security against usability: every approval gate reduces risk and reduces throughput, so identify the actions that carry real consequences and gate those selectively rather than gating everything. Simplicity against capability: a supervisor multi-agent architecture adds latency, cost and operational surface, so if a single agent with a router satisfies the requirements, that is the answer.

The five challenge scenarios are constructed so that the constraints, not the subject matter, choose the pattern. A breaking news summariser checking fifty sources on a short cycle takes map-reduce with asynchronous fetching, because the fetches are independent and sequential fetching leaves little room for retries once a source is slow; the trade-off is per-source failure, answered with a timeout for each source and a tolerance for a small proportion failing, and reflection is ruled out by the cycle time rather than by any judgement about its value. A legal contract reviewer with a four-hour service level takes a chain with retrieval and a reflection step plus a non-negotiable human approval gate, and accepts latency as the price. A complaint router at high volume takes a single agent behind a lightweight classifier and a queue, and accepts that routing accuracy depends on the classifier's training distribution, mitigated by sending low-confidence classifications to an exception queue rather than by adding a supervisor, which is the one place the challenge admits a human without breaking its own constraint.

The last two scenarios add the constraints that are easiest to underestimate. A code review agent facing pull requests far larger than one context window takes map-reduce with chunking plus a second verification pass to hold the false positive rate down, read-only access to the pull request and write access only to the comment interface, and no merge or approval permission at all; the accepted cost is that chunked review can miss an issue spanning several files, which is documented as a known limitation rather than hidden. An enterprise knowledge assistant over a large document corpus takes retrieval with permission filtering applied at query time inside the vector store rather than after retrieval, a citation in every response, and query logs that can be deleted for an individual on request; the accepted cost is that permission filtering reduces index coverage and so answer quality for users with restricted access, which has to be said to those users rather than left as a surprise. Scoring reflects the priority: three points for the right pattern with a valid justification and the primary trade-off correctly identified, two if the trade-off is secondary or misidentified, one for a defensible but suboptimal pattern, and none for a pattern that would not meet the constraints at all.

Rule one is to match the pattern to the constraint rather than to the default. The most common error is reaching for a complex pattern because it feels more capable, not because the constraints require it. Start with the simplest pattern that satisfies all the stated requirements and add complexity only when the simpler approach has a documented, verifiable failure mode under those requirements. The corollary is that over-engineering costs as much as under-engineering, because every extra component is another thing that can fail, another network call, more latency, more spend and more to operate.

Rule two is to name the primary trade-off explicitly. Map-reduce accepts partial failure. A chain with reflection accepts latency. A supervisor accepts coordination overhead. If you cannot say what your chosen pattern costs you, you do not understand it well enough to run it in production, and the sentence you would have written becomes the first line of the risk register entry for that decision. This is the same discipline as the consequences section of a decision record, applied at the moment of choosing rather than afterwards.

Rule three is that security and compliance constraints are inputs to the architecture, not additions to it. Least privilege, approval gates, audit logging and deletion requirements belong in the first diagram, because retrofitting them means redesigning the permission model, the logging schema and often the storage layer. The knowledge assistant scenario is the clean illustration: filtering documents by permission at query time is an architecture, while filtering them after retrieval is a leak with a filter in front of it. The habit to carry out of the stage is that there is no optimal architecture for a task type, only one that correctly addresses the constraints of a specific context, which is why the same brief can produce different correct answers in two organisations.