The structural framework for context-aware, composable software.

From elements to structure. From structure to context.

Traditional frameworks tell applications how components are implemented. A-Concept adds another dimension: it defines the structural context in which those components exist and operate. A conventional object, component, API, or service usually tells you what it is. A-Concept additionally represents the context in which it is being used.

That context becomes available to the runtime, to AI agents, to governance mechanisms, and to the rest of the Architecture Intelligence Platform — turning architecture from documentation that drifts into a model the software itself can carry.

Traditional frameworks describe implementation structure. A-Concept describes conceptual and implementation structure — together, and kept connected.

What is A-Concept?

A-Concept is ADAAS's application and conceptual framework for representing software as a structured, contextual, and composable system. It provides a persistent model of application concepts, their relationships, features and capabilities, structural and contextual dependencies, execution boundaries, permissions, composition rules, runtime relationships, and implementation mappings.

The result is a software structure that can be reasoned about at a level above individual services, files, APIs, and implementation details — a model of what a feature is, what it needs, where it belongs, what it can access, and how it can be composed with other capabilities. The framework is expressed in TypeScript: components contribute capabilities as features, and other components compose into them.

import { A_Concept, A_Component, A_Feature, A_Dependency } from '@adaas/a-concept';

// A component contributes capabilities to the application as features.
export class PortfolioComponent extends A_Component {
    @A_Dependency.Required()
    declare customers: CustomerComponent;

    // The structural context is available to every feature.
    @A_Feature.Define()
    async overview(feature: A_Feature): Promise<void> {
        await feature.next();
    }
}

In AI-native development this matters: an AI agent should not have to rediscover an application's architecture every time it performs a task. The architecture is already represented in a form the platform can understand.

Software structure today

Modern enterprise applications are increasingly distributed. A single business capability may involve many microservices, APIs, databases, frontend components, authorization systems, external services, background jobs, AI agents, and domain rules. The actual business feature therefore rarely exists in one place. Consider a Customer Portfolio Overview whose information is spread across services:

Customer Service
      ↓
Portfolio Service
      ↓
Account Service
      ↓
Transaction Service
      ↓
Risk Service
      ↓
Market Data Service

A conventional approach requires developers, tools, or agents to discover these services individually and reconstruct the relationships between them. A-Concept changes the abstraction. Instead of asking “which services do I need to call?” the system can ask “what is the structural context of the Customer Portfolio Overview?” — and the distributed implementation becomes a detail of the larger concept.

Software needs more than definitions

The individual elements of an application are useful, but the real meaning comes from their relationships. A-Concept represents those relationships as part of the application's structure, so an AI agent does not need to infer the entire graph from source code, API docs, service registries, and runtime behaviour.

Customer
    ├── Accounts
    ├── Transactions
    ├── Portfolio
    └── Risk Profile

In A-Concept, context becomes an application primitive. It can determine what an element means, which capabilities are available, which components can interact, what data can be accessed, what operations are permitted, which dependencies are required, which alternatives can be used, and how a feature should be composed — turning context from something developers merely understand into something the software itself can represent and use.

One feature can span many systems

A business feature does not need to correspond to a single service. A-Concept can compose a higher-level feature from distributed capabilities that physically exist in different services, databases, or applications. The application reasons about Customer Portfolio Overview rather than forcing every developer or agent to reason about Service A → API B → Database C → Service D.

The distributed system still exists: microservices, APIs, and databases remain underneath. But they no longer have to be the primary abstraction through which every feature is understood. A-Concept creates a higher-level structural representation over them — and an agent can work with the conceptual feature and its context while the framework handles the relationship to its distributed implementation.

Composition instead of static dependency

Traditional applications often encode dependencies as fixed implementation relationships: A depends on B, B depends on C, and if C fails, the chain fails. A-Concept introduces a different model — capabilities are composed dynamically according to the context in which they are required. Composition lets the system distinguish between essential structure, optional capabilities, alternative capabilities, unavailable capabilities, recoverable failures, and independent execution paths.

// A separate component composes into the same feature — without
// knowing where the feature was originally defined.
export class RiskComponent extends A_Component {
    @A_Feature.Extend('overview')
    async addRisk(feature: A_Feature): Promise<void> {
        await feature.next();
    }
}

The application is therefore not necessarily tied to one rigid execution path. Capabilities extend a feature from wherever they live, and the framework composes the pipeline.

Fault tolerance through composition

Consider a feature composed of five capabilities where one becomes unavailable. A conventional implementation may treat the missing dependency as a failure of the entire feature. A composable A-Concept application can instead continue with the capabilities that remain available.

Feature
 ├── Customer Data       ✓
 ├── Portfolio Data      ✓
 ├── Risk Analysis       ✓
 ├── Market Data         ✗
 └── Recommendations     ✓

The failure of one capability does not automatically imply the failure of the entire application.

A-Concept can isolate execution paths and compose what remains available according to the current context. This is particularly valuable in distributed environments where services become temporarily unavailable, external APIs fail, AI models are unavailable, permissions change, data sources disappear, or an agent's access is restricted — the application keeps operating within the boundaries of what is currently available.

Features composed at runtime

A-Concept is designed for applications whose structure and behaviour can change dynamically. Instead of assuming the complete application must be predetermined before execution, the framework works with the set of concepts, capabilities, context, and constraints that are available — and composes features at runtime.

User
  ↓
Context
  ↓
Available capabilities
  ↓
Permissions
  ↓
Composition
  ↓
Feature execution

The resulting feature is determined not only by what the application contains, but by what is relevant and available at that moment. This creates a fundamentally different type of application architecture.

Governance through structural boundaries

Dynamic software needs stronger governance, not weaker governance. When applications compose capabilities dynamically, the system needs to understand what can be used, by whom, under which conditions, in which context, with which permissions, over which data, and for which operation. A-Concept provides structural boundaries where these decisions are represented — making governance part of the application structure rather than an external mechanism applied after the fact.

Agent: PortfolioAssistant

Allowed:
    Read Customer
    Read Portfolio
    Read Transactions
    Run Risk Analysis

Not Allowed:
    Execute Trade
    Modify Customer
    Change Risk Policy

The agent can work with the application without receiving unrestricted access to the underlying system. The structural context determines which capabilities are available to it — increasingly important as organizations move from AI assistants toward autonomous software agents.

Permissions that operate on concepts, not just endpoints

An AI agent does not simply execute predefined code — it reasons about a task and decides which capabilities to use. That means permission models must operate at a higher level than individual API endpoints. A-Concept associates permissions with the conceptual structure and capabilities of an application, so an agent operates within a defined application context:

Agent
   ↓
Context
   ↓
Permitted Concepts
   ↓
Permitted Capabilities
   ↓
Permitted Composition
   ↓
Execution

The agent is not given the entire application. It receives access to the portion of the application structure relevant to its role and permissions — a foundation for governed, least-privilege agentic software.

A common language for software-development agents

AI-native development increasingly involves multiple agents: one analyzes requirements, another designs architecture, another implements a feature, another tests it, another reviews security, another manages deployment. The hard problem is not simply communication — it is shared software context. Generic natural-language messages are not enough; agents need a representation of concepts, structures, relationships, features, dependencies, capabilities, constraints, permissions, implementation, and execution context.

Instead of an instruction like “please modify the customer service,” an agent can operate against a structured concept and feature. The receiving agent understands the structural context of the request — it does not need to reconstruct the entire application from natural-language descriptions.

AIS, A-Concept, A-Frame — and the agents above them

A-Concept and AIS are complementary but fundamentally different. AIS expresses intent. A-Concept provides structure and context for that intent. A-Concept gives declarations structural meaning: how concepts relate, where their implementations exist, what capabilities they expose, what context they require, what permissions apply, how they can be composed, and how they behave at runtime.

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-Concept and A-Frame

A-Concept and A-Frame solve different parts of the same problem. A-Concept defines the conceptual and structural model — what exists, how it is related, what context it belongs to, and what capabilities and boundaries exist. A-Frame provides the real-time indexing and composition mechanism — what is available right now, which components and knowledge are relevant, and how they can be composed for a given request.

A-Concept provides the stable conceptual structure. A-Frame composes the implementation that is available at runtime.

A-Concept vs conventional frameworks

A-Concept vs microservices

A-Concept does not replace microservices — it changes the level at which the application is understood. A microservices architecture might be a flat list of Customer, Portfolio, Risk, Transaction, and Market Data services. A-Concept can represent Customer Portfolio Management as a structure spanning those services. The services remain underneath, but the business feature becomes the primary structural abstraction — so an agent, architect, or runtime works with the feature without manually traversing every service.

Microservices define distribution. A-Concept defines conceptual structure across that distribution.

Worked examples

Distributed wealth management

A portfolio overview drawing on seven systems can exist as one structured concept. The agent starts from the feature; A-Concept provides its structural context, A-Frame identifies available implementation, permissions determine access, and composition determines what executes — instead of rediscovering the architecture from scratch.

Partial failure

If Market Data becomes unavailable, the feature still composes from Customer, Accounts, Holdings, Transactions, and Risk. The system removes real-time market functionality while preserving the rest of the experience — an architectural consequence of composable capabilities, not just error handling.

Least-privilege agents

A Portfolio Analyst agent can read portfolios and run analytics but not execute trades; a Trading agent can submit approved trades but not modify customer identity. All operate against the same application — their structural context differs.

Legacy modernization

Existing distributed systems can be given a structural model without being rewritten, so architectural context is preserved as the estate evolves.

Structural context is the layer AI is missing

AI systems are extremely capable at generating actions. The difficult problem is determining which actions are appropriate in this application. A generic model does not inherently know which service represents a customer, which data source is authoritative, which capabilities are allowed, which relationships are important, which operations are safe, which dependencies are optional, or which business concepts belong together.

A-Concept gives AI systems something more reliable than a collection of prompts and documentation: a machine-readable model of the application itself.

A-Concept inside the ADAAS platform

A-Concept is a core layer of the Architecture Intelligence Platform. The key difference from conventional development is that architecture is not discarded once implementation begins — it remains part of the software system, a shared reference point for humans, agents, implementation, governance, and execution.

Who is A-Concept for?

Software architects

Designing complex application structures that stay connected to implementation.

Enterprise architects

Managing distributed systems as coherent business capabilities.

CTOs & technology leaders

Establishing AI-native development standards across the organization.

Engineering organizations

Working with microservices and distributed architectures at scale.

AI engineering teams

Building agent-driven applications that need structural context and governance.

Platform teams

Creating reusable enterprise capabilities and governed agent access.

A new abstraction for software

The industry has moved through machine, process, object, service, microservice, application, and capability. AI-native software introduces another question: how do we represent the structure connecting all of these capabilities? A-Concept treats software structure itself as an executable and governable concept — understandable not only by developers, but by AI agents and runtime systems.

A-Concept makes software concepts, context, capabilities, relationships, permissions, and composition understandable and executable by both applications and AI agents.

Frequently asked questions