Where this prototype sits on the path to AI-native Product Operations

AI can help draft a document without changing how an organization works. An agentic operating model goes further: systems retrieve context, perform multi-step work, invoke tools, pause for review, record decisions, and respond to new information. This portfolio contains a working prototype of the middle ground, and a target architecture for the longer-term system.

Product organizations already produce large numbers of documents: research summaries, initiative proposals, business cases, prioritization records, roadmaps, requirements, features, stories, delivery plans, and status updates.

The harder problem is maintaining continuity between them.

Evidence is summarized into an initiative. The initiative becomes a business case. The business case becomes a score. The score influences a roadmap. The roadmap becomes requirements. Requirements become a backlog. The backlog becomes a delivery plan. At every translation, context can be lost, assumptions can become facts, and a decision made for one reason can later appear to have been made for another.

The two roles share the same raw material — user data, customer feedback, release plans, and planning frameworks — which is exactly why the boundary gets blurry. In each of the four areas below, Product Operations builds and runs the underlying system; Product Management uses what that system produces to decide what to build and communicate why.

It helps to think of this as three modes, not a single before-and-after switch. The working prototype on this site is primarily in the middle mode.

Here's a problem that doesn't get talked about enough: an AI agent is only as useful as the data it can see. If an AI tool can't read a company's support tickets, it can't summarize them, no matter how smart the underlying model is.

For years, connecting an AI tool to each different piece of software required custom, one-off code: a different "plug" for every system. Model Context Protocol (MCP) fixed that. It's an open standard, first released by Anthropic in late 2024, that lets any AI tool connect to any data source the same standardized way, read a support ticket, edit a file, look something up in a database, through one shared connection method instead of custom code for every single pairing. People sometimes call it the USB-C of AI: one universal plug shape instead of a different cable for every device.

In practice, this might mean an AI agent automatically reads new customer support tickets overnight, groups them by topic, and flags the handful that look like a brand-new problem, instead of a person scrolling through hundreds of tickets every Monday morning.

The network diagram shows the target wiring. If you want to see what's actually implemented today, the document flow page is the tool-by-tool version: nine real steps, each one showing what it consumes and produces, and which conditions are checked in code. Every step links to that tool's own real sample run, not a mockup.

What "agentic" means here

An AI agent does more than produce one response. It performs multiple related steps, maintains state, uses tools or data sources, and decides or acts within defined boundaries. The Initiative Intake, Business Documents, Backlog Builder, and Sprint Planner tools contain multi-step AI chains, so calling those subchains agentic is reasonable when the term is tied to their actual behavior. Calling the complete portfolio an autonomous or end-to-end agentic Product Development Lifecycle would be inaccurate: the current workflow does not independently choose its objectives, select among the tools, retrieve live enterprise data, write into operating systems, or monitor outcomes after release.

What is working today

The working prototype includes:

• Nine connected browser tools
• Structured artifact handoffs stored in the browser
• Multi-step AI calls in selected tools
• Worked examples that can be inspected without an API key
• Fixture-backed evidence records for the fictional PetHealth scenario
• Deterministic recalculation of WSJF and RICE scores
• A code-enforced funding gate before BRD generation
• Computed requirement-to-feature coverage
• Computed sprint load and declared dependency-order checks
• Downloadable run files and Jira bulk-import CSV export

The practitioner still initiates and reviews every stage.

What is not working today

The following appear only in the target architecture:

• Live retrieval from research repositories, support platforms, analytics, CRM, financial systems, internal communications, or ITSM systems
• Production MCP servers
• Scheduled signal-synthesis, competitive-monitoring, release-note, or ROI-validation agents
• Authenticated approvals and a persistent audit and observability service
• Team workspaces and enterprise access controls
• Jira write-back and post-release telemetry validation

Fixture data is used to explore how evidence might be shaped and cited. It does not prove that a live connector exists or that the underlying evidence is accurate.

Human review is not a decorative approval at the end of the chain. The reviewer must be able to identify what came from evidence, what was inferred, what was generated, and what remains unresolved. At each stage, the reviewer should ask five questions.

• 01
  Do I understand the reasoning?

  Can I explain why this recommendation or requirement exists?
• 02
  Can I trace the claim?

  Is the claim supported by supplied evidence, or did the model introduce it?
• 03
  Could I detect a failure?

  Do I have enough subject-matter knowledge to recognize invented precision or missing constraints?
• 04
  Does this solve the actual problem?

  Is the output merely well structured, or does it reflect the real operating context?
• 05
  What authority am I exercising?

  Am I reviewing a draft, approving an investment, authorizing system access, or accepting operational risk?

The more consequential the decision, the more the review must be grounded in real evidence and accountable authority.

This idea, that real authority requires real understanding, isn't new. It comes from David Marquet, a U.S. Navy submarine commander who argued that no one should approve a decision they don't understand, no matter how senior they are or how much they trust the person (or system) that made it. Read the full story →

Why deterministic checks matter

Language models are useful for synthesis and drafting. They are not reliable authorities for arithmetic, schema compliance, dependency order, or whether every requirement has been represented downstream. The prototype therefore recalculates a small number of structural conditions in code:

• WSJF and RICE calculations
• Funding-line eligibility for BRD generation
• Requirement identifiers represented by downstream features
• Sprint capacity based on declared points
• Story order based on declared dependency relationships

These checks are useful but narrow. They do not validate:

• Whether a requirement is correct
• Whether a feature adequately satisfies a requirement
• Whether a cost or benefit is real
• Whether an NFR threshold is justified
• Whether an estimate is credible
• Whether a stakeholder has actually approved anything
• Whether the product should be built

Inside an actual product team, this plays out across four stages, and at every stage, AI tools handle more of the drafting and synthesis while a person still signs off on the result.

• 01
  AI does the busywork, not the thinking

  The tools handle synthesis and the first draft. People still own the judgment calls: what matters, what's risky, what's worth doing.
• 02
  The connections matter more than the AI model itself

  MCP sounds like boring plumbing, but it's the actual reason any of this works at scale: without it, AI can't see the data it needs to be useful.
• 03
  Checking the work is not optional

  The more autonomous AI gets, the more a human who understands the work matters, not less.

None of this requires you to be a product manager, an engineer, or even particularly technical. It just requires understanding that AI tools are now a real part of how software gets built, and knowing enough to ask good questions about it.

The role of MCP in the target architecture

Model Context Protocol can provide a standard way for AI applications to access approved tools and data sources. In a future Product Operations system, MCP services could expose research, support, analytics, strategy, delivery, or financial context without requiring every workflow component to implement a separate integration pattern.

MCP alone does not make a workflow agentic, accurate, or safe. The quality of the system would still depend on which sources are authorized, what the agent is allowed to read or change, how evidence provenance is preserved, how stale or conflicting data is handled, where human approval is enforceable, what is logged, and how failures are detected and recovered. The MCP nodes in the network diagram are architectural proposals, not working connections.

The practical proposition

The proposition being tested is narrower than “AI can run Product Management.” It is:

Explore the evidence

• See the current implementation

  The Document Flow page shows what each working tool consumes and produces.
• Follow one worked example

  The PetHealth case study traces a fictional initiative through the chain and identifies both useful continuity and quality risks.
• Review the target architecture

  The Network Diagram shows what would be required to evolve the prototype into an agentic Product Operations system.
• Inspect the implementation decisions

  The Technical Notes describe the stack, data contracts, checks, limitations, security boundary, deployment model, and test gaps.
• Evaluate it yourself

  The Limited Evaluation Beta is for practitioners willing to test a fictional, public, or sanitized initiative and identify where the workflow helps or fails.