Agent Definition Language (ADL): The Open Source Standard for Defining AI Agents
GitHub Repository: https://github.com/nextmoca/adl
Artificial Intelligence is entering its next major phase: the era of agents. Not just chatbots or one-off prompts, but fully defined agents that can reason, call tools, retrieve knowledge, and orchestrate workflows across complex enterprise environments.
From customer support and logistics optimization to fraud detection, underwriting, product operations, HR automation, and engineering enablement, AI agents are beginning to sit at the center of critical business processes.
But as adoption accelerates, a structural problem has emerged: there is no shared, vendor-neutral standard for describing what an agent is. Every platform, vendor, and internal team defines “agents” differently. Tool contracts, retrieval (RAG) setups, permissions, and LLM configuration are all fragmented and inconsistent.
This fragmentation slows adoption, weakens governance, increases vendor lock-in, and makes it nearly impossible for enterprises to safely scale agent-based systems.
ADL (Agent Definition Language) was created to solve that problem. And now, ADL is available as an open source standard, designed to be the common language for defining AI agents across vendors, runtimes, and ecosystems.
We at Next Moca believe that open sourcing ADL will accelerate ecosystem adoption, improve interoperability, and provide enterprises with the transparency they require.
Why ADL? The Problem It Solves
Before ADL, every serious enterprise AI initiative ran into the same set of issues:
1. Each team defined agents differently.
One group used a YAML file, another embedded configuration in code, another used proprietary JSON fields that only worked with a specific framework. There was no single, predictable way to define what an agent could do.
2. Governance and security were an afterthought.
Security and risk teams kept asking basic questions: What tools can this agent call? What data can it read? What files can it write? What environment variables does it depend on? Without a standard, these answers required manual code review which is brittle and unsustainable.
3. RAG and tool configurations were ad hoc.
Retrieval-augmented generation (RAG) pipelines, code search, document indices, and tool definitions were all wired differently per project. This made agents fragile and nearly impossible to share across teams or business units.
4. Vendor lock-in was implicit.
Because every platform defined its own concept of an “agent,” companies effectively locked themselves into whichever vendor they started with. Moving agents between systems meant rewriting them from scratch.
5. Compliance and audits had no stable artifact.
Regulators and internal auditors now expect AI systems to be explainable and controllable. Without a declarative artifact that describes what an agent is allowed to do, audits become a high-friction, manual process.
ADL exists to address all of these problems. It is a single, expressive, machine-validated definition of an AI agent: its purpose, tools, RAG inputs, LLM configuration, dependencies, and security boundaries. With ADL, enterprises gain a standard object they can inspect, version, audit, and reuse.
What ADL Is
ADL (Agent Definition Language) is a vendor-neutral, declarative specification for defining AI agents in a way that is both human-readable and machine-validated.
An ADL definition captures, in one place:
• Agent identity: name, description, role, owner, version.
• LLM configuration: provider, model, temperature, max tokens, and other generation settings.
• Tools and capabilities: the functions the agent can call, including parameters, types, descriptions, invocation type, and expected return structure.
• Retrieval inputs (RAG): the indices or corpora (documents, code, media) that the agent may query, including paths, types, and metadata.
• Permissions and boundaries: file read/write allow lists, network policies, environment variables, and sandbox constraints.
• Dependencies: required packages or libraries, with optional version pinning.
• Lifecycle and audit metadata: who created the agent, when, and how it has evolved over time.
In simple terms: ADL is the blueprint or contract for an AI agent. It defines what the agent is allowed to do, what resources it can access, and how it is configured — independent of any specific runtime, vendor, or framework.
If OpenAPI is the standard way to describe an HTTP API, and Terraform configurations are the standard way to describe infrastructure, ADL is designed to be the standard way to describe AI agents.
What ADL Is Not
Just as important as defining what ADL is, is clarifying what it is not. ADL focuses on the static, declarative definition of an agent and not its runtime protocol or orchestration logic.
• Not an agent-to-agent communication protocol.
ADL does not define how agents talk to each other, coordinate, or message one another during execution. That is the domain of A2A (agent-to-agent) protocols or orchestration systems.
• Not a runtime tool protocol like MCP.
ADL does not define the mechanics of how a model calls a remote tool server, streams tokens, or passes messages back and forth. Protocols such as the Model Context Protocol (MCP) and other tool-invocation standards operate at that layer.
• Not OpenAPI.
OpenAPI is fundamentally about HTTP APIs: endpoints, request bodies, and responses. Agents are richer entities that reason, retrieve, use tools, and act within permissioned contexts. ADL is not an API spec; it is an agent spec.
• Not a workflow engine.
ADL is not a replacement for Airflow, Temporal, Dagster, or any other task scheduler or workflow orchestrator. You can absolutely use ADL-defined agents inside workflows, but the workflow logic lives elsewhere.
• Not a prompt engineering format.
While prompts may be included or referenced inside an agent definition, ADL is not a prompt markup language. It is concerned with the structural contract of the agent, not just its initial instructions.
• Not an RPC or wire protocol.
ADL says nothing about transport formats such as gRPC, JSON-RPC, or HTTP. It describes capabilities and configuration, not the network protocol used to integrate systems.
By keeping its scope focused on definition - not transport, not orchestration, not runtime protocols - ADL stays composable and interoperable with other standards and ecosystems.
How ADL Compares to A2A, MCP, OpenAPI, and Other Standards
There are several emerging and established standards in the AI and software ecosystem. ADL is designed to complement them, not compete with them.
ADL vs A2A (Agent-to-Agent specifications):
A2A efforts focus on how agents communicate, delegate tasks, share state, and coordinate work across a network of agents. They define messaging formats, routing semantics, and multi-agent behaviors. ADL fits one layer below that: it defines what each participating agent is — its tools, RAG bindings, permissions, and configuration. In other words, A2A defines conversations; ADL defines the participants.
ADL vs MCP (Model Context Protocol):
MCP describes how a model (such as an LLM) can access external tools, resources, and context at runtime: how requests and responses are structured, how servers expose tools, and how clients connect to them. ADL does not describe the mechanics of tool invocation; it describes the agent’s allowed tools, their parameters, and their declarative configuration. MCP is a runtime tool protocol; ADL is a static agent definition.
ADL vs OpenAPI:
OpenAPI is a powerful and widely adopted standard for describing RESTful HTTP APIs. It focuses on paths, methods, parameters, and response schemas. ADL operates at a different abstraction level. Agents might call APIs behind the scenes, but ADL is focused on the agent’s behavior, not the underlying HTTP interface. In some cases, ADL can reference OpenAPI-described services as tools, but the two standards are not interchangeable.
ADL vs Workflow Definitions (e.g., Airflow DAGs, Temporal workflows):
Workflow engines define when and how tasks execute over time: scheduling, dependencies, retries, and error handling. ADL can be used inside those workflows to define the agents that perform certain tasks, but it does not replace the workflow logic itself.
ADL vs Prompt Formats and Templates:
Many tools define how prompts are templated, parameterized, or combined. ADL may reference prompts as part of the agent’s configuration, but its main purpose is to define the agent’s capabilities and environment, not to standardize prompt syntax.
ADL occupies the “definition” layer in the emerging agent stack. It sits naturally alongside A2A protocols, MCP, OpenAPI, and workflow standards, and gives all of them a stable, interpretable agent contract to work with.
ADL Architecture and Schema Overview
At a high level, ADL organizes an agent’s configuration into a small set of well-defined sections. These sections are expressed in JSON (or JSON-compatible) form and validated against a canonical JSON Schema.
Core components of ADL include:
1. Agent Metadata:
• name, display_name
• description
• role
• version
• owner and created_by
• timestamps and lifecycle metadata
2. LLM Configuration:
• llm provider (e.g., openai, anthropic, google, local)
• model name or identifier
• temperature
• max_tokens
• additional provider-specific generation parameters
3. Tools and Capabilities:
Each tool has:
• name and human-readable description
• parameter list with names, types, descriptions, and required flags
• invocation type (python_function, http, mcp, etc.)
• optional return type or schema
• optional categories (e.g., File Operations, RAG, Utilities, Messaging)
4. Retrieval (RAG) Inputs:
• id and name of the index or corpus
• rag_type (doc, code, image, etc.)
• virtual_index_path or identifier
• location_type (local, remote, cloud provider, vector DB)
• metadata for filtering, domain, or governance
5. Permissions and Boundaries:
• network: whether network access is allowed and to what domains
• file_read: whitelisted locations for reading
• file_write: whitelisted locations for writing
• env_vars: which environment variables may be exposed
• other sandbox limits and safety flags
6. Dependencies:
• pip or package names
• optional pinned versions
• references to code files that implement tools
7. Governance & Audit:
• created_at, updated_at
• created_by, updated_by
• change notes or rationale
• versioning aligned with semantic versioning (SemVer)
This structure is intentionally modular. It provides enough detail for engines and runtimes to execute an agent safely and consistently, while remaining flexible enough to support new tools, LLM providers, and RAG strategies over time.
Enterprise Governance and Security with ADL
For enterprises, governance is not optional. Agents interact with sensitive data, internal systems, and sometimes regulated workflows. ADL is designed from the ground up to support governance and security requirements.
With ADL, governance teams can:
• Inspect agent definitions as version-controlled artifacts.
• Understand exactly what tools and data an agent can access.
• Enforce policies based on permissions, file paths, network domains, or environment variables.
• Require review and approval of ADL definitions before deployment.
• Audit historical changes using Git or other version control systems.
• Validate agents automatically in CI/CD pipelines using ADL schema validators.
Because ADL is declarative, it enables proactive control rather than reactive monitoring. Instead of discovering capabilities by watching logs after the fact, enterprises can examine the ADL file and know in advance what an agent will be allowed to do.
This is essential not only for internal security but also for external regulatory compliance, including emerging AI governance expectations in various jurisdictions.
Open Source, Apache 2.0, and the ADL Ecosystem
To become a true standard, ADL must be bigger than any single vendor — including the one that created it. That is why ADL is open sourced under the Apache License 2.0.
Apache 2.0 was chosen specifically because it:
• Provides explicit patent protection and a clear patent grant from contributors.
• Is widely trusted by enterprises and open source foundations.
• Encourages commercial and non-commercial adoption alike.
• Is the license of choice for many foundational technologies and standards, from Kubernetes and Kafka to OpenTelemetry and Apache Arrow.
By open sourcing ADL, Next Moca invites:
• Vendors to adopt ADL as their agent definition format.
• Startups to build tooling, validators, editors, and runtimes around ADL.
• Enterprises to standardize their internal agent catalogs on ADL.
• Researchers to extend the schema with experimental features.
• Foundations and working groups to help steward the long-term evolution of the language.
The goal is not to create yet another proprietary configuration file. The goal is to define a stable, open, and extensible standard for agent definition that the entire ecosystem can rely on.
Roadmap and Future Directions
ADL v1 focuses on core agent definition: metadata, tools, RAG inputs, LLM configuration, permissions, dependencies, and governance metadata. But this is only the beginning.
Planned and potential future directions include:
• Multi-agent specifications:
Defining not only single agents but ensembles of agents, their roles, and coordination patterns.
• Workflow and state modeling:
Expressing higher-level orchestration semantics or linking ADL agents directly into workflow definitions.
• Richer type systems:
Expanding the parameter and return-type definitions with stronger typing, constraints, and validation rules.
• Memory models:
Defining episodic, long-term, or domain-specific memory schemas that agents can rely on across sessions.
• Domain-specific extensions:
Healthcare, finance, logistics, legal, and other verticals may benefit from domain-focused additions to ADL that remain backwards compatible with the core standard.
These directions will be guided by a combination of real-world usage, community feedback, and formal RFC processes as the ADL community and governance mature.
How to Adopt ADL in Your Organization
Enterprises, startups, and individual developers can start using ADL gradually without needing to overhaul their entire stack.
Practical steps to adopt ADL include:
1. Start with a single agent.
Take an existing agent in your environment and express its configuration the tools, RAG sources, LLM settings, and permissions as an ADL file.
2. Introduce validation.
Use an ADL schema validator in your CI pipeline to ensure that any new or changed agent definitions conform to the standard.
3. Integrate ADL into your platform.
If you provide an internal agent platform, extend it to read ADL files as first-class inputs, converting them into runtime configurations.
4. Bring security and governance teams into the loop.
Use ADL definitions as the basis for risk review, compliance checks, and production approval workflows.
5. Engage with the community.
As you encounter gaps or promising extensions, contribute RFCs, examples, or tooling back to the ADL project.
ADL is designed to be incrementally adoptable: you can start small, then expand its use as your agent ecosystem grows.
Conclusion: A Foundation for the Agent Era
AI agents are poised to become a core abstraction in enterprise software — the programmable, policy-aware, tool-using intelligences that sit between data, systems, and users.
For that vision to be safe, sustainable, and interoperable, the world needs a shared, open, and expressive way to define what those agents are.
ADL (Agent Definition Language) is that definition layer: a vendor-neutral, open source, Apache-licensed standard for describing agents, their tools, their retrieval inputs, their LLM configurations, and their permission boundaries.
By focusing on definition rather than runtime, and by complementing rather than competing with protocols like A2A or MCP, ADL provides a solid foundation for an entire ecosystem of runtimes, tools, platforms, and governance frameworks.
Whether you are building an internal agent registry, a multi-agent execution engine, a compliance dashboard, or a next-generation AI product, ADL offers a common language you can rely on.
The agent era is here. Now it has a standard.
To adopt, extend, or contribute to ADL, visit the official repository:
GitHub Repository: https://github.com/nextmoca/adl
Welcome to the agent era. Welcome to ADL.