The real-time knowledge and context engine for composable software.
A-Frame is the knowledge and context distribution layer of the ADAAS platform. It indexes an application's knowledge and software components, understands which of them are relevant to a given context, and composes exactly that knowledge into the software or AI agent that needs it — in real time.
Storing knowledge has never been the hard part. The hard part is making the right knowledge available to the right software context at the right time. A-Frame is built for that problem — not to answer questions about code, but to compose the knowledge that software and agents run on.
A-Frame is part of the ADAAS Architecture Intelligence Platform. A-Concept defines structure and context — A-Frame indexes what is available and composes what is relevant.
Storing knowledge is easy. Distributing it is not.
Modern systems are full of places to put knowledge: repositories, wikis, databases, vector stores, documentation sites, service registries, and model context windows. The problem is no longer where to keep knowledge. It is relevance and distribution: getting the specific knowledge a task needs into the specific context that needs it, without flooding that context with everything else.
When software was written entirely by humans, developers carried that context in their heads. In AI-native development, knowledge has to be delivered to software and agents deliberately — structured, scoped, and composed. That delivery layer is what A-Frame provides.
Do not give every context all available knowledge. Give each context the knowledge it actually needs.
What is A-Frame?
A-Frame is a real-time knowledge indexing and composition engine. It indexes the knowledge and software components of an application — organized around its modules and features rather than arbitrary document chunks — and composes the relevant subset for each request, feature, or agent. Where A-Concept represents the structure of an application, A-Frame represents what is available right now and assembles what is relevant.
AIS intent what should exist
↓
A-Concept structure how the application is organized
↓
A-Frame indexing + which knowledge is available and
composition relevant, composed in real time
↓
AI / Agents reasoning act on the composed knowledge
The engine is designed for composition and execution — not just for answering questions. Its output is the working knowledge a piece of software or an agent runs on, delivered in the shape of the application's own structure.
Knowledge is distributed
In a real application, the knowledge required to build or run a single feature is scattered. A Customer Portfolio Overview depends on knowledge that lives in many different places:
Source code behaviour, contracts, edge cases Service definitions boundaries, endpoints, ownership Domain models entities, relationships, rules Documentation intent, constraints, decisions Configuration environments, feature flags Data schemas shape and meaning of data Team knowledge conventions, history, rationale
No single store holds all of it, and no single context should carry all of it. A conventional approach forces a developer, tool, or agent to rediscover and re-assemble this knowledge for every task. A-Frame indexes it once, keeps it structured, and composes the relevant portion on demand.
Knowledge distribution by module
A-Frame indexes knowledge the way software is actually organized: by module and feature. Each module owns its knowledge and keeps it local. When a feature is requested, A-Frame composes a view from the modules that are relevant to it — and leaves the rest out of the context entirely.
This preserves distributed knowledge ownership: a module remains the authority on its own knowledge, and A-Frame indexes and composes across modules without collapsing everything into one undifferentiated pool.
Only the knowledge you need
Relevance is contextual. The same application looks different to a billing task, a risk analysis, and a customer-support agent. A-Frame determines what a given context requires and composes accordingly, so no context is handed knowledge it does not need.
Feature: Portfolio Overview
Relevant:
Accounts knowledge ✓
Portfolio knowledge ✓
Risk knowledge ✓
Not distributed to this context:
Billing knowledge ✗
Marketing knowledge ✗
Admin tooling knowledge ✗
Narrowing knowledge is not only an efficiency measure — it is a correctness and governance measure. A context that only receives what it needs is cheaper, faster, easier to reason about, and safer.
Aggregated context, assembled on demand
For any given request, A-Frame aggregates knowledge from every relevant module into a single composed context. The consumer — whether a service, a UI, or an AI agent — receives one coherent view of the feature rather than a list of sources to visit and reconcile.
Request: "Explain this customer's portfolio risk" ↓ A-Frame selects relevant modules ↓ Accounts + Portfolio + Risk knowledge ↓ Aggregated into one composed context ↓ Delivered to the agent or service
The aggregation is structural: knowledge arrives connected to the concepts and relationships it belongs to, not as a flat bag of text.
Composition happens in real time
Applications change constantly — code is deployed, modules are added, data shifts, permissions update, services go up and down. A-Frame composes against the current state of the system, so the knowledge delivered to a context reflects what is true now, not a stale snapshot captured at build time.
A-Frame does not ship a fixed knowledge base. It composes the knowledge that is relevant and available at the moment it is requested.
Composition instead of rebuilding
Because A-Frame composes knowledge from indexed modules, a change in one module does not require rebuilding the whole picture. The engine recomposes the affected context from the parts that changed. New capabilities become available to compose as soon as they are indexed — existing features can incorporate them without being rewritten.
Module updated ↓ Re-indexed by A-Frame ↓ Only affected contexts recomposed ↓ Everything else stays valid
Composition, not reconstruction, is what makes knowledge distribution sustainable as an application grows.
The .aframe knowledge format
Indexed knowledge needs a portable representation, and that representation is the .aframe format. An .aframe artifact captures the knowledge about a module, feature, or application in a machine-readable, composable form — and it does so without publishing the original source.
This is the key idea: a team or organization can share what a capability is and what it knows without exposing the underlying implementation. Knowledge becomes a portable artifact that can move across boundaries on its own terms.
Private source / module
↓ indexed by A-Frame
knowledge.aframe (portable, source not included)
↓ shared / versioned / distributed
Authorized system, team, or agent
↓ composed into context
used without access to the original source
In other words, an .aframe artifact is knowledge as a software dependency. Like any dependency, it can be:
- Stored
- Persisted as a first-class artifact rather than trapped inside a running system.
- Versioned
- Tracked over time, so a consumer can pin, upgrade, or diff the knowledge it depends on.
- Shared
- Distributed across teams and organizations without publishing the original source.
- Reused
- Consumed by many features, services, and agents from a single indexed representation.
- Composed
- Combined with other .aframe artifacts to assemble a larger context.
- Distributed
- Delivered to exactly the contexts that need it, at the moment they need it.
The .aframe format turns knowledge into something you can ship — portable, governed, and composable — instead of something locked inside a codebase or a single model's context window.
A-Frame and AI agents
An AI agent is only as good as the knowledge in its context. Give it too little and it guesses; give it everything and it is slow, expensive, and prone to acting outside its remit. A-Frame narrows an agent's knowledge to what its current task actually requires, composed from the relevant modules and nothing else.
Agent task: reconcile a customer's holdings
↓
A-Frame composes context:
Accounts knowledge
Portfolio knowledge
Holdings knowledge
✗ no billing, marketing, or admin knowledge
↓
Agent reasons and acts within a scoped context
The agent receives a focused, structured, and current view of the application — the working knowledge for its task, not the entire system.
A-Frame and agent governance
Because A-Frame decides which knowledge reaches which context, it is also a natural governance point. Knowledge distribution can respect permissions, ownership, and boundaries: an agent or service only receives the .aframe artifacts it is authorized to compose, and never gains implicit access to knowledge outside its scope.
Controlling what an agent knows is one of the most direct ways to control what an agent can do.
Fault-tolerant composition
Knowledge sources are not always available. A module may be offline, a service unreachable, or a data source temporarily unavailable. A-Frame composes from what is available rather than failing the whole request — delivering the best context it can assemble under current conditions.
Composing context for: Portfolio Overview ├── Accounts knowledge ✓ ├── Portfolio knowledge ✓ ├── Risk knowledge ✓ ├── Market Data knowledge ✗ (unavailable) └── History knowledge ✓ Result: context composed from what is available
An unavailable knowledge source narrows the context — it does not collapse it.
A-Frame vs conventional RAG
A-Frame is sometimes mistaken for a retrieval-augmented generation pipeline. They overlap in that both make knowledge available to AI, but they are built for different problems.
| Conventional RAG | A-Frame |
|---|---|
| Indexes document chunks | Indexes software components and structured knowledge |
| Organized around text similarity | Organized around application modules and features |
| Retrieves passages for a prompt | Composes knowledge for a context, feature, or agent |
| Flattens sources into a pool | Preserves distributed ownership and structural context |
| Prompt-driven | Feature- and structure-driven |
| Optimized for answering questions | Optimized for composition and execution |
| Knowledge stays in the index | Knowledge is portable as .aframe artifacts |
| Requires access to the source content | Shares knowledge without publishing the source |
| Little notion of dependency or version | Knowledge behaves as a versioned dependency |
| Availability is a retrieval concern | Composition is fault-tolerant by design |
A-Frame can incorporate retrieval where it makes sense — but its purpose is knowledge distribution for composable software, not passage lookup for a single prompt.
A-Frame vs a traditional index
A traditional index answers “where is this?” A-Frame answers “what does this context need, and how should it be composed?” An index returns locations; A-Frame returns a composed, structured, governed context assembled from the relevant modules. The index is a lookup mechanism; A-Frame is a distribution and composition layer that happens to index as part of its job.
An index tells you where knowledge lives. A-Frame delivers the knowledge, in context, to the software that needs it.
AIS, A-Concept, A-Frame — and the agents above them
A-Frame is complementary to AIS and A-Concept, but it solves a distinct part of the problem. AIS expresses intent. A-Concept provides structure and context. A-Frame indexes what is available and composes what is relevant. Agents reason and act on the result.
The four-part distinction is one of the clearest ways to understand the whole platform: AIS = intent, A-Concept = structure + context, A-Frame = indexing + composition, AI agents = reasoning + action.
A-Frame and A-Concept
A-Frame and A-Concept are two sides of the same model. A-Concept defines the stable conceptual structure — what exists, how it relates, and what context it belongs to. A-Frame provides the dynamic layer — what knowledge and components are available right now, which are relevant, and how they compose for a given request.
A-Concept provides the stable conceptual structure. A-Frame composes the knowledge that is available at runtime.
A-Frame inside the ADAAS platform
A-Frame is the knowledge and context distribution layer of the Architecture Intelligence Platform. It connects intent and structure to reasoning agents and runtime by delivering the right knowledge to the right context at the right time.
Who is A-Frame for?
- CTOs & technology leaders
- Making knowledge a governed, reusable asset across an AI-native organization.
- Enterprise architects
- Distributing structural knowledge across many systems without central bottlenecks.
- Platform teams
- Providing modular, composable knowledge and governed access as a shared capability.
- AI engineering teams
- Giving agents scoped, current, structured context instead of an entire codebase.
- Distributed & microservice orgs
- Composing feature-level knowledge across many independently owned services.
- Modular knowledge-base owners
- Sharing and versioning knowledge as portable .aframe artifacts across boundaries.
The future of knowledge distribution
As software is increasingly built and operated by AI, the decisive question is not how much knowledge a system stores, but how precisely it can distribute knowledge to the contexts that need it. A-Frame treats knowledge as a first-class, portable, composable asset — indexed by structure, delivered by relevance, and governed at the point of distribution.
The winners in AI-native software will not be those who store the most knowledge, but those who distribute the right knowledge to the right context at the right time.
Frequently asked questions
What is A-Frame?
A-Frame is ADAAS's real-time knowledge indexing and composition engine. It indexes an application's knowledge and software components, understands which of them are relevant to a given context, and composes just that knowledge into the software or AI agent that needs it.
Is A-Frame just a RAG engine?
No. Retrieval-augmented generation retrieves document chunks to answer a prompt. A-Frame indexes software structure, components, and knowledge around an application's modules and features, preserves distributed ownership and structural context, and composes knowledge for execution — not only for answering questions.
What is the .aframe format?
The .aframe format is a portable representation of indexed knowledge. It lets a system share the knowledge about a module, feature, or application without publishing the original source, so knowledge can be stored, versioned, shared, reused, composed, and distributed like a software dependency.
How is A-Frame different from A-Concept?
A-Concept defines the structural context and relationships of an application. A-Frame indexes what knowledge and components are actually available and composes the relevant subset in real time. A-Concept provides the structure; A-Frame provides dynamic availability and composition.
Why not give an AI agent all the knowledge?
Giving every context all available knowledge is expensive, slow, and unsafe. A-Frame gives each context only the knowledge it actually needs, which improves relevance, cost, latency, and governance.
Does A-Frame store the original source?
The .aframe representation carries indexed knowledge rather than the raw source. This lets teams and organizations share and compose knowledge across boundaries without exposing the underlying implementation.
How does A-Frame handle unavailable knowledge?
A-Frame composes from what is available. If a module or knowledge source is unavailable, the engine composes the remaining relevant knowledge rather than failing the whole request — supporting fault-tolerant composition.
How does A-Frame work with microservices?
A-Frame indexes knowledge across distributed services and modules and composes a feature-level view from them, so a distributed feature can be understood and assembled without rediscovering every service.
Is A-Frame useful without AI agents?
Yes. A-Frame is valuable in any complex, modular, or distributed application. Its importance grows when AI agents participate, because agents need relevant, governed, structured knowledge rather than an entire codebase.
How does A-Frame relate to AIS?
AIS expresses software intent. A-Frame makes the knowledge and components needed to realize that intent available and composable in real time. AIS says what should exist; A-Frame supplies the relevant knowledge to build and run it.
Can knowledge be shared between teams and organizations?
Yes. Because .aframe artifacts are portable and do not require publishing the source, knowledge about a module or capability can be shared, versioned, and composed across teams and organizations as a dependency.
What role does A-Frame play in the Architecture Intelligence Platform?
A-Frame is the knowledge and context distribution layer of the platform. It connects structure (A-Concept) and intent (AIS) to reasoning agents and runtime by delivering the right knowledge to the right context at the right time.
Go deeper
The right knowledge, in the right context, at the right time.
Give software and agents the knowledge they actually need — A-Concept gives it structure, A-Frame indexes and composes it, agents reason and act.