ABL Overview - Kore.ai Docs

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.

​File structure

​File extensions

​Required sections

​Recognized top-level sections

​Syntax rules

​Indentation

​Keywords

​Comments

​Strings

​Lists

​Auto-detection

​YAML format

​Version declaration

​Template interpolation