Knowledge Graphs vs. Skills Files: The End of Static Agent Configuration

Microsoft Agent 365 gives agents their own email addresses, OneDrive storage, and Teams identities. The Cloud Security Alliance's Agentic IAM framework proposes Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) for agent authentication. Google's Agent2Agent protocol uses "Agent Cards" as JSON-LD capability descriptors.

The industry is converging on a truth that should have been obvious from the start: agents are not scripts. Stop configuring them like scripts.

Yet the dominant pattern for agent configuration in 2026 remains the static skills file — AGENTS.md, capabilities.yaml, tool manifests — flat text files that enumerate what an agent can do, hand-maintained by developers, duplicated across every platform that deploys the agent.

This is Web 1.0 thinking applied to autonomous systems. It is time to end it.

The Duplication Problem

Here is a number from our analysis of production agent deployments: 40-60% of agent configuration is duplicated across platforms.

The same agent deployed across three orchestration platforms (say LangChain, CrewAI, and a custom framework) typically has three separate configuration files, each describing the same capabilities in slightly different formats, each maintained independently, each drifting out of sync with the others.

When an agent gains a new capability, someone has to update three files. When a governance constraint changes, someone has to update three files. When a tool is deprecated, someone has to update three files. In practice, "someone" means "nobody consistently," and the configuration files become unreliable within weeks.

Static configuration is a scaling trap. It works for 5 agents. It is painful for 50. It is impossible for 500. And production multi-agent systems are heading toward thousands.

Why AGENTS.md Is Antiquated

Let us be direct about this. The AGENTS.md pattern — a markdown file in a repository root that describes an agent's capabilities in prose — was a reasonable starting point. It gave humans a way to understand what an agent does. It was adopted by over 60,000 repositories.

But it has fundamental limitations:

It is not machine-readable in a meaningful way. Yes, an LLM can parse markdown. But parsing prose to extract structured capability data burns tokens — often thousands of tokens — for information that could be expressed in a 200-token structured format.

It is not discoverable. An AGENTS.md file exists in a git repository. There is no protocol for one agent to find another agent's AGENTS.md. There is no search. There is no federation. Discovery requires a human knowing where to look.

It is not verifiable. Anyone can claim any capability in a markdown file. There is no attestation, no signature, no trust chain. The file says the agent can process payments? You have to trust the author.

It is not dynamic. When an agent's capabilities change at runtime — when it learns, adapts, or gains access to new tools — the AGENTS.md file does not update. It is a snapshot of what the developer intended the agent to do, not what it can do right now.

Knowledge Graphs: Dynamic Capability Discovery

Knowledge graphs solve these problems architecturally. Instead of a flat file that lists capabilities, a graph encodes the relationships between capabilities, tools, agents, governance rules, and trust attestations.

Consider an agent that processes invoices. In an AGENTS.md file, this might be described as:

## Capabilities
- Invoice processing
- OCR extraction
- Data validation
- ERP integration

In a knowledge graph, the same agent's capabilities are encoded as a connected structure:

Agent invoice-processor → has_capability → invoice-processing
invoice-processing → requires_tool → ocr-engine-v3
invoice-processing → governed_by → pci-dss-policy
ocr-engine-v3 → attested_by → security-audit-2026-02
invoice-processing → compatible_with → sap-erp, netsuite, quickbooks
pci-dss-policy → restricts_data → credit-card-numbers

This graph is:

Machine-readable: Any agent can query it
Discoverable: DUADP federation makes it searchable across organizations
Verifiable: Trust attestations are first-class nodes, not prose claims
Dynamic: The graph updates as capabilities change

Qdrant: Semantic Search Over Capabilities

Knowledge graphs encode structure. Qdrant adds semantic understanding.

When an orchestrator needs "an agent that can validate European tax invoices against VAT regulations," a static registry requires an exact string match. A vector store enables semantic search — finding agents whose capability embeddings are closest to the query's meaning, even if the terminology does not match exactly.

This is the difference between searching a phone book and asking a knowledgeable colleague. The phone book requires you to know the exact name. The colleague understands what you need.

In practice, the combination works like this:

Semantic query via Qdrant: "I need invoice validation with EU VAT compliance" → returns top-5 candidate agents
Graph traversal: For each candidate, verify governance constraints, trust attestations, and capability dependencies
Selection: Choose the agent that best matches capabilities and passes trust/governance checks

This entire flow — discovery, verification, selection — happens in fewer tokens than parsing a single AGENTS.md file.

Multimodal Agent Configuration

Static files are text-only. Real agent capabilities are multimodal.

An agent that performs physical infrastructure monitoring (PID — Process and Instrumentation Diagrams) needs to understand images, sensor data streams, time-series databases, and 3D models. Its capabilities cannot be meaningfully described in a markdown file.

Knowledge graphs naturally accommodate multimodal capability descriptions. A node in the graph can reference an image schema, a sensor data format, a 3D model specification — anything the agent can process. Vector embeddings in Qdrant can encode multimodal representations, enabling discovery across data types.

Private access is another dimension that static files handle poorly. An agent may have capabilities that are only available to authorized callers — internal tools, sensitive data access, privileged operations. Knowledge graphs encode access control as graph relationships. OSSA manifests encode it as governance constraints. Static files just... do not.

The OSSA Manifest + DUADP Federation

The OSSA manifest is our answer to static configuration. It is a structured, versioned, validatable contract that encodes everything an AGENTS.md file tries to encode — but in a format that is machine-readable, discoverable, verifiable, and dynamic.

Combined with DUADP federation, OSSA manifests become nodes in a global capability graph. An agent registered with DUADP is not just described — it is indexed, searchable, and verifiable across organizational boundaries.

The architecture eliminates the duplication problem entirely. One manifest. One source of truth. Federated across every platform that supports DUADP. Updated dynamically as capabilities change.

Static files:    N platforms x M agents = N*M configuration files
OSSA + DUADP:     M agents = M manifests (federated everywhere)

For an organization with 100 agents across 5 platforms, that is the difference between maintaining 500 configuration files and maintaining 100 manifests. At 1,000 agents, it is 5,000 vs 1,000. The math only gets more favorable at scale.

The Path Forward

The transition from static files to graph-native agent configuration will not happen overnight. AGENTS.md files will coexist with OSSA manifests for years. That is fine — the OSSA specification includes migration tooling (ossa migrate) specifically for this transition.

But the direction is clear. Static configuration is a dead end. The agents of 2028 will not be configured by markdown files any more than the websites of 2010 were configured by static HTML pages hand-uploaded via FTP.

Knowledge graphs, vector stores, and structured manifests are not future technology. They are available today. The question is not whether to adopt them, but how quickly.

Start with the OSSA specification. Explore DUADP. Read our research on token-efficient agent architecture. The tools exist. The standards are forming. The static file era is ending.