Anthesis Update: Memory, Governance, and Beyond the SDLC

By Robert Ryan Jennings Published Mar 27, 2026 12:00AM 13 min read

software engineering artificial intelligence
anthesis ai agentic-systems memory governance software-architecture security

Anthesis Update: Memory, Governance, and Beyond the SDLC

When I first started shaping Anthesis, a lot of the early energy went into design and into a fairly obvious ambition for agentic systems:

Could a set of subagents take a project from intent to completion in one shot?

The answer so far is: not in any trustworthy or cost-effective way.

It is possible to get flashes of impressive output from multi-agent orchestration. It is much harder to get bounded, replayable, governable, affordable execution that still respects real engineering constraints.

That has pushed Anthesis in a more serious direction.

Instead of treating the system as a clever prompt wrapper around autonomous coding tools, the recent work has focused on memory, context engineering, governance, and explicit contracts. The result is a system that is becoming less about “AI does the project for you” and more about “AI participates inside a governed engineering substrate without being allowed to quietly invent authority.”

If you want the broader foundation behind the project, read the Anthesis whitepaper. If you want the process-level motivation behind this direction, read AI SDLC: automating the grind. If you want the security framing behind the same direction, read Threat Modeling AI as an Engineering Coprocessor.

The Main Lesson: One-Shot Completion Is Expensive

The first major correction was practical.

Dogfooding subagent-driven, one-shot project completion turned out to be expensive in several ways:

  • token-expensive
  • context-fragile
  • difficult to replay
  • difficult to govern
  • prone to hidden state and silent assumption drift

That is not just a tooling issue. It is an architecture issue.

If every useful step depends on a massive prompt, a long chat transcript, or a fuzzy recollection of prior reasoning, then the system does not really have memory. It has temporary persuasion.

Anthesis was already heavily file-based, but the recent work pushes that model much further. The important shift is not merely “store more things in files.” It is to define what kinds of memory exist, what authority each one has, and how agents are allowed to read or mutate them.

That is the focus of RFC-0051: Memory Model and Authority Rules.

The core idea is simple:

  • normative memory stays authoritative
  • structured state is explicit and mutable under rules
  • retrieval memory is useful but non-authoritative
  • chat history is convenience context, not system truth

That matters because it stops Anthesis from treating conversational context as if it were a database, a policy engine, or a constitutional layer.

The implementation direction is also becoming more practical. Anthesis can keep the repo and explicit artifacts as the primary substrate while improving retrieval through embedding-backed recall and tighter I/O strategies for exact lookup versus semantic enrichment. That combination is far more defensible than trying to brute-force every task through giant prompt assemblies.

External Tools Need Admission, Not Trust

A second major area of progress is how Anthesis treats external agentic tooling.

There is no reason to assume the tool landscape will stabilize soon. Codex, Claude, Gemini, agentfield.ai, agentgateway, kwaak, MCP-connected tools, IDE assistants, scanners, and custom adapters all operate at different layers and with different trust assumptions.

Anthesis now treats that volatility as normal.

The important move is not to pick a winner. It is to build a governed abstraction layer where external tools can be categorized, admitted, scoped, suspended, and replaced without collapsing the rest of the system.

That abstraction is powerful precisely because these tools do not all solve the same problem.

Model Runtimes and Provider Surfaces

Some are best understood as model runtimes or provider surfaces:

Agentic Orchestration and Control Planes

Some are better understood as agentic orchestration or control-plane platforms:

Gateways, Brokers, and Federation Layers

Some act more like tool gateways, integration brokers, or federation layers:

Interactive Assistants and Execution Surfaces

Others fit into interactive assistants and execution surfaces:

  • IDE copilots
  • headless coding agents
  • CLI-bound execution tools

Analysis, Review, and Scanning Systems

And others are primarily analysis, review, or scanning systems:

  • security scanners
  • policy evaluators
  • drift detection and audit tooling

Why The Abstraction Matters

Those categories matter because they imply different authority ceilings, replayability expectations, evidence requirements, and approval boundaries. Treating them all as just “AI tools” is architecturally weak. Anthesis becomes much stronger once it can distinguish the class of tool it is talking to and govern that class accordingly.

That work sits most clearly in RFC-0032: External Tool Integration & Admission and related integration RFCs.

The operating principle is blunt:

  • external tools are untrusted by default
  • tools do not own intent
  • tools do not approve actions
  • participation must be explicit and revocable

This is the right abstraction for the real world. Vendor models will change. Platforms will disappear. New orchestration surfaces will appear. Anthesis should be able to absorb those changes by treating tools as admitted participants behind adapters, not as sovereign actors.

That also opens the door to future orchestration across context tooling, model routing, execution surfaces, and specialized analysis systems without letting any one of them redefine governance.

Part of that work also includes incorporating the OpenAI Responses API as a practical interoperability surface.

That matters less as a branding choice than as an architectural one. Anthesis needs a durable way to normalize modern model interactions across tool calls, structured outputs, intermediate reasoning surfaces, and multi-step execution patterns without hard-coding itself to a single vendor runtime.

Treating the Responses-style interaction model as one adapter target helps in two ways:

  • it gives Anthesis a cleaner contract for model IO and tool invocation
  • it makes cross-provider orchestration easier to reason about when different systems expose similar capabilities through different APIs

In other words, Anthesis is not just abstracting tools. It is also abstracting the interaction formats those tools increasingly expect.

UGC: QART Plus Drift as a Single Control System

Another important clarification in Anthesis is that governance is not being treated as a scattered set of review habits.

The governance core is now much more explicit across:

  • RFC-0036: QART Engineering
  • RFC-0037: Drift Loop Engineering
  • RFC-0038: Unified Governance Control

QART handles the pre-decision side of engineering:

  • Questions
  • Alternatives
  • Recommendation
  • Tradeoffs

Drift handles the post-decision side:

  • detect divergence
  • classify it
  • reconcile it
  • audit the result

UGC is the doctrine that binds those two together into one control loop.

That matters because Anthesis increasingly treats documentation as a governed operational surface rather than as passive explanation. RFCs, plans, requirements, task artifacts, and derived implementation references are not just text blobs. They are part of the control system that connects intent formation to realization and then back again when reality diverges.

The practical value is that governance is now easier to carry into lifecycle state itself. In the current loop and bridge work, UGC does not appear as a vague idea sitting outside the system. It appears as an explicit overlay or governance envelope attached to loop objects and bridge objects, alongside references to artifacts, evidence, approvals, and policy snapshots.

That gives Anthesis a cleaner way to express:

  • this lifecycle state is governed under UGC
  • this state or bridge is carrying QART concerns
  • this relationship is specifically part of drift reconciliation

without pretending those overlays create execution authority on their own.

Loops Are No Longer Limited to the SDLC

Another major improvement is conceptual.

Anthesis started from an agentic SDLC framing, but real engineering systems do not stop at the software development lifecycle. Product work, operational learning, security response, and delivery governance all have lifecycle behavior.

That is what RFC-0042: Loop Contract and UGC Bridge Semantics addresses.

Instead of hard-coding Anthesis around one lifecycle, loops are now abstracted as governed artifacts with explicit contracts. That means Anthesis can support:

  • sdlc loops
  • product_lifecycle loops
  • governed bridges between loop instances
  • overlays like UGC, QART, and Drift without confusing them for lifecycles themselves

The important architectural point is that loops can interact without smuggling in unauthorized execution power.

That same contract is also where the documentation and governance envelope start to become operational. Loop objects and bridge objects can carry the artifact references, approval references, evidence references, policy snapshots, and overlay markers that tell Anthesis how a lifecycle state is being governed. In practice, that means a loop state is not just “analysis” or “deliver.” It can also carry whether it is under a UGC overlay, whether it is still in a QART-shaped decision space, or whether a bridge is acting as part of drift reconciliation.

In Anthesis terms, this lets the system model richer behavior while still using existing governance concepts like Inflorescence, Calyx, and Phloem as the control fabric. Loops become a way to coordinate lifecycle semantics naturally instead of cramming everything through one pipeline vocabulary.

That matters because “building the software” and “operating the product” are related, but they are not identical. Anthesis now has a better substrate for representing both.

NIST SSDF Is Now a First-Class Governance Layer

Security governance has also become much more explicit.

One of the recent architectural shifts is that NIST SSDF (SP 800-218) is now treated as a first-class citizen inside Anthesis, formalized in RFC-0046: SSDF Integration and Enforcement Model.

This is important because Anthesis is not trying to be a compliance slideshow. It is trying to answer a harder question:

How do you make secure software development controls operational instead of advisory?

The answer Anthesis is converging on is:

  • use SSDF as a governed baseline
  • map it onto existing Anthesis primitives
  • enforce it through policy, evidence, validation, and response flows

That means SSDF provides a strong part of the what, while Anthesis provides the how.

In practice, this tightens the relationship between:

  • policy gates in Phloem
  • validation and scanning layers
  • admitted security agents
  • evidence linkage
  • vulnerability response and learning loops

This is a much stronger position than bolting security onto the end of an AI-assisted workflow and calling it “best practices.”

Phloem Now Has Its Own Decision Contract

As Anthesis matured, it became clearer that Phloem needed a normalized, explainable decision surface of its own.

That is the role of RFC-0048: Phloem Policy Evaluation and Decision Contract.

The RFC defines:

  • normalized evaluation context
  • policy result vocabulary
  • strictest-wins aggregation
  • evaluator explanation requirements
  • the Phloem Decision Record (PDR) schema
  • attestation handoff requirements

The PDR matters because policy evaluation should not dissolve into vague runtime behavior. If the system blocks, warns, requires justification, or rejects, that decision needs to be attributable, reproducible, and scoped to an exact subject.

This is one of the places where Anthesis is becoming much more serious as a governance system. Decisions are not just runtime events anymore. They are explicit records that can be handed off into surrounding verification and evidence flows without pretending they replace approvals.

Tracks Introduce Bounded Work Streams Without New Authority

One of the more practical additions is RFC-0045: Tracks as Governed Coordination Artifacts.

Tracks exist to solve a common operational problem:

How do you represent a bounded stream of work that touches multiple sessions, executions, RFCs, approvals, artifacts, and evidence records without inventing a new state machine or a new authorization model?

Anthesis now answers that by making tracks:

  • durable
  • repo-scoped
  • reference-oriented
  • explicitly subordinate

Tracks group the right artifacts together for review, traceability, and handoff, but they do not create execution permission, approval scope, or runtime state on their own.

That sounds small, but it closes a real ergonomics gap. Systems often become messy not because the core primitives are wrong, but because operators still need a bounded coordination surface that does not secretly mutate governance. Tracks are an attempt to provide exactly that and no more.

gittuf Strengthens the Git Boundary

Anthesis already treats Git as a source of truth. The newer work tightens that by making gittuf a first-class part of the governance model through RFC-0044: gittuf as Git-Native Policy and Verification Substrate.

This is a meaningful gap closure.

A lot of modern development policy still depends too heavily on forge-local controls and CI conventions. Those are useful, but they are not enough if Anthesis is supposed to remain local-first, Git-native, and independently verifiable.

The split is now cleaner:

  • Anthesis decides semantic governance questions
  • gittuf verifies Git-native policy and attestation outcomes
  • CI and forge controls remain convenience layers, not constitutional authority

That reduces the mismatch between local Git development and Anthesis governance. It also makes the repository itself a stronger substrate for protected refs, protected paths, approval-backed changes, and later verification.

For a system trying to govern agentic work instead of merely accelerating it, that boundary matters.

Sessions Are Becoming Replayable Artifacts

The other important shift is how Anthesis treats sessions.

Historically, sessions are easy to misuse as soft runtime state: a blob of context, a prompt boundary, a bit of chat memory, maybe a partial audit surface.

Anthesis is cleaning that up.

Between the earlier session governance work and RFC-0047: Session Declaration Persistence and Replay Contract, sessions are now being treated as explicit stored artifacts with immutable declarations, append-only execution linkage, and replay-oriented lookup semantics.

That matters for at least three reasons:

  • the same declared context can be revisited later
  • auditing becomes more honest
  • replay stops depending on somebody remembering what was “probably in the prompt”

This does not mean Anthesis promises deterministic model output. It means the system can reconstruct the declared context lineage clearly enough to support audit, review, and operational replay.

That is the right promise.

The Direction of Travel

Taken together, these RFCs mark a broader shift in Anthesis.

The project is moving away from the fantasy that agentic engineering is mainly about stacking enough subagents together to produce autonomous project completion.

It is moving toward something stricter and more useful:

  • explicit memory authority
  • governed external tool admission
  • adapter support for formats like OpenAI Responses
  • lifecycle abstraction beyond the SDLC
  • SSDF-backed security structure
  • normalized decision records
  • bounded coordination artifacts
  • Git-native verification
  • replayable session declarations

That is a less flashy story than “press a button and ship the product.”

It is also more likely to survive contact with reality.

Anthesis is still very much a living system. But the recent RFC work makes the project more coherent as a governed substrate for AI-assisted engineering rather than as a pile of prompts wrapped around a command runner.

That is the update.

References

The update above is especially informed by the following Anthesis RFCs:

  • RFC-0032: External Tool Integration & Admission
  • RFC-0036: QART Engineering
  • RFC-0037: Drift Loop Engineering
  • RFC-0038: Unified Governance Control
  • RFC-0042: Loop Contract and UGC Bridge Semantics
  • RFC-0044: gittuf as Git-Native Policy and Verification Substrate
  • RFC-0045: Tracks as Governed Coordination Artifacts
  • RFC-0046: SSDF Integration and Enforcement Model
  • RFC-0047: Session Declaration Persistence and Replay Contract
  • RFC-0048: Phloem Policy Evaluation and Decision Contract
  • RFC-0051: Memory Model and Authority Rules

Related background on this site:

Appendix

Key Terms

Anthesis

The broader governed platform for AI-assisted engineering, oriented around explicit artifacts, approvals, policy, and traceable execution rather than informal prompt state.

QART

The pre-decision governance doctrine defined in RFC-0036:

  • Questions
  • Alternatives
  • Recommendation
  • Tradeoffs

Drift

The post-decision reconciliation discipline defined in RFC-0037 for handling divergence between canonical intent and implementation reality.

UGC

Unified Governance Control, defined in RFC-0038, which binds QART and Drift into one architectural control system.

Loop

A governed lifecycle artifact, such as an sdlc loop or product_lifecycle loop, used to coordinate state, evidence, approvals, and policy snapshots without redefining execution law.

Bridge

A governed, directional relationship between loop instances, used to express how one lifecycle informs, constrains, derives, or reconciles another.

Track

A bounded, reference-oriented coordination artifact for a work stream. Tracks group the right governed artifacts together without creating new authorization, state, or execution semantics.

PDR

Phloem Decision Record, the normalized record of a Phloem policy evaluation outcome.

Working Thesis

The underlying thesis of this update is straightforward:

Anthesis becomes more useful as it becomes less dependent on implicit memory, less impressed by one-shot autonomy, and more disciplined about authority, replay, policy, and lifecycle coordination.