The New PRD Is Not a Document. It's a Runnable Context Package
How AI agents are dissolving the coordination artifacts that defined product teams, and what replaces them.
For the last 20 years, we split product work like this:
Product writes intent: PRDs, requirements, success metrics.
Design makes it legible: flows, comps, interaction decisions.
Engineering makes it real: systems, code, reliability
Those artifacts existed for one reason: humans needed alignment. PRDs weren’t “the work.” They were the coordination substrate. The layer that let people who didn’t share context, vocabulary, or mental models get on the same page long enough to ship something.
I think we’ve been so deep inside this paradigm that we forgot it was a choice. We optimized our entire operating model (the roles, the rituals, the tools, the org charts) around the assumption that a human would read the intent, interpret it, and translate it into action through their own judgment.
That assumption is breaking.
When the primary executor is an AI agent, the job stops being “write a doc that another human can interpret.” It becomes “provide the smallest amount of context that produces the right outcome.” Not minimal documentation. Minimal context.
I’ve been calling this Minimal Viable Context. I’m not the first. Eric Broda uses the term to describe token-budget optimization for enterprise agents. XTrace uses it to frame their AI memory product. Anthropic’s engineering team talks about curating a “minimal viable set of tools” [1]. The concept is convergent, which itself is a signal that something real is happening.
But the existing uses of MVC are all about the engineering problem: how do you optimize what goes into a context window? My argument is different. I think MVC is the organizational design answer to a question product teams haven’t fully articulated yet: what replaces the PRD when the primary executor is an agent?
This article attempts three things I haven’t seen in the existing MVC conversation:
A specific five-component framework for what MVC contains, designed for product teams, not just AI engineers.
A compiler metaphor that reframes the relationship between human intent and agent execution.
An argument about role reconvergence: how product, design, and engineering reorganize around a shared context package rather than sequential handoff artifacts.
The teams that figure this out first will build circles around the ones still writing 14-page Google Docs that no one reads.
The Archaeology of Alignment
To understand what’s dissolving, you have to understand why it was built.
Product development artifacts have always been coordination technologies. The PRD didn’t emerge because someone decided products needed a “requirements document.” It emerged because organizations needed a way to translate executive intent into engineering action across teams that didn’t share context, vocabulary, or mental models.
The history tracks cleanly to the communication problem of each era. In the waterfall age, the artifact was the specification. Massive documents that attempted to define every behavior in advance. The coordination problem was completeness: if you couldn’t build iteratively, you needed to get the spec right the first time. The primary executor was a team of engineers working from printed documents. Every ambiguity was expensive.
Agile compressed the cycle but didn’t eliminate the coordination need. It just changed the artifact. User stories replaced specifications. The coordination problem shifted from completeness to shared understanding: “As a user, I want X so that Y” was a format designed to force product thinking into the shape that a two-week sprint could consume. The artifact got smaller, but it was still fundamentally a translation layer between the person who understood the customer and the person who would write the code.
The modern PRD sits at the end of this lineage. It’s a hybrid: part specification, part narrative, part alignment ritual. It includes user stories, success metrics, wireframe references, edge case documentation, and often a section on “what we’re not building” that exists solely because scope creep is a human coordination failure. Product managers spend, by some estimates, over half their time on documentation, status updates, and alignment activities. The PRD is the crown jewel of that overhead.
PRDs are optimized for human interpretation. That’s obvious once you say it, but we don’t say it. Every section (the user narrative, the “why now,” the carefully worded acceptance criteria) exists because another human needs to read it, internalize it, and translate it into action through their own judgment.
What happens when the primary executor doesn’t need narrative? Doesn’t need motivation? Doesn’t need to be convinced?
The Substrate Shift
In September 2025, Anthropic’s Applied AI team published a blog post that quietly reframed the entire discipline of working with language models [1]. The post’s argument was precise: building with LLMs is no longer primarily about finding the right words for your prompts. It’s about answering a broader question: what configuration of context is most likely to generate the desired behavior?
They called this context engineering. Andrej Karpathy distilled it further: context engineering is “the delicate art and science of filling the context window with just the right information for the next step” [2].
That shift in language tells you something. The coordination problem moved. For two decades, the bottleneck in product development was human alignment: making sure everyone understood the intent. Now the bottleneck is machine context: making sure the agent has exactly what it needs to execute correctly, and nothing more.
The parallels are appearing everywhere. Google’s Agent Development Kit architecture enforces a principle they call “scope by default,” where every model call and sub-agent sees the minimum context required, reaching for more information only when explicitly needed [3]. Addy Osmani, writing about how to spec work for AI agents, advocates designing for “Agent Experience” the same way we designed APIs for developer experience: clean, parseable, unambiguous [4]. The open-source AGENTS.md standard, which emerged in early 2026, exists to solve exactly this problem: providing a single, versioned source of truth for how agents should operate within a codebase [5].
They’re all circling the same realization: when the executor is an agent, the job stops being “write a doc that another human can interpret.” It becomes “provide the smallest amount of context that produces the right outcome.”
I’ve been calling this Minimal Viable Context, and as I noted above, others have independently landed on the same term for related but distinct problems.
Not minimal documentation. Not shorter PRDs. Minimal context: the least an agent needs to consistently do the right thing without guessing. Where the existing MVC conversation focuses on token optimization and memory infrastructure, I’m focused on what this means for the artifacts product teams actually ship.
Minimal Viable Context: A Framework
Minimal Viable Context is not a document format. It’s a design principle: what’s the smallest bundle of structured information that reliably produces correct behavior from an AI agent?MVC has five components:
1. Objective + Non-Goals
The objective is what the system must achieve, stated precisely enough that success is measurable. Non-goals are equally important. They define the boundary of the solution space. In a traditional PRD, non-goals are a polite section at the end. In MVC, they’re load-bearing: they’re what keeps the agent from solving a problem you didn’t ask it to solve.
A PRD might say: “Build a dashboard that helps users understand their usage patterns.” An MVC objective says: “Generate a weekly usage summary for active users with >5 sessions, surfacing the top 3 features by time spent. Non-goal: do not build real-time monitoring, do not personalize recommendations.”
2. Constraints (Policy, Risk, Performance, Cost)
Constraints define the walls of the solution space. This is where compliance requirements, latency budgets, cost ceilings, and risk tolerances live. Traditional PRDs scatter constraints across sections: some in “technical requirements,” some in “open questions,” some never written down at all because “everyone knows” them. MVC makes them explicit and machine-readable.
3. Acceptance Tests (What Must Be True to Ship)
Not “acceptance criteria” buried in a Jira ticket. Acceptance tests: executable assertions about the state of the world after the agent has done its work. This is the single most important difference between a PRD and an MVC: the validation mechanism is built into the context, not applied after the fact by a human reviewer.
4. Allowed Tools, Data, and Boundaries
An agent that can access anything will eventually access something it shouldn’t. MVC explicitly scopes the tools available, the data sources permitted, and the boundaries of what the agent can modify. This is the “control plane” layer. It’s what keeps the agent from being creative in ways that break things.
5. Canonical Examples
A few representative inputs and expected outputs that anchor the agent’s behavior. Anthropic’s own guidance strongly recommends curating “a set of diverse, canonical examples that effectively portray the expected behavior” rather than stuffing prompts with exhaustive edge-case rules [1]. Examples are the highest-signal, lowest-ambiguity form of context.
The contrast with a traditional PRD is stark.
Where a traditional PRD optimizes for shared understanding among humans, Minimal Viable Context optimizes for correct execution by agents. Where a PRD is validated through human review and debate, an MVC is validated through executable acceptance tests. Where a PRD is written once, debated, and archived, an MVC is versioned, tested, and run continuously. And where a PRD fails through misinterpretation, an MVC fails through insufficient or ambiguous context.
To make this concrete, consider a real scenario: your team is building an automated customer onboarding flow. Here’s what the Minimal Viable Context might look like:
Objective: Reduce time-to-first-value for new users from 14 days to 3 days by automating personalized onboarding sequences. Non-goal: Do not replace human CSM touchpoints for Enterprise tier accounts.
Constraints: All emails must comply with CAN-SPAM. No PII stored outside SOC 2 boundary. Max latency per step: 200ms. Monthly compute budget: $2,000.
Acceptance tests: (1) New user receives first personalized email within 5 minutes of signup. (2) Onboarding sequence adapts correctly for each of the 4 user personas. (3) Users who complete the automated sequence achieve activation within 3 days at ≥60% rate. (4) Zero emails sent to users who opt out.
Tools/Boundaries: Agent may access user signup data, product analytics API, and email service. Agent may not access billing data, modify account tiers, or contact users via channels other than email.
Examples: Three sample user profiles with expected onboarding sequences and email content tone.
Compare that to the typical PRD for the same feature: two pages of narrative context about why onboarding matters, a section on competitive benchmarks, wireframes of the email templates, a RACI chart, and acceptance criteria that say “user should receive a timely onboarding email.” The PRD tells a story. The MVC defines a contract.
The shift isn’t about making documents shorter. It’s about changing what “done” means. A PRD is done when stakeholders agree on it. An MVC is done when the agent can execute it end-to-end and pass its acceptance tests.
The Runnable Context Package
If Minimal Viable Context is the design principle, the runnable context package is the artifact. It’s what actually ships instead of a PRD: prompts and schemas, evals and test cases, tool contracts, decision records, and telemetry hooks. A small bundle that lives next to the code and can be executed.
The pattern is already emerging. The AGENTS.md specification functions as a lightweight context package for coding agents [5] adding an operational layer designed for agent consumption on top of existing docs. Claude Code uses CLAUDE.md files. Cursor uses .cursorrules. The convergence is coming from every direction: frontend engineers, DevOps teams, and product managers are all creating structured context files for their agents, even if they don’t call them that yet.
Anthropic’s research on long-running agents shows why this matters at scale [6]. When agents work across multiple context windows, they need persistent, structured context that bridges sessions. The Anthropic team found that even frontier models would fail to build a production-quality application given only a high-level prompt, but could work effectively across dozens of context windows when given structured requirements, progress tracking, and acceptance criteria [6].
Google’s Agent Development Kit formalizes this as a “context compiler”: a system that builds context through named, ordered processors rather than ad-hoc string concatenation [3].
The runnable context package is the intermediate representation of product intent.
New Seams: How Roles Reconverge
AI compresses handoffs. When a product lead can go from intent to working prototype in an afternoon, the translation layers between PM, design, and engineering don’t disappear, but they collapse into a much tighter loop. What remains is judgment, authority, delivery, and accountability. Less translator, more editor.
The roles reconverge around new seams:
Product owns the objective function and tradeoffs. Defining “what does good look like?” and making the hard tradeoff calls that agents can’t. Less document writing, more decision making.
Design owns experience constraints. Not wireframes but standards: accessibility requirements, interaction patterns, emotional register. These feed into the context package as testable assertions, not deliverables that sit in Figma.
Engineering owns enforcement and the control plane. Eval frameworks, guardrails, monitoring, deployment pipelines. As Microsoft’s 2025 Work Trend Index found, leaders expect their teams will be training and managing agents within five years [7].
The shared deliverable becomes: context that compiles. Not a PRD that product wrote, that design annotated, that engineering interpreted. A single context package that all three disciplines contribute to and that the agent executes.
We’re already seeing the early signs. AI-first startups in 2026 routinely operate with 5-person teams building what required 50 people a decade ago. Not because the work disappeared, but because the coordination overhead collapsed. When context packages replace PRDs, you don’t need a meeting to align on the PRD. You run the tests.
Context That Compiles
Compilers introduced an intermediate representation between human intent and machine execution: a structured layer that could be reasoned about, optimized, and validated independently. The key insight wasn’t that compilers made programming faster. It was that they changed what programmers needed to specify. You no longer wrote instructions for the machine. You wrote intent that the compiler could translate.
Minimal Viable Context is the intermediate representation for agent-driven product development. Human intent (business objectives, user needs, design constraints) gets structured into a context package (testable, versionable) that the agent executes against real systems. The context package is the compiler layer.
This is why the new PRD is not a document. A document is source code that never gets compiled. It stays in the human-readable layer and depends on another human to manually translate it into action. A context package compiles. It goes through a structured transformation from intent to execution, and you can test whether the compilation is correct.
The question “is this PRD good enough?” becomes “does this context package pass its evals?” The former is a matter of opinion. The latter is a matter of fact.
Implications for Leaders
If the argument above is directionally correct, it has immediate practical implications for anyone leading a product, design, or engineering team.
Audit your artifacts for compile-ability. Take your last three PRDs and ask: could an AI agent execute this end-to-end without a human clarification? If not, find what’s missing. It’s usually acceptance tests, explicit constraints, and scoped tool boundaries. That gap is your coordination tax.
Start writing acceptance tests before prose. This is the single highest-leverage change. Define “what must be true for this to ship” before writing a word of narrative. It’s test-driven development applied to product intent.
Most teams I talk to don’t have a way to version, test, and deploy context packages alongside code. They’re accumulating what I’d call context debt: the growing gap between what their agents need and what their artifacts actually provide. Context debt compounds the same way tech debt does. Invisibly at first, then all at once when you try to scale. If that sounds familiar, invest in your context infrastructure now: eval frameworks, structured schemas, telemetry that tracks agent behavior, not just product metrics.
Reorganize around the context package, not the handoff. The three-lane model (PM writes PRD, Design creates comps, Eng builds it) is optimized for sequential handoffs between humans. The new model is collaborative contribution to a shared context package. This doesn’t mean everyone does everything. It means everyone contributes to the same executable artifact rather than throwing documents over walls.
Finally, watch for warning signs. Your coordination artifacts are probably legacy if PRDs get “translated” by engineering leads before sprint planning, if design specs require a walkthrough meeting to be understood, or if no one on your team can describe the success state of a feature in terms a machine could parse. Those are symptoms of a substrate built for the previous executor.
The Question That Actually Matters
The idea that agents need structured, minimal context isn’t new, and the term “Minimal Viable Context” is already being used by others to describe the engineering challenge of token optimization. What I’ve tried to do here is extend that concept into organizational territory: the artifacts your product team runs on (PRDs, wireframes, Jira tickets) were built for a coordination problem that AI is re-solving at the infrastructure layer.
The five-component MVC framework applied to product teams, the compiler metaphor, the concept of context debt, the argument that roles reconverge rather than disappear: those are the contributions I think are worth your time. Not because they’re the final answer, but because they give you a vocabulary for a shift that most teams are feeling but haven’t named.
Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025 [8]. The tools for building context packages (AGENTS.md, CLAUDE.md, structured eval frameworks) didn’t exist 18 months ago. Now they’re table stakes for any team doing serious agent-driven development.
Here’s what I keep coming back to: the constraint in an agent world isn’t typing speed. It isn’t how fast you can write code or crank out wireframes. The constraint is whether the system can consistently do the right thing with limited ambiguity.
That’s a context problem. And context problems don’t get solved by more documents. They get solved by better architecture.
So the question for your team is not “do we still write PRDs?”
It’s: what is your minimal viable context, and can you run it end-to-end?
The answer will define who builds fast and who builds meetings.
Part 1 of the Minimal Viable Context series. Next: MVC in Practice: Operationalizing Minimal Viable Context Across the Product Development Lifecycle.
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] Karpathy, Andrej. Post on X, June 25, 2025.
[3] 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/
[4] Osmani, Addy. “How to write a good spec for AI agents.” AddyOsmani.com, 2025. https://addyosmani.com/blog/good-spec/
[5] AGENTS.md. Open standard for AI agent context in repositories. https://agents.md
[6] Anthropic Engineering Blog. “Effective harnesses for long-running agents.” 2026. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
[7] Microsoft. “2025 Work Trend Index Annual Report: The Year the Frontier Firm Is Born.” April 23, 2025. https://www.microsoft.com/en-us/worklab/work-trend-index
[8] Gartner. “Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026.” Press release, August 26, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025