Reading the Harness as a PM

The architecture review you don’t know how to read

You are seven months into an AI PM role.

The team is presenting an architecture review. There is a diagram on the screen with sixteen boxes, eleven arrows, three labelled regions, and two yellow stickers reading “TBD.” Two engineers are pointing at the diagram and using words like eviction policy, vector recall thresholds, deterministic fallback, and agent.md. The conversation is dense and clearly important.

You are nodding at the appropriate intervals. You have asked two questions and the answers were polite and indirect. You realise, somewhere around minute thirty, that you do not actually know which of the boxes on the diagram you are supposed to have signed off on, which ones are engineering’s call, and which ones nobody owns yet because the boundary between your job and theirs is, in this room, undefined.

This is the moment most senior AI PMs get to once and never quite resolve. There is no SaaS analogy for it. In SaaS, the PM owned the what (write a spec) and engineering owned the how (build it), and the boundary was tidy because the what lived in product and the how lived in code. In AI products that boundary has migrated. Substantial parts of the what are now expressed in things that look like code (eval scripts, tool descriptions, system prompts) and substantial parts of the how are now expressed in things that look like product (memory policies, escalation rules, fallback paths). The line between PM and engineer is no longer the line between English and code. It is somewhere else, and most teams are still arguing about where.

This post is about where. It will not teach you what a harness is — if you need that, L1-T01 has the sixty-second answer, the Anthropic NIST four-layer framing is the canonical source, and the entire Agentic Stack series goes deep on harness mechanics. This post assumes you have absorbed all of that. It is about the question that comes after: given that the harness is the product, what part of it are you, the PM, supposed to own?

The category error that wastes most cross-functional cycles

Watch a few hours of any AI product team’s planning sessions and you will see the same pattern, which is worth naming because once you can see it you can stop it.

The PM, often without realising, will start specifying the how. They will ask for a particular retrieval algorithm. They will dictate the chunk size for the vector database. They will say “use Claude for this and GPT for that” without a structured reason. The engineers will smile, take notes, and quietly do something different — because the PM’s request reflects an opinion about the product without an understanding of the engineering trade-offs.

A few minutes later, the engineer, often without realising, will start specifying the what. They will say “let’s just have the agent be more polite when it refuses” or “we should push the user to clarify when the input is ambiguous” without engaging with whether politeness or clarification in this specific domain has agreed-upon definitions. The PM will smile, take notes, and quietly do something different — because the engineer’s suggestion reflects an opinion about the user without an understanding of the product trade-offs.

This is the category error. Both sides are operating in each other’s domain, badly. The output is meetings that feel productive but produce drift, harnesses that feel comprehensive but contain quiet contradictions, and agent behaviour that feels almost-right in seventy percent of cases and very wrong in the rest.

The fix is not better collaboration. The fix is a sharper boundary.

If a decision can be expressed fully in plain English — the agent must always cite a source, the agent must never recommend a competitor’s product, the agent should refuse if it can’t verify the user’s identity — that decision belongs to the PM. The PM owns it whether the implementation is a prompt, a code rule, a permission system, or a layered combination. The implementation is engineering’s call.

If a decision cannot be expressed in plain English without losing meaning — vector recall threshold of 0.78 with a re-ranker on top of the top-12 results, evicting from the cache when relevance drops below 0.5 — that decision belongs to engineering. The PM should not be in the meeting where the threshold is set. The PM should be in the meeting where the acceptable failure rate is set, which is a language decision, not an implementation one.

The boundary, then, is the language test: can this decision be made by someone who only speaks the language of the user, the business, and the domain? If yes, the PM owns it. If no, engineering does. Apply that test to every box on the architecture diagram you got lost in earlier and you will know which boxes you should have signed off on. Most of them. Almost all of them, actually. The PM owns more of the harness than they realise. They just usually own the wrong layer.

The seven layers, and what the PM owns at each

The Agentic Stack series teaches the seven-layer CONTEXT stack — Constitution, Observations, kNowledge, Tracks, Equipment, eXecution, Template — as the architectural decomposition of what goes into the model on every turn. If you have not read Agentic Stack L1-T03, it is worth ninety seconds. For this post, I am going to take the seven layers as given and ask the question this series exists to answer: which side of the language–implementation boundary does each layer sit on, and what does the PM own there?

What you’ll see, reading layer by layer, is that the PM owns the WHAT at every single layer. What changes is the artefact — the document, the file, the spec — that the PM produces at each one. Together, those seven artefacts are not a PRD. They are something newer, which the practitioner community has begun calling a Context Spec. We come back to it in the next section.

Layer 1 — The Constitution (system prompt, identity, refusal cases)

The Constitution is the agent’s identity. You are a financial-advice agent. You always cite a source. You refuse to recommend specific equities. You speak in three sentences or fewer.

The PM owns this layer completely. Every word in the system prompt is a product decision. The instinct to delegate the system prompt to engineering is the most common ownership error a new AI PM makes. The system prompt is not a technical artefact. It is the product definition. Anthropic’s published system prompt for Claude runs to thirty thousand tokens — a substantial document representing years of safety and capability engineering — and the team that owns it at Anthropic is not infrastructure. It is the product team.

What the PM ships at this layer: a written constitution that defines identity, rules, refusal cases, and the priority hierarchy when those rules conflict. The hardest part is writing the boundary cases — what to refuse, when to escalate, what to do when goals contradict — because those are where the agent’s behaviour actually gets decided.

What engineering owns at this layer: how the constitution is loaded, cached, versioned, and evaluated against. The content is yours; the delivery mechanism is theirs.

Layer 2 — Observations (examples, demonstrations, golden cases)

The Observations layer is where the agent learns by example — canonical inputs and outputs that show, more than tell, how the agent should behave.

The PM owns this layer because which examples count is a domain question. An ambiguous customer email that resolves to “schedule a refund” is a canonical case in one product and a canonical case for “escalate to compliance” in another. Whichever your business is, only you can curate the example set.

What the PM ships at this layer: a curated dataset of canonical input–output pairs, drawn from real production logs (not invented in a meeting), with annotations explaining why this is the right answer. The annotation is the part that makes it a product artefact rather than a training set.

What engineering owns: how the examples are surfaced to the model — whether through few-shot in the prompt, a vector lookup, a fine-tune, or a hybrid. The which is yours; the how is theirs.

Layer 3 — kNowledge (RAG, authoritative sources, domain rules)

The kNowledge layer is the body of facts the agent draws on at inference time. RAG (Retrieval-Augmented Generation) is the dominant 2026 implementation pattern, but the layer existed conceptually before RAG and will exist after it.

This is where the category error gets worst. Engineers want to talk about chunk sizes, embedding models, vector recall, re-rankers — all real concerns, all theirs. The PM, hearing those words, often abdicates the layer entirely. That is the mistake. Underneath the implementation, every kNowledge layer is making one product decision repeatedly: which sources are authoritative, and what to do when they disagree. That decision is yours.

A legal-research agent that retrieves from federal case law and a vendor’s blog post and treats them as equally authoritative is failing at the product layer, not the retrieval layer. The retrieval is working perfectly. The PM never specified the source hierarchy. So the agent silently treats a marketing blog post the same as Supreme Court precedent, and the failure shows up as “the agent is hallucinating,” which is the wrong diagnosis.

What the PM ships at this layer: a written source hierarchy. Tier-1 sources (always authoritative). Tier-2 sources (authoritative when tier-1 is silent). Tier-3 sources (referenceable but not citable). Conflict-resolution rules — what to do when two tier-1 sources disagree. Freshness requirements — how recent does information need to be to count.

What engineering owns: the retrieval architecture, the embedding choice, the chunk-and-rerank strategy, the cache. The which sources count is yours; the how to retrieve them is theirs.

Layer 4 — Tracks (memory, conversation history, persistent state)

The Tracks layer is everything the system remembers between turns and across sessions.

This is the layer most teams shipped without anyone owning, because in SaaS memory was a database concern and the PM didn’t have to think about it. In AI products, memory is a product concern and a database concern at the same time, which is why nobody owns it by default.

What the PM ships at this layer: a memory policy. What does the agent remember within a session? What persists across sessions? Who can see what — the user, the user’s manager, the auditor, the legal team? When does memory expire, and on what trigger? Each answer is a language-level decision. Each answer has a privacy implication, an enterprise-readiness implication, a billing implication, and (sometimes) a regulatory implication. Engineering cannot decide it because engineering does not know which compliance regime your customer operates under. You have to.

What engineering owns: the storage layer, the retrieval pattern, the indexing strategy, the encryption, the deletion mechanics.

The most useful 2026 read on memory ownership is LangChain’s writing on harness ownership, which argues — correctly, in my view — that closed harnesses (managed agent platforms that store memory on the vendor’s side) are appealing in the short term and ruinous in the long term. The vendor owns your data flywheel. Switching providers means losing months or years of accumulated agent learning. Open harnesses (where you own the memory layer) are more work upfront and substantially more defensible at scale. That is a strategic choice. It is yours.

Layer 5 — Equipment (tools, APIs, agent capabilities)

The Equipment layer is what the agent can do — the tool calls, API invocations, and external actions it can take.

This is where the principle of least privilege becomes a PM decision, because least privilege is fundamentally a question of acceptable risk, and acceptable risk is a domain judgment. An accountant agent that can read a ledger but not write to it is one product. An agent that can write to it under specified conditions is a different product. The conditions are yours.

What the PM ships at this layer: the tool catalogue. Which tools the agent has access to. What permissions each tool requires. What conditions trigger which tools. Which tools require human approval, and at what threshold.

What engineering owns: the tool implementation, the rate limiting, the retry logic, the failure handling, the auth flow.

A useful diagnostic at this layer: if the agent can do something irreversible without human approval, the PM has not fully owned this layer. Irreversibility is the PM’s threshold to set. The CAIR equation — Consequence × Effort to Correct — is a useful lens. Sending an internal message: low consequence, low effort. Initiating a $100K wire: high consequence, high effort. The first is HOTL-appropriate; the second is HITL-mandatory. We unpack the full HITL/HOTL/HOOTL framework in L2-T08; for this post, the operational point is simpler. Walk through every tool in your catalogue. Note which ones are reversible. Note the consequence cost of each. The pattern that emerges is your autonomy map. That is a product artefact, not a technical one.

Layer 6 — eXecution (success criteria, fallback paths, escalation rules)

The eXecution layer is what the agent does during the run — when to declare success, when to retry, when to escalate, when to give up.

This is the layer that distinguishes a demo from a product. Demos almost always have a happy path and no fallback path. Products always have a fallback path because in production, things fail. Documents are not retrieved. Tools time out. Memory services hiccup. Rate limits hit. The harness either has a graceful response, or the user gets a blank screen, or — worst — a confidently wrong answer that the agent cannot tell is wrong.

What the PM ships at this layer: the degradation ladder. Full autonomy at the top, simpler model in the middle, rules-based fallback below that, cached response below that, human escalation at the bottom. At each level, what is the acceptable user experience? What is the message the user sees? What is the cost of the fallback in terms of unit economics? The Agentic Stack L2-T18 on graceful degradation is the canonical mechanic; the PM-side ownership is the ladder itself, with the user-experience and economic trade-offs spelled out at each level.

What engineering owns: how the ladder is implemented — the circuit breakers, the timeouts, the fallback model invocation, the eval signal that triggers escalation.

Layer 7 — Template (output format, schema, structure)

The Template layer is the shape of the output. Free text, structured JSON, a particular schema, a length limit, a tone constraint.

This is the layer that quietly determines whether the agent’s output is consumable by anything downstream. An unstructured response can be brilliant prose or it can be missing a critical field. A structured response is less creative but is always parseable, always complete, always in the format the next system expects. Structure is reliability. The PM decides where in the product creativity matters and where predictability matters, and that decision is the Template specification.

What the PM ships at this layer: the output schema. JSON shape, required fields, validation rules, the length budget, the tone register, the things the output must always include and never include. For each user-facing surface, the schema may be different — an in-product card has different requirements from an email summary from a CSV export. All of those are yours.

What engineering owns: how the schema is enforced — at the model level via constrained decoding, at the post-processing level via validators, at the failure level via repair loops.

The Context Spec — what replaces the PRD

Notice what we just walked through. Seven layers. Seven artefacts the PM produces. None of them is a PRD in the SaaS sense. The PRD as a document type — a Word file describing how the feature should behave from the user’s perspective, handed to engineering for implementation — is dying for AI features. The thing replacing it is what the practitioner community has begun calling a Context Spec: a structured document that fills in the WHAT side of every layer of the CONTEXT stack and leaves the HOW side blank for engineering.

A complete Context Spec for an AI feature contains, at minimum:

• The Constitution — system prompt, identity, refusal rules, priority hierarchy
• The Observations — curated golden examples with annotations
• The kNowledge map — source hierarchy, conflict-resolution rules, freshness requirements
• The memory policy — retention, expiry, visibility, compliance
• The tool catalogue — capabilities, permissions, autonomy thresholds, irreversibility flags
• The degradation ladder — fallback levels, user experience at each, cost trade-offs
• The output schema — per surface, with validation rules

Seven artefacts. One spec. Engineering can build the harness from this spec without further input from the PM. That last sentence is the litmus test, and we come back to it at the end of the post.

The shift from PRD to Context Spec is not a renaming. The artefacts are different. A PRD describes the experience. A Context Spec describes the substrate that produces the experience. A senior PM who has internalised this stops writing PRDs for AI features. They write Context Specs and then describe the resulting experience as a verification step, not as the source artefact. The chain reverses.

Three things to stop trying to own

For balance, here are three things PMs in 2026 frequently try to own and should not. Each one feels like product. None of them is.

Three things you can never delegate

Conversely, three layers no PM should ever push onto engineering. If you do, the harness will be technically excellent and quietly unintelligent, and you will not know why until the failure becomes expensive.

The litmus test

Here is the question that, in one sentence, tells you whether you have written a complete Context Spec or a partial one:

If the answer is yes, your ownership is tight. The seven artefacts are filled out. The decisions are made and documented. Engineering knows what is theirs and what is yours, because the spec marks the line. Productivity goes up.

If the answer is no, you have left judgment calls undone, and the way that shows up in production is engineering will make those calls for you — not because they want to but because someone has to. The choices they make may be defensible at the implementation level and silently wrong at the product level. The Constitution will get edited to fix a bug. The source hierarchy will get inverted because tier-2 had better recall. The memory policy will be set by what the database supports rather than by what the user expects. Each of those drift moments is a product decision that the PM was supposed to make and didn’t.

The litmus test is not a one-time thing. It is the question to bring to every architecture review, every roadmap discussion, every quarterly planning cycle. Could a competent engineer build the next version of this harness from what I have written down? If yes, the team accelerates. If no, find the gap and close it. That is most of the senior AI PM job.

At portfolio scale, the third role is the leverage

Everything above is the initiative-level discipline. A senior PM running a portfolio of 5 AI initiatives at a Fortune 500 firm operates one floor higher. Five engineering teams. Five harnesses. Five eval suites. Five cost dashboards. The portfolio review used to be “show me the roadmap.” In 2026 it has to be “show me the harness diagram, the eval-flywheel cadence, and the cost-per-outcome distribution — and tell me where this initiative duplicates platform work the rest of the portfolio is also paying for.” The conversation has to get architectural fast.

At that scale, the PM’s three roles separate cleanly. Specify is the Context Spec for each initiative. Delegate is the implementation territory engineering owns. Ask is the new one — the architectural questions that surface decisions a PM should have a vote on but engineering would otherwise own unilaterally. The questions are the leverage. They earn architectural ownership without writing the code.

Six questions to bring to every harness review

Each one surfaces a decision that determines the initiative’s 18-month trajectory. Bring this checklist to portfolio reviews. The teams that resist these questions are the teams that need them most.

1. Retrieval rerank strategy. “What’s our retrieval rerank strategy on this initiative, and how do we know it’s working?” — surfaces whether kNowledge-layer quality is actually measured.
2. Cost cliff. “How are we handling the L1-T07 cost cliff? What’s our cost-per-outcome trajectory at projected scale, not at pilot scale?” — surfaces whether the unit economics survive volume.
3. Eval-flywheel cadence. “How fast does production failure feed back into the CI gate? Days, weeks, or never?” — surfaces whether the harness compounds or decays.
4. Trust architecture. “At the tool-call level, is the model the permission system, or is there a deterministic gate?” — surfaces whether L2-T08 trust architecture is real or theatrical.
5. Platform comparison. “How does this initiative’s harness compare to the platform standard? Where are we duplicating work the platform should own?” — surfaces consolidation opportunities the portfolio can capitalise on.
6. Day-1 cost discipline. “What does our cost dashboard look like, and is it paired with engagement so a feature team sees both numbers in the same view?” — surfaces whether FinOps is a discipline or a postmortem.

Engineering teams that respect a PM’s architectural input do so because the PM has earned it through fluency. Once the PM can read the harness, the engineering relationship shifts — the PM becomes a partner in architectural decisions rather than a downstream consumer. The Anthropic Claude Code working model is the public reference. Intent doc is short. Eval suite is the spec. Harness is the artifact. PM and engineering work as integrated peers.

The fourth trap — skipping the platform conversation

Three things to stop owning. Three things you can never delegate. There is one more failure mode that only shows up at portfolio scale, and it is the one most senior PMs miss because the symptoms look like “each team is shipping fine.”

Remember this

1. The PM owns three roles on the harness: specify intent, delegate implementation, ask the architectural questions. The art is knowing the boundaries.
2. The CONTEXT 7-layer framework structures the specification surface. Constitution, Observations, kNowledge, Tracks, Equipment, eXecution, Template — seven layers, seven artefacts, one Context Spec.
3. Harness fluency is the senior-PM differentiator at portfolio scale. Read the harness as fluently as a senior strategist reads a P&L.
4. The right questions surface decisions. “What’s our retrieval rerank strategy?” surfaces a decision. “Is this on track?” doesn’t.
5. At portfolio scale, push for platform consolidation. Five initiatives building five harnesses is the wasteful default; one shared platform is the L3 leverage.

In practice — six steps

1. Build harness fluency through the Agentic Stack series. At minimum: L1-T03 the CONTEXT stack, L2-T11 what is a harness, and the spectrum of agency. The framework is the vocabulary.
2. Run a CONTEXT audit on each portfolio initiative. For each, document the seven layers. Score each from 1–5 on whether the WHAT is written down. Surface the gaps and the duplication.
3. Build the architectural-questions checklist for portfolio reviews. Use the six questions above as the starting set; add domain-specific ones. Bring the checklist to every harness review — not as a gotcha, as the agenda.
4. Draft the harness-platform consolidation roadmap. Identify capabilities (retrieval, eval suite, cost dashboard, trust architecture) that should serve multiple initiatives. Plan the consolidation as a dedicated workstream with its own funding.
5. Stand up engineering–PM working sessions on architectural decisions. Quarterly working sessions where engineering and PM together decide architectural direction. The L1-T01 ninety-minute Tech Lead conversation, scaled to portfolio cadence.
6. Translate harness investment for the executive layer. L2-T07 stakeholder translation applied to the harness: harness investment → margin protection → defensible moat → durable revenue. The executive layer doesn’t read harness diagrams; they read translated business impact.