ABL language overview

Agent Blueprint Language (ABL) is the enterprise control plane for agentic AI — a schema-driven language purpose-built for multi-agent orchestration where deterministic governance meets autonomous reasoning. ABL spans the full control spectrum: delegate autonomously, supervise selectively, or lock down as a deterministic state machine. Agent definitions compile into immutable artifacts, and AI can author blueprints just as humans do.

File structure

An ABL document is a plain-text file composed of top-level sections, each introduced by an uppercase keyword followed by a colon. Sections can appear in any order, but by convention the AGENT: declaration comes first.

AGENT: Customer_Support

GOAL: |
  Help customers resolve billing questions.

PERSONA: |
  Friendly, patient support representative.

TOOLS:
  lookup_account(account_id: string) -> {name: string, balance: number}
    description: "Retrieve account details"
    type: http
    endpoint: "/api/accounts/lookup"
    method: POST

GATHER:
  account_id:
    prompt: "What is your account number?"
    type: string
    required: true

File extensions

Extension	Contents
.agent.abl	Agent definition (most common)
.tools.abl	Reusable tool library (see Tool file imports)
.agent.yaml	Agent definition in YAML format

Required sections

Every agent document must contain:

• AGENT: — the agent name
• GOAL: — the agent’s objective

All other sections are optional. If a section is omitted, its value defaults to empty (empty list, empty object, or platform defaults as specified in each section’s reference).

Recognized top-level sections

Section	Purpose	Reference
AGENT:	Agent name declaration	Agent declaration
VERSION:	Semantic version	Agent declaration
DESCRIPTION:	Human-readable description	Agent declaration
LANGUAGE:	Agent language code	Agent declaration
GOAL:	Agent objective	Agent declaration
PERSONA:	Agent personality description	Agent declaration
LIMITATIONS:	Explicit boundaries	Agent declaration
IDENTITY:	Combined identity block	Agent declaration
INSTRUCTIONS:	Operational instructions	Agent declaration
EXECUTION:	Model and runtime configuration	Agent declaration
TOOLS:	Tool definitions	Tools
GATHER:	Information collection fields	GATHER
FLOW:	Structured execution steps	FLOW
MEMORY:	Session and persistent state	Memory & Constraints
CONSTRAINTS:	Business rule enforcement	Memory & Constraints
GUARDRAILS:	Input/output safety checks	Guardrails
DELEGATE:	Sub-agent delegation	Multi-Agent & Supervisor
HANDOFF:	Agent transfer	Multi-Agent & Supervisor
ESCALATE:	Human escalation	Multi-Agent & Supervisor
COMPLETE:	Completion conditions	Multi-Agent & Supervisor
ON_ERROR:	Error handlers	Lifecycle & Hooks
ON_START:	Session initialization	Lifecycle & Hooks
MESSAGES:	Customizable system messages	—
TEMPLATES:	Reusable response templates	Rich Content & Expressions
HOOKS:	Lifecycle event handlers	Lifecycle & Hooks
NLU:	Natural language understanding	NLU
MULTI_INTENT:	Multi-intent configuration	NLU
LOOKUP_TABLES:	Reference data for validation	Data Types & Utilities
SYSTEM_PROMPT:	Custom system prompt template	—
ATTACHMENTS:	File/media collection	Data Types & Utilities

Syntax rules

Indentation

ABL uses indentation to express nesting. Use spaces (two or more) for indentation. Tabs are accepted but spaces are preferred for consistency. Content nested under a section keyword must be indented further than the keyword line.

TOOLS:
  search(query: string) -> {results: string[]}
    description: "Search the catalog"
    type: http
    endpoint: "/api/search"
    method: GET

Keywords

Section keywords are uppercase by convention and followed by a colon (:). Keywords are case-insensitive at the parser level — AGENT:, agent:, and Agent: all parse identically. However, uppercase is the canonical style for the ABL format.

In YAML format files (.agent.yaml), lowercase keywords are used exclusively.

Comments

Lines beginning with # are comments and are ignored by the parser. Comments can appear anywhere in the file.

# This is a comment
AGENT: My_Agent

GOAL: "Help with orders"  # Inline comments are NOT supported in ABL format

Strings

Strings can be written in several forms:

Form	Syntax	Use case
Quoted	"value"	Single-line values
Unquoted	value	Simple values without special characters
Pipe block	| followed by indented lines	Multi-line text (preserves newlines)

GOAL: "Single line goal"

GOAL: |
  Multi-line goal that preserves
  line breaks within the block.

LANGUAGE: "en"

Lists

Lists use YAML-style - item syntax with indentation:

LIMITATIONS:
  - "Cannot access external systems"
  - "Cannot process payments directly"

Auto-detection

The parser determines the document type from the first meaningful keyword it encounters:

First keyword	Document type
AGENT:	Agent document
SUPERVISOR:	Supervisor document
BEHAVIOR_PROFILE:	Behavior profile document
TOOLS: (at root level in a .tools.abl file)	Tool file document

Within an agent document, execution mode is not declared via a global MODE: keyword. Instead, agents operate in reasoning mode by default — the LLM decides which tools to call and when, guided by the GOAL: and PERSONA:.

Any agent can optionally include a FLOW: section to add structured execution steps. Adding a FLOW: section gives the agent a step-by-step execution graph. Each step within the flow declares REASONING: true or REASONING: false to control whether that individual step uses LLM reasoning or deterministic execution.

Note: The MODE: keyword is deprecated and produces a parser error if used. Remove it and use per-step REASONING: declarations within FLOW: instead.

YAML format

ABL supports an alternative YAML format for agent definitions. YAML files use .agent.yaml as their extension. The parser auto-detects YAML format by checking whether the first non-comment, non-empty lines use lowercase keys matching known ABL sections (agent, goal, persona, tools, etc.).

agent: Customer_Support

goal: |
  Help customers resolve billing questions.

persona: |
  Friendly, patient support representative.

tools:
  - name: lookup_account
    parameters:
      - name: account_id
        type: string
    returns:
      type: object
      fields:
        name: string
        balance: number
    description: Retrieve account details
    type: http
    endpoint: /api/accounts/lookup
    method: POST

Both formats produce the same intermediate representation (AST) and compile to identical runtime artifacts.

Version declaration

The optional VERSION: directive specifies the document version in semver format:

VERSION: "2.0.0"

When omitted, the version defaults to "1.0.0". The version is stored in the document metadata and can be used for compatibility tracking.

Template interpolation

Throughout ABL, string values support template interpolation using double-brace syntax:

"Hello, {{customer_name}}. Your balance is {{balance}}."

Conditional blocks use Handlebars-style helpers:

"{{#if exchange_rate}}Rate: {{exchange_rate}}{{/if}}"

Template expressions are resolved at runtime against session variables and tool results.