---

Why This Domain Model Matters

The Proliferation Problem

The velocity of AI tool development has outpaced the velocity of standardization. Every major platform — IDEs, agent frameworks, consumer AI products, cloud orchestration layers — has shipped its own conventions for configuring agents, encoding capabilities, managing memory, and routing tasks. The result is an ecosystem of deeply capable but structurally isolated AI assets: agent definitions, skill packages, memory stores, routing policies, and workflow specifications that exist in one vendor's format and cannot be meaningfully transported to another.

This is not theoretical. It is already materializing:

• Lock-in at the knowledge layer. Teams investing in agent configuration for one tool (Cursor rules, Kiro steering files, CrewAI YAML) accumulate context that is not portable to the next generation of tools. When a better tool emerges — or a vendor pivots, is acquired, or discontinues a product — that accumulated intelligence is stranded.
• Orchestration fragility. Multi-agent systems built on framework-specific coordination patterns (LangGraph edges, CrewAI crews, AutoGen GroupChat) cannot interoperate with agents built on other frameworks, even when those agents perform complementary functions.
• Memory amnesia across tool boundaries. An agent's working context, session history, and long-term knowledge exist in incompatible formats. As of mid-2026 there is still no ratified standard for exporting memory state from one system and importing it into another — academic proposals exist (see Concept 06) but no production standard.
• Compounding duplication costs. Without portability, teams rebuild equivalent configurations for every new tool. The cost is not just engineering time — it is the loss of accumulated prompt engineering and behavioral tuning that makes an agent useful.
• Governance blind spots. Safety constraints, approval gates, permission scopes, and audit trails are implemented per-platform. A security posture established in one system does not transfer — a compounding compliance risk as the EU AI Act's high-risk obligations take effect (August 2, 2026) and NIST's AI Agent Standards Initiative (launched February 2026) begins to shape expectations.

Why a Stable Ontology is the Foundation

Before standards can converge, the industry needs agreement on what needs standardizing. The proliferation of competing formats (AGENTS.md, .cursorrules, Kiro steering, CrewAI YAML, Strands decorators) is partly a symptom of different tools solving different subsets of one larger problem space without shared vocabulary for the shape of that space.

A stable ontology — a structured map of the distinct concern areas agent configuration must address — serves four purposes:

1. Monitoring surface. A consistent framework for tracking which standards exist, how mature they are, and which tools implement them — instead of tool-by-tool changelog reading.
2. Architecture guidance. Future-facing architecture means betting on standards-aligned primitives over proprietary ones. The ontology shows where stable bets exist (MCP, A2A, SKILL.md, OTel GenAI) and where you must still accept proprietary lock-in (memory, routing policy, approval gates).
3. Gap identification. Several concepts have no emerging standard. Identifying these is the first step toward either building proprietary bridges designed to be replaced or contributing to the standards process.
4. Fungibility by design. AI assets are interchangeable across platforms only if they conform to shared formats. The ontology defines the scope of what "fungible AI assets" means in practice.

The central thesis: organizations treating AI configuration as ephemeral, tool-specific work are accumulating technical debt at an accelerating rate. Those who invest now in standards-aligned, portable AI asset design will hold a compounding advantage as the ecosystem matures.

---

Ontology Summary — The 12 Concepts

The ontology maps the complete problem space of configuring, encoding, and operating intelligent agents into 12 concepts, grouped into four thematic clusters. Concepts are technology-neutral — they describe what must be addressed, not how any tool addresses it.

AI Agent Configuration Ontology (12 concepts)

CLUSTER A — IDENTITY & CAPABILITY

• 01: Agent Identity & Persona
• 02: Skill / Capability Definition
• 03: Tool Integration Protocol
• 07: Agent Manifest / Config

CLUSTER B — COORDINATION & STATE

• 04: Inter-Agent Communication
• 06: Memory Architecture
• 08: Model Selection & Routing
• 12: Knowledge & RAG Integration

CLUSTER C — EXECUTION & WORKFLOW

• 05: Lifecycle Event Hooks
• 11: Spec-Driven Development

###CLUSTER D — TRUST & OPERATIONS

• 09: Observability & Telemetry
• 10: Guardrails & Safety Constraints

---

Domain Maturity Overview

Maturity is assessed on two axes:

• Standards Coverage — How much of the concept's scope is addressed by published or emerging standards (formal or de-facto).
• Tool Adoption — How broadly those standards are implemented across leading consumer and developer AI tools.

Scale: ○ None · ◔ Minimal · ◑ Partial · ◕ Strong · ● Full

The standards frontier in one sentence: The tool and capability layer (02, 03) is solved; the coordination layer (04, 09, 10) is actively maturing under foundation governance; the spec-content sub-layer of execution (11's notations — EARS, RFC 2119, ADR/MADR) is quietly already portable; and the remaining state, execution-workflow, and policy concerns (05, 06, 08, and 11's workflow layer) stay proprietary — which is where portable-architecture discipline matters most today.

---

Concept Deep Dives

For each of the 12 concepts, here is a deeper dive into the current state of industry standards and proprietary solutions.

01 — Agent Identity & Persona

Cluster: Identity & Capability · Maturity: Consolidating (◕ / ◕)

Scope. Everything that defines who an agent is and how it behaves absent any specific task — name, role, goals, tone, behavioral constraints, and the persistent project-scoped rules that shape outputs across all interactions.

Why it matters for portability. Persona and behavioral rules are often the most labor-intensive AI asset a team creates, representing hundreds of prompt-engineering iterations. Without a portable format this investment is stranded in one tool's configuration syntax.

Standards & solutions.

Tool leaders. Claude Code and OpenAI Codex CLI (AGENTS.md originators/strongest), Amazon Kiro (richest steering model with inclusion modes), Cursor and Cline (compatible).

Research signal. Empirical work (Gloaguen et al., 2026, across 138 repositories) found that LLM-generated context files reduce agent success rates by ~2% and inflate cost by ~23%, because agents follow generated instructions faithfully and over-explore. Human-written, minimal, non-obvious context files are the only ones that help — a strong argument for treating AGENTS.md as a deliberately curated asset, not an auto-generated one.

Sub-concepts.

• 01.a — Persona & role definition. Natural-language identity (role, goal, backstory, tone). De-facto: AGENTS.md. developers.openai.com/codex
• 01.b — Behavior steering & inclusion modes. When and how rules load (always-on vs. conditional vs. triggered) and how conflicts resolve. Most mature: Kiro inclusion modes. kiro.dev/docs/steering

---

02 — Skill / Capability Definition

Cluster: Identity & Capability · Maturity: Established (● / ◕)

Scope. Modular, reusable, portable packages that encode specialist knowledge, tool procedures, and output formats — loaded on demand without consuming context when idle.

Why it matters for portability. Skills are the highest-value reusable AI asset. A skill built once — encoding how to use an API, produce a document format, or follow a coding convention — should deploy across any agent, any tool, any session unchanged. SKILL.md delivers exactly this and is the strongest single signal that the ecosystem is maturing.

Standards & solutions.

Architecture. A skill is a directory: a required SKILL.md (YAML frontmatter with name + description, plus a Markdown body) and optional scripts/, references/, and assets/ folders. Progressive disclosure loads metadata first (~30–50 tokens/skill), the full body on trigger match (median ~1,414 tokens per Bosch/CMU analysis of 40,000+ skills), and scripts/assets only on execution — letting an agent hold hundreds of skills without context exhaustion.

Tool leaders. Claude Code (originator), then per the spec's own adoption list: OpenAI Codex CLI, Google Gemini CLI, GitHub Copilot (via VS Code agent skills), Cursor (manual placement), Cline, Windsurf, OpenCode. Launch-partner skills came from Atlassian, Figma, Stripe, and Notion. Kiro added SKILL.md support February 5, 2026.

Sub-concepts.

• 02.a — Skill packaging & progressive disclosure. The directory format and three-tier loading model. agentskills.io · github.com/agentskills/agentskills
• 02.b — Skill distribution & discovery. Registries and package-style install (npx skills add ...). No formal registry standard yet; de-facto registries emerging.

---

03 — Tool Integration Protocol

Cluster: Identity & Capability · Maturity: Established (● / ●)

Scope. The standardized wire protocol by which an agent invokes external tools, APIs, file systems, and live data — discovering tools at runtime, calling them with structured parameters, and receiving structured results.

Why it matters for portability. MCP is the "USB-C of AI": one protocol replacing bespoke per-tool integration code. A tool exposed as an MCP server works with any MCP-compatible host (Claude, Cursor, Kiro, Codex, Gemini), making the integration itself a fungible asset.

Standards & solutions.

Architecture. Client-server over JSON-RPC 2.0. A host (Claude Desktop, Cursor, Kiro) instantiates an isolated MCP client per server; servers expose tools, resources, and prompts. Transports: stdio (local), Streamable HTTP + OAuth 2.1 (remote). The 2026 roadmap (published March 2026) prioritizes transport scalability behind load balancers, agent-to-agent communication, governance, and enterprise readiness (audit trails, SSO).

Tool leaders. Universal among serious tools: Claude Code, Cursor, Windsurf, Cline, VS Code + Copilot, Codex CLI, Kiro, Strands SDK, plus consumer hosts (Claude Desktop, ChatGPT, Gemini).

Sub-concepts.

• 03.a — Tool invocation & discovery. Runtime tool listing and structured calls. modelcontextprotocol.io
• 03.b — Resource exposure. Servers exposing data/knowledge as addressable resources (also underpins Concepts 06 & 12). spec.modelcontextprotocol.io/.../resources
• 03.c — Dynamic tool loading. Loading only relevant tools to conserve context (Kiro POWER.md; MCP roadmap item).

---

04 — Inter-Agent Communication

Cluster: Coordination & State · Maturity: Maturing (◕ / ◑)

Scope. How agents discover peers, advertise capabilities, delegate tasks, and exchange structured results across framework or vendor boundaries.

Why it matters for portability. Multi-agent value scales with composability. A research agent (CrewAI) should hand off to a code agent (Strands) and a review agent (LangGraph) without any knowing the others' internals. A2A is the first serious cross-vendor answer; MCP handles the complementary agent-to-tool layer.

Standards & solutions.

Architecture. A2A uses a client-remote model over HTTP + Server-Sent Events + JSON-RPC 2.0. Agent Cards advertise capabilities; Tasks carry a defined lifecycle (submitted → working → input-required → completed / failed / canceled / rejected). MCP and A2A are explicitly complementary: MCP = agent↔tool, A2A = agent↔agent. In practice an agent accesses its own tools via MCP, then delegates to peers via A2A.

Tool leaders. Google Gemini / Cloud (originator), Amazon Bedrock AgentCore & Amazon Q (native), CrewAI (v1.14+ A2A support), OpenClaw (typed Message Bus with @mention routing).

Sub-concepts.

• 04.a — Agent discovery & capability advertisement. A2A Agent Cards. a2a-protocol.org
• 04.b — Task delegation & lifecycle. Message format + task states. github.com/a2aproject/A2A
• 04.c — Coordination patterns. Sequential / hierarchical / parallel / consensus / swarm. No standard taxonomy — framework-specific vocabulary only.

---

05 — Lifecycle Event Hooks

Cluster: Execution & Workflow · Maturity: Nascent (◔ / ◑)

Scope. Callbacks fired at defined moments in an agent's execution — spawn, pre/post tool use, prompt submit, stop — used for audit logging, approval gates, auto-formatting, and cost control.

Why it matters for portability. Hooks encode critical control logic. Implemented in platform-specific syntax, they must be rebuilt on every tool migration. There is no cross-tool hook standard — this is one of the clearest unstandardized gaps in the ontology.

Standards & solutions.

Tool leaders. Amazon Kiro (definitive), Claude Code, Strands SDK.

Note. Kiro's preToolUse with exit-code-2 blocking is the closest thing to architecturally enforced gating in a mainstream tool — guardrails as infrastructure rather than prompt compliance. This pattern has no portable standard.

Sub-concepts.

• 05.a — Tool-use hooks. Pre/post tool interception (audit, format, block). kiro.dev/docs/hooks
• 05.b — Session lifecycle hooks. Spawn / prompt-submit / stop. Proprietary per platform.

---

06 — Memory Architecture

Cluster: Coordination & State · Maturity: Nascent (◔ / ◑)

Scope. What an agent remembers across the immediate task (working memory), within a session (episodic), and across all sessions over time (long-term / semantic / procedural). The most consequential portability gap: memory cannot be exported and re-imported across tools.

Why it matters for portability. Memory is where compounding AI value lives. An agent that has processed thousands of documents and learned from hundreds of corrections holds enormous accumulated value. If that cannot be exported, switching cost grows unbounded over time.

Standards & solutions.

Tool leaders. OpenClaw and CrewAI (built-in tiered memory), Mem0/Letta/Zep (dedicated layers), Claude.ai Projects (persistent project context), Google Gemini (Memory Bank).

Open problems (mem0 State-of-Memory 2026). Cross-session identity resolution (anonymous/multi-device users break the user_id assumption); memory staleness (a high-relevance fact becomes confidently wrong when reality changes); embedding drift on model upgrades. None have standard solutions.

Sub-concepts.

• 06.a — Working memory (active context). Context-window composition and dynamic load/unload. Best answered by SKILL.md progressive disclosure (Concept 02).
• 06.b — Episodic memory (session state). Turn-to-turn history and scratchpad. Mostly ad-hoc in-memory objects; no standard.
• 06.c — Long-term / semantic memory. Cross-session facts, preferences, learned workflows. De-facto: Mem0 / Letta / Zep; no portable format standard. mem0.ai/blog/state-of-ai-agent-memory-2026
• 06.d — Procedural memory. Stored multi-step workflows/skills the agent has learned. Overlaps Concept 02; no standard.

---

07 — Agent Manifest / Config

Cluster: Identity & Capability · Maturity: Emerging (◑ / ◑)

Scope. The machine-readable file fully describing an agent to a host — allowed tools, permitted paths, model selection, resource references, and lifecycle hooks. The manifest is the portability primitive: if multiple hosts can read it, the agent is portable.

Why it matters for portability. Persona (Concept 01) is the human-readable half; the manifest is the machine-readable half. Today every platform has its own manifest format, so a fully-specified agent is locked to its host. A2A Agent Cards standardize capability advertisement but not full configuration.

Standards & solutions.

Tool leaders. Amazon Kiro (most complete manifest), OpenClaw (typed declarative manifest), CrewAI (role-based YAML).

Sub-concepts.

• 07.a — Capability advertisement. What an agent exposes to peers/orchestrators. A2A Agent Cards. a2a-protocol.org/.../agent-cards
• 07.b — Resource & permission binding. Tools, paths, knowledge bases, model an agent may use. Most complete: Kiro. kiro.dev/.../configuration-reference

---

08 — Model Selection & Routing

Cluster: Coordination & State · Maturity: Nascent coverage, strong practice (◔ / ◕)

Scope. Rules and runtime policies determining which LLM (provider, model, parameters) serves a given agent role or task type — the basis for cost/quality optimization across a multi-agent workflow.

Why it matters for portability. Routing logic — "Sonnet for architecture, a cheaper model for bounded execution" — is valuable accumulated tuning. There is no policy-language standard; every framework expresses routing in proprietary config, so the logic is stranded on migration. The market is, however, converging on the AI gateway as the practical enforcement point.

Standards & solutions.

Tool leaders. Amazon Strands (full Bedrock multi-model), AI gateways (Bifrost/LiteLLM, cross-provider), CrewAI (per-agent), Kiro (task-type routing).

Sub-concepts.

• 08.a — Per-agent / per-task model assignment. Static routing in agent config. Proprietary.
• 08.b — Gateway routing & failover. Runtime routing, fallback, budget control at a gateway. De-facto via OpenAI-compatible APIs; no formal standard.

---

09 — Observability & Telemetry

Cluster: Trust & Operations · Maturity: Maturing (◕ / ◑)

Scope. Structured traces capturing every model call, tool execution, and reasoning step; token accounting; cost attribution across (and within) agents; and audit logs for compliance.

Why it matters for portability. If observability uses vendor-proprietary telemetry, switching platforms loses historical execution data and the institutional knowledge of how your agents behave. Instrumenting to a vendor-neutral standard keeps the migration door open — re-point the exporter instead of re-instrumenting every agent.

Standards & solutions.

Maturity nuance. Six GenAI convention layers now exist (LLM calls, agent orchestration, MCP tool calling, content capture, quality evaluation, plus base metrics), but the conventions remain experimental — OTEL_SEMCONV_STABILITY_OPT_IN enables dual-emission during the transition. Critically, OTel is a data plane only: it records that a call returned 1,200 tokens in 850 ms but cannot score whether the output was faithful or safe — that needs a separate evaluation layer (Concept 10).

The cost-attribution gap. When an agent spawns sub-agents, token cost is lost across the boundary. There is no standard for propagating cost metadata through A2A calls — a named gap with no current answer.

Tool leaders. Amazon Kiro / Strands (CloudWatch + Bedrock native), Langfuse (OTel-aligned OSS), CrewAI AMP, Microsoft Copilot (Azure Monitor).

Sub-concepts.

• 09.a — Execution tracing & spans. Hierarchical spans per call/tool/sub-agent. opentelemetry.io/.../gen-ai
• 09.b — Cost attribution & token accounting. Per-task/agent/user cost. Single-call only in OTel; multi-agent attribution unstandardized.
• 09.c — Audit & compliance logging. Tamper-evident decision logs. OTel logs (base) + MCP 2026 audit-trail working group (planned).

---

10 — Guardrails & Safety Constraints

Cluster: Trust & Operations · Maturity: Maturing (◑ / ◕)

Scope. Runtime controls that filter, scope, gate, and govern what agents may do — content policies, permission scoping, prompt-injection defense, PII redaction, human-in-the-loop approval, and inter-agent trust.

Why it matters for portability. Safety posture does not transfer between platforms. Carefully tuned filters, path restrictions, and approval gates must be rebuilt on every migration — perpetually the most expensive migration cost. Two forces are pushing toward shared taxonomies (not yet portable enforcement): the EU AI Act high-risk obligations (from August 2, 2026) and NIST's AI Agent Standards Initiative (February 2026).

Standards & solutions.

The shape of the gap. Risk taxonomies (OWASP) and governance frameworks (NIST, EU AI Act) are consolidating fast. What is missing is a portable policy language — a way to express "this agent may do X but not Y" once and enforce it across platforms. Enforcement today is gateway-level (proprietary) or platform-native (Bedrock/Azure). Agentic guardrails (controlling tool use, inter-agent messages, and goal pursuit) are explicitly emerging but unstandardized.

Tool leaders. Anthropic Claude (Constitutional AI baseline), Amazon Bedrock / Kiro (most configurable enterprise guardrails + exit-code-2 hard gating), GitHub Copilot (enterprise filtering), Character.ai (consumer safety).

Sub-concepts.

• 10.a — Content policy & output filtering. Block/redact harmful or policy-violating output. Bedrock Guardrails
• 10.b — Permission scoping & access control. Least-privilege over tools/paths/data. Kiro allowedTools/allowedPaths; MCP Authorization; OAuth 2.1.
• 10.c — Human-in-the-loop & approval gates. Pause → present → proceed/abort for high-risk actions. Ad-hoc (filesystem gates, MCP prompts, platform UIs); no protocol standard.
• 10.d — Risk taxonomy & governance mapping. OWASP LLM/Agentic Top 10; NIST AI RMF; EU AI Act. owasp.org · nist.gov

---

11 — Spec-Driven Development

Cluster: Execution & Workflow · Maturity: Emerging (◑ / ◑)

Scope. Producing structured planning documents (proposal/requirements → design → tasks) before execution — concentrating reasoning into a planning phase that yields durable, inspectable, version-controlled artifacts, then executing within bounded scope against them. This concept decomposes into four distinct standardization layers, treated separately below because each sits at a different maturity.

Why it matters for portability. Spec artifacts are durable, high-value assets encoding intent, architecture, and rationale. The good news for portability: the underlying artifact formats are mostly plain Markdown plus a small number of tool-agnostic notations (EARS, RFC 2119, BDD, ADR/MADR) — so these assets are far more fungible than, say, memory stores. The fragmentation is at the workflow/orchestration layer (which CLI, which slash commands, which folder topology), not at the content layer. A requirements.md written in EARS is readable by Kiro, Spec Kit, OpenSpec, or a human regardless of which tool produced it.

---

Layer 1 — Workflow frameworks (the orchestration layer)

The competing, partially-adopted frameworks that define the process — folder topology, phase sequence, slash commands. This is where the real fragmentation lives, yet all four converge on the same artifact vocabulary.

Convergence signal. Despite four different CLIs, the artifact vocabulary has effectively standardized on (constitution|project) + (proposal/requirements/spec) + design + tasks. OpenSpec and Spec Kit both explicitly position against Kiro's IDE lock-in and converge on portable Markdown. The pattern emerging across all of them: a project constitution / project.md (durable principles) feeds a per-change spec set, and an AGENTS.md (Concept 01) acts as the "README for robots" that lets even non-integrated tools follow the workflow.

---

Layer 2 — Planning-artifact structure (the document layer)

The shape of the individual documents. No single ratified standard, but strong de-facto convergence:

• constitution.md / project.md — durable, non-negotiable project principles (Spec Kit's constitution.md; OpenSpec's project.md). Spec Kit's nine-article constitution model is the most formalized.
• requirements.md / spec.md — user stories + acceptance criteria + scope (in/out). De-facto content via EARS + RFC 2119 + BDD (Layer 3).
• design.md — technical approach, data models, sequence diagrams (mermaid), and embedded architecture decisions (Layer 4). This is the practical home of what is sometimes called adl.md (architecture description) — in current practice it's design.md + embedded ADRs rather than a separate ratified ADL file.
• tasks.md — discrete, ordered, trackable tasks with dependency ordering and parallel-execution markers ([P] in Spec Kit).
• delta specs (OpenSpec) — ## ADDED / MODIFIED / REMOVED Requirements — a notable brownfield innovation specifying changes rather than restating the whole spec; the closest thing to a portable change-format convention in the domain.

---

Layer 3 — Requirements notation (the content-format layer — the most portable part)

Mature, tool-agnostic notations that predate the AI-agent era and travel cleanly across every framework:

Adoption signal. Kiro generates requirements.md natively in EARS. OpenSpec uses RFC 2119 keywords + Given/When/Then scenarios as its core requirements grammar. Spec Kit does not mandate EARS by default — and there is an open feature request (spec-kit issue #1356, Dec 2025) to integrate EARS, itself evidence that EARS is becoming the expected requirements notation across the ecosystem. This layer is where portability is strongest: an EARS requirement is framework-neutral by construction.

---

Layer 4 — Decision records (the rationale layer)

Capturing why architectural choices were made — the most mature and longest-standardized layer in the entire ontology:

Adoption signal. Kiro's design.md embeds ADRs, and a steering instruction like "generate ADRs for significant architectural choices" reliably produces them. ADR/MADR is the one layer here with a real versioned spec and a dedicated standards organization — fully portable, plain-Markdown, AI-tool-independent.

---

Tool leaders. GitHub Spec Kit (broadest cross-agent reach, formal constitution model), OpenSpec (lightest, brownfield delta-spec innovation, strongest portability stance), Amazon Kiro (deepest single-IDE integration: native EARS + embedded ADRs + phase gates), BMAD (richest open multi-agent methodology).

The honest gap. What does not yet exist is a single ratified, neutrally-governed, end-to-end SDD standard that fixes the workflow layer (Layer 1) the way MCP fixed tool integration. Content layers 3 and 4 are effectively solved and portable; the artifact layer (2) is converging; the workflow layer (1) remains a three-to-four-way de-facto contest. This is the precise whitespace where a community standard — or a contribution bridging the BMAD / Spec Kit / OpenSpec / Kiro artifact formats — would have the highest leverage.

Sub-concepts (consolidated).

• 11.a — Workflow framework & folder topology. Spec Kit / OpenSpec / Kiro / BMAD. Converging vocabulary, fragmented orchestration. github.com/github/spec-kit · openspec.dev · kiro.dev/docs/specs · github.com/bmad-code-org/bmad-method
• 11.b — Requirements notation. EARS + RFC 2119 + BDD. Mature, portable, framework-neutral. alistairmavin.com/ears · RFC 2119
• 11.c — Decision records. ADR (Nygard) / MADR v4. Most mature layer; versioned spec + standards org. adr.github.io · adr.github.io/madr
• 11.d — Change / delta specification. OpenSpec delta specs (ADDED/MODIFIED/REMOVED). Notable brownfield-portable innovation. github.com/Fission-AI/OpenSpec

---

12 — Knowledge & RAG Integration

Cluster: Coordination & State · Maturity: Emerging (◑ / ◕)

Scope. Retrieval-augmented context from codebases, docs, or vector stores — indexed, scoped, and injected at query time so an agent supplements training data without pre-loading all possible context. Overlaps Concept 06.d (semantic memory).

Why it matters for portability. Indexed knowledge bases are expensive to build and tune (chunking, embeddings, retrieval thresholds). With no standard for index format, chunking strategy, or retrieval API, a knowledge base is locked to its platform. MCP Resources is the nearest portability bridge — a knowledge store exposed as MCP resources is reachable by any MCP-compatible agent.

Standards & solutions.

Maturity nuance. Retrieval backends have converged on hybrid vector+graph; what remains unstandardized is the format — chunking, index schema, and retrieval API differ per platform. No cross-tool standard exists for moving an indexed corpus between systems.

Tool leaders. Perplexity (RAG is its entire product — the retrieval depth leader), Amazon Kiro (auto-indexed knowledge bases), Bedrock Knowledge Bases, GitHub Copilot / Gemini (codebase + web retrieval).

Sub-concepts.

• 12.a — Retrieval integration. How indexed knowledge is queried and injected. Partial: MCP Resources. spec.modelcontextprotocol.io/.../resources
• 12.b — Index & chunking format. Corpus structure for retrieval. No standard — proprietary per platform.

Appendix A — Standards Bibliography

Standards, specifications, frameworks, and notable academic proposals referenced above. Grouped by ontological cluster, sorted by first-published date.

Capability & Tool Integration (Concepts 02, 03, 12)

Identity, Manifest & Behavior (Concepts 01, 07)

Inter-Agent Communication (Concept 04)

Memory (Concept 06)

Execution & Lifecycle (Concept 05)

Spec-Driven Development (Concept 11)

Layer 1 — Workflow frameworks

Layer 3 — Requirements notation

Layer 4 — Decision records

Observability (Concept 09)

Safety & Governance (Concept 10)

Transport & Authentication (cross-cutting — Concepts 03, 04, 10)

---

Governance Consolidation Note

A defining structural development of 2025–2026 is the consolidation of the core agent-configuration standards under neutral foundation governance. The Agentic AI Foundation (AAIF) — a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI in December 2025 — now governs MCP (03), A2A (04), AGENTS.md (01), and the Agent Skills / SKILL.md standard (02). This means the four most portable, best-adopted concepts in the ontology are no longer single-vendor projects.

The concepts that remain outside foundation governance — memory (06), lifecycle hooks (05), model routing (08), the workflow layer of spec-driven development (11), and portable guardrail policy (10) — are precisely where portable-architecture discipline carries the highest payoff today.

One important nuance on Concept 11. Spec-driven development is not a uniform gap. Its content layers are already portable: the EARS requirements notation (Rolls-Royce, 2009), RFC 2119 keywords (IETF, 1997), BDD Given/When/Then, and the ADR/MADR decision-record formats (MADR v4.0.0, 2024) are mature, plain-Markdown, AI-tool-independent standards that travel cleanly across Spec Kit, OpenSpec, Kiro, and BMAD. What is not yet standardized — and not foundation-governed — is the workflow/orchestration layer: the folder topology, phase sequence, and slash-command surface, where Spec Kit, OpenSpec, Kiro, and BMAD form a three-to-four-way de-facto contest. The practical takeaway: author spec content in the portable notations now (low risk, high reuse), but treat the workflow framework choice as a still-volatile bet — and the single highest-leverage place a neutral standard (or a format-bridging contribution) could land.

---

This document reflects published and draft standards as of June 2026. The landscape is evolving rapidly; the MCP 2026 roadmap, the OTel GenAI conventions' path to stable status, NIST's AI Agent Standards Initiative, and the EU AI Act's August 2026 high-risk deadline are all active and will materially change several maturity ratings within the year.