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.

Design principles

ABL agents are goal-driven rather than script-driven. Rather than encoding an explicit numbered state machine, you declare the outcome the agent should achieve and the rules it must respect, and the runtime reasons toward that goal — falling back to deterministic execution wherever you need it.

Goal-oriented — agents work toward a declared GOAL:, not through hard-coded scripts.
Constraint-guarded — business rules are enforced by CONSTRAINTS: and GUARDRAILS:, independent of step order.
Memory-enabled — agents can remember user and session state across turns and sessions.
Composable — agents can DELEGATE: to sub-agents or HANDOFF: to peers and supervisors.
Human-in-the-loop — ESCALATE: provides explicit paths to human operators.

Reasoning and determinism are not either/or. An agent reasons by default; adding a FLOW: section lets you make any part of the conversation deterministic, step by step (see Auto-detection).

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	Lifecycle & Hooks
`TEMPLATES:`	Reusable response templates	Rich Content & Expressions
`HOOKS:`	Lifecycle event handlers	Lifecycle & Hooks
`NLU:`	Natural language understanding	NLU
`MULTI_INTENT:`	Multi-intent configuration	NLU
`INTENTS:`	Intent categories (routing)	NLU
`ENTITIES:`	Reusable named entities	NLU
`LOOKUP_TABLES:`	Reference data for validation	Data Types & Utilities
`SYSTEM_PROMPT:`	Custom system prompt template	Agent declaration
`ATTACHMENTS:`	File/media collection	Data Types & Utilities
`DESTINATIONS:`	Outbound HTTP delivery targets	Data Types & Utilities
`TRANSFER_FLOW_POLICIES:`	Named policies referenced by escalation routing	Multi-Agent & Supervisor
`RETURN_HANDLERS:`	Named parent-resume handlers for returnable handoffs	Multi-Agent & Supervisor
`ACTION_HANDLERS:`	Reusable interactive-action handlers	Rich Content & Expressions
`CONVERSATION:`	Conversation-behavior configuration	Behavior profiles

TESTS: is a reserved section name the parser accepts but currently ignores — content under it is parsed and discarded with no effect. It exists to avoid “unknown section” errors; do not rely on it for behavior.

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 followed by a colon (:). In the .agent.abl format, section keywords must be uppercase (AGENT:, GOAL:, TOOLS:, …). In the .agent.yaml format, they must be lowercase (agent:, goal:, …). Mixed case is not supported, and the two formats do not accept each other’s casing.

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.

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.

Compilation

ABL source files are compiled to a typed intermediate representation (AgentIR) at deploy time. The runtime loads and executes the IR directly — there is no code-generation step.

ABL source (.agent.abl / .agent.yaml)
        │
        ▼
   Parser        → parses the document into an AST
        │
        ▼
   Compiler      → produces a CompilationOutput: a map of AgentIR
        │           instances (one per agent, including supervisors)
        │           plus the entry agent
        ▼
   Runtime       → loads the IR and executes it (reasoning loop,
                   flow steps, routing, constraint checking)

Each agent (and supervisor) compiles to a single AgentIR that gathers the document’s sections into typed configuration — identity (from GOAL/PERSONA/LIMITATIONS, including a generated system prompt), tools, gather, constraints and guardrails, coordination (handoffs/delegates/escalation), completion, and memory. Supervisors are ordinary agents with routing populated, so a project’s agents and supervisors all live in one registry and can compose hierarchically.

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.

​Design principles

​File structure

​File extensions

​Required sections

​Recognized top-level sections

​Syntax rules

​Indentation

​Keywords

​Comments

​Strings

​Lists

​Auto-detection

​YAML format

​Version declaration

​Compilation

​Template interpolation

Design principles

File structure

File extensions

Required sections

Recognized top-level sections

Syntax rules

Indentation

Keywords

Comments

Strings

Lists

Auto-detection

YAML format

Version declaration

Compilation

Template interpolation