Skip to main content

Specification Engineering: The Layer That Doesn't Forget

· 25 min read
Barry Henry
Engineering Leader

The previous post mapped four cumulative layers of agentic engineering — prompt, context, intent, specification — and argued that the industry keeps miscounting them by confusing abstraction levels with tooling. This post goes deep on Layer 4: Specification Engineering.

Layer 4 is the least understood, the least implemented, and the most consequential. It is also the only layer where real production-grade tooling has shipped in 2026 — policy-as-code engines, formal agent contracts, and specification standards — which means the gap between what's possible and what teams are actually doing is now an engineering choice, not a capability limitation.

The thesis: specifications that live in the system prompt will be silently erased by the agent's own memory management. Any specification that matters must be enforced at the infrastructure layer, external to the model's context window. This is not a theoretical position. It was measured this year, in a controlled study and in production — the evidence base is still young, but the direction is consistent everywhere it's been tested.

What Specification Engineering Is​

Vishnyakova's formulation remains the clearest [1]: Specification Engineering is the discipline of creating a complete machine-readable corpus of policies, quality standards, operational procedures, and corporate agreements — everything that previously lived in PDF regulations, executive orders, verbal agreements, and the formulation "everyone just knows."

"Specifications for agents are what ERP is for business processes: ERP runs on codified procedures, not verbal agreements. Multi-agent systems require the same formalisation, applied to corporate knowledge." [1]

The key words are machine-readable and complete. A policy document on a wiki is not a specification. A verbal agreement between engineers is not a specification. A system prompt that says "follow company guidelines" is not a specification — it's a gesture toward a specification that doesn't exist. A specification is a machine-readable artefact that an external enforcement system can evaluate at runtime, independent of the model's reasoning.

The Boundary: Where Intent Ends and Specification Begins​

The Layers post drew the line between Layer 3 (Intent Engineering) and Layer 4 (Specification Engineering). The confusion between them is the most common architectural error in agent system design, so it's worth making the distinction concrete.

Intent Engineering (Layer 3)Specification Engineering (Layer 4)
ScaleTeam / productOrganisation / ecosystem
Question"What should the agent optimise for?""What must the agent obey?"
CharacterStrategic — goals and trade-offsNormative — constraints and compliance
Example"Maximise customer satisfaction while minimising cost""Never share customer financial data with third parties"
Example"Prefer concise over comprehensive when they conflict""All healthcare responses must include a disclaimer"
EnforcementEncoded in the agent's loop — success criteria, termination conditionsEnforced by external infrastructure — policy engines, CI gates
When absentAgent optimises the wrong thingAgents across the organisation contradict each other

Intent tells the agent what to optimise. Specification tells it what it must never do and what it must always do, regardless of the goal. Intent is negotiable — trade-offs shift by context. Specification is non-negotiable — policies hold across all contexts.

Google DeepMind's Intelligent Delegation framework [2] operationalises this boundary through contract-first decomposition: specifications define the verification methods for outcomes (the normative layer), while intent defines the goals being delegated (the strategic layer). A task can only be delegated when both its intent and its verification specification are clear.

Why Specifications Can't Live in the Prompt​

This is the section that changes the argument from "specifications are important" to "specifications in the prompt don't survive contact with a long-running agent."

Governance Decay​

Governance Decay diagram in two halves. Left: a compliance-over-time chart shows a flat line at 100% compliance, a steep drop to 50-60% at the first context compaction event, and a further drop to roughly 20% at the second compaction event, ending in a solid tile reading '20% — rules effectively gone,' sourced from a production measurement of Claude Code by TokenJam. Right: a mechanism chain shows rules visible in context producing 0% violation, then context compaction firing as the context grows, forking into two bad outcomes — the rule is dropped, producing 38% violation, or the rule 'survives' as a residue with a 34 to 57 point behavioural gap — both converging on a dark closing box that reads 'Neither outcome is safe: a presence check is not a safety check.' A closing band states the conclusion: in-context specifications have an expiration date, so they must be evaluated externally and never live in context. A closing quote from Chen (2026) reads: 'Governing agents requires governing how they forget.'Governance Decay diagram in two halves. Left: a compliance-over-time chart shows a flat line at 100% compliance, a steep drop to 50-60% at the first context compaction event, and a further drop to roughly 20% at the second compaction event, ending in a solid tile reading '20% — rules effectively gone,' sourced from a production measurement of Claude Code by TokenJam. Right: a mechanism chain shows rules visible in context producing 0% violation, then context compaction firing as the context grows, forking into two bad outcomes — the rule is dropped, producing 38% violation, or the rule 'survives' as a residue with a 34 to 57 point behavioural gap — both converging on a dark closing box that reads 'Neither outcome is safe: a presence check is not a safety check.' A closing band states the conclusion: in-context specifications have an expiration date, so they must be evaluated externally and never live in context. A closing quote from Chen (2026) reads: 'Governing agents requires governing how they forget.'

Governance Decay: in-context specifications have an expiration date — click to expand

Chen (2026) [3] identified a failure mode that should alarm anyone running long-horizon agents: governance decay. In-context governance constraints that agents reliably obey while visible are silently removed by context compaction — the process by which agents summarise their own context to fit within the context window.

The findings from a controlled study across 7 models and 1,323 episodes [3]:

  • Context compaction raises policy violation from 0% to 30% (up to 59% for some models)
  • That 30% is a blend of two outcomes: when the constraint survives the summary, 0% violation; when it's dropped, 38% violation. Most sessions land somewhere between the two, which is what pulls the aggregate down from 38% to 30%
  • Soft organisational policies decay 8.3× more than hard safety norms — meaning the policies most likely to be erased are exactly the deployment-specific constraints that live only in context
  • The model doesn't rebel against the constraint. It forgets the constraint existed.

A follow-up study [4] found something worse: a presence check is not a safety check. Even when a rule survives compaction textually, it can degrade into a "residue" — text that looks like a rule but no longer acts like one. Degraded residues produce +34 to +57 point behavioural gaps versus intact rules.

Compaction-Eviction Attack​

The governance decay finding also opens an adversarial surface [3]: an attacker who can place content in the agent's context can bias compaction to delete a specific constraint. Optimised injections defeated every model tested, including those immune to passive decay — achieving 0% → 65% violation rates.

Production Measurements​

TokenJam measured this in production with Claude Code [10]: compliance starts at 100% in the first 30 minutes, drops to 50-60% after the first compaction, and hits 20% after the second compaction. The rules were effectively gone. It's one team's deployment, not a controlled study — but the shape of the curve matches Chen's lab results closely enough that it reads as confirmation rather than a separate claim.

The Implication​

"Governing agents requires governing how they forget." [3]

This is not a model quality problem. Passive decay alone is already model-dependent — some models held up far better than others in Chen's numbers above. But better models don't make the problem go away: the adversarial version defeated every model tested, including the ones that were comparatively resistant to passive decay. Between the two, no model is safe by default. It's an architectural problem, which means the fix has to be architectural too: something outside the context window that has no context window to compact, and therefore nothing to forget.

What Specifications Look Like in Practice​

The tooling exists. The question is no longer "can we do specification engineering?" but "why aren't we?" — a question this post comes back to with numbers in The Scale Problem below. First, what the tooling actually looks like.

Three different problems get solved by three different categories of tool, and none of them substitute for each other. Policy languages decide what an agent is allowed to do, evaluated at runtime. Specification standards decide what an agent is — its identity, capabilities, and trust boundaries — independent of any single runtime. Formal contracts decide what "compliant" means precisely enough to verify and bound mathematically. A system with policy-as-code but no shared identity standard still lets agents misrepresent what they are to each other. A system with an identity standard but no formal contracts has no way to measure whether behaviour is actually drifting from what was specified.

Policy-as-Code​

The pattern: specifications are written as code in a formal policy language, evaluated by an external policy engine at runtime, independently of the agent's reasoning. The agent proposes an action; the policy engine permits or denies it. The agent never sees the policy text, never reasons about the policy, and never has the opportunity to reinterpret, paraphrase, or forget it.

The Agent Patterns Catalogue [8] codifies this as the Policy-as-Code Gate pattern: "The LLM must not dispatch any governed tool call without first obtaining an allow verdict from the external policy engine, must not modify or paraphrase rule content at runtime, and must surface the rule ID behind any deny rather than synthesising its own explanation."

Three policy languages dominate:

Cedar [5][6] — AWS's purpose-built authorisation language with formal verification via automated theorem provers. Default-deny posture; forbid-wins-over-permit semantics. Amazon Bedrock AgentCore uses Cedar to enforce a three-layer model for multi-agent chains:

  • L1: Agent-to-tool — which tools an agent may invoke, with what parameters
  • L2: Agent-to-agent delegation — what capabilities an agent may delegate to another agent (using Delegation Capability Tokens)
  • L3: Originating user authorisation — the human's permissions propagate through the entire delegation chain

Each layer maps to NIST SP 800-53 controls (AC-4, AC-6, AU-2, AU-3, SI-10, IA-2, SC-12, SC-28) [6].

OPA / Rego — Open Policy Agent's Datalog-inspired language. The broadest ecosystem integration (Kubernetes, Istio, cloud-native). Partially analysable for policy conflicts. Best for behavioural constraints: rate limiting, sequence validation, multi-condition policies [9].

Microsoft Agent Governance Toolkit [7] — open-source (MIT), released April 2026, and language-agnostic across YAML rules, OPA Rego, and Cedar. Five components cover the stack end to end: Agent OS is the stateless policy engine itself, running at <0.1ms p99 latency; Agent Mesh handles DID-based inter-agent identity and dynamic trust scoring; Agent Shield is an MCP security gateway; Agent SRE does runtime monitoring; and Agent Compliance maps enforcement automatically to regulatory frameworks like the EU AI Act, HIPAA, and SOC 2. The toolkit claims to address all 10 OWASP Agentic AI risks [7].

Agent Specification Standards​

Policy-as-code handles the enforcement question: how do you prevent violations? Specification standards handle the identity question: what is this agent, what can it do, and what rules govern it?

OSSA (Open Standard Agents) [11] — a vendor-neutral YAML specification sitting above protocols (MCP, A2A) and below applications. Defines agent identity, capabilities, trust boundaries, and governance. Integrates Cedar for fine-grained authorisation. Extensions for CrewAI, LangChain, and Anthropic. Current version: v0.5.6 (August 2026).

Oracle Agent Spec [12] — framework-agnostic declarative language with a key finding: the same specification executed across different runtimes (LangGraph, CrewAI, AutoGen, WayFlow) produces measurably different results. This demonstrates that specification alone is necessary but insufficient — the runtime matters, and specifications must account for runtime variance.

Agentic App Spec [13] — "protobuf for AI agent orchestration." File-tree based: YAML agent definitions + Markdown system prompts. The key innovation is build-time validation: the spec compiler catches reachability errors, cycle detection, branch isolation, and trail isolation violations before deployment. You can't deploy a specification that's internally inconsistent.

Agent Behavioural Contracts (Formal Specification)​

The ABC paper [14] provides the formal theory. A contract is C = (P, I, G, R):

  • P — Preconditions: what must be true before the agent acts
  • I — Invariants: what must remain true throughout execution
  • G — Governance policies: organisational constraints
  • R — Recovery mechanisms: what happens when a contract is violated

The key formal result is the Drift Bounds Theorem: contracts with recovery rate γ > α (natural drift rate) bound behavioural drift to D* = α/γ in expectation, with Gaussian concentration [14]. Translation: if your recovery mechanism corrects violations faster than they occur, drift is bounded and measurable. Without contracts, drift is unbounded.

Across 1,980 sessions [14]: contracted agents held 88–100% hard constraint compliance. That's not a like-for-like baseline comparison — the study measured uncontracted agents on a different axis, soft-violation counts rather than hard-compliance rate — but on that axis uncontracted baselines missed 5.2–6.8 soft violations per session entirely, which is the gap the contract's recovery mechanism exists to close.

The Scale Problem​

The governance gap is not closing. It is widening.

The Numbers​

MetricSourceValue
Enterprises with mature agentic AI governanceDeloitte 2026 [15]21%
Enterprises planning agentic AI within 2 yearsDeloitte 2026 [15]~75%
Enterprises that have NOT redesigned roles around AIDeloitte 2026 [15]84%
Organisations with agentic-specific policiesR Systems/Everest 2026 [22]7%
Organisations encountering risky agent behavioursMcKinsey 2026 [17]80%
Organisations with full security/IT approval before deploying agentsMcKinsey 2026 [16]14.4%
Enterprises predicted to have autonomous AI derailed by governance gapsGartner 2026 [18]40%
Average RAI maturity score (out of 4)McKinsey 2026 [16]2.3
Agentic AI governance maturity score (out of 4)McKinsey 2026 [16]~2.0

Worth being precise about what these numbers are: self-reported maturity from four separate industry surveys, not independently measured outcomes. Deloitte, McKinsey, Gartner, and R Systems/Everest each asked organisations to rate their own governance — that's a softer form of evidence than Chen's controlled study above, and it should carry less weight per data point. What makes it worth including anyway is that four unrelated surveys, run by four different firms, converged on the same shape: governance maturity sitting well below deployment velocity. That agreement across independent methodologies is closer to a real signal than any single number in the table is on its own.

McKinsey's reframing [16] is precise: "In the gen-AI era the risk was AI saying the wrong thing, which a human could catch before acting on it; in the agentic era the risk is AI doing the wrong thing, where the action has already happened."

Only 7% of organisations have agentic-specific policies [22]. 80% have already encountered risky agent behaviours [17]. The tooling exists — Cedar, OPA, Microsoft's toolkit, OSSA. The gap is adoption, not capability.

The Standards Landscape​

Standards bodies are moving, but the standards haven't hardened:

NIST launched the AI Agent Standards Initiative in February 2026 [19] with three pillars: standards facilitation, open-source protocol development, and agent security/identity research. They've issued an RFI on AI Agent Security and an NCCoE concept paper on agent identity and authorisation. But no published standard yet.

OWASP released the Top 10 for Agentic Applications in December 2025 [20] — the first formal taxonomy of autonomous AI agent risks. Ten categories from Goal Hijack (ASI01) through Rogue Agents (ASI10). This is the closest thing to a widely adopted risk framework.

ISO/IEC 42001:2023 [21] is the first certifiable AI management standard with 38 AI-specific controls. But it was designed pre-agentic AI. Multiple analyses identify four critical gaps [23]: the autonomy gap (42001 assumes human-in-the-loop), the composition gap (multi-agent systems aren't addressed), the adaptation gap (agents that modify their own behaviour), and the cross-boundary gap (agents operating across organisational boundaries).

Specification Drift​

Specifications that exist but are not maintained are worse than no specifications at all — they create false confidence.

Five Classes of Drift​

The drift detection literature [10][24][25] identifies five classes:

  1. Input drift — the user population or request distribution changes, but specifications assumed the original distribution
  2. Decision drift — the agent selects different tools or routes over time, drifting from specified behaviour
  3. Execution drift — tool behaviour changes without the agent's awareness (API updates, dependency changes)
  4. Context drift — retrieval quality or policy documents change, shifting the informational foundation
  5. Outcome drift — task success or compliance rates move gradually

Detection​

Three detector levels are recommended [10]:

  • Distribution detectors — statistical shape of inputs/outputs over time (Z-scores on tool-call counts, Jaccard similarity on tool sets)
  • Trace detectors — structural analysis of individual runs (did required controls execute? did the policy gate fire?)
  • Outcome detectors — results monitoring (lagging indicator — by the time this fires, drift has already had impact)

The key insight from the practitioner literature [25]: "Every drift signal is a signal about missing memory infrastructure. Constraint drift means the constraint was only in the system prompt and got buried." The fix is not longer prompts but a memory layer that persists and re-injects what matters — or, better, an external enforcement layer that never relies on the context window in the first place.

The Honest Limitation​

Moving specifications to infrastructure doesn't make them self-maintaining. A policy engine enforces exactly what it's told to enforce — if the Cedar policy is wrong, the enforcement is now confidently wrong at sub-millisecond latency on every call, instead of vaguely wrong in a system prompt somebody might notice. The concept registry can drift from the codebase it describes. The spec gate's completeness check only catches what someone thought to require.

This isn't an argument against the architecture. A specification that can be versioned, tested, and audited beats one that lives in a system prompt and can't be inspected at all. But it reframes the problem instead of closing it: specification engineering doesn't remove the need for governance — it moves governance to a layer where governing it is actually possible. The drift detectors above exist because of that, not despite it. Someone still has to own the registry.

Connecting the Laws​

The Laws post identified structural forces that shift when agents join teams. Two of them are specification failures outright:

The Specification Amplifier — 41.8% of multi-agent production failures trace to specification problems. A vague spec given to three agents produces three divergent implementations. This is a Layer 3/4 failure: the agents had context (Layer 2) and well-formed prompts (Layer 1), but no shared specification for what "correct" meant.

Agentic drift — parallel agents independently inventing competing abstractions. This is a Layer 4 failure: no shared concept registry existed. The ABC framework's Drift Bounds Theorem [14] proves this is formally solvable: contracts with adequate recovery rates bound drift to D* = α/γ.

Two more touch specification more lightly, as mitigations rather than root causes. The review bottleneck — agents producing faster than humans can review — is eased by moving constraints from "things a reviewer checks by hand" to "things the policy engine enforces automatically." Goodhart intensified — agents optimising metrics mechanically, without the friction a human would introduce — is countered the same way: encoding what the agent must not optimise at the specification layer, enforced externally, rather than trusting a prompt to hold the line. Neither problem originates at Layer 4. Specification engineering just happens to be where the fix lives.

The Practical Architecture​

Bringing together policy-as-code, specification standards, and drift detection into a coherent system:

The Specification Engineering Architecture, a layered diagram. At the top, a dashed Specification Registry zone holds four cards — Policies (Cedar, OPA, YAML; default-deny, forbid wins), Contracts (C = (P, I, G, R); preconditions, invariants, recovery), Concepts (shared vocabulary; prevents agentic drift), and Domains (Conway boundaries; agent scoping rules) — as the source of truth. Arrows flow down to three enforcement components: Policy Engine (evaluates every tool call, returning permit or deny plus reason, and the agent never sees the policy text), Spec Gate (validates before the agent starts, returning start agent or reject as underspecified), and Drift Detection (monitors compliance over time via distribution, trace, and outcome detectors). Arrows continue down into an Agent Runtime band stating that the agent proposes an action and the policy engine permits or denies it, and that the agent never sees or reasons about the policy text — illustrated by a contrast between a 'context window' that compacts, forgets, and decays, and a 'specification registry' that is persistent and enforced, marked as not equal. A closing panel lists three properties: it survives governance decay because specs live outside context and compaction can't erase them, it prevents agentic drift because the concept registry catches duplicate abstractions, and it reduces review load because enforced constraints don't need human review.The Specification Engineering Architecture, a layered diagram. At the top, a dashed Specification Registry zone holds four cards — Policies (Cedar, OPA, YAML; default-deny, forbid wins), Contracts (C = (P, I, G, R); preconditions, invariants, recovery), Concepts (shared vocabulary; prevents agentic drift), and Domains (Conway boundaries; agent scoping rules) — as the source of truth. Arrows flow down to three enforcement components: Policy Engine (evaluates every tool call, returning permit or deny plus reason, and the agent never sees the policy text), Spec Gate (validates before the agent starts, returning start agent or reject as underspecified), and Drift Detection (monitors compliance over time via distribution, trace, and outcome detectors). Arrows continue down into an Agent Runtime band stating that the agent proposes an action and the policy engine permits or denies it, and that the agent never sees or reasons about the policy text — illustrated by a contrast between a 'context window' that compacts, forgets, and decays, and a 'specification registry' that is persistent and enforced, marked as not equal. A closing panel lists three properties: it survives governance decay because specs live outside context and compaction can't erase them, it prevents agentic drift because the concept registry catches duplicate abstractions, and it reduces review load because enforced constraints don't need human review.

The Specification Engineering Architecture: specifications live outside the context window, enforced by infrastructure — click to expand

The specification registry is the source of truth. The policy engine enforces it at runtime. The spec gate validates completeness before agents start. Drift detection monitors compliance over time. The agent never touches the specifications directly — it proposes actions, and the infrastructure permits or denies them.

Nothing in this architecture depends on the agent remembering anything.

What to Do​

For teams that have read the Laws post and the Layers post, specification engineering is the concrete next step. Here's the order:

1. Audit what's currently in the system prompt that should be infrastructure. Every constraint in your system prompt is a constraint with an expiration date. Identify the ones that must hold for longer than a single context window. Those are your specifications.

2. Choose a policy language. Cedar if you want formal verification and are in the AWS ecosystem. OPA/Rego if you're cloud-native and need ecosystem breadth. Microsoft's toolkit if you want to start open-source with multiple language support. All three are production-grade.

3. Move one constraint to the policy layer. Start with the simplest, most critical constraint — "agents may not access production databases directly" or "agents may not commit to the main branch without CI passing." Enforce it externally. Verify the agent respects it even after context compaction.

4. Build the concept registry. The agentic drift problem — parallel agents inventing competing abstractions — requires a shared vocabulary. This doesn't need to be a full knowledge graph on day one. It can be a YAML file listing the concepts that exist in your codebase and which module owns each one. The agent checks the registry before creating a new abstraction.

5. Add drift detection. Start with the simplest detector: Z-scores on tool-call distributions. If the agent's tool-use pattern shifts significantly week-over-week, something changed — either the task distribution or the agent's compliance.

6. Formalise the spec-before-prompt contract. The Laws post's third strategy: spec before you prompt. Encode this as infrastructure — the agent cannot start without a specification that passes the spec gate's completeness check.

The Through-Line​

The three posts form a single argument:

  1. The Laws Don't Break, They Shift — the forces that govern engineering teams didn't disappear with agents. They migrated to the specification, review, and comprehension layers.

  2. The Layers of Agentic AI Engineering — four levels of abstraction, each answering a different question. Specification engineering is the highest and least implemented.

  3. This post — specification engineering is not optional, not theoretical, and not waiting for tooling. The tooling exists. The governance decay research is the strongest evidence yet that context can't hold a rule for as long as the rule needs to matter. The only remaining question is whether you move your specifications to the infrastructure layer before or after the production incident that forces you to.

Specifications are the constitution of a nation of agents: intents are the laws enacted under it, context is their enforcement, and the prompt is a specific action in a specific situation. [1]

The organisations that build specification infrastructure now will compound that advantage. The ones that keep writing policies in system prompts will keep losing them to context compaction.

References​

// references
25 sources

  1. Vishnyakova, V. V. (2026). "Context Engineering: From Prompts to Corporate Multi-Agent Architecture." arXiv:2603.09619.

    ↗ Paper

  2. Tomašev, N., Franklin, M., & Osindero, S. (2026). "Intelligent AI Delegation." Google DeepMind. arXiv:2602.11865.

    ↗ Paper

  3. Chen (2026). "Governance Decay: How Context Compaction Silently Erases Safety Constraints in Long-Horizon LLM Agents." arXiv:2606.22528.

    ↗ Paper

  4. (2026). "AI Guardrail Survival under Single-Cycle Agentic Self-Summarization." arXiv:2608.11392.

    ↗ Paper

  5. AWS (2026). "Secure AI agents with Policy in Amazon Bedrock AgentCore."

    ↗ Article

  6. AWS (2026). "Enforce least-privilege authorization in multi-agent AI chains using Cedar."

    ↗ Article

  7. Microsoft (2026). "Introducing the Agent Governance Toolkit." Open-source, MIT license.

    ↗ Article

  8. Agent Patterns Catalogue (2026). "Policy-as-Code Gate."

    ↗ Pattern

  9. Armalo AI (2026). "Policy-as-Code for AI Agents."

    ↗ Article

  10. TokenJam (2026). "AI Agent Drift Detection."

    ↗ Article

  11. OSSA (2026). Open Standard Agents Specification v0.5.6.

    ↗ Specification

  12. Oracle (2026). Open Agent Specification.

    ↗ Repository

  13. Agentic App Spec (2026).

    ↗ Repository

  14. (2026). "Agent Behavioral Contracts: Formal Specification." arXiv:2602.22302.

    ↗ Paper

  15. Deloitte (2026). "State of AI in the Enterprise" (7th ed.). N=3,235, 24 countries.

    ↗ Report

  16. McKinsey (2026). "State of AI trust in 2026: Shifting to the agentic era." AI Trust Maturity Survey, ~500 organisations.

    ↗ Report

  17. McKinsey (2025). "The State of AI: Global Survey 2025." N=1,993.

    ↗ Report

  18. Gartner (2026). AI Agent Governance Report.

    ↗ Via CIO

  19. NIST (2026). AI Agent Standards Initiative.

    ↗ Initiative

  20. OWASP (2025). "Top 10 for Agentic Applications 2026." Released December 2025.

    ↗ Resource

  21. ISO/IEC 42001:2023. AI Management System Standard.

    ↗ Standard

  22. R Systems / Everest Group (2026). "Agentic AI 2026: A Mid-market Playbook."

    ↗ Via TechTarget

  23. COMPEL Framework (2026). "Industry Standards for Agentic AI."

    ↗ Article

  24. LatentMesh (2026). "Drift Detection Patterns for Production Agents."

    ↗ Article

  25. Flowlines (2026). "How to detect agent drift in production."

    ↗ Article