The AX Stack¶

The AX stack names four layers — model, harness, agent extensions, technology surface — to locate where an agent failure or optimisation lives.

When this helps (and when it misleads)¶

The stack is a diagnostic and communication tool, not an architecture. Use it when a team needs shared vocabulary to locate a failure ("the agent picked the wrong SDK — that is an extensions-layer problem, not a model swap") or to prioritize where to invest first. Treat the fixed and open boundaries as approximate, not absolute. The cases where the framing actively misleads are catalogued in when this backfires below.

The Five-Failure-Layers Diagnostic is a different cut of the same problem — five working layers, no independence claim. The AX stack frames fixed versus controllable layers. The failure-layers diagnostic frames attribution before a model swap.

The four layers¶

Microsoft's 2026-05-21 post articulates the path from a developer's prompt to generated code as four layers, each with a different owner and a different intervention surface (Mastykarz, Microsoft Developer Blog):

flowchart TD
    P[Developer prompt] --> H[Harness<br/>Copilot · Claude Code · Cursor]
    H --> M[Model<br/>weights · tokenizer · alignment]
    M --> E[Agent extensions<br/>skills · MCP · instructions · agents]
    E --> T[Technology surface<br/>CLI · SDK · API]
    T --> O[Generated code]

    style M fill:#fee,stroke:#c33
    style H fill:#fee,stroke:#c33
    style E fill:#efe,stroke:#3c3
    style T fill:#efe,stroke:#3c3

Layer	Owner	Typical intervention	Canonical failure mode
Model	Vendor	None directly — you can only swap models	Outdated SDK pattern; hallucinated API; default to competing technology when yours has thinner training data (Mastykarz)
Harness	Vendor (mostly)	Hooks, settings, system-prompt knobs the vendor exposes — but not full replacement	Inconsistent extension behaviour across Copilot, Claude Code, Cursor (Mastykarz)
Agent extensions	You	Skills, MCP servers, `AGENTS.md`/`CLAUDE.md`, custom agents	Discovery, selection, or quality failure (Mastykarz)
Technology surface	You	The shape of the CLI, SDK, or API the agent ultimately calls	Surface assumes human-readable feedback the agent cannot parse

The "fixed" layers (model, harness) are red — the developer cannot rewrite them. The "controllable" layers (extensions, technology surface) are green — they ship in your repository and your service.

Three extension failure modes¶

Within the controllable surface, Mastykarz names three failure modes, each with a different intervention (Mastykarz):

Discovery failure — the extension exists but the agent never sees it. A context-window budget or harness prioritization hides it. Fix at the progressive-disclosure layer.
Selection failure — the agent sees the extension but does not connect it to intent. It is the "most common and most fixable" mode, usually a naming or description problem.
Quality failure — the extension is invoked but returns content that hurts outcomes, producing drag instead of lift.

Why it works¶

The stack works as a diagnostic vocabulary, not a description of architectural independence. Its mechanism matches the Five-Failure-Layers Diagnostic: asking "which layer changed?" before "which model should we swap to?" closes the cheaper interventions first. Anthropic notes that a model swap is the most expensive option (Anthropic).

The empirical case for non-model layers carrying the optimization budget is independent: LangChain raised Terminal Bench 2.0 from 52.8% to 66.5% through pure harness changes, no model swap (LangChain). Mastykarz runs the same direction at the extensions layer: improving public docs is "a long-term bet with no guaranteed payoff," changing the harness is impossible, but changing extensions gives "instant results" (Mastykarz).

Pair the diagnostic with measurement. Mastykarz's lift-vs-drag test runs the same scenario with and without the extension: lift if outcomes improve, drag otherwise. Without it, the vocabulary justifies unfalsifiable claims about which layer "really" caused a failure.

Where layers leak¶

The stack model imports its layering intuition from networking, where layer boundaries are deliberately engineered to be narrow and stable. AI coding agents have no such interface contracts — the layers leak in named, predictable ways. A reader who treats the layers as independent will be surprised by every one of these:

Model ↔ extensions: Models trained on more data for one technology will default to it even when your extension steers toward another. The extension fights training-data bias rather than a clean slot (Mastykarz).
Harness ↔ extensions: "Different harnesses interpret extensions differently, making outcomes inconsistent across platforms" (Mastykarz). An MCP server that performs well in Claude Code may produce drag in Copilot.
Harness ↔ model: The harness controls system-prompt content and tool-call protocols. Changing the model under the same harness can invalidate prompt-format assumptions baked into the harness's tool descriptions.
Extensions ↔ technology surface: An extension that returns human-readable prose to the model produces context bloat without inference value. The AX/UX/DX Triad names this conflation, and the Confucius Code Agent (CCA) paper measures its cost (42.0% → 48.6% Resolve@1 on SWE-Bench-Pro from context compression and hierarchical working memory, on a fixed Claude 4 Sonnet).

The stack model is useful precisely because you can name the leak points. Joel Spolsky's Law of Leaky Abstractions — all non-trivial abstractions leak — is the prior to assume here (Spolsky). A stack vocabulary that hides leak points reproduces the OSI false-independence intuition.

When this backfires¶

The four-layer model adds taxonomy overhead and assumes a stable enough environment that the same layer names will mean the same thing tomorrow. It misleads when:

Cross-harness portability is the real question: The stack implies extensions behave the same across harnesses; in practice they do not (Mastykarz). Plan portability empirically — measure lift in each harness — rather than from the stack diagram.
Fixed or open is taken literally: Treating "harness is fixed" as binary forecloses real interventions vendors expose — PreToolUse hooks, managed settings, system-prompt overrides. The split is approximate; treat it as a planning prior, not a rule.
Small teams with one tool surface: For two people running one agent against one API, locating failures by name ("broken environment", "wrong instructions") is faster than first attributing to a layer. The taxonomy overhead exceeds its yield. Use the Five-Failure-Layers Diagnostic instead, which carries less metaphorical baggage.
Pre-PMF iteration: Lift-vs-drag measurement per extension is overhead that pays off at scale. Early-stage projects gain more from one prompt iteration than from layer attribution.
Disagreement on layer cuts is in scope: Anthropic's own four-layer enumeration of harness failures (premature victory, broken environment, premature feature-completion, undocumented run procedure) does not align with Mastykarz's model→harness→extensions cut (Anthropic). Two reasonable practitioners using "layered model" vocabulary slice the layers differently. Pick a working enumeration and stay consistent within a team — do not assume the slicing is canonical.

Applying the stack¶

A working sequence when an agent fails or you want to invest:

Name the layer where the failure is visible, and where it originates. The visible layer is often downstream of the cause.
Check the controllable layers first. Extensions are the only layer where "changing them gives instant results". A model swap is the most expensive option.
Run the lift-vs-drag test on each candidate fix. Use the same scenario, harness, and model, with the extension on and then off. Promote lifts, remove drags.
When the controllable layers are exhausted, accept the fixed-layer constraint. Record it in the project's AGENTS.md so contributors do not relitigate it.

Example¶

A team using Claude Code finds the agent keeps generating code against a deprecated version of their internal SDK. The AX stack locates this:

Model layer (fixed): The model's training data is older than the SDK rewrite. Confirm by asking the model to recite the SDK signature — it will return the deprecated one.
Harness layer (fixed): Claude Code controls how MCP servers and skills are surfaced; the team cannot rewrite that.
Extensions layer (controllable): The team has no skill or MCP server that exposes the current SDK signatures. This is the candidate fix.
Technology surface (controllable): The SDK could ship machine-readable signature metadata for an MCP server to serve, but that is a larger investment.

Lift-vs-drag test: add a one-paragraph AGENTS.md entry and an MCP server returning the current signatures. Run ten realistic generation tasks with the extension off, then ten with it on. If pass rate improves, promote; if not, the failure is upstream — likely at the technology surface (the SDK itself is not legible to an agent) and the next move is to add structured signature output.

Key Takeaways¶

Four layers — model, harness, agent extensions, technology surface — give a shared vocabulary for naming where an agent failure or optimisation lives.
The model and harness are mostly fixed by the vendor; extensions and the technology surface are where developers have leverage.
The fixed/controllable dichotomy is approximate, not absolute — vendors expose harness-level levers (hooks, settings, system-prompt overrides) that the binary framing hides.
Layers leak in predictable ways: model bias defeats extension steering; harness conventions change extension behaviour across platforms (an MCP server can lift in Claude Code and drag in Copilot); tool descriptions interact with system prompts.
Pair the diagnostic with a lift-vs-drag measurement — without it the vocabulary justifies unfalsifiable claims.

Five-Failure-Layers Diagnostic — A different cut of the same problem: enumerate five working harness layers and attribute every failure before swapping the model.
Harness Engineering — The discipline underlying Mastykarz's "fixed" harness layer; documents what is and is not vendor-controlled inside it.
AX/UX/DX Triad — Layered framing of audiences (agent, user, developer) rather than execution layers; complements the stack by naming inter-consumer leaks.
The Agent Stack Bet — Architectural bets that move concerns (identity, durability) into the platform layer; takes "what is fixed" as the design question rather than the diagnostic question.
Progressive Disclosure for Agent Definitions — Discovery-failure remediation at the extensions layer: load context proportional to task.