YAML configuration files define your multi-agent system’s structure, behavior, and capabilities. This guide covers the complete configuration schema with practical examples.Documentation Index
Fetch the complete documentation index at: https://docs.atthene.com/llms.txt
Use this file to discover all available pages before exploring further.
Configuration Structure
Every YAML configuration follows this basic structure:Core Fields
The following sections detail all configuration parameters available in your YAML file.System Configuration
These parameters are defined at the root level of your YAML configuration:Name of your multi-agent system
Brief description of what your system does
Architecture pattern for agent coordinationOptions:
workflow- Linear or branching agent workflows with explicit edgessupervisor- Multi-agent coordination with a supervisor agent
Additional architecture types (
routing, orchestration, collaboration) are defined but not yet implemented.Maximum number of steps allowed in workflow execution to prevent infinite loops. Controlled by environment variables:
- Default:
AGENT_ITERATION_LIMITenv var (fallback: lower limit) - Range:
AGENT_ITERATION_LOWER_LIMIT(default 5) toAGENT_ITERATION_UPPER_LIMIT(default 50)
Name of the agent that receives the initial user input. Must match an agent name in the
agents list.Whether to persist messages in the agent session for conversation history
Enable checkpointing for state persistence across executions
Variable schema for dynamic values updated during execution. Defines variables that can be modified by agents.
Global memory system configuration (applies to all agents unless overridden). Note that
agent scoped modules are not allowed at the system level.Agent Configuration
Each agent in theagents list requires these fields. These parameters are defined within individual agent objects:
Basic Agent Fields
Unique identifier for the agent within the system
Type of agent to instantiate. See Agent Types for available options.Common types:
llm_agent- Basic LLM-powered conversational agentreact_agent- ReAct pattern agent with tool callingsupervisor- Supervisor agent for multi-agent coordination
Human-readable description of the agent’s purpose and capabilities
List of dependencies on other agents’ structured outputs (e.g.,
[{"agent": "classifier"}])List of output declarations for this agent
List of knowledge base references or configurations accessible to this agent. Both strings and detailed objects are supported.
Agent-specific memory configuration (overrides system-level memory config)
Prompt Configuration
Configure how the agent’s prompt is composed. This is nested within each agent’s configuration:Prompt composition configuration
The
system_prompt field must be placed inside prompt_config, not at the agent level. While some examples may show system_prompt at the agent level for brevity, the correct location is prompt_config.system_prompt.LLM Configuration
Configure the language model for your agents. This is nested within each agent’s configuration:Configuration for the language model
Streaming Configuration
Control real-time event streaming for each agent. This is nested within each agent’s configuration:Controls real-time event streaming behavior
Structured Output
Agents can be configured to produce structured data (JSON) matching a specific schema instead of unstructured text. This uses BAML under the hood for reliable extraction.Configuration for structured output generation.
Variable Assignments
Map agent outputs (either structured output fields or raw text) to system variables. This allows sharing data between agents across the workflow.Dictionary mapping system variable names to their values. Values can be:
- References to structured output fields (e.g.,
"agent_name.output.field_name") - References to raw agent text (e.g.,
"agent_name.output") - Static values (e.g.,
10,"fixed_string")
Tool Configuration
Tools can be configured at two levels. Choose the approach that best fits your use case:Agent-Level Tools (Recommended)
Configure tools directly within each agent’s configuration:List of tool identifiers for this agent. Only applicable for
react_agent type.Example tools: tavily_search, tavily_extract, calculatorSystem-Level Tools (Advanced)
Define tools at the root level for reuse across multiple agents:Optional system-level tool definitions. This is for advanced configurations where you want to define tool configurations once and reference them across multiple agents.
Most users should configure tools at the agent level. System-level tools are for advanced use cases.
Tool Calling Behavior
The ReAct agent’s iteration limit is configured directly on the agent, not in a nestedtool_calling object:
Maximum number of ReAct reasoning-action-observation cycles. Only applicable for
react_agent type. Prevents infinite tool calling loops.There is no
tool_calling configuration object. Tool calling is always enabled for react_agent agents when tools are provided. Use max_iterations at the agent level to control the iteration limit.Supervisor Configuration
For supervisor agents only. These parameters are configured within the supervisor agent’s configuration object:Required for supervisor agents. List of agent names that this supervisor coordinates. Must contain at least one agent.
Whether worker agents should return control to the supervisor after completing their tasks. Set to
false for simple one-way delegation where workers respond directly to the user.Maximum number of agent handoffs to prevent infinite coordination loops
Additional tools for the supervisor agent (the handoff tool is automatically injected)
Supervisor agents use
prompt_config.system_prompt for their coordination instructions. There is no separate supervisor_prompt field. The system prompt is injected into a template that adds routing and evaluation logic around your custom instructions.Workflow Edges
Forworkflow architecture only. Define edges at the root level to connect agents in your workflow:
__start__orSTART- Entry point of the workflow__end__orEND- Exit point of the workflow
Dynamic edges can use the
llm_model parameter to specify an evaluation model compatible with BAML (e.g. google_gemini, azure_openai, mistral, telekom_otc). If omitted, the system default is used.Supervisor architecture does not require explicit edges - the supervisor handles routing dynamically.
Complete Examples
Basic Conversational Agent
Tool-Enabled Agent
Supervisor Multi-Agent System
Best Practices
Validation
The system automatically validates your configuration:- Required fields are checked
- Agent types are verified against the registry
- Entry point must reference an existing agent
- Supervised agents must exist in the agents list
- Edges must reference valid agent names
Next Steps
Agent Types
Learn about available agent types and when to use each
Agent Capabilities
Explore tools, streaming, and other agent capabilities