Retrieval-Augmented Generation became a standard way to connect enterprise data to language models, and for good reason. But as enterprises move from AI assistants toward autonomous, multi-step agents, a harder problem is surfacing: finding relevant information is not the same as constructing the context an AI system needs to operate.
Models have general knowledge; enterprise applications depend on information that changes continuously — documentation, policies, customer records, product data, specifications, operational state and proprietary business knowledge. RAG brings that information into the model's context. The open question is what constructs the context in which that knowledge should be used.
If RAG retrieves knowledge, what constructs the context in which that knowledge should be used?
What RAG actually solves
The basic RAG architecture is powerful. Instead of relying entirely on training data, the system retrieves external information and places it into the model's context.
This solves several real problems: knowledge freshness (information changes without retraining), grounding (responses base on retrieved data), accessibility (proprietary data reaches general models) and operational flexibility (retrieval updates independently of the model). For a question like 'what is our expense-reimbursement policy?' the primary problem is retrieval, and RAG fits.
Now consider a different request: 'prepare a risk review for this customer and recommend the next action.' Suddenly the system needs customer and account information, transaction history, risk policies, current portfolio state, market data, regulatory constraints, user permissions, available analytical capabilities, previous decisions, organizational policy, the current task, and the capabilities the agent is allowed to invoke.
That is no longer a document-retrieval problem. It is a context-construction problem.
Knowledge is not context
The distinction can be put simply: knowledge is information; context is information that is relevant to a particular situation. A company may have millions of pieces of information available to an AI system — the agent should not receive millions of pieces of information.
- It needs the subset relevant to the current user, task, application and state.
- It needs the current permissions, workflow and business context.
- It needs the capabilities that are actually available to it right now.
This is why simply growing the retrieval index does not solve the problem. More information can make it harder — noisier retrieval, more conflicts, more ways to be 'almost right.'
The RAG pipeline has an important boundary
Traditional RAG mainly answers 'which information should I retrieve?' An agent operating in an enterprise has to answer a much larger set: what is relevant, why, what it relates to, which capabilities are available, which this agent may use, what belongs to the current task, what should be excluded, what the application state is, and how multiple pieces of information and capabilities should be composed.
RAG has known limitations
This is not merely theoretical. Microsoft's current enterprise RAG documentation identifies practical failure modes — and notes explicitly that incomplete or irrelevant passages can still yield incomplete or inaccurate answers.
- Poor retrieval quality; incomplete or irrelevant passages.
- Hallucination despite grounding.
- Latency and token-budget limitations.
- Access-control problems.
Independent research agrees. A 2024 study identified security, accuracy, scalability and integration as major enterprise-RAG challenges. A 2026 benchmark found that while models satisfied individual constraints at high rates, only 26.8% of responses satisfied all requirements simultaneously — instruction adherence collapsed under noisy retrieval, knowledge gaps and conflicting facts. A 2026 study of knowledge-graph-enhanced RAG reported substantial gains over vector RAG on complex regulatory queries. The industry is not abandoning retrieval — it is adding structure around it.
From vector search to knowledge graphs
One response to the limits of vector retrieval is to introduce relationships. Instead of independent chunks, a knowledge graph represents how entities connect.
Customer
├─ owns → Account
│ └─ contains → Transaction
└─ associated_with → Portfolio
└─ evaluated_by → Risk ModelThis lets systems reason about relationships rather than only similarity — a major improvement. But it still does not fully solve the application-context problem. A graph can say entities are related; it does not necessarily say which parts of the graph matter to this application, which capabilities are available, what should be exposed to this agent, what the workflow requires, how capabilities compose, or what happens if one becomes unavailable.
The problem has moved from retrieval to contextual composition.
The context engineering shift
The emerging field of context engineering makes this explicit. A 2026 paper describes it as designing, structuring and managing the broader informational environment in which an agent makes decisions — naming relevance, sufficiency, isolation, economy and provenance as key properties. The progression reflects an expanding problem definition.
The system is no longer just trying to produce a better prompt. It is trying to construct a reliable operating environment for an agent. Gartner's July 2026 research similarly describes an enterprise context layer as an architectural foundation for agentic AI — emphasizing reliability, governance and cost optimization.
But context is not just more data
A context layer should not become another giant repository. An enterprise application might contain customer, portfolio, accounts, transactions, risk, trading, market data, compliance, reporting, documents, policies and operations — while a particular request only requires a handful of them. Sending everything into the agent is inefficient and potentially dangerous.
Do not give every context all available knowledge. Give each context the knowledge and capabilities it actually needs.
This has direct implications for latency, token consumption, security, permissions, relevance, reasoning quality, cost and agent reliability. Recent work on adaptive structuring of enterprise data shows the same thing from another angle: repeatedly recovering relevant information from unstructured data is expensive, while pre-structured data makes reasoning dramatically cheaper. The challenge is not storing more information — it is making the right structure available at the right time.
A runtime knowledge frame
This is the problem ADAAS A-Frame was designed to address. A-Frame is an indexing and composition engine for the A-Concept ecosystem. Instead of treating enterprise knowledge as one large retrieval repository, it treats knowledge and capabilities as components that can be indexed, distributed and composed according to application context.
A-Frame is not another vector database
A-Frame is not a replacement for vector search, semantic search, keyword search, knowledge graphs or traditional databases. Those are all useful. A-Frame operates at a different architectural level — a contextual indexing and composition layer above them.
| Approach | Primary question |
|---|---|
| Database | Where is the structured data? |
| Vector search | Which content is semantically similar? |
| RAG | Which information should be placed into the model context? |
| Knowledge graph | How are entities and information related? |
| Context engineering | What information should an agent operate with? |
| A-Frame | Which knowledge, components and capabilities are relevant to this software context, and how should they be composed? |
From retrieval to composition
Consider a distributed feature — Customer Portfolio Overview — that depends on the customer, portfolio, account, transaction, risk, market-data and compliance services. In a conventional architecture an agent may have to discover these independently. But the application already knows these capabilities belong together. The problem is not 'find information about portfolios' — it is 'construct the context required to execute the Customer Portfolio Overview capability.'
A-Concept
└─ Customer Portfolio Overview
├─ Customer
├─ Portfolio
├─ Accounts
├─ Transactions
├─ Risk
├─ Market Data
└─ Compliance
↓
A-Frame → relevant indexes → runtime contextA-Concept provides the structural representation; A-Frame provides the indexing and composition mechanism. The result is not merely a retrieved document. It is a software context.
Context can be distributed
Enterprise software rarely keeps all relevant knowledge in one place. Different services own different pieces of the domain — customer knowledge in the customer service, portfolio knowledge in the portfolio service, risk knowledge in the risk service, and so on. A centralized RAG system tends to pull knowledge toward the retrieval layer. A context-oriented architecture can preserve distributed ownership while still making the relevant knowledge discoverable — which matters enormously where information ownership, security boundaries and application boundaries already exist.
Context should be dynamic
Enterprise software is not static, and the relevant context changes with the user, task, application, permissions, current state, available services and knowledge, and business and operational conditions. A static index (knowledge → index → query) is fundamentally different from a dynamic context assembled from the current request, application, user, permissions, available components and relevant knowledge. A-Frame is designed around the second model.
The importance of availability
As agents interact with distributed applications, capabilities can become unavailable. A rigid workflow fails when one dependency is down. A composable architecture instead constructs the best valid context from the capabilities currently available.
A-Frame and AI agent context
For agents this becomes critical. An agent should not receive unrestricted access to the entire enterprise — it should receive the context required to perform its task: allowed concepts, allowed knowledge, allowed capabilities, allowed operations and the current task. A-Frame makes relevant knowledge and capabilities discoverable within the structural context defined by A-Concept, creating a tighter relationship between architecture, context, knowledge, capabilities, permissions and the agent — rather than treating the AI as an external model searching a document repository.
The .aframe knowledge format
A-Frame also introduces the .aframe format: a custom, shareable and storable representation of knowledge and context that other systems can consume without exposing the original source material. It distinguishes publishing the original data from sharing a representation of knowledge another system can use — useful when organizations need to distribute reusable knowledge while preserving ownership and source-system boundaries.
Private knowledge
↓ A-Frame processing
knowledge.aframe
↓ store / share / distribute
Authorized system
↓
use knowledge (source never exposed)A-Frame vs. conventional RAG
| Dimension | Conventional RAG | A-Frame |
|---|---|---|
| Primary objective | Retrieve relevant information | Index and compose relevant context |
| Main unit | Documents / passages | Knowledge, components and capabilities |
| Context | Primarily query-driven | Application- and context-driven |
| Structure | Often retrieval-oriented | Structurally connected |
| Distribution | Often centralized | Can preserve distributed ownership |
| Composition | Primarily retrieved passages | Runtime knowledge / capability composition |
| Application architecture | External to retrieval | Part of the context model |
| Capabilities | Usually external tools | Can participate in contextual composition |
| Availability | Usually a retrieval concern | Part of composition |
| Permissions | Retrieval filtering | Contextual capability / knowledge boundaries |
| Runtime behavior | Retrieve → generate | Context → compose → reason → execute |
| Portable representation | Depends on implementation | .aframe |
The point is not that RAG should disappear. The point is that RAG becomes one mechanism inside a larger context architecture.
The emerging enterprise AI architecture
The evolution runs from generation (an LLM with a prompt), to grounded generation (an LLM with RAG over enterprise knowledge), to agentic AI (an agent with RAG, tools, memory and APIs), and increasingly to an enterprise agentic architecture built around a context layer.
Context Layer
│
┌───────────┼───────────┐
Knowledge Capabilities State
└───────────┼───────────┘
Permissions
↓
Agent
↓
ActionsA-Frame is intended to operate in this context layer.
From RAG to context architecture
RAG solved a first-generation problem: how can an AI model access information it was not trained on? The next generation asks a harder one: how can an AI system operate inside the right knowledge, application, capability and governance context at runtime? That requires more than retrieval.
- Structural context and contextual indexing.
- Knowledge distribution and capability discovery.
- Permissions and application state.
- Dynamic composition, runtime availability and agent-aware context.
Documents ↓ Retrieval ↓ RAG ↓ Knowledge structures ↓ Context engineering ↓ Context architecture ↓ Dynamic composition ↓ Agentic software
A-Frame is ADAAS's approach to this problem. Its role is not to replace RAG, vector databases or knowledge graphs — it is to provide a higher-level knowledge indexing and composition layer in which those technologies participate. The future of enterprise AI may not be determined by who can retrieve the most information. It may be determined by who can construct the right context.
RAG retrieves knowledge. A-Frame helps turn knowledge, capabilities and software structure into usable context.