The Missing Layer Between AI-Native SDLC Artifacts and Agent Context

1. August 21, We Recognized the Shape

Anthropic published "The AI-Native SDLC Playbook: How to transform your software development lifecycle with AI—stage by stage."

Our team read it straight through, then went back over it with a text file open, pulling out anything that matched a boundary we'd already hit. The list ran long, not because the playbook validated anything we'd built, but because it kept arriving at edges we'd walked into from the opposite direction.

Since March we've been working one problem across nine articles: an LLM keeps no state between sessions, so a project running for months accumulates decisions that evaporate every time the context window resets. Part 9 closed on accountability (who answers when the agent gets it wrong).

The playbook came at all of this from enterprise process: team throughput, approval queues, review backlogs. Different problem, different pressure, and several of the same structural conclusions.

That is a useful external convergence signal. It is not validation.

Anthropic's document is a playbook drawn from customer work, not a controlled study, and it says nothing about MICA(Memory Invocation & Context Archive).

What makes it worth writing about is narrower and more interesting: reading a lifecycle framework made a gap in our own design visible that we had not seen in six months of staring at it.

---

2. What the Playbook Actually Changes

The playbook's premise is that once agentic coding accelerates implementation, the bottleneck shifts toward the human-speed phases around it. So it restructures each stage around artifacts an agent produces and a person gates.

Stage	Input	Output Artifact	Trigger
Plan	Idea, ticket, or alert	intent.md	Manual, or a Stage 6 breach
Design	intent.md	spec.md	Product owner accepts intent
Build	spec.md	plan.md + PR	Product owner approves spec
Test	Code changes	Verified diff	Build completion
Deploy	PR	Merged commit & deploy record	Tests pass, review approved
Maintain	Production metrics	New intent.md	Control-band breach

The important part for us was not the filenames.

Teams have been passing requirements, specifications and deployment records between people for decades. What changes in an agent-heavy workflow is that these files also become a way of transporting decisions between computational contexts that do not share the conversation in which those decisions were made.

The consumer of plan.md does not need to have participated in the discussion that produced intent.md. The artifact carries enough of the decision forward for the next actor to work from it. The lifecycle therefore contains a context-handoff mechanism, even though context continuity is not the problem the document is primarily trying to solve.

The enforcement model is similarly concrete. CLAUDE.md carries repository conventions and operational knowledge. Skills encode repeatable procedures. Hooks execute outside the model and can block tool operations. Subagents get scoped access rather than a general bag of capabilities.

The production side adds statistical control bands so that different deviations can result in logging, diagnosis or intervention instead of handing the whole decision back to an LLM.

That was where our attention stuck.

Every transition in this lifecycle was also carrying context forward.

The question it left us with was considerably narrower: if these artifacts exist, which of them should a particular AI session receive, and what evidence can we retain about the exact material that crossed that boundary?

---

3. MICA Had Already Reached One Half of That Boundary

MICA did not start as an invocation contract. Earlier versions were much closer to a governed project archive that an AI maintainer would load when a session opened.

By Part 6, a package could describe its session-start behavior roughly like this:

schema_version: "0.2.0"
archive_id: "flamehaven-space-maintainer"
mode: "memory_injection"

session_report_format:
  gate_block_on: "critical_self_test_failure"
  format_template: |
    [SESSION READY]
    Archive: {archive_version}
    Self-test: {self_test}
    Drift: {drift_status}
    Gate: {gate}

self_test_policy:
  checks:
    - id: "ST-001"
      name: "provenance_sha256_format"
      severity: "error"
    - id: "ST-002"
      name: "provenance_file_exists"
      severity: "warning"

drift_response_policy:
  on_hash_mismatch: "warn_continue"
  on_file_missing: "warn_block"

drift_response_policy splits content change from disappearance deliberately, because files legitimately change during development, but a vanished path means a deleted file or a wrong reference.

ST-002 earns its keep in production: an agent mid-refactor reaching for a utility deleted four sessions ago hits the absence at session start instead of spiralling through an ImportError loop and inventing a replacement.

The series moved past that description well before August:

• Part 2: a schema can exist perfectly and still never reach the model.
• Part 4: invocation became explicit through README-as-protocol.
• Part 7: we discovered that a protocol was still not an entrypoint, which led to natural, guided and forced invocation modes.
• Part 8: real archives forced a harder boundary between structural checks and semantic truth. A green structural result could not be allowed to manufacture confidence about what the evidence actually meant.
• Part 9: deterministic verification moved in front of the probabilistic actor rather than asking the actor to certify itself.

Those July commits matter for reading this article correctly. Moving verification outside the model, emitting a deterministic runtime summary, and separating what reaches agent context from what stays operator-only were all in place roughly six weeks before the playbook was published. Nothing in this section was learned from it.

By July, MICA's center had also shifted. The archive was no longer the point. As the README now puts it, MICA is primarily an invocation and context-loading contract, with archive, playbook, and governance machinery subordinate to that.

Part 9 put governance at the center because that was the problem we were testing then. The September work narrowed the authority boundary: governance remained supporting machinery, while invocation returned to the top-level contract.

---

4. The Embarrassing Part Was Selection

Reading the SDLC playbook against our own code led to an audit that was difficult to explain away.

Invocation had grown into two very uneven halves. One half dealt with proving what a session received: capsules, digests, invocation checks, live-byte comparisons and increasingly careful distinctions about what had actually happened. The other half decided what memory should be selected in the first place.

The imbalance looked like this:

Concern	Implementation
Proving memory reached the session	~580 lines
Governing the authoring pipeline	~485 lines
Deciding which memory a session receives	two hardcoded lists

The selection logic was effectively:

["archive", "playbook", "slots"] if mode == "memory_first" else ["archive", "playbook"]

Every session got the same surfaces regardless of task. Whether a typo fix, security review, or production incident, context remained identical. Selection was a constant in the source rather than anything a package could declare.

We thought the hard part of invocation was proving what reached the session. The playbook's stage-specific artifact flow made us notice the half we had barely designed: deciding what the session should receive in the first place.

---

5. September: Selection Becomes Part of the Contract

The September work came from two related tracks, and collapsing them into one would make the history cleaner than it actually was.

5-1. Context Continuity: bind the evidence to actual bytes

The Context Continuity work introduced mica.invocation.v2. Instead of merely recording that an archive or playbook surface had been selected, the invocation evidence can bind the exact selected content using its digest and byte count.

It also became much more careful about verbs.

The delivery states distinguish:

• declared: the surface belongs to the composition contract;
• resolved: its path was valid and its selected bytes were hashed;
• emitted: an adapter reports that those bytes were written to its output channel;
• acknowledged: an external host reports receipt.

None of those means the model read the material correctly. None means it understood it. None means it followed the instructions.

That distinction sounds pedantic until a runtime begins reporting things it cannot actually know. Earlier MICA articles sometimes used language close to "the model proves it loaded the archive." The implementation eventually became stricter than our own prose. resolved now means exactly what happened: bytes were resolved and hashed.

Nothing more gets smuggled into the word.

5-2. Origin: selection, authority, measurement

Origin separated the result into Contract, Archive and Flow axes so that archive quality or authoring-pipeline problems could remain visible without silently taking authority over whether the invocation contract itself closed.

More importantly for this article, memory selection became declarative.

invocation_protocol:
  profiles:
    review:
      surfaces: [archive, playbook, lessons]
    incident:
      surfaces: [archive, playbook]
      sections:
        playbook: [Incident Runbook]

A review session is not an incident session. Giving them identical context budgets may occasionally be correct, but it is no longer an assumption hidden inside two Python lists.

A package can declare the difference, and requesting a profile that does not exist becomes a contract failure rather than an excuse for the runtime to improvise.

The playbook became addressable. Until this point it was one opaque file, so an incident session received the review procedure and the onboarding notes along with the runbook. Now a profile delivers named sections, and the capsule digest covers the delivered slice rather than the source file.

Evidence scope should equal delivery scope.

Hashing the complete playbook while delivering only Incident Runbook would create an evidence record covering text the session never received.

The implementation therefore hashes the delivered slice. Drift follows the same boundary; changing a section excluded from that invocation does not make the invocation evidence stale.

Profile selection itself remains an external caller input. mica_runtime.py --profile incident lets the caller choose a declared profile. Whether that caller is an operator, a wrapper or a hook is an integration choice. MICA can expose the boundary; it cannot stop somebody from wiring authority back into the model if they decide to do that elsewhere.

---

6. The First Measurement Wasn't a Result

Origin also added an instrument for measuring invocation properties that we had previously discussed mostly in structural terms: selected context size, surface resolution, capsule coverage and the active verdict axes.

The first fleet baseline covered six live consumer packages.

Live consumer packages	6
Contract closed	6 / 6
Can identify exact invoked bytes	6 / 6
Declaring a memory profile	0 / 6
Combined baseline context across six consumers	213,112 bytes
Tests	184

The 213,112-byte number needs some care because it is easy to misuse. It is the combined baseline across six consumers, not the amount one session receives. Individual packages ranged from 3,998 bytes to 97,560 bytes.

The more interesting finding was that none of those six baseline consumers declared the new memory profiles. Inside a given consumer, different kinds of work were therefore still starting from the same declared context set.

This does not demonstrate that profile-selected context performs better. It doesn't even demonstrate that the reduced context is worth the additional machinery. It only establishes that there is something measurable now, and that the first baseline exposed the exact adoption gap the new mechanism was supposed to address.

The selection machinery exists. The six baseline consumers do not use it yet.

A consumer pilot with a control has not been run.

The proposed handoff surface is in a similar state. There is an architecture for carrying bounded working state into the next invocation, but implementation has not started. That remains work rather than evidence.

---

7. Where the Two Systems Stop

The Anthropic playbook and MICA overlap enough to make comparison useful, although collapsing them into the same architecture would destroy the distinction that made the comparison useful in the first place.

	AI-Native SDLC Playbook	MICA
Authority	Lifecycle	Invocation
Decides	Which stage runs next	Which context surfaces enter this session
Asks	Who approves	What resolved, and which bytes
Trigger	Artifact unlocks next stage	Invocation resolves the selected surfaces
Optimizes	Team and process throughput	Context continuity and provenance

MICA does not decide product intent, assign code owners, approve pull requests or roll back production. If it starts doing those things, it has become a workflow or governance engine wearing the name of a memory system.

Both point the same direction: verification moves ahead of execution. CI checks results after the agent acted. Hooks that block before tool execution, and MICA runtime summaries that our wrapper injects before model invocation, are the same instinct reached from different rooms.

Make a project's memory something a session can be given, and make it checkable that it was given.

Whether a dedicated invocation layer actually improves long-horizon outcomes is exactly what we still need to test. We have built the selection and evidence machinery. We have not shown that it improves task outcomes.

That is the next experiment: one consumer repository, whole-context against profile-selected context, measured.