The strongest AI applications are not the ones that delegate the most to the model — they are the ones that draw the sharpest boundary between what the model decides and what the code guarantees. A 19-step methodology for building agentic applications around that boundary.
Structure is deterministic. Content is generative.
It sounds obvious. Applying it consistently is not.
The model should generate content: draft the recommendation, summarise the inputs, reason across the evidence. But the application itself should own everything structural — validation, schemas, accessibility, formatting, compliance, and every non-functional requirement. The moment you let an LLM control structure, you lose three things you cannot ship without: testability (you can't assert on output that changes shape every run), reproducibility (the same input no longer yields the same artefact), and clean debugging (when something breaks, you can't tell whether the bug is in your code or in the model's mood).
This article lays out the boundary, why the industry is independently converging on it, and the 19-step methodology I use to build agentic applications around it — one where every step produces a verifiable artefact and ends with a validation gate.
This isn't a private preference — three independent threads of engineering practice have arrived at the same boundary from different directions.
Production agents are mostly deterministic code. The 12-Factor Agents principles, distilled from over a hundred production implementations, land on the same conclusion: the agents that actually work are not "prompt plus a bag of tools, loop until done." They are well-engineered software that sprinkles an LLM only where probabilistic reasoning genuinely helps — and they own their control flow rather than letting the model (or a framework) decide when to retry, pause, or terminate.
Structured outputs are becoming the default contract. Schema-enforced generation has moved from prompt hygiene to contract-level infrastructure. Constrained decoding pushes the validation problem out of your application and into the inference engine itself — and because grammar enforcement trims the model's search space, it is often faster than unconstrained generation, not slower.
Model-owned UI fails accessibility. The research here is blunt: LLM-generated interfaces replicate the accessibility flaws of their training data, producing markup that is technically plausible and practically exclusionary. Efforts like A11YN try to align models toward WCAG compliance with reward shaping — useful, but the deeper fix is architectural: let the model choose content and intent, and let a deterministic renderer guarantee the markup.
The discipline that makes the boundary real is classification: every element of every deliverable gets explicitly labelled deterministic or generative before any code is written. Not the deliverable as a whole — every element. A single screen will usually contain both.
| Element | Classification | Owner |
|---|---|---|
| Recommendation narrative | Generative | Model (via constrained prompt) |
| Shape of the recommendation object | Deterministic | Schema contract |
| Section order, layout, typography | Deterministic | Renderer |
| Tone and persona of the copy | Generative — constrained | Prompt template |
| ARIA roles, contrast, focus order | Deterministic | WCAG-compliant UI generator |
| Disclaimers, regulatory text | Deterministic | Template — never the model |
Once an element is classified, the decision never gets re-made implicitly. If the model produces a field the schema doesn't define, that's a rejected output — not an exciting new feature. If a developer is tempted to "just let the model format the table," the classification sheet says no, and says why.
The contract at the boundary is always a schema. Every byte the model produces crosses into the application through a typed, validated structure — fields, types, enums, ranges. The model fills the slots; it never invents the shape. Downstream of that contract, a deterministic renderer turns validated data into the final artefact: the document, the dashboard, the UI. The renderer is ordinary code — testable, snapshot-able, auditable — and it's where formatting, branding, accessibility, and compliance are guaranteed rather than requested.
The boundary is a principle; shipping needs a process. I've written the approach up as a 19-step methodology covering the full lifecycle of an agentic application. The steps group into six phases:
Two mechanisms hold the nineteen steps together.
Every step ends at a gate. Each step produces a verifiable artefact — a persona sheet, a classification matrix, a schema, a rendered prototype, a passing harness — and finishes with a validation gate. You do not proceed on vibes; you proceed on evidence.
A living traceability matrix. Requirements link to implementation, implementation links to test evidence, and the matrix stays current as the system evolves. This is what makes the methodology navigable: when something changes — a new requirement, a bug, a model upgrade — you can see exactly which artefacts the change touches.
Most AI-app methodologies quietly assume a green field. Real systems live under continuous change, and this is where the traceability matrix pays for itself.
When an enhancement or bug fix arrives, you don't restart the lifecycle. You enter at the affected step and move forward from there. A copy-tone complaint enters at the constrained prompt and re-runs the gates downstream of it. A new field in a deliverable enters at the schema contract. A layout defect enters at the renderer — and never touches a prompt, because layout was never the model's job. The classification you did up front is what makes the entry point unambiguous: every defect maps to an owner, and every owner maps to a step.
This is also the quiet payoff of the whole boundary discipline. When structure is deterministic, a structural bug is just a bug — reproducible, bisectable, fixable with a failing test. It is only when the model owns structure that every defect becomes an archaeology project.
The strongest AI applications are not the ones that delegate the most to the model. They are the ones that draw the sharpest boundary between what the model decides and what the code guarantees.
Classify every element as deterministic or generative before you build. Put a schema contract on everything that crosses the boundary. Render with code, not with hope. Gate every step on a verifiable artefact, keep the traceability matrix alive, and when change comes — enter at the affected step and move forward. No restarts.