Sprint 8 · Capstone

Ship a flagship agentic product: decoupling + harness + guardrails + evals

Build

Concept

What a flagship agentic product actually requires

By Sprint 7, you have built every load-bearing piece of a production-grade agentic system: a perceive-reason-act loop, schema-validated tools, memory architectures, supervisor-worker orchestration, eval harnesses, the plan-first execution discipline, and layered guardrails. The capstone asks you to combine them into a single coherent product — something you would put your name on and link from a portfolio.

What makes a system a product rather than a demo is the same thing that distinguishes a reliable agent from a clever one: the non-model layers are doing most of the work. A product has deterministic input validation so bad data cannot reach the model in the first place. It has structured tool contracts so the model's outputs route into well-typed actions. It has an eval harness so you can tell when a change makes it better or worse. It has guardrails that hold regardless of what the model reasons. The model is the judgment layer inside a composed system, not the system itself.

The four pillars and how they compose

A well-structured flagship product applies each pillar in a deliberate way.

Logic decoupling means keeping the model as a judgment layer and placing deterministic code around it. Data retrieval, input sanitisation, schema validation, output routing, and any computation with a correct answer — these belong outside the model. As Anthropic's primary reference on agent architecture frames it, the model should be reserved for tasks where genuine judgment or synthesis is required; everything else should be deterministic code that does not vary with the model's mood or temperature.

The harness (Sprints 5–6) wraps the execution loop: impact maps before changes, plan-first protocol before any destructive action, eval gates that run after each iteration. As shown in Anthropic's account of building a multi-agent research system, stability at scale comes from execution discipline around the model, not from a cleverer model. The harness is what makes iteration safe: each change is bounded by what the impact map predicted, and each outcome is measured by the eval suite.

Layered guardrails (Sprint 7) provide two deterministic gates: input validation that rejects injection-carrying requests before any model call, and a tool allow-list that blocks every proposed tool call not explicitly permitted for the current task. Both run outside the model's reasoning path. As Anthropic's guardrails documentation makes clear, asking the model to detect or resist injection is structurally insufficient — the detection and rejection logic must be architecture, not prompt.

Evals close the loop. A product is only as reliable as its regression coverage. The eval suite should include deterministic checks for every tool call contract, a trajectory check that the agent reaches the goal state within a bounded number of steps, and a model-as-judge check for at least one open-ended output. Together they give you the feedback signal that makes iterative improvement tractable.

Synthesis: what belongs where

The hardest design question for a flagship product is the same question that runs through every sprint in this track: at each capability, which layer owns it? Deterministic code owns it if there is a correct answer a function can compute reliably. The model owns it if the task requires judgment, contextual synthesis, or reasoning over ambiguous inputs that a rule cannot cover. Guardrails own the boundary enforcement — they are not model reasoning, they are structural constraints.

The Golden Rule

Never ask an LLM to do something a deterministic function can do reliably. Applied as a capstone design test: for every capability in your product, ask whether a deterministic function could do it reliably. If yes, move it out of the model. Only keep the agent where genuine judgment or synthesis is required — and structure the architecture so that no amount of model confusion can override the structural constraints around it.

How the four pillars reduce surface area

A product that applies all four pillars correctly has a very small surface area of model-dependent behaviour. Inputs are validated deterministically before the model sees them. The model's action proposals are gated by an allow-list before any tool is invoked. The harness wraps each execution in an impact-bounded, eval-measured loop. What remains in the model's domain is genuine: reasoning about ambiguous goals, synthesising information across retrieved documents, making judgment calls that a rule cannot cover. That residual is what the model is for — and structuring the system so that is all the model is for is the core design discipline the capstone is testing.

Build

What to build this sprint

The capstone build lives in your own standalone GitHub repository — not in this course repo. This site only links it from the portfolio page. The in-repo artifact for Sprint 8 is the design/spec brief at projects/sprint-8/README.md, which defines what you are building, the acceptance bar, and how to link it into the portfolio when it is ready.

  1. Read the capstone brief. Open projects/sprint-8/README.md. It defines the goal, the four pillars to apply, the acceptance bar, and the portfolio link instructions. Read it fully before designing your product.
  2. Design your flagship product. Choose a domain where an agentic system provides genuine value — something you would use or that solves a real problem. Write a design document that specifies: what the product does, what tools it exposes, which inputs are validated deterministically before the model, which tool calls are gated by an allow-list, and what the eval harness checks. The design document is the first ship item.
    bash 
    $ mkdir my-flagship-agent && cd my-flagship-agent
$ git init
$ touch design.md agent.py eval_harness.py README.md
# Scaffold your capstone repo. The design.md is your first deliverable.
  3. Apply the Golden Rule to each capability. For every capability in your design, write a short note (one sentence each): does it belong in deterministic code, in the guardrail layer, or in the model? This classification exercise is the core discipline the capstone is testing. At minimum, classify two capabilities: one that stays deterministic and one that genuinely needs the agent.
  4. Scaffold the product in your standalone repo. Implement the structure: the tool-dispatch loop with input validation gate, the tool allow-list gate, the harness entry point, and the eval suite skeleton. The scaffold does not need to be fully functional — it needs to demonstrate the four-pillar architecture in runnable form.
    bash 
    $ python agent.py
# Your scaffold should run without errors and demonstrate
# at least one deterministic gate blocking a disallowed action.

$ python eval_harness.py
# Your eval harness should run and print per-case pass/fail results.
  5. Link it into the portfolio. When your standalone repo is ready, link it from the portfolio page. See projects/sprint-8/README.md for the exact format. The portfolio entry should include the repo URL, a one-sentence product description, and the Golden Rule note classifying at least two of its capabilities.
When you are done

You have a written design/spec for a flagship agentic product that combines all four pillars. You have scaffolded it in your own standalone GitHub repo — not in this course repo. You have a portfolio entry linking it, with a Golden Rule note classifying at least two capabilities (which stay deterministic, which need the agent). That is the Sprint 8 ship condition — and the capstone of the Agentic Engineering Lab.