Documentation Index
Fetch the complete documentation index at: https://koreai-v2-home-nav.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
An AI-native platform for building, running, and governing programmable agent systems at enterprise scale.
Agent Platform 2.0 is the next-generation Kore.ai platform for designing, deploying, and operating intelligent agent systems.
The platform unifies conversational AI and agentic AI under a single programming model, so a single agent definition can combine deterministic workflows with autonomous reasoning.
Agent definitions are authored in Agent Blueprint Language (ABL), compiled to a portable intermediate representation, and executed by a single runtime that handles orchestration, observability, governance, and scale.
Key Capabilities
Agent Platform 2.0 introduces five capabilities that together change how enterprise agents are built and operated.
| Capability | Description |
|---|
| Agent Blueprint Language (ABL) | A typed, schema-driven domain-specific language for defining agent behavior. ABL provides formal constructs for goals, tools, memory, guardrails, handoffs, and delegation. Definitions are compiled and validated rather than stitched together as framework glue code. |
| Arch AI | A built-in multi-agent system that drives the full agent lifecycle — design, build, test, deploy, observe, and optimize — with a direct connection to the ABL compiler and runtime. Arch AI authors and validates ABL on the user’s behalf, so agent creation does not require writing ABL by hand. |
| Reasoning-aware Observability | Native tracing across agent delegation chains. Every reasoning step, tool call, routing decision, and guardrail evaluation is captured as structured trace data, making agent behavior auditable for compliance and debugging. |
| Agent Lifecycle as Code | Agent definitions are immutable YAML artifacts that are Git-native, diffable, and reviewable in pull requests. Agents move through development, staging, pilot, and production environments with the same software practices used for application code. |
| AI-native Foundation | A re-architected runtime that delivers the same enterprise capabilities as Platform 1.0 with at least 50% lower infrastructure footprint. Horizontally scalable from the ground up, with multi-tier guardrails, circuit breakers, and rate limits built in. |
Architecture
The platform is organized into four planes that sit on a shared enterprise foundation. Builders interact with the Studio plane; the Compiler and Runtime planes execute agents; the Operations plane provides observability and governance. The platform connects to enterprise ecosystems — AI models, channels, data sources, and cloud or on-premise infrastructure — through pluggable adapters.
Key Components
Each component delivers a focused capability. Components communicate through ABL-defined contracts and shared runtime services.
| Component | Description |
|---|
| Studio IDE | The authoring environment for agents. Includes the Agent Builder for visual editing, the Arch AI Assistant for conversational authoring, and a Monaco-based code builder for direct ABL editing. |
| ABL Compiler | Compiles ABL definitions through DSL → IR → Runtime stages. Output is Git-native and diffable. Compile-time validation catches missing tools, broken references, and contract violations before deployment. |
| Agent Runtime | Executes compiled agents. Handles reasoning, flow control, supervisor agents, and multi-agent orchestration. Runs both the agentic and deterministic execution paths defined in ABL. |
| Arch AI | Built-in AI that builds, manages, and optimizes agents. Operates across the full lifecycle, so users do not need to author ABL directly. Connects to the ABL compiler and runtime. |
| Tools and Integrations | The connectivity layer for external systems. Supports HTTP, MCP, AWS Lambda, SDK invocations, the A2A protocol, sandboxed tools, OpenAPI definitions, and webhooks. Includes circuit breakers and retry logic. |
| Search AI | The knowledge retrieval layer. Provides RAG, vector search, knowledge graph traversal, and reranking. Surfaces relevant context to agents during reasoning. |
| Workflow Engine | Runs long-running workflows that span minutes to days. Supports human-in-the-loop steps, approval gates, and durable execution that survives pod restarts. |
| Agent Evals | Automated evaluation framework. Provides test suites, regression tracking, and quality gates that run as part of the deployment pipeline. |
| Deep Observability | Captures over 200 trace events per session. Includes runtime inspection, alerting, and session-level debugging across multi-agent interactions. |
| Agent Insights | Analytics dashboards covering ROI tracking, experiments, user feedback, and usage patterns across deployed agents. |
| Operations and Analytics | Operational tooling: Observatory, traces, diagnostics, alerts, deployments, CI/CD, evals, ROI tracking, backup and disaster recovery, and voice analytics with quality monitoring. |
| Security and Governance | Enterprise controls: SSO, RBAC, guardrails, audit logging, encryption, KMS, multi-tenancy, PII detection, identity verification, and compliance reporting. |
| Enterprise Foundation | The platform substrate. Built ground-up for AI-native architecture with proven scalability. Provides versioning, environment management, and certifications for PCI, SOC 2, GDPR, and FedRAMP. |
Enterprise Ecosystem
The platform is agnostic to every ecosystem layer. Each layer is pluggable: customers can swap providers without rewriting agents.
| Layer | Supported Providers and Types |
|---|
| AI Models | OpenAI, Anthropic, NVIDIA, Cohere, LLaMA 2, and additional providers. Open-source and custom fine-tuned models are supported through the same interface. |
| Channels | Microsoft Teams, ServiceNow, Slack, Webex, Zoom, and additional channels. Agents are deployed across 27 channels in total — web, voice, messaging, email, and enterprise APIs — without per-channel rebuilding. |
| Data Sources | Salesforce, SAP, Microsoft, VMware, Zendesk, and additional sources. Data is accessed through tool definitions, not embedded in agent logic. |
| Cloud / Infrastructure | Microsoft Azure, Google Cloud, AWS, on-premise installations, and private VPC deployments. |
How It Works
Every enterprise interaction is processed by two cognitive engines that operate in parallel.
ABL defines both engines in a single language, the runtime executes both, and a shared memory layer coordinates state between them.
This split-brain model allows a single agent definition to combine autonomous reasoning with deterministic, auditable execution.
The Agentic Brain
The agentic brain reasons, explores, and decides. It handles the open-ended parts of an interaction where the right path is not known in advance.
The agentic brain runs:
- A multi-intent orchestrator that decomposes compound user requests into separate intents.
- Specialized agents for domains such as billing, network operations, or compliance.
- Remote agents reached via the A2A protocol, including agents that cross enterprise boundaries.
- Tool calling against CRM systems, BSS platforms, knowledge bases, and payment systems.
- An LLM reasoning engine that holds context across turns.
The Deterministic Brain
The deterministic brain validates, enforces, and executes. It handles the parts of an interaction where the path must be predictable, auditable, and policy-compliant.
The deterministic brain runs:
- Entity collection with deep validation rules.
- Authorization profile checks against the requesting user.
- A routing engine that combines intent, customer segment, and entitlement.
- Constraint and guardrail enforcement on inputs and outputs.
- BSS, OSS, and billing integrations with known inputs and auditable outputs.
- A flow-and-escalation engine for human handoff and supervisor queues.
The Shared Spine
Neither brain owns the shared spine; it is the runtime layer through which both brains coordinate state.
The spine holds:
- Session memory
- Threaded conversation context
- The entity store
- Authentication state
- Active guardrails
Compilation and Execution
Agent definitions move through three stages: ABL Compiler → IR → ABL Runtime. The compiler validates the definition, the IR is the portable artifact stored in version control, and the runtime executes the IR. Both brains share the same compiler, the same IR format, and the same runtime — there is no separate framework for deterministic flows and agentic reasoning.
Observability Outputs
The runtime emits three categories of structured trace data. Together, they make every agent decision reconstructable after the fact.
| Trace Category | What It Captures |
|---|
| Reasoning Traces | Every agent step, LLM call, and tool result is produced by the agentic brain. |
| Context Audit Trail | Every read and write to shared memory — what each brain was working with at the moment of every decision. |
| Decision Records | Every routing choice, constraint check, and guardrail evaluation is produced by the deterministic brain. |
Agent Blueprint Language
ABL is the language used to define agents on the platform. It is a typed, schema-driven domain-specific language that produces an intermediate representation (IR) that the runtime can execute. The same blueprint compiles to the same AST and IR, whether it is authored as ABL syntax or as YAML.
What ABL Replaces
On framework-based stacks, building a production agent typically involves stitching together prompts, code, and connectors across multiple languages and SDKs. The orchestration logic ends up as glue code that is hard to review, hard to test, and brittle when scaled.
ABL replaces that glue with a single declarative definition. A short ABL blueprint compiles to runtime primitives — handoff, delegation, fan-out, multi-intent routing, guardrails, retries, and tracing — that would otherwise be re-implemented per project.
ABL versus Framework Code
| Capability | Framework Code | ABL |
|---|
| Compile-time Validation | Not available; errors surface at runtime. | Built in; missing tools, broken references, and contract violations are caught before deployment. |
| Version Control and Diff | Mixed across code, prompt files, and configuration; diffs are noisy. | Clean YAML diffs; agent changes review like application code. |
| Cross-runtime Portability | Locked into the framework’s runtime. | IR-based; the same definition runs anywhere the runtime is deployed. |
| AI-programmable | Fragile; AI-generated framework code breaks at scale. | Reliable; ABL was designed so that AI can author and validate blueprints. |
Why a DSL
Two properties of ABL matter most:
- Compiler-validated abstractions - ABL exposes constructs such as DELEGATE and HANDOFF as first-class primitives. The compiler enforces the contracts between agents, so agent-to-agent boundaries are explicit rather than implicit in prose prompts.
- Reliable AI authoring - Because ABL has a strict schema, Arch AI can reliably generate, validate, and modify agents. Authoring through Arch AI is the default experience; users do not need to write ABL by hand.
Multi-Agent Orchestration
The runtime supports four orchestration patterns out of the box. Each pattern is invoked through ABL constructs and is enforced by the runtime, including the difficult cases — parallel fan-out with barrier synchronization, asynchronous delegation that survives pod restarts, and multi-intent messages where a single user turn maps to multiple agents.
| Pattern | Description | Runtime Depth |
|---|
| Handoff | Transfer control to another agent with a configurable history strategy, context passing, and return expectations. | Cycle detection through a handoff stack; self-handoffs are rejected. |
| Delegate | Invoke a child agent as a subroutine with explicit input and output contracts. Maximum depth of 10 nested delegations. | Stack-based; the result is piped back to the parent agent. |
| Fan-Out | Execute multiple agents in parallel and synchronize their results at a barrier. | Asynchronous; supports suspension and resumption across pod restarts. |
| Multi-Intent | Handle a single message that contains multiple intents belonging to different agents. | Four resolution strategies: primary_queue, sequential, parallel, and disambiguate. |
Cross-runtime and Supervisory Features
- Google A2A Protocol (v0.3.0+) – Used for cross-runtime agent communication, including agents hosted outside the platform.
- Supervisor Routing – Handoff and delegation decisions are guardrail-aware; the runtime can override an agent’s chosen route when policy requires it.
- Pipeline Classifier – Short-circuits the orchestrator for high-confidence intents, so simple requests do not pay the cost of a full reasoning loop.
Agent Lifecycle with Arch AI
Arch AI is not a copilot or a suggestion engine; it is a multi-agent system with specialized sub-agents that drive every phase of the agent lifecycle. There is no separate manual step to author ABL, run tests, or promote between environments — Arch AI runs each phase end-to-end and surfaces work products for human review.
Lifecycle Phases
| Phase | What Arch AI Does |
|---|
| Design | Interprets user intent and generates a complete agent blueprint — goals, flows, tools, memory, and guardrails — ready to compile. |
| Build | The build sub-agent authors ABL, validates cross-references, resolves tool bindings, and confirms deployment readiness before a human reviews. |
| Test | Runs Persona × Scenario × Evaluator matrices autonomously, surfacing failures, edge cases, and policy violations without manual test authoring. |
| Deploy | Manages environment promotion, versioning, and rollout. Compiler validation ensures no broken agent reaches production. |
| Observe | The observability sub-agent monitors trace events, session health, and runtime anomalies in real time, surfacing what matters rather than raw logs. |
| Optimize | Continuously analyzes performance, cost, and quality signals, and recommends or applies improvements to prompts, routing, and tool usage. |
Arch AI connects directly to the ABL compiler and the platform runtime, and exchanges content, compiled IR, traces, and topology data through MCP. It is also accessible from external coding assistants — Claude Code, Cursor, and Codex — through the same MCP interface, so agents can be authored from a CLI or IDE in addition to the Studio.
Agent Lifecycle as Code
Agent definitions are first-class software artifacts. They are stored as YAML files, reviewed in pull requests, and promoted across environments using the same CI/CD practices used for application code.
Environment Pipeline
Agents move through four environments. Each environment runs the same compiled IR; configuration and credentials are externalized.
- Dev – Where agents are authored and unit-tested.
- Staging – Where automated test suites and regression checks run.
- Pilot – Where a limited production audience validates behavior on real traffic.
- Production – Where the agent serves the full audience.
YAML Definitions
Agent configurations are Git-native and diffable. A change to an agent’s behavior produces a reviewable diff in version control, just like a change to application code. Compiler validation runs on every commit, so broken definitions never reach a downstream environment.
Infrastructure Efficiency
Agent Platform 2.0 was rebuilt from the ground up on an AI-native enterprise foundation. The runtime is horizontally scalable and has a substantially smaller infrastructure footprint than Platform 1.0.
For equivalent workloads, customers can expect at least a 50% reduction in infrastructure footprint relative to a Platform 1.0 deployment, with no reduction in capability. The reduction comes from architectural changes in the runtime — not from disabling features.
Enterprise Capabilities
The platform is built for the scale, governance, and accountability that enterprises require. The four capabilities below are foundational and apply to every deployment.
| Capability | What It Covers |
|---|
| Security and Data Governance | Every agent interaction is scoped, encrypted, and auditable by design. Tenant isolation, role-based access control, PII detection, and key management are built into the platform rather than added on. |
| Multi-tenancy at Scale | A single platform deployment supports hundreds of agent deployments across business units, geographies, and brands. Each tenant is fully isolated, and policy is administered centrally. |
| Omnichannel Reach | Agents are deployed across 27 channels — including web, voice, messaging, email, and enterprise APIs — with consistent behavior across channels. There is no per-channel rebuilding. |
| Compliance and Auditability | Full audit trails, data minimization controls, right-to-erasure handling, and governance policies that satisfy regulated industries. Agent behavior is explainable, traceable, and accountable. |
Business Outcomes
Agent Platform 2.0 is designed around three measurable outcomes for the enterprise:
| Outcome | How It is Achieved |
|---|
| Build Faster | Arch AI authors and validates ABL on the user’s behalf, automated test matrices replace manual test authoring, and compile-time checks catch errors before they reach review. Time-to-market for new agentic solutions is shortened across every phase of the lifecycle. |
| Run Leaner | The re-architected runtime delivers at least a 50% reduction in private VPC infrastructure footprint for equivalent workloads. The reduction is a direct cost saving with no trade-off in capability. |
| Scale Smarter | ABL is AI-programmable, so the platform itself becomes a code-generation target. New capabilities can be added, refined, and operated through the same compiler-validated abstraction, with full observability and governance built in. |
Deployment Options
Choose SaaS or self-hosted to match your infrastructure and compliance requirements.
| Option | Description |
|---|
| Cloud (SaaS) | Default experience. Sign up, open Studio in your browser, and start building — nothing to install or manage. |
| Self-hosted (Enterprise) | For organizations requiring on-premises deployment. Same platform capabilities, available for enterprise customers with data-residency or compliance requirements. |