Your agent just produced 400 lines that compile, pass tests nobody asked for, and encode a design you never approved. The industry's answer is "use a bigger model." That answer costs you your budget, your code's confidentiality, and your ability to reproduce a result six months from now.

There is a better answer, and Java developers have had it for twenty years: write the specification first, and make the tests the contract.

This session walks through a working, open-source pipeline where a requirements catalog — not a chat transcript — is the source of truth. A Java MCP server exposes a small, deliberately locked-down set of tools: no "write this file," no shell. The agent must validate a requirement's structure, survive a wording review that rejects ambiguity like should, handles, and properly, turn the accepted criteria into a tagged Gherkin scenario and a JUnit test, watch it go red, then make it green. A state machine refuses to let it refactor on a red bar, and every write lands in a staging area a human reviews.

Here is the part worth your hour: once that discipline lives in deterministic Java instead of in a prompt, model capability stops being the variable that decides quality. We run the identical loop twice against the same server — once with a frontier agent in an IDE, once with a coder model on the laptop on stage through Ollama — and compare the diffs. Then we look at what makes the local model hold up: JSON-only response contracts, one-finding-at-a-time correction, validate-and-retry that feeds the invalid reply back, and deterministic templates as the floor when generation fails.

Then comes the segment most talks skip: Where This Breaks. Real failures this project hit — format drift, fixing the wrong file, silently dropping a criterion, looping on an attempt that already failed — each with the deterministic check that now catches it, and an honest account of where a frontier model is still the right call.

The server and CLI were built this way themselves: every tool has a numbered requirement, a Cucumber scenario, and a test that fails the build when spec and scenarios drift apart.

To prove the point, the demo runs with the Wi-Fi switched off.

You will leave with:
A pattern for MCP servers that enforce a workflow instead of handing agents filesystem access
The deterministic validation layer that lets a local model produce output you would sign your name to
A spec format that maps onto Cucumber-JVM and JUnit 5, and the build gate that keeps the two from drifting apart
A named catalog of local-model failure modes, each with the guardrail that catches it
A repository you can run on your own machine, behind your own firewall.

For Java developers, tech leads, and architects accountable for what their AI agents produce — especially in regulated, air-gapped, or cost-constrained environments. Comfort with JUnit and Cucumber assumed; no MCP or LLM experience needed.

Formats: 50-minute session, or a hands-on workshop where attendees run the loop on their own machines against a local model.

Requirements: projector and my laptop. No conference network needed — the demo runs locally against Ollama. Stack: Java 21, Maven, MCP Java SDK 2.0, Cucumber-JVM 7, JUnit 5.

First delivery of this talk. The workshop material is rehearsed; the local-model comparison and failure-mode segment are new.

Code and follow-along harness: github.com/davidparry/tdd-bdd-agentic (AGPL-3.0).