MVC in Practice: Operationalizing Minimal Viable Context
Part 2 of the Minimal Viable Context series. The lifecycle, the ownership model, the metrics, and the failure modes of running context packages instead of PRDs.
Part 1 argued that the PRD is dissolving into something new: a runnable context package built on Minimal Viable Context, the smallest bundle of structured information that reliably produces correct behavior from an AI agent. The most common response I got was some version of: I buy the argument, now what do I do on Monday morning?
Fair. Part 1 was a thesis (from a few months ago — my bad!). This is the operating manual.
The disclaimer: nobody has fully operationalized this yet, including myself. What follows is assembled from what’s working on teams I’ve watched adopt agent-driven development, what’s failing on teams that adopted it poorly, and what I’ve learned building context infrastructure myself. Treat it as a map drawn mid-expedition.
The lifecycle, remapped
The product development lifecycle doesn’t get replaced. Discovery, definition, build, validation, operation: those phases survive because they map to real epistemic states (we don’t know what to build, we know what but not how, we’re building it, we’re checking it, it’s live). What changes is the artifact each phase produces and consumes.
Discovery changes the least. Talking to customers, studying behavior, forming judgment about what matters: agents don’t do this for you, and pretending otherwise is how you end up automating the wrong thing very efficiently. What changes is discovery’s output. Instead of insights flowing into a narrative deck, they flow into candidate objectives and non-goals: the raw material of component one. Every discovery conversation should end with someone asking “does this change an objective, add a constraint, or produce a canonical example?” If the answer is no, it was a nice conversation.
Definition inverts. This is the single biggest workflow change, and it’s the one I’d start with if you change nothing else: write the acceptance tests before the prose [2]. In the PRD world, definition starts with narrative (the why, the user story, the market context) and acceptance criteria come last, often written by whoever drew the short straw. In the MVC world, definition starts with “what must be true for this to ship,” stated as executable assertions, and narrative exists only to explain decisions the tests can’t encode.
This inverts the review, too. A PRD review is a debate about a story. A context package review is much closer to a code review: are these tests actually testing the objective, are the constraints complete, do the canonical examples cover the personas? Opinion still enters, but it enters at the level of “is this the right objective” rather than “I read that sentence differently than you did.”
Build becomes a feedback channel, not a handoff. When the agent executes against the package, something valuable happens: every failure is diagnostic. If the agent asks a clarifying question, the package was ambiguous. If it does the wrong thing confidently, a constraint or non-goal was missing. If it does the right thing slowly, the examples were weak.
The discipline here is treating every clarification as a context bug. Don’t answer the agent’s question in chat and move on. Answer it, then patch the package so the question can never occur again. Teams that skip this step end up with a context package that’s technically versioned and practically fictional, while the real context lives in scattered chat threads. That’s the same failure mode as the wiki nobody updates, and it compounds just as fast, if not faster.
Validation becomes two gates instead of one. Gate one is mechanical: do the acceptance tests pass? This is the gate that used to be a meeting. Gate two is judgment: the things tests can’t capture. Taste, brand coherence, ethical comfort, the felt experience of the flow. Part 1 argued that what remains for humans is judgment; validation is where that judgment gets exercised. The mistake to avoid is letting gate one’s objectivity crowd out gate two’s necessity. “The evals pass” is necessary and radically insufficient, and any team that ships on green checkmarks alone will learn this in public.
Operation is where context packages earn their keep, and where documents never could. A PRD is done when it ships. A context package is never done (continuous and dynamic), because the world under it moves. Three things drift: the product (features change), the users (behavior shifts), and, this is the one nobody budgets for, the model itself. Providers retune what’s behind an API alias without ceremony. In my own testing I’ve measured the same prompts consuming over 40% more tokens across a model version change, byte-identical inputs, without an announcement. If your context package was tuned for last quarter’s model behavior, your acceptance tests are the only thing standing between you and silent regression. Re-run the eval suite on every model update the way you’d re-run unit tests on a dependency bump. It’s the same event.
Who writes what
Part 1 argued that roles reconverge around the shared package rather than sequential handoffs. Here’s the concrete version, mapped to the five MVC components:
Objective and non-goals: product owns this outright. This is the residue of the PM role once the translation work evaporates, and it’s the highest-judgment component in the package. Nobody else should be writing it, and a PM who delegates it to the agent has automated themselves out of the only part that mattered.
Constraints: split ownership by constraint type. Policy and risk constraints come from product working with legal and compliance. Performance and cost constraints come from engineering. Experience constraints come from design, and this is where design’s contribution changes shape most: not comps, but assertions. “All interactive elements meet WCAG 2.2 AA.” “Error states never blame the user.” “Email tone matches the voice guide, validated against these three examples.” Design encodes taste as testable statements, which sounds like a demotion until you realize it means design’s standards now gate every build automatically instead of being sanded off in implementation.
Acceptance tests: everyone, in their own dialect. Product writes outcome tests (activation rate, time-to-value). Design writes experience tests. Engineering writes system tests (latency, error budgets). The package interleaves them. This is the component that most needs all three disciplines, which is precisely why it was everyone’s afterthought in the PRD era.
Tools, data, and boundaries: engineering owns enforcement, product owns the grants. What the agent may touch is a product and risk decision. Making the boundary mechanical rather than aspirational is an engineering problem. I’ve been building in exactly this space (docket, an open-source permission layer and audit trail for agents), so discount my emphasis accordingly, but I’ll defend the claim on the merits: this is the component teams skip most often, and it’s the one that turns a bad agent day into an incident report. A boundary that lives in a prompt is a suggestion. A boundary the harness enforces is a control [4].
Canonical examples: product and design, curated jointly. Few, diverse, and maintained. Examples rot faster than any other component because they encode the most specific assumptions.
One addition to the model: every package needs a named editor. Not an owner of the content (the components have owners) but an owner of the coherence: the person who merges contributions, kills contradictions, and holds the line on “minimal.” Packages without editors bloat into exactly the 14-page documents they replaced, just in YAML.
The metric that matters: clarification rate
If you instrument one thing, instrument this: how often does the agent stop and ask, per unit of work?
Clarification rate is the purest measurement of context quality. A rising rate means the package is falling behind the work (context debt, accruing). A rate near zero on a package that hasn’t changed in months might mean the opposite of what you hope: work has drifted somewhere the package doesn’t cover, and the agent has stopped asking because it’s guessing.
Around it, a small dashboard: first-run eval pass rate (how often does the agent’s output clear the acceptance tests without human repair), intervention rate (how many actions per human touch), and time-to-amend (how long between a clarification and the package patch that retires it). Together these tell you whether your context infrastructure is an asset or a liability, and they’re the numbers I’d put in front of a leadership team instead of velocity, which measures motion, not context health.
A maturity ladder
Teams don’t jump from PRDs to packages in one quarter. The progression I’ve seen looks like four levels:
Level 0: prose PRDs, ad hoc agents. The document is the source of truth, agents are individual productivity tools, and context lives in whatever each person pastes into their chat window. Most teams are here. The tell: two people working on the same feature give the agent contradictory context and nobody knows.
Level 1: the machine-readable appendix. The PRD survives, but it gains an executable annex: acceptance tests in a file, constraints in a schema, an AGENTS.md in the repo [3]. This level is cheap to reach and worth reaching this quarter. The tell: at least one “what must be true to ship” assertion runs in CI.
Level 2: the package exists, the document is generated. This is the inversion moment, and it’s bigger than it sounds. The context package becomes the source; the human-readable document becomes a compiled view of it, produced for stakeholders who want narrative [5]. When the package changes, the document regenerates. You’ve stopped maintaining two sources of truth that disagree.
Level 3: the package is the workflow. Reviews are eval runs plus a judgment gate. Contributions flow from all three disciplines directly into the package. Telemetry from production feeds amendments. Clarification rate is on a dashboard someone actually looks at. Model updates trigger eval re-runs automatically. Very few teams are here. The ones that are look, from the outside, implausibly fast.
The ladder’s practical use is diagnostic: figure out your level, then build only the next one. Teams that try to jump from 0 to 3 produce the cargo cult I describe below.
The failure modes
Every operational shift produces its own pathologies. Five I’ve already seen:
Context stuffing. The team hears “context package” and ships Maximal Viable Context: every document, every edge case, every historical decision, crammed in. The result underperforms a good prompt, because relevance is the scarce resource, not information [1]. Minimal is the load-bearing word. If a component doesn’t change the agent’s behavior on the acceptance tests, it’s not context, it’s sediment.
Eval theater. Acceptance tests that always pass, because they were written to describe what the agent already does rather than what the product needs. You can smell this one: the eval suite has never once blocked a ship. A test suite that can’t fail is a ritual, not a gate.
The orphaned package. Built with enthusiasm in Q1, editorless by Q2, fictional by Q3. Real context migrates back into chat threads and tribal memory, and the package becomes the thing you update before the audit. This is why the editor role isn’t optional.
Template cargo-culting. The five components filled out as a form, with acceptance “tests” that are actually prose criteria nobody can run. The framework’s value is not the section headers; it’s that component three executes. If nothing in your package runs, you’ve written a shorter PRD with extra steps.
Ungoverned autonomy. Everything else done right, component four skipped, because boundaries felt like friction during the demo phase. This is the failure with the incident report attached. The teams moving fastest on agents are, counterintuitively, the ones with the most explicit boundaries, because explicit boundaries are what let them stop supervising every step.
The onboarding flow, end to end
To make the lifecycle concrete, run Part 1’s example (the automated customer onboarding flow) through it.
Discovery produces the objective (”reduce time-to-first-value from 14 days to 3”) and, crucially, the non-goal that a stakeholder interview surfaced: Enterprise accounts keep their human CSM touchpoints. Definition starts with the four acceptance tests from Part 1, written before any narrative; the definition review catches that persona coverage is only three personas deep and the product has four. Build surfaces a clarification in week one (the agent asks whether “signup” means account creation or email verification), which gets answered and then patched into the package as a constraint, so it never gets asked again. Validation runs the tests (green) and then the judgment gate, where design flags that the tone in the third email reads as pushy despite passing the tone assertions, which produces a new canonical example. In operation, the model behind the email-personalization step gets a version bump; the eval re-run catches a regression in persona adaptation before any customer sees it, and the package gets amended.
Total meetings required for alignment across that entire arc: approximately zero. The package absorbed the coordination.
What this replaces, and what it doesn’t
I want to be precise about the claim, because the agressive version (”no more documents, no more meetings, agents all the way down”) is wrong and will burn the teams (and the world) that believe it.
Context packages replace the coordination artifact: the thing whose job was to make separate humans converge on shared intent. They do not replace discovery, judgment, taste, accountability, or the political work of deciding what a company should build. If anything they expose those things, because the translation layer that used to hide weak judgment under process is gone. A team with a crisp objective function will feel superhuman at Level 2. A team that never really knew what “good” looked like will discover that an agent executes confusion at machine speed.
Before any tooling: take your most important in-flight initiative and try to write its acceptance tests. If you can, you’re one file away from Level 1. If you can’t, you’ve learned the problem was never the document format.
Part 2 of the Minimal Viable Context series. Part 1: The New PRD Is Not a Document. It’s a Runnable Context Package.
References
[1] Anthropic Applied AI Team. “Effective context engineering for AI agents.” Anthropic Engineering Blog, September 29, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[2] Osmani, Addy. “How to write a good spec for AI agents.” AddyOsmani.com, 2026. https://addyosmani.com/blog/good-spec/
[3] AGENTS.md. Open standard for AI agent context in repositories. Agentic AI Foundation, Linux Foundation. https://agents.md
[4] Anthropic Engineering Blog. “Effective harnesses for long-running agents.” November 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
[5] Google Developers Blog. “Architecting efficient context-aware multi-agent framework for production.” December 4, 2025. https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/