Source-linked AI summary
ADL: A Declarative Language for Agent-Based Chatbots
Sirui Zeng, Xifeng Yan
TL;DR
Customer-service agent frameworks can couple agent declarations with Python code, making their design harder to understand and maintain. The paper introduces ADL, a declarative language for defining agents and their interactions; its experiments report trade-offs among orchestration methods, while the authors note limits in scenario coverage and evaluation.
Problem
Agent declarations interleaved with Python can make customer-service chatbot designs difficult to grasp and runtime-optimize, while a single large prompt can complicate development, debugging, maintenance, and reuse.
Source: §1 · p. 1Method
Results
Merging achieved the lowest cost and latency, while Best-of-N had the highest output quality at high cost; GPT-4o accurately detected an ADL infinite loop but falsely flagged an impossible Swarm loop.
Source: §4 · p. 4, §6.2 · p. 5Takeaways & Limitations
ADL separates agent task specification from system implementation and optimization, which the authors say makes programs easier to understand and maintain.
Source: §8 · p. 6The orchestration comparisons cover token cost and latency, not more complex scenarios; further system-level optimization experiments remain necessary.
Source: Limitations · p. 7
Abstract
from arXiv · showhide
There are numerous frameworks capable of creating and orchestrating agents to address complex tasks. However, most of them highly coupled Python programming with agent declaration, making it hard for maintenance and runtime optimization. In this work, we introduce ADL, an agent declarative language for customer service chatbots. ADL abstracts away implementation details, offering a declarative way to define agents and their interactions, which could ease maintenance and debugging. It also incorporates natural language programming at its core to simplify the specification and communication of chatbot designs. ADL includes four basic types of agents and supports integration with custom functions, tool use, and third-party agents. MICA, a multi-agent system designed to interpret and execute ADL programs, has been developed and is now available as an open-source project at https://github.com/Mica-labs/MICA. Its documentation can be found at https://mica-labs.github.io/.
1 Introduction
The paper presents ADL as a structured way to define customer-service agents and their relationships, addressing the difficulty of maintaining agent designs interleaved with Python code. It separates agent specification from implementation and runtime optimization.
1 Introduction
- Existing agent frameworks can be overly complicated for customer-service chatbots because agent declarations are interleaved with Python code, obscuring design and runtime optimization.The introduction also notes that a single, oversized prompt can complicate development, debugging, maintenance, and reuse as business logic evolves.Source: §1 · p. 1
- ADL declaratively and structurally describes agents and their relationships, leaving implementation and optimization issues to the underlying multi-agent system.The authors say this abstraction avoids manual reprogramming when the underlying system changes.Source: §1 · p. 1
- ADL’s design principles are modular separation of logic from execution, extensive natural-language programming, and leaving runtime optimization to the underlying system.The authors state that ADL programs can benefit from LLM advances without code revisions.Source: §1 · pp. 1–2
- MICA, a system for interpreting and executing ADL programs, is available as open source; a few novice users reported that it was faster to learn and program.The paper also presents MICA as an implementation of ADL.Source: §1 · p. 2
2 Declarative Language
ADL supports modular task-oriented chatbot design through four agent types, with ensemble agents coordinating other agents. Its language also supports guardrails and integration with custom functions, tools, and third-party agents.
2 Declarative Language
- ADL defines four agent types: knowledge-base agents retrieve information and answer questions, LLM agents handle business logic in natural language, flow agents provide domain-specific control flow, and ensemble agents orchestrate agents.Knowledge-base agents are atomic, while the other agent types can call agents.Source: §2 · p. 2
- Guardrail agents can run before and after other agents in an ensemble to detect potentially problematic inputs or outputs.The bookstore example includes a relevance guardrail intended to prevent answers to irrelevant user input.Source: §2 · p. 2
- ADL supports rapid prototyping with LLM agents, step-by-step control with flow agents, and integration with custom functions, tools, and third-party agents.The paper points to the appendix for detailed syntax and grammar.Source: §2 · p. 2
3 Natural Language Programming
ADL uses natural-language programming to make agent definitions easier to specify and customize. It makes user interaction explicit, supports natural-language conditions, and lets agent policies be expressed in natural language.
3 Natural Language Programming
- ADL incorporates natural language to make defining and customizing agents easier for a wider audience.This is the section’s stated aim for natural-language programming.Source: §3 · p. 2
3.1 Interactive Syntax
- ADL explicitly shows the user-input and bot-response interaction that can be unclear in other systems’ code.The example describes a user input, a condition check, a bot reply, and then waiting for another input.Source: §3.1 · pp. 2–3
3.2 Natural Language Condition
- ADL replaces code-level intent checking with a single natural-language condition that directly analyzes user input using an LLM.The example condition checks whether a user is asking about baggage allowance.Source: §3.2 · p. 3
3.3 Natural Language Policy
- Agent descriptions, fallback policies, and exit conditions can be written in natural language to help LLMs select an agent and handle requests.The section’s exit-policy example specifies reminders after 30 seconds without input and a goodbye after 3 minutes.Source: §3.3 · p. 3
4 Separation of Logic and Optimization
ADL separates agent design from runtime optimization, leaving orchestration choices to the underlying multi-agent system. Across the compared methods, merging had the lowest cost and latency, while Best-of-N had the highest output quality but high cost.
4 Separation of Logic and Optimization
- ADL lets developers focus on desired bot outputs while leaving system-performance tuning to the underlying multi-agent system.Autonomous avoids ensemble-agent calls but incurs slightly higher token execution cost; proactive has similar token costs to merging but slightly higher latency.Source: §4 · pp. 3–4
- The comparison covered Merging, First-Success, Best-of-N, Proactive, and Autonomous orchestration methods.The experiment used intent-shifting dialogue turns and averaged five runs per dialogue sequence.Source: §4 · pp. 3–4
- Merging combines consecutive LLM agents; First-Success iterates until an agent responds satisfactorily, while Best-of-N runs all agents in parallel and selects a response.Proactive selects an agent based on its description and the request; Autonomous lets the active agent choose the next agent.Source: §4 · pp. 3–4
- The evaluation measured token cost and latency, with each dialogue sequence run five times and averaged.Token cost is the average total prompt tokens used by invoked agents per turn; latency is average elapsed time from user input to bot response.Source: §4 · p. 4
- Merging achieved the lowest cost and latency, while Best-of-N had the highest output quality but high cost.Merging integrates the guardrail with other agents; Best-of-N typically calls all agents in each conversation round.Source: §4 · p. 4, Table 1 · p. 4
5 Case Study: Maintainability
The bookstore example illustrates how ADL can accommodate a new discount flow with a small change, while Python-based logic requires more involved updates and maintenance.
5 Case Study: Maintainability
- A discount interaction can be added to the ADL bookstore bot with a few lines, whereas equivalent step-by-step control in Swarm requires more extensive modification.The proposed change adds a branch for the discount request.Source: §5 · p. 4
- In Python, changing the intent set requires updating an explicitly maintained intent-classifier agent.The example also shows new classifier and intent-list code for adding the discount intent.Source: §5 · p. 4
- As conversation logic grows, Python implementations may accumulate internal state variables and become less readable and maintainable.Changes in conversation logic often introduce additional internal state variables.Source: §5 · p. 4
6 Case Study: Debugging Assistance
The case study presents LLM-assisted debugging as a potential use for ADL’s more comprehensible natural-language flows, then illustrates an infinite-loop detection scenario in a retail banking bot. GPT-4o detected the ADL loop but incorrectly inferred one in Swarm.
6 Case Study: Debugging Assistance
- ADL’s natural-language flow is presented as more comprehensible than a hybrid natural-language-and-Python form, motivating LLM debugging assistance.The authors describe the example as illustrative rather than a comprehensive evaluation.Source: §6 · p. 5
6.1 Retail Banking Bot
- The retail banking bot comprises eight agents for functions including FAQ handling, transfers, payee management, balance inquiries, and card blocking.The implementation intentionally includes an infinite-loop bug.Source: §6.1 · p. 5
6.2 Debugging Infinite Loops
- The simulated loop cycles between money transfer and add_payee when the latter mistakenly asks about a transfer and the user agrees.A transfer requires a payee, so the transfer agent invokes add_payee to validate one; add_payee then directs the user back to transfer_money.Source: §6.2 · p. 5
- GPT-4o accurately detected the infinite loop in the ADL implementation but incorrectly identified an impossible loop in Swarm.In Swarm, the triage agent can tell whether the greeting agent has already run, preventing that loop.Source: §6.2 · p. 5, Table 2 · p. 6
- The authors attribute Swarm’s false loop reasoning to a misinterpretation of function execution, where termination is inferred to trigger additional calls.They suggest the Python-and-prompt combination may make fine-grained control flow harder for an LLM to understand.Source: §6.2 · p. 5
- The example addresses infinite-loop detection; debugging flow agents is left for future investigation.The paper describes manual inspection of dialogue histories as time-consuming when prompts and agent interactions become complex.Source: §6.2 · pp. 5–6, §6 · p. 5
7 Related Work
Related work spans multi-agent systems, agent programming languages, and LLM-based frameworks. The paper positions ADL as a simpler customer-service chatbot approach that separates agent definitions from Python implementation.
7 Related Work
- Earlier multi-agent work studied cooperation, task representation, unified frameworks, and orchestration layers for chatbot agents.Examples include middle agents that integrate responses from other chatbot agents.Source: §7 · p. 6
- AgentSpeak, JADE, and GOAL are cited as agent programming languages, with GOAL distinguished by its declarative-goal concept.The passage cites AgentSpeak, JADE (Bellifemine et al., 2001), and GOAL (de Boer et al., 2002).Source: §7 · p. 6
- LLM-agent frameworks such as AutoGen, LangGraph, CrewAI, and Swarm offer flexible construction, but the paper notes that they do not separate declaration from implementation.The authors argue that Python integration offers library access, while decoupled definitions may suit customer-service chatbots.Source: §7 · p. 6
- Natural-language approaches have explored extracting agents from task descriptions and defining chatbots in natural language, though the latter requires more elaborate definitions as logic grows complex.The cited approaches are Trirat et al. (2024) and Rebedea et al. (2023).Source: §7 · p. 6
8 Conclusion
ADL defines multi-agent systems for task-oriented chatbots declaratively, separating agent-task specification from implementation and optimization. The conclusion identifies standardization, broader scenarios, and underlying-system optimization as future research needs.
8 Conclusion
- ADL is a declarative language for defining multi-agent systems for task-oriented chatbots.It separates agent-task specification from system implementation and optimization.Source: §8 · p. 6
- This separation is intended to make ADL programs easier to understand and maintain.Source: §8 · p. 6
- ADL is fully operational and available as an open-source package.Source: §8 · p. 6
- Future work should standardize interaction patterns among agents and explore declarative languages for more complicated scenarios.Source: §8 · p. 6
- Further work should examine system optimization of underlying MASs that run ADL programs.Source: §8 · p. 6
Limitations
The study does not evaluate orchestration performance in complex scenarios and limits comparisons to token cost and latency. Its automatic-debugging research covers infinite loops, while finer-grained conversation logic may widen the performance gap between declarative and programming definitions as understood by LLMs.
Limitations
- Orchestration methods were not evaluated in complex scenarios, and comparisons cover only token cost and latency.Further experiments on ADL for system-level optimization remain necessary.Source: Limitations · p. 7
- Automatic-debugging research focused exclusively on infinite loops, leaving other development problems for future investigation.Source: Limitations · p. 7
- As agent applications grow more complex and require finer-grained conversation logic, the performance gap LLMs perceive between declarative and programming definitions may widen.Further experimental validation is needed.Source: Limitations · p. 7
A ADL 1.0 Language Specification
The ADL 1.0 specification describes YAML programs using four agent types, flow-control constructs, and integrations with functions, tools, and third-party agents. It details how Python annotations and docstrings inform LLM tool descriptions and parameters, while noting that interfaces with external services and resources need further definition and interactive agents would require an additional external-agent type.
A ADL 1.0 Language Specification
- ADL programs are YAML collections of four agent types, with a required main entry agent and shared description, optional arguments, and fallback or exit policies.The four types are KB, LLM, Flow, and Ensemble; KB agents are atomic, while the other types can call one another.Source: A ADL 1.0 Language Specification · p. 9, B Language · p. 11
The user
- ADL’s preliminary specification prioritizes simplicity in agent programming, but its interfaces for tool calls, third-party agents, and external resources still need further specification.The paper identifies the Model Context Protocol as one example of a protocol for external resources.Source: The user · p. 11
B.2 KB Agent
- KB agents retrieve information and answer questions from sources or FAQs, whereas LLM agents encode domain knowledge and constraints in prompts and may use declared Python functions.An LLM agent can return control to other agents when its prompt does not let it respond adequately.Source: §B.2 · p. 11, §B.3 · pp. 11–12
B.4 Flow Agent
- Flow agents express predefined workflows in YAML: user steps wait for input, bot steps define replies, and calls invoke agents or functions with mapped arguments.Flow steps also support setting arguments and invoking subflows.Source: The user · p. 10, §B.4 · p. 12, §B.4.1 · p. 12
B.4.5 Condition
- Flow conditions can use user intent, argument expressions, or natural-language evaluation; labels and next support jumps and retries, while return ends a flow with success or error.The optional tries limit bounds retries; if omitted, retries are unlimited.Source: §B.4.6 · pp. 13–14, §B.4.5 · p. 13
B.5 Ensemble Agent
- An ensemble agent selects the next action from the conversation context, coordinating its listed agents through a natural-language strategy and optionally initializing steps.It can recommend selecting an agent, clarifying input, using a fallback, terminating, or waiting for the user.Source: §B.5 · p. 14
C Interfacing with External Services
- ADL supports external services through custom functions called in steps, functions exposed to LLM agents as tools, and third-party agents that can take over conversations.For tool calling, the function name must appear in the LLM agent’s prompt, and the function uses the custom-function format.Source: C Interfacing with External Services · p. 14, §C.2 · p. 15
C.1 Custom Function
- Custom functions use explicit arguments and a structured return format that separates caller messages, bot responses, and argument updates.Standard print output goes to the caller agent, while the function’s official return carries the bot response to the user.Source: §C.1 · p. 15
C.2 Tool Calling
- ADL parses Python function annotations as tool parameter types and uses function docstrings as descriptions, passing both to the LLM without requiring a separately specified request.The parsed information is transmitted to the LLM as attributes.Source: §C.2 · p. 15
C.3 Third-party Agents
- Custom functions can integrate non-interactive third-party agents, while interactive agents would require adding an external-agent type to share conversation context and state.The external-agent type is described as a possible future extension to ADL’s existing four agent types.Source: §C.3 · p. 15
D Retail Banking Bot
- The authors implement the same retail banking bot with ADL and Swarm, but exclude database-related code from the implementation.The provided implementation description is incomplete beyond this detail.Source: D Retail Banking Bot · p. 15
D.1 ADL Implementation
The implementation examples assemble banking tasks from specialized agents, flow steps, and function calls. They cover transfers, payee management, balance inquiries, and card blocking.
D.1 ADL Implementation
- Transfers collect account, payee, amount, and timing details, check payee existence and available funds, then process immediate payments or validate and schedule future-dated ones.The flow can cancel when funds are insufficient or the user declines to proceed or schedule.Source: §D.1 · pp. 15–16
- Balance inquiries ask for a username and account, then call functions to retrieve account information and report the selected account’s balance.A separate listing agent retrieves the user’s authorized payees after receiving the username.Source: §D.1 · pp. 16–17
- The card-blocking flow distinguishes reasons such as damage, loss, suspected fraud, or travel, updates card status, and can guide replacement-card delivery.For a replacement, it retrieves the user’s address and confirms delivery there.Source: §D.1 · p. 17
- The payee examples add a payee after collecting and confirming its details, while separate agents list or remove authorized payees.Adding a payee uses an action function and reports success or failure.Source: §D.1 · pp. 16, 18
- An ensemble agent maps banking tasks to specialized agents, while the session-start flow stores the user’s segment and contact details.The ensemble mappings pass username and, for card blocking, physical address; the startup example calls a session function and assigns returned values.Source: §D.1 · p. 18
D.2 Swarm Implementation
This section presents a banking-assistant implementation using specialized agents and tool-backed workflows, and contrasts ADL’s agent properties and natural-language logic with Rasa-CALM’s chatbot definitions through a conditional card-blocking example.
D.2 Swarm Implementation
- Card blocking classifies reasons such as loss, damage, theft, fraud, malfunction, or expiry, then may confirm replacement and delivery to the user’s address.The flow directs users reporting a lost or potentially fraudulent card to contact local law enforcement.Source: §D.2 · pp. 19–20
- A triage agent identifies the request topic, asks a direct question when needed, and transfers the user to the appropriate intent agent.Its instructions say not to disclose its reasoning or make unreasonable assumptions about the user.Source: §D.2 · p. 20
- Specialized policies guide adding payees, checking balances, listing or removing payees, and collecting service feedback through named functions and agent handoffs.Adding a payee gathers and confirms details before the action; balance lookup maps the selected account to its account number.Source: §D.2 · p. 21
- The transfer-money policy checks satisfaction, gathers account and payee details, verifies funds, then executes an immediate transfer or schedules a dated payment with confirmation.If funds are insufficient, the agent terminates; scheduled transfers require a future date and user confirmation.Source: §D.2 · p. 21
F Case Study
- Rasa-CALM combines predefined dialogue logic intended to reduce hallucination with LLM-based text comprehension, and the banking bot covers transfers, balances, payees, and card blocking.The example is a Retail Banking bot.Source: F Case Study · p. 24
F.1 Remove payee
- CALM separates flows, responses, actions, and slots, whereas ADL defines dialogue logic in natural-language prompts, arguments in args, and external functions under uses; ADL also supports a flow-agent form.The ADL flow-agent form expresses the logic as a list of steps.Source: §F.1 · pp. 24–25
F.2 Card blocking
- For card blocking, the bot asks the reason and varies its actions: it may deactivate, block, or temporarily block the old card, issue a new one, or direct the user to support.Damaged or expired cards prompt confirmation about issuing a replacement; lost or stolen cards are blocked before replacement, while travel or moving prompts a temporary block and replacement.Source: §F.2 · p. 25
F.2.1 CALM implementation
The examples contrast CALM’s state-declared card-blocking procedure with ADL implementations using an LLM prompt or Flow agent. The conclusion says ADL simplifies logic expression, but whether that produces a better implementation remains open and requires objective benchmarking.
F.2.1 CALM implementation
- The CALM example collects the blocking reason, branches to different responses for fraud or theft versus travel or moving, and proceeds through card-blocking actions.The example also includes prompts to confirm whether a new card is wanted and whether the delivery address is correct.Source: §F.2.1 · pp. 26–27
F.2.2 ADL implementation
- ADL presents the card-blocking procedure either as natural-language conversation logic in an LLM agent or as an explicit step-by-step Flow agent.The Flow version explicitly defines the logic flow.Source: §F.2.2 · pp. 28–29
F.3 Conclusion
- CALM’s state-declaration approach offers fine-grained control over dialogue content and progression but makes unforeseen real-conversation situations difficult to handle.Source: §F.3 · p. 30
- ADL simplifies programming through natural-language logic or intuitive flow structures, but whether this yields a better implementation remains open.The authors identify objective evaluation and a suitable comparison benchmark as ongoing needs.Source: §F.3 · p. 30