Remember when every website had its own custom markup language before HTML became the standard? Or when APIs were a free-for-all before OpenAPI (Swagger) came along and said, “Hey, maybe we should all describe our endpoints the same way”? Well, AI agents are having their own Wild West moment right now, and it’s exactly as messy as you’d imagine.
Meet Agent Definition Language (ADL) — the open-source standard that’s trying to bring some order to this chaos. Think of it as the “OpenAPI for AI agents,” except instead of defining what an API endpoint does, it defines what an agent is, what tools it can use, what data it can access, and most importantly, what guardrails keep it from going rogue.
And before you groan thinking this is yet another tech company trying to lock everyone into their ecosystem, plot twist: it’s open source under Apache 2.0. The folks at Next Moca literally said, “We’re giving this to the world because the alternative — fragmented, incompatible agent definitions across every platform — is worse for everyone.”
The Problem: Everyone’s Speaking a Different Language
Here’s what’s happening right now in enterprise AI: Team A defines their customer support agent using a YAML file. Team B hard-codes everything in Python. Team C uses some proprietary JSON format that only works with their vendor’s platform. Meanwhile, the security team is pulling their hair out asking basic questions like:
- “What tools can this agent actually call?”
- “What data can it read or write?”
- “Can it access the internet?”
- “What happens if it fails?”
Without a standard way to define agents, these questions require manual code reviews, digging through documentation, and a lot of trust that developers documented everything correctly. Spoiler: they didn’t.
It’s like having a company full of contractors who all speak different languages, use different tools, and document their work on random sticky notes scattered across different filing systems. Good luck auditing that when regulators come knocking.
What ADL Actually Is (Without the Marketing Fluff)
ADL is a declarative, vendor-neutral specification that describes an AI agent in a structured, machine-readable format. It’s typically written in JSON and validated against a standardized schema. Think of it as a blueprint or contract that says: “This is Agent X, here’s what it does, here’s what it’s allowed to touch, and here’s how it’s configured.”
An ADL definition captures everything you need to know about an agent:
1. Agent Identity and Metadata
Who owns this thing? What version is it? When was it last updated? This is your paper trail.
{
"name": "customer_support_agent",
"display_name": "Customer Support Assistant",
"description": "Handles tier-1 customer inquiries and ticket routing",
"role": "Customer Service Agent",
"version": "2.1.0",
"owner": "[email protected]",
"created_by": "[email protected]",
"created_at": "2025-01-15T10:30:00Z"
}
2. LLM Configuration
Which language model powers this agent? What temperature setting? How many tokens can it generate? This stuff matters when you’re troubleshooting why an agent suddenly started giving weird answers.
{
"llm": "openai",
"llm_settings": {
"model": "gpt-4",
"temperature": 0.7,
"max_tokens": 2048,
"top_p": 0.9
}
}
3. Tools and Capabilities
This is the heart of the agent definition. What functions can it call? What parameters do those functions take? Can it send emails? Query databases? Book flights?
{
"tools": [
{
"name": "search_knowledge_base",
"description": "Searches internal documentation and FAQs",
"parameters": [
{
"name": "query",
"type": "string",
"description": "Search query text",
"required": true
},
{
"name": "max_results",
"type": "integer",
"description": "Maximum number of results to return",
"required": false
}
],
"invocation": {
"type": "python_function"
}
},
{
"name": "create_support_ticket",
"description": "Creates a new support ticket in the system",
"parameters": [
{
"name": "title",
"type": "string",
"required": true
},
{
"name": "description",
"type": "string",
"required": true
},
{
"name": "priority",
"type": "string",
"enum": ["low", "medium", "high", "urgent"],
"required": true
}
],
"invocation": {
"type": "http",
"endpoint": "https://api.company.com/tickets",
"method": "POST"
}
}
]
}
4. RAG (Retrieval-Augmented Generation) Inputs
What knowledge bases can this agent query? Where are they stored? What kind of data do they contain?
{
"rag": [
{
"id": "product_docs_index",
"name": "Product Documentation",
"rag_type": "doc",
"virtual_index_path": "/indices/product-docs",
"location_type": "pinecone",
"metadata": {
"domain": "product_knowledge",
"last_updated": "2025-02-01T00:00:00Z"
}
}
]
}
5. Permissions and Security Boundaries
This is where enterprises get serious. What files can this agent read or write? Can it access the network? Which environment variables does it need?
{
"permissions": {
"network": {
"enabled": true,
"allowed_domains": ["api.company.com", "docs.company.com"]
},
"file_read": [
"/data/customer-info/*",
"/config/agent-settings.json"
],
"file_write": [
"/logs/agent-activity.log"
],
"env_vars": [
"API_KEY",
"DATABASE_URL"
]
}
}
Why This Matters More Than You Think
For Developers: You define your agent once, and it works across different platforms. No more rewriting agent configurations because you switched from one framework to another. It’s like writing HTML that works in Chrome, Firefox, and Safari — that’s the dream.
For Security Teams: Finally, a single artifact they can audit. “Show me all agents that can write to the customer database” becomes a simple query instead of a week-long investigation. They can set policies like “No agent with network access can also write to the file system” and actually enforce them.
For Compliance Officers: When auditors ask “How do your AI systems work?” you hand them ADL files. These are version-controlled, timestamped, and show exactly what changed and when. It’s the audit trail that actually makes sense.
For Platform Vendors: Instead of inventing yet another proprietary agent format, they can support ADL and instantly integrate with everyone else’s tooling. It’s how the entire ecosystem grows faster together.
How ADL Fits Into the Bigger Picture
Here’s where people get confused: ADL isn’t trying to replace other standards. It’s complementary. Let me break down the distinctions:
ADL vs. A2A (Agent-to-Agent Communication)
- A2A defines how agents talk to each other during runtime — the messaging, coordination, and handoffs
- ADL defines what each agent is — its capabilities, configuration, and boundaries
- Analogy: A2A is like HTTP (how systems communicate), ADL is like OpenAPI (what each system does)
ADL vs. MCP (Model Context Protocol)
- MCP is about how models access tools and context at runtime — the plumbing for tool invocation
- ADL is about what tools an agent is allowed to use — the declarative specification
- Relationship: An agent defined in ADL might use MCP to actually call its tools during execution
ADL vs. OpenAPI
- OpenAPI describes REST APIs — endpoints, request/response formats
- ADL describes agents — reasoning entities with tools, memory, and permissions
- Key difference: APIs are stateless request handlers; agents are stateful, reasoning systems
Think of it this way: if you’re building a house, OpenAPI describes the plumbing specifications, MCP describes how water flows through pipes, A2A describes how different rooms communicate, and ADL describes the entire house blueprint — what’s in each room, who can enter, and what they’re allowed to do there.
A Real-World Example: The Campaign Image Generator
Let’s look at a complete, practical ADL definition for a marketing agent that generates campaign images:
{
"name": "campaign_image_generator",
"description": "Generate a 1024x1024 marketing image from a creative brief.",
"role": "Creative Producer",
"version": "1.0.0",
"llm": "openai",
"llm_settings": {
"temperature": 0.8,
"max_tokens": 4096
},
"tools": [
{
"name": "generate_campaign_image",
"description": "Generate a high-quality image from a prompt.",
"parameters": [
{
"name": "prompt",
"type": "string",
"description": "Detailed image generation prompt including style, mood, and composition",
"required": true
},
{
"name": "style",
"type": "string",
"enum": ["photorealistic", "illustration", "3d-render", "minimalist"],
"description": "Visual style for the generated image",
"required": false
}
],
"invocation": {
"type": "python_function",
"module": "image_generation.dalle",
"function": "create_image"
}
}
],
"rag": [],
"permissions": {
"network": {
"enabled": true,
"allowed_domains": ["api.openai.com"]
},
"file_write": [
"/output/campaign-images/*"
]
},
"dependencies": {
"python": [
"openai>=1.0.0",
"pillow>=10.0.0"
]
}
}
This single file tells you everything: what the agent does, what tools it can use, where it can save files, what dependencies it needs, and how it’s configured. Any developer can read this and understand the agent without digging through code. Any security team can audit it without running the agent first.
The Open Source Advantage
Next Moca could have kept ADL proprietary and built a moat around it. Instead, they chose Apache 2.0 licensing, which means:
- No vendor lock-in: You can use ADL with any platform, any framework, any vendor
- Patent protection: Contributors grant patent licenses, so you won’t get sued for using it
- Community-driven evolution: Anyone can propose improvements, extensions, or domain-specific variants
- Enterprise-friendly: Large companies can adopt it without legal headaches
The Apache 2.0 choice wasn’t altruistic naivety — it was strategic pragmatism. Standards only work when everyone adopts them. Making ADL proprietary would’ve ensured it remained a niche tool for one vendor’s ecosystem. Making it open source gives it a shot at becoming the actual standard that everyone uses.
What’s Coming Next
ADL v1 focuses on single-agent definitions. The roadmap includes some genuinely interesting directions:
Multi-agent specifications: Defining not just individual agents but entire teams of agents, their roles, and how they coordinate. Think “organizational chart for AI agents.”
Workflow integration: Linking ADL directly into workflow engines like Airflow or Temporal, so your agents become first-class citizens in your orchestration logic.
Domain-specific extensions: Healthcare, finance, and other regulated industries will want specialized fields — “HIPAA compliance flags” or “SOC 2 audit metadata” — while keeping the core standard intact.
Memory models: Defining how agents remember things across sessions — what they store, how long they keep it, and who can access it.
How to Actually Use This
If you’re intrigued and want to start experimenting, here’s the practical path:
1. Start small: Pick one existing agent in your organization and write its ADL definition. You don’t need to change how the agent runs — just document it in ADL format.
2. Add validation: Set up a CI/CD pipeline that validates ADL files against the JSON Schema. This catches configuration errors before they hit production.
3. Build your agent catalog: Create a repository of ADL files for all your agents. Suddenly you have visibility into your entire agent ecosystem.
4. Integrate with your platform: If you’re building agent infrastructure, make ADL files a first-class input. Parse them, validate them, use them to configure runtime behavior.
5. Contribute back: Found something missing? Propose an RFC. Built cool tooling? Share it. That’s how open standards actually improve.
The Bigger Picture: Why Standards Matter
Here’s the thing about technology standards: they’re boring until they’re not. Nobody thinks HTML is exciting, but try building the modern web without it. Nobody wakes up excited about USB-C, but we’re all grateful we don’t need 47 different chargers anymore.
AI agents are following the same trajectory. Right now, every company is building their own agent formats, their own configurations, their own governance systems. It’s innovative chaos. Five years from now, we’ll look back and wonder why we tolerated the fragmentation.
ADL isn’t perfect — no v1.0 standard ever is. But it’s tackling a real problem that enterprises are feeling right now: “How do we deploy hundreds of agents without losing control?” And it’s doing it the right way: openly, collaboratively, with a focus on interoperability rather than vendor lock-in.
The agent era is here. The question isn’t whether we need standards — we absolutely do. The question is whether we’ll collectively rally around good ones like ADL, or whether we’ll spend the next decade building incompatible silos that make 1990s corporate intranets look like paragons of interoperability.
I’m betting on the standards. They tend to win eventually.
Getting Started
Want to dive deeper? The ADL project lives on GitHub with full documentation, examples, and the JSON Schema specification. You can read the spec, try writing your own ADL definitions, or contribute to the project.
The repository also includes validators, example agents, and integration guides for popular frameworks. Whether you’re building agent infrastructure or just trying to bring order to your organization’s agent chaos, it’s worth a look.
Because ultimately, the best standard is the one everyone actually uses. And for that to happen, it needs to be open, practical, and solve real problems. ADL checks all three boxes.