Frameworks Are Not
Architecture.

The category error

Teams often describe an AI system by naming the framework that orchestrates it, the model that reasons inside it, the vector database that stores retrieval state, and the protocol used to expose tools. This is useful inventory information. It is not yet an architecture.

An architecture explains which capabilities are required, how they interact, where trust changes, which constraints apply, who may decide, what evidence supports the design, and how the system behaves when a component fails or changes. A framework is one possible implementation of part of that design.

The distinction matters because implementation choices move faster than control objectives. A model can be replaced in weeks. A governed decision about who may approve a consequential action, which data may cross a boundary, or what evidence must remain should not be rewritten every time a library changes.

Four layers that should not collapse

Capability architecture states what the system must be able to do. Governance architecture states what must remain controlled, explainable and reviewable. Solution architecture connects those requirements through interfaces and operational boundaries. Implementation selects concrete products, libraries and services.

The layers influence each other, but they are not interchangeable. A product limitation can constrain a solution. It should not silently redefine the business objective or remove an accountability requirement.

What a framework legitimately provides

A framework can provide valuable defaults: an execution loop, graph or workflow representation, tool adapters, state management, retry behaviour, tracing hooks, evaluation utilities and deployment integrations. Those features can reduce delivery cost and encode hard-won engineering practice.

The error is treating the framework's object model as a complete description of the governed system. A node in an agent graph may represent a function call, a model invocation, a human approval or an external organisation. Those objects have different trust, legal, evidence and recovery properties even if the framework renders all of them as nodes.

Framework configuration also tends to capture the happy path better than the decision rationale. It may show that a retry is configured without preserving why three retries are acceptable, which failure classes must not be retried, who accepted the residual risk, or what change would invalidate that decision.

Protocols define interoperability, not the whole control model

The Model Context Protocol illustrates the distinction well. The July 2026 protocol redesign moved the core toward stateless request/response interactions: protocol version, client identity and capabilities are carried explicitly with requests, while state that must persist can be represented by explicit handles rather than hidden transport-session state. Policy-visible routing metadata also makes protocol method and capability names available to gateways without requiring the protocol to become the organisation's governance model.

This evolution strengthens the architectural separation. A protocol can change its session, discovery, routing and extension mechanics while the governed system still needs stable decisions about identity, authorization, data classification, evidence retention, state ownership, recovery and acceptable autonomy. Transport state is not application state, and application state is not automatically governed durable state.

MCP can therefore be an implementation of an integration capability. It should not become shorthand for the complete agent architecture. The same applies to an API gateway, message bus, container interface or identity federation protocol.

Kubernetes provides a mature non-AI analogy: the Container Runtime Interface lets kubelet work with multiple conformant runtimes. The interface creates replaceability at one boundary; it does not make all runtimes operationally equivalent. Compatibility is necessary, while security posture, performance, lifecycle and failure behaviour still require evaluation.

The contract stack

Replaceability becomes real only when the boundary is explicit. “We can swap the model later” is not a design property unless inputs, outputs, state, evaluation, safety and operational assumptions are represented outside the model-specific integration.

A replacement can satisfy the functional API and still violate the architecture. It may process data in a different region, retain prompts, expose weaker audit events, change tool-selection behaviour, change state semantics, remove deterministic controls, or make graceful degradation impossible. The contract stack makes those differences visible before migration.

Generated implementation is still implementation

Recent agentic engineering work makes the architecture/implementation distinction even more important. In SMART, design documents form a dependency graph that agents use to regenerate implementation modules, while reconciliation and tests decide whether the generated build can replace the previous one. The useful lesson is not that every system should make natural-language design documents its source of truth. It is that a regenerable implementation can remain subordinate to durable intent and qualification gates.

This also strengthens the evidence contract. EG-VQA and ExtractBench show in different domains that a plausible or schema-valid output can still fail evidence grounding or completeness. Replacement therefore needs more than interface compatibility: correct output ≠ evidence-grounded qualified outcome.

Governance must sit above orchestration

NIST AI RMF describes GOVERN as a cross-cutting function that connects technical design and development to organisational policy, roles and risk management across the lifecycle. The EU AI Act similarly treats risk management for high-risk AI systems as a continuous iterative lifecycle process where applicable. Neither source requires this specific architecture. Both support the conclusion that governance cannot be reduced to a framework plugin activated at deployment time.

A framework may execute a policy check. The policy owner, applicability decision, evidence threshold, exception authority and reassessment trigger must remain independently governed. Otherwise replacing the framework can remove the effective control even when the policy document still exists.

The replacement test

A useful architecture review asks what happens when a central implementation changes. The test is not whether migration is effortless. It is whether the organisation can identify the affected contracts, decisions, risks and evidence without rediscovering the system from source code.

replace(implementation):
  identify capabilities provided
  traverse dependent decisions and controls
  compare functional, trust, evidence, quality, state and operational contracts
  re-run evaluation suite against representative tasks and failure paths
  verify identity, data residency, state, logging and human-approval invariants
  record changed assumptions and residual risks
  approve, reject or time-bound the migration decision

Failure patterns

• Framework-shaped architecture: every architectural concept is named after a library primitive.
• Provider-shaped governance: policy follows the settings exposed by the current vendor rather than organisational risk.
• Protocol maximalism: an integration protocol is assumed to solve identity, consent, evidence and lifecycle governance.
• Portable code, immovable state: adapters are replaceable but memory, evaluation history, audit records or embeddings are not.
• Nominal human oversight: a human step exists inside the workflow but authority, information quality and response time are undefined.
• Migration without decision replay: technical tests pass while the assumptions supporting the original approval are never reconsidered.

Trade-offs and boundaries

Abstraction has a cost. A universal interface can hide useful vendor-specific capabilities, reduce performance, create a lowest-common-denominator design and add operational complexity. Some systems rationally accept deep coupling when speed, specialised performance or short product life matters more than portability.

Vendor neutrality should therefore not mean pretending implementations are identical. It means keeping the decision explicit: which coupling is accepted, what value justifies it, how long the assumption is valid, and what evidence would trigger reconsideration.

The model also does not imply that every small AI feature needs enterprise architecture ceremony. The depth of contracts and evidence should follow consequence, autonomy, data sensitivity, scale and regulatory context.

Claim boundaries

• Established: architecture practice distinguishes functionally defined architecture building blocks from implementation-specific solution building blocks.
• Supported synthesis: capability and governance concepts usually change more slowly than AI products, frameworks and model versions.
• Supported refinement: current research supports preserving durable specification/evidence/qualification boundaries even when implementation is generated or replaced, but no cited paper validates this complete contract stack across all agentic systems.
• Hypothesis: the six-part contract stack reduces migration risk and governance loss in agentic systems.
• Not claimed: that framework coupling is always wrong, that every implementation is replaceable at equal cost, or that vendor neutrality guarantees resilience.

Open questions

• Which AI capabilities are stable enough to standardise now?
• Where does abstraction protect governance, and where does it conceal material implementation differences?
• How should evaluation evidence be made portable when model behaviour is probabilistic?
• Which state must remain vendor-independent: prompts, memory, traces, decisions, embeddings, or all of them?
• What is the minimum replacement test for a high-impact agentic capability?

Evidence notes

• E1, architecture separation: The Open Group distinguishes Architecture Building Blocks, defined functionally, from implementation-specific Solution Building Blocks. This supports the central distinction but does not prescribe the four layers used here.
• E2, protocol boundary: MCP's July 2026 architectural redesign provides a concrete protocol-evolution example: stateless core interactions and explicit state/routing metadata can change without defining the organisation-wide governance architecture.
• E3, replaceable interfaces: Kubernetes CRI demonstrates runtime replaceability through a stable interface; it is an analogy, not evidence that AI components are equally substitutable.
• E4, lifecycle governance: NIST AI RMF and the EU AI Act support continuous lifecycle governance in their respective scopes. They do not mandate the contract stack proposed here.
• E5, regenerative implementation: SMART (Kushnir et al., 2026) reports an AI-native ML performance tool built from dependency-linked design documents with generated implementation and reconciliation. Transfer beyond that domain remains an architectural inference.
• E6, outcome qualification: EG-VQA and ExtractBench support separating apparent output correctness from evidence grounding, completeness and reproducible qualification in their respective benchmark domains.
• Reassessment trigger: standardised AI component interfaces, evidence formats or architecture models that supersede these proposed abstractions.

Evidence base

Standards and architecture practice

• The Open Group — Building Blocks and the ADM
• NIST AI RMF Core
• Regulation (EU) 2024/1689, EU AI Act

Research and benchmarks

• Kushnir et al. — Design Docs Are All You Need
• Huang et al. — EG-VQA
• ExtractBench — enterprise document extraction benchmark

Engineering specifications and implementations

• Model Context Protocol — July 2026 protocol update
• Kubernetes Container Runtime Interface

Where this goes next

Once architecture is separated from implementation, the next question is how operational capability should be packaged, qualified and governed. A reusable skill is more than a prompt: it needs context, authority, evidence, ownership and lifecycle. That is the next part of the series.