Santander AI Lab introduces A2K (Agent-to-Knowledge), a transport-neutral protocol suite that lets enterprise AI agents discover, select, query, cite, audit, and reconcile knowledge bases, with scoped authority, lifecycle management, authorization-safe discovery, cited responses, and optional regulated controls. A2K runs over the transports you already use (MCP, A2A, and HTTPS) and is published as an open specification with reference Python packages.
In the current state of the art, context management is the key to agentic solutions. Most organizations face the same challenge: turning their scattered data into knowledge bases that agents can use, in context, safely. As agents move from demos into daily processes, one question keeps coming back: how does an agent find the right information, at the right time, while respecting the company's access, governance, and audit policies?
Most current architectures connect models to tools, databases, or applications in a vertical, static way. An agent is wired to a fixed set of knowledge bases by configuration, and at query time those connections can't be extended to other knowledge bases. There's no standard way to cite where an answer came from, no standard way to guarantee an answer is grounded in the original information, and no standard way to govern and audit what agents produce.
Few architectures address the most fundamental problem of all: trust in knowledge. Knowing where to search does not tell you which knowledge base is authoritative, whether the information is still current, or whether the person behind the query is even allowed to see it.
When knowledge becomes an architecture problem
If the Internet needed DNS to scale how we locate information, enterprise agent ecosystems may need a standard like A2K to scale how we trust it.
In a modern enterprise, knowledge is spread across SharePoint, Confluence, Notion, Jira, GitHub, ServiceNow, corporate portals, regulatory repositories, data catalogs, and support platforms. Every one of these may contain valid information, but they do not all carry the same authority.
An agent asking a single question might retrieve three documents that all seem to answer it:
- an official policy published by the corporate department.
- a local adaptation created by one team.
- an old presentation from a historical project.
Technically, all three are retrievable. From a business perspective, only one should be treated as the reference knowledge base. That gap between finding information and finding the right information is exactly what A2K exists to close.
A2K borrows its shape from one of the most successful designs on the Internet: the combination of DNS and HTTP. A browser first resolves where a site lives, then consumes its content. A2K applies the same two-step idea to corporate knowledge:
| Internet | DNS | IP address → HTTP | content |
| A2K | KRP Knowledge Resolution Protocol | KB Card → KCP Knowledge Consumption Protocol | cited response |
The crucial difference: resolution doesn't depend on a name alone, but on who is asking and what they're allowed to see. Two employees can ask exactly the same question and legitimately receive different sets of knowledges bases, because their authorizations differ. Discovery becomes governed from the very first step.
Three building blocks
A2K's contribution is not to improve how agents talk, it's to improve how they justify what they say.
A2K-Resolve - discover trustworthy knowledge bases
A2K-Knowledge Resolution Protocol works like an intelligent corporate catalog. When an agent receives a question, it does not go straight to documents. It first asks which knowledge bases are relevant to the query's context. The result isn't an answer, it's a list of authorized, validated candidates. Its responsibilities include knowledge bases discovery, permission filtering, authority evaluation, conflict detection, and enforcement of corporate policy.
One property matters above all: a knowledge base cannot declare itself official. Authority is asserted by the catalog through corporate governance, never self-promoted by a knowledge base.
The Enterprise KB Card — the identity of a knowledge base
The Enterprise KB Card is the heart of A2K: think of it as a knowledge base's ID document. It describes functional scope, the accountable owner, review status, access rules, conformance level, supported capabilities, regulatory policies, and audit mechanisms. Thanks to the card, an agent can understand what a knowledge base represents before it ever queries it, and it's what lets the ecosystem grow in a federated way without losing governance.
A2K-Knowledge Consumption — query with evidence
Once a knowledge base is selected, A2K-Knowledge Consumption Protocol defines how an agent consumes it. The difference from ordinary search is that the result is not just generated text. Every response carries evidence, citations, traceability, freshness metadata, an access decision, and audit information. In other words, the answer and the justification for the answer travel together, so everyone can later reconstruct exactly what the agent used and why it reached a given conclusion.
Design decisions that make the difference
Trust in enterprise agents depends on the quality, authority, traceability, and governance of the knowledge they use.
- Resolution and consumption are separate concerns. Discovering knowledge bases and querying them have different operational profiles. Separating them simplifies evolution and strengthens governance.
- Knowledge is contextual. Answers depend on the user the agent represents, so resolution is tied to On-Behalf-Of (OBO) context, preventing an agent from becoming an indirect path to privilege escalation.
- Authority is a corporate capability. Deciding which system is the reference for a domain stops being a local configuration detail and becomes an explicit, owned enterprise responsibility.
- Conflicts are information. When knowledge bases contradict each other, A2K doesn't hide the discrepancy, it surfaces it as a governance signal that deserves attention.
- Adoption can be progressive. Not every organization needs the same level of control, so A2K defines five conformance levels -from simply registering a knowledge base (Level 0) all the way to fully verifiable, regulated knowledge bases (Level 4)- plus security tiers derived from data classification, so protection scales with the sensitivity of the data rather than with feature maturity.
Complementary to MCP and A2A — not a replacement
A2K does not compete with the protocols you're already adopting. MCP and A2A have proven essential for connecting tools and coordinating agents. A2K sits in a different layer:
- MCP answers: How do I technically access a knowledge base?
- A2A answers: How do several agents collaborate?
- A2K answers: Which knowledge base should I use, why can I trust it, and how do I prove it?
That clean separation of responsibilities improves interoperability and avoids reinventing capabilities that already exist. A2K is MCP-compatible, not MCP-competitive, and A2A-compatible, not an A2A replacement. It layers on both.
The next generation of corporate platforms won't be defined solely by more powerful models. It will be defined by ecosystems of agents reasoning over distributed, governed, and regulated knowledge. In that world, the quality of an answer will depend less on raw generation and more on the ability to identify reliable knowledge bases, respect permissions, cite evidence, and maintain complete traceability.
An example and how to test it
“What is the current policy for using generative AI with customer information?”
Without A2K, an agent might pull documents from several areas, blend partially outdated material, and produce an answer that looks right but is hard to validate.
With A2K, the flow is different: the agent calls A2K-Resolve. The catalog identifies the authorized knowledge bases. It determines which one is the system of record for that policy. The user's access level is verified. The agent queries the correct knowledge base via A2K-Knowledge. Finally, the answer arrives with citations, document versions, references, and evidence. If knowledge bases disagree, the response says so explicitly. The result is far closer to the rigor expected in critical business processes.
A2K is being released as an open specification with reference implementations:
- Specs: The normative specs: A2K-Overview, A2K-KBCard-Schema, A2K-KRP (resolution), and A2K-KCP (consumption). https://github.com/SantanderAI/a2k/tree/main/specs
- Packages: Transport-agnostic Python packages (a2k_kbcard, a2k_krp, a2k_kcp) shipping the wire models and interfaces. A service becomes A2K-conformant by implementing the interfaces and binding them to its own transport and backend. https://github.com/SantanderAI/a2k/tree/main/src
- Examples: A set of examples implementing the protocol for enabling engineers to understand the protocol. https://github.com/SantanderAI/a2k-examples
A recommended rollout keeps the barrier low: directly integrate an agent with a conformant knowledge base, then stand up a catalog, register existing knowledge bases (cards only) to light up collision and orphan detection with zero endpoint work, then add authorization-scoped discovery, cited retrieval on your highest-value knowledges bases, and regulated controls only where they're required.
