Inside Arch AI: how Kore.ai's built-in architect takes agents from design to production

Most agent builders are conversational. You describe an agent, you get an agent, and everything that makes it production-grade is still manual: validating behavior across edge cases, reviewing changes safely, tracing decisions for audits, keeping quality and cost from drifting under real traffic.

That manual work compounds. N agents create N×(N−1) potential handoffs, shared context paths, and failure modes. Testing becomes a matrix of personas, scenarios, tools, and policies. Governance, observability, and security get re-implemented per project because the agent's logic lives in prompts and glue code, where behavior is unauditable and every change is a rewrite. Each new agent adds more complexity than value, and that's where agent programs stall.

Arch AI is what we built in response, and it's a different kind of thing than a copilot. Arch AI is the AI architect inside the Kore.ai agent platform {Artemis}: a multi-agent system that moves from intent to blueprint, ABL (agent blueprint language), tests, deployment, trace analysis, and optimization proposals, with human review at the decision points. It is not a build-time assistant that hands off and disappears, and it is not a post-launch analyzer bolted on at the end. It spans the full lifecycle.

It's new in three specific ways:

1. First, that lifecycle span. 
2. Second, it doesn't generate prompts: everything Arch AI produces is written in ABL, the platform's Agent Blueprint Language, a formal definition that can be compiled, diffed, audited, and edited line by line. 
3. Third, and this shapes everything else: governance is the design principle, not a bolt-on. Every agent Arch AI builds is validated before deployment, policy-enforced at runtime, auditable per decision, and changeable only through human-approved gates.

This article walks Arch AI's six lifecycle stages end to end. One thing to watch as you read: at every stage, Arch AI carries a concrete artifact forward. Intent becomes topology, topology becomes ABL, ABL becomes an eval matrix, evals gate deployment, deployment produces traces, and traces become the evidence for the next change. Each handoff between stages is a concrete, inspectable artifact.

Arch by architecture:

Stage 1: Design - Brief or SOP → topology

When you create a new project, the platform offers a blank canvas, a template (accelerators for banking, healthcare, telecom, retail, IT, HR), or Arch AI, labeled "AI designs your project."

Choose Arch AI, and it interviews you the way a solution architect would: goals, constraints, tools, knowledge sources, human approval points, channels, and operating policies. You answer in plain language and can add requirements midstream. If a standard operating procedure or an existing architecture document already exists, upload it; Arch AI designs from your document instead of starting cold.

Underneath, specialized agents parse the use case, design the workflow, select tools, define guardrails, and determine the agent topology, constrained by built-in template architectures and domain specialists so designs land on proven patterns rather than improvisation. What comes back is a reviewable proposal: pattern decisions, blueprint, full topology.

Review gate 1, human review: blueprint approval. Stakeholders validate intent before anything is generated. Arch AI proposes; you decide.

Stage 2: Build - Topology → ABL

On approval, Arch AI produces the deployable blueprint: agents, handoffs, tools, memory grants, guardrails, workflows, and starter evals, all written in ABL.

ABL structure:

ABL is the load-bearing decision, so it's worth a beat. It's a schema-driven DSL: SQL is to queries and HTML is to pages what ABL is to agents. Each definition formally captures an agent's goals, tools, policies, handoffs, and escalation paths, and deterministic steps coexist with autonomous LLM reasoning in one compilable schema. 

Policy logic, exception handling, and escalation stay formal; agents reason where judgment adds value. A typical agent is a few hundred readable lines, which activate thousands of lines of generated platform capability underneath: short-term and long-term memory, session management, context passing, guardrail enforcement. The scaffolding your teams keep rebuilding per project is generated, not hand-written.

Because ABL is human-readable and directly editable, there's no regeneration trap. Change one policy, one handoff condition, one tool binding, at exactly the granularity you need, without regenerating anything else. Definitions are Git-diffable and PR-reviewable, so agent review plugs into the code-review culture your team already has.

Read more about - ABL (Agent Blueprint Language)

Agent Blueprint Language (ABL) is the world's first compiled, declarative language built specifically for enterprise AI agents, and the foundation of Artemis, Kore.ai's AI-native enterprise agent platform. Not a framework. Not a prompt. A language, with a compiler, that brings structure, governance, and predictability to enterprise AI for the first time.

Stage 3: Test - ABL → eval matrix

Before anything reaches production, Arch AI generates the eval matrix from the intended behavior itself: persona, scenario, and evaluator coverage derived from what the ABL says the system should do. Test suites run with LLM-judge evaluators, quality gates, and regression tracking, and Arch AI flags coverage gaps before they become production incidents.

This inverts the usual sequencing. Testing isn't something your team writes after the build if there's time; it's an artifact generated alongside the build, and it gathers everything downstream.

Stage 4: Deploy - Compiler gates release

Review gate 2, compiler review: deployment readiness. The ABL Compiler runs a DSL to IR runtime pipeline, and the platform validates structure before release: broken references, missing tools, incomplete policies, and unapproved consequential actions all fail before promotion. The pipeline will not ship an invalid definition, which is the mechanism behind 100% of agents validated before deployment. Failures surface in front of the builder, never in front of users.

Approved agents promote through Dev, Staging, Pilot, and Production with diff reviews, approval workflows, and instant rollback. In a recorded walkthrough, the journey to this point (one typed sentence, a short interview, a blueprint approval) produced ShopAssist: five coordinated agents behind a triage agent, across SMS, WhatsApp, and web chat, generated and deployed in real time. For a voice application, you can pick up the phone and call the result.

What Arch AI's output lands on is the platform's production machinery:

1. Multi-agent orchestration runtime. Six orchestration patterns (supervisor routing, delegation, escalation, fan-out, parallel execution among them), coordinating specialists in one continuous session, with deterministic and reasoning-driven execution in one runtime.
   
   
2. Runtime guardrails. Tool access, escalation triggers, and policy compliance enforced deterministically at execution time. Agents cannot take actions their definition doesn't grant: zero unauthorized agent actions.
   
   
3. Workflow engine. Long-running, stateful workflows that survive failures, wait on human-in-the-loop approval gates, and resume. Real processes run for hours or days, not turns.
   
   
4. Search AI. Responses grounded in enterprise knowledge via RAG, vector search, knowledge graph, and reranking, over live, permission-scoped data with citation tracking.
   
   
5. Tools and channels. 250+ connectors spanning HTTP, MCP, Lambda, SDK, A2A, OpenAPI, and webhooks with circuit-breaker and retry logic, plus 10+ channel adapters (voice, web, WhatsApp, Teams, SMS) sharing the same ABL definitions, with identity resolution and session rehydration across channels. Voice is native, not bolted on: W3C SSML, barge-in handling, and real-time STT/TTS.
   
   
6. Hybrid economics and model inheritance. Deterministic steps execute at sub-500ms with no LLM call; every step independently selects a fast model, a reasoning model, or no model, so cost stays predictable at volume. And because the platform is AI-programmable and model-, channel-, and cloud-agnostic, every model advance lands inside your agents automatically. The same ABL rides each upgrade: no rebuild, no catch-up.

Stage 5: Observe - Traces → diagnosis

Everything Arch AI built stays visible, and what it reads is richer than logs. Arch AI consumes runtime traces, eval deltas, knowledge gaps, tool latency, and guardrail outcomes as typed evidence: structured signals it can reason over, not text it has to guess at.

The substrate: every reasoning step, guardrail check, tool call, and handoff is logged as a structured trace event, 200+ event types, with session debugging and alerting, across 100% of conversations rather than the 5-15% sample manual review achieves. When an agent misbehaves, you get the causal chain: what happened, why, which rule fired, what data it used. Agent Insights ties performance, cost, latency, and quality to business outcomes in one view, with A/B testing across versions on resolution rate, handle time, escalation rate, and CSAT.

Stage 6: Optimize - Evidence → reviewable patch

Arch AI turns that evidence into recommended changes, and they land as diffs your engineers can review: ABL, workflow, tool, prompt, guardrail, or eval diffs.
Two real examples of the shape:

• "The escalation rate for billing is above the threshold. Here's a routing change that could reduce it by 15%."
• "The verification agent is using a reasoning model for simple identity checks. Switching to a fast model would cut latency 60% and cost 80% with no quality loss."

Review gate 3, engineering review: the optimization pull request. Every proposed change is validated through Agent Evals against quality gates, and humans approve anything that affects production. Alongside these review-gated structural changes, platform auto-tuning continuously optimizes prompts, tools, and flows within approved boundaries, and LLM cost routing keeps model selection efficient per step. The loop closes, and it feeds the next Design stage with everything the system has learned.

The gain extends past any one agent. Because every agent lands in the same governed ABL format, an optimized pattern doesn't stay locked to the team that built it. A refund-handling agent tuned and hardened in customer support becomes a starting topology another team can adopt for, say, order cancellations, inheriting the same guardrails, tested handoffs, and eval coverage instead of rebuilding and re-optimizing from zero. Optimization isn't just better agents; it's the organization compounding on its own best-tested work.

Governance, by design and at every stage

Governance runs through every stage above; here it is consolidated in one place. It operates at four levels, and none of them is optional or retrofitted.

• The artifact is governed: Agent behavior lives in ABL: reviewable before deploy, compile-time validated (100% of agents, mechanically enforced), versioned, and auditable line by line. There is no ungoverned place for logic to hide, because there are no prompts to hide it in.
  
  
• The runtime is governed: Deterministic guardrails enforce tool access, escalation triggers, and policy compliance at execution time. Agents cannot take actions their definition doesn't grant: zero unauthorized agent actions, as a mechanism, not a policy memo.
  
  
• The record is governed: 200+ structured trace event types across 100% of conversations, PII detection and masking, and audit trails give you the causal chain for every decision: what happened, why, which rule fired, and what data was used.
  
  
• Arch AI itself is governed: Its authority is bounded by the three review gates you just walked: human review at blueprint approval (Stage 1), compiler review at deployment readiness (Stage 4), and engineering review on every optimization pull request (Stage 6). Arch AI proposes; your team decides.

The enterprise wrapper holds it together: SOC 2, HIPAA, GDPR, PCI, and FedRAMP posture, multi-tenancy, RBAC, tenant isolation, region-scoped deployments for data residency, and dynamic policy rules enforced across inputs, outputs, and workflows.

The following shows a typical runtime flow:

Where Arch AI fits in your team's workflow

Arch AI is one of four authoring paths, and they all converge. Write ABL directly for full manual control; build visually alongside code in Agent Studio; author through Claude Code, Cursor, or Codex with native platform integration; or start with Arch AI, the recommended default. Every path emits the same governed ABL artifact under the same controls described above. One format for every agent in the enterprise, whoever or whatever wrote it, is what prevents sprawl.

The team-level shift is worth naming, because it's the real change Arch AI introduces: developers move from writing every line to supervising generation, validating architecture, and managing quality. Humans become orchestrators of AI agents, and the three review gates are where that supervision happens.

Three things worth understanding well:

1. ABL (Agent Blueprint Language): Agent behavior is a formal, compilable artifact rather than a prompt. Validation, diffing, traces, and safe optimization all follow from this one design choice.
   
   
2. Granular post-generation editing: Because ABL is directly editable, a generated system can be changed at the level of a single policy, handoff, or tool binding, without regenerating the rest.
   
   
3. Generated eval matrices: Arch AI derives persona, scenario, and evaluator coverage from the intended agent behavior, and runs that coverage at every promotion and against every proposed change.

Try it on a real workflow

Bring a real workflow to a technical walkthrough. You'll see Arch AI run Design through Deploy, and you can open the generated ABL and read it directly.

FAQs

1. What is Arch AI? 

Arch AI is the AI solution architect built into the Kore.ai Agent Platform. It is a multi-agent system that moves from intent to blueprint, ABL, tests, deployment, trace analysis, and optimization proposals, with human review at the decision points, across six lifecycle stages: Design, Build, Test, Deploy, Observe, Optimize.

2. What does Arch AI actually generate? 

The deployable blueprint in ABL (Agent Blueprint Language): agents, handoffs, tools, memory grants, guardrails, workflows, and starter evals, plus the eval matrix (persona, scenario, and evaluator coverage) and deployment artifacts. ABL is a schema-driven DSL that unifies deterministic steps and LLM reasoning in one compilable schema.

3. How is Arch AI different from prompt-based agent builders? 

Prompt-based tools produce agents whose behavior depends on model interpretation, with no pre-deployment validation and no meaningful version diffs. Arch AI produces formally defined agents that are compile-time validated, Git-diffable, auditable per decision through 200+ structured trace event types, and editable at any level of granularity. It also stays engaged after launch, turning production evidence into reviewable patches.

4. Does Arch AI change production agents automatically?

No. Arch AI proposes changes as reviewable diffs (ABL, workflow, tool, prompt, guardrail, or eval), validated through Agent Evals against quality gates, and applied only with human approval. Platform auto-tuning operates continuously, but only within approved boundaries.

5. Can developers keep their own tools? 

Yes. Teams can write ABL directly, build in Agent Studio, or work through Claude Code, Cursor, or Codex with native platform integration. Every path produces the same governed ABL artifact.

6. What does the compliance posture look like? 

Guardrails, PII detection and masking, audit trails, and lifecycle and access policies apply platform-wide, with SOC 2, HIPAA, GDPR, PCI, and FedRAMP posture, multi-tenancy, RBAC, tenant isolation, and region-scoped deployment options for data residency.