K9-AIF — K9 Agentic Integration Framework

K9-AIF is an architecture-first framework for designing governed, enterprise-scale multi-agent AI systems.

Unlike agent runtimes that focus mainly on execution, K9-AIF defines the architectural structure, interaction boundaries, governance model, and runtime execution control needed to build scalable agentic AI systems.

The framework separates Architecture Building Blocks (ABB) from Solution Building Blocks (SBB), enabling extensible and composable agentic applications.

K9-AIF layered architecture — click the image to view full resolution.

K9-AIF provides architectural patterns for constructing agentic workflows where multiple AI agents collaborate to perform reasoning, analysis, and decision-support tasks while maintaining clear governance, orchestration, and integration boundaries.

The framework draws inspiration from established architectural disciplines, including:

• Object-Oriented Analysis & Design (OOA/OOD)
• Enterprise Architecture (TOGAF)
• Service-Oriented Architecture (SOA)
• Modern multi-agent AI systems

The goal is to enable composable, scalable, and governed agentic AI applications.

Table of Contents

• A Simple Way to Think About It
• Understanding K9-AIF
• Architecture Building Blocks (ABB)
• Solution Building Blocks (SBB)
• Architectural Layers
• Agent Squads
• Governance by Construction
• Zero Trust Execution Layer
• Human-in-the-Loop (HIL)
• Prototype Implementations
  • Built on K9-AIF: Defense Acquisition System (DAS)
• Design Goals
• Architectural Patterns
• Intelligent Model Routing
• Multi-Provider LLM Support
• Example Use Cases
• K9X Studio — Visual Builder
• K9X Ecosystem
• K9-AIF Developer Journey
• Framework Implementation
• Developer Guide
• Using Claude Code with K9-AIF
• Quick Start (Linux / Ubuntu)
• Project Status
• License
• Contributions
• Architectural Foundations
• Architecture Notes & Blog
• Author's Recommendation
• Author

A Simple Way to Think About It

• Frameworks like CrewAI define how agents collaborate.
• Cloud platforms like Azure or AWS provide infrastructure.
• Runtimes execute workflows.
• K9-AIF defines how the full AI system should be architected.

Understanding K9-AIF

Start here for a structured explanation of K9-AIF:

• The Path of K9-AIF
• What K9-AIF Is
• K9-AIF for Stakeholders
• K9-AIF vs Agent Frameworks
• Where Agent Systems Fail
• FAQ

Core Architectural Concepts

K9-AIF separates architecture into abstract ABB contracts and concrete SBB implementations.

Architecture Building Blocks (ABB)

Architecture Building Blocks define abstract architectural capabilities and contracts within the K9-AIF framework. ABBs specify responsibilities, interfaces, and interaction patterns without prescribing concrete implementations or technologies.

An ABB typically defines:

• Interfaces and interaction contracts
• Responsibilities and functional boundaries
• Lifecycle expectations
• Governance and observability hooks

Examples include:

• Agent interface contracts
• Orchestrator contracts
• Tool connector interfaces
• Inference adapters
• Storage or persistence adapters

Solution Building Blocks (SBB)

Solution Building Blocks provide concrete implementations of ABB contracts. SBBs introduce domain-specific behavior, technology choices, and runtime integrations while conforming to the architectural constraints defined by the ABB layer.

This separation allows architectural stability while enabling domain-specific extensions without modifying the core framework.

Examples:

• Document Analysis Agent
• Retrieval Agent
• CrewAI Agent
• LangChain Tool Adapter
• OpenAI LLM Connector

Architectural Layers

A typical K9-AIF system is organized into a set of architectural layers that separate interface concerns, orchestration, external integration, inference, and persistence.

1. Presentation Layer Handles incoming user or system interactions through web interfaces, conversational channels, or APIs.
2. Application Layer Coordinates orchestration flows, routing, and workflow execution across agents and services.
3. Integration Layer Provides governed access to external systems, APIs, tools, messaging platforms, and storage services.
4. Inference Layer Supports model invocation, retrieval-augmented generation (RAG), and context-aware reasoning.
5. Data Layer Provides persistence, object storage, and messaging infrastructure used by the framework.
6. Cross-Cutting Concerns Security, governance, and observability apply across all layers to enforce policy, auditability, monitoring, and operational control. Every agent call is governed by construction (k9x_Shield checks around execute()/execute_stream(), and around any llm_invoke() call made outside an agent). The opt-in Zero Trust Execution Layer (enable_zero_trust) adds identity, authorization and risk evaluation at the Router and Orchestrator.

Agent Squads

K9-AIF introduces the concept of Agent Squads.

A Squad represents a coordinated group of agents working together to perform a specific capability within an orchestration workflow.

Rather than orchestrators invoking individual agents directly, K9-AIF introduces a structured collaboration layer between orchestrators and agents.

Execution hierarchy:

Event → K9EventRouter (single entry point)
    ├── event_type known  ──────────────────► domain topic
    └── event_type unknown ──► intent.in
                                    │
                        IntentOrchestrator
                            → IntentSquad → K9IntentAgent
                                ├── intent resolved ──► domain topic
                                └── intent unclear  ──► responses.out

domain topic → Orchestrator → Squads → Agents → LLM

Squads allow enterprise workflows to be modeled as capability-based teams of agents. All squad-level execution remains subject to K9-AIF’s governance and Zero Trust execution controls, ensuring that agent actions are verified and policy-enforced at runtime.

Examples include:

• Claims Processing Squad
• Medical Review Squad
• Architecture Analysis Squad
• Threat Assessment Squad

Squads are defined declaratively using configuration and loaded dynamically at runtime using the SquadLoader component.

Core squad framework components include:

• BaseSquad
• SquadLoader
• SquadContext
• DefaultSquadMonitor

Governance by Construction

Since 1.15, governance is a property of the runtime, not something each agent must remember to call:

• BaseAgent wraps every subclass's execute() and execute_stream() when the class is defined, so every call is checked on the way in and on the way out. Overriding execute() does not bypass it.
• One setting governs every agent of an application: security.shield.enabled: true (with ingress and egress check lists) in the solution's config.yaml gives each agent ShieldGovernance.
• llm_invoke(), the single model-call path, runs the same checks itself for any call made outside an agent (orchestrator, service or script code), so every model call is checked exactly once.
• In production (K9_ENV unset or production), an agent or model call with no governance configured raises PermissionError before anything runs.
• k9aif inspect <folder> checks statically that a solution is wired this way.

Zero Trust Execution Layer

Once you understand the execution hierarchy (Router → Orchestrator → Squads → Agents), Zero Trust is the cross-cutting layer that governs every step of it.

Traditional Zero Trust focuses on access — who can reach a system. K9-AIF applies Zero Trust to execution — every action is verified before it runs.

• Every action is verified before execution
• Contextual risk is evaluated (identity, data sensitivity, destination)
• Policies are enforced at runtime (allow, conditional, deny)

Zero Trust is opt-in (enable_zero_trust). When enabled, it is enforced at two layers:

• Router — pre-routing enforcement
• Orchestrator — pre-execution enforcement before the Squad runs

Zero Trust is not a checkpoint — it is a layer applied across the system.

Human-in-the-Loop (HIL)

An Agent or Squad can trigger a human decision mid-flow — a fraud score below an auto-approve threshold, a low-confidence classification, a policy that always requires sign-off — by raising RequiresHIL, a first-class exception rather than a return-value flag your Squad author has to remember to check.

Two rules govern how this crosses the framework's existing layers, both deliberate, documented carve-outs rather than accidents:

• Agents and Squads never touch Kafka, even for HIL. RequiresHIL propagates by exception through the normal Agent → Squad → Orchestrator call chain; only the catching Orchestrator actually publishes. Publishing below the layer that controls whether execution continues can't stop the rest of the flow from completing normally — exactly the inconsistency this design avoids.
• The Orchestrator delegates to a real, separate BaseHILOrchestrator — a second, conscious exception to "Orchestrators don't call other Orchestrators" — so every part of the framework that can trigger HIL shares one place that knows how to publish, persist, and resume, instead of each SBB orchestrator hand-rolling it.

The Orchestrator never blocks waiting for a decision — a human review can take hours or days. It returns {"status": "pending_hil", ...} immediately; K9EventRouter picks the decision back up later by subscribing across every hil.replies.* topic (one consumer, pattern- subscribed — never one Kafka topic per job) and resolving by correlation_id against a persisted hil_pending row, then re-routing the resumed payload through its own route() — resuming a workflow is just re-routing it with new information now available, not a second mechanism.

Prototype Implementations

Prototype systems based on K9-AIF demonstrate how the framework can support governed multi-agent architectures across multiple domains.

Featured Example

K9X Enterprise Insurance Operations Center (EOC) → examples/K9X_Enterprise_Insurance_OperationsCenter

The EOC is the canonical reference implementation of K9-AIF — the most complete, production-aligned example in the framework. It demonstrates every architectural concept end-to-end:

• Full Kafka-based event pipeline (Router → domain topics → Orchestrator → eoc-results)
• Seven domain orchestrators, each owning a Squad and its agents
• Agent pipeline with sequential flow, conditional steps (when:), and accumulated context
• Zero Trust enforcement at the Orchestrator layer
• Governance pre/post processing across all agents
• Neo4j graph sync, PostgreSQL persistence, Docling OCR via MCP
• FastAPI backend + Web UI with real-time SSE event streaming
• Containerised deployment (Podman pod, three containers)

Use the EOC as your reference when building any new K9-AIF solution.

Built on K9-AIF: Defense Acquisition System (DAS)

DAS turns capability documents into JCIDS, acquisition and systems-engineering deliverables aligned with DoDAF 2.0. It is built entirely on K9-AIF: 1 router, 4 stage orchestrators, 5 YAML squads and 17 agents, all SBBs extending framework ABBs. → github.com/k9aif/dow-k9x · Live: das.k9x.ai

Tips from building it:

• Route deterministically when the intent is known. The analyst picks the document type; the router maps it to a stage topic with a plain table, and no LLM decides the route.
• One orchestrator per stage, squads reused across stages. The gate-readiness and package-assembly squads serve the JCIDS, Acquisition and SE orchestrators unchanged; stages differ in config and prompts, not code.
• Validation loops only where output must converge, such as generating views, proposing trace links and classifying drift. Everything else is a single-pass BaseAgent.
• Ground agents in the source. Agents use only the source document or approved prior-stage outputs, write NOT PROVIDED IN SOURCE instead of inventing, and cite evidence, with governance checking every agent's input and output.
• Carry a job ID on every event. Output from two concurrent runs once appeared in the same session; the cause was events without a job_id, not queueing.
• Human gates at stage boundaries, documents by reference. The review task carries an s3:// link, and K9X HIL fetches the document from object storage. New solutions should use the framework's RequiresHIL round trip (see Human-in-the-Loop) so the flow resumes on the decision.

Additional Examples

• ACME Health Insurance Claims Assistant — Multi-agent insurance workflow demo including eligibility checks, provider lookup, and claims support. → examples/acme_health_insurance
• K9Chat — Reference chat application demonstrating BaseAgent, llm_invoke, multi-provider model routing, governance, and retrieval grounding. A single-agent app, not a multi-agent Squad/Orchestrator example — see the EOC example above for that. → github.com/k9aif/examples (moved out of this repo 2026-09-21)
• WeatherAssist Decision Support System — a CrewAI crew wrapped by K9-AIF governance through the CrewAI adapter. → examples/weather_assist
• ACME Support Center — the bundled Quick Start demo: a support squad of triage, knowledge, resolution and quality agents. → examples/acme_support_center
• Zero Trust Execution Demo — signed identity at the Router edge, with API-key and Keycloak (OIDC) authentication. → examples/zero_trust_execution_demo
• Defense Acquisition System (DAS) — multi-stage JCIDS, acquisition and systems-engineering pipeline aligned with DoDAF 2.0, built entirely on K9-AIF. See Built on K9-AIF: Defense Acquisition System (DAS) above.

Design Goals

K9-AIF is designed to support the development of governed, modular agentic AI systems aligned with enterprise architecture practices.

Key architectural goals include:

• Modular architecture supporting independently deployable AI capabilities
• Reusable architectural building blocks for consistent system composition
• Governed AI workflows with policy, control, and observability integration
• Clear orchestration boundaries between agents, tools, squads, and services
• Scalable integration with enterprise systems and external platforms
• Architecture-driven routing of inference requests across multiple models and providers
• Governance by construction: every agent call passes the configured k9x_Shield checks, and production refuses ungoverned agents; an opt-in Zero Trust layer adds identity and risk evaluation at the Router and Orchestrator

The framework bridges traditional enterprise architecture principles with emerging agentic AI system design.

Architectural Patterns

Many of the architectural ideas used within the K9-AIF framework are documented separately as reusable architecture patterns.

These patterns describe the core design principles behind the framework while remaining independent of any specific runtime implementation.

The pattern catalog includes topics such as:

• Factory-based governed component instantiation
• Inference layer abstraction for model providers
• Connector-based integration with external systems
• Configuration-driven runtime loading of agents and orchestration components

The full set of patterns is available in the K9-AIF Architecture Patterns repository:

➡️ https://github.com/k9aif/k9aif-patterns

Validation Loop Pattern

An in-framework pattern for iterative hypothesis-validate-reason workflows — applicable across security, fraud, claims, compliance, and document extraction domains.

Implemented as BaseValidationLoopAgent in k9_aif_abb/k9_agents/validation/. K9ValidationLoopAgent is the OOB LLM-driven implementation for confidence-convergence loops. K9PlanningLoopAgent (k9_aif_abb/k9_agents/planning/) is the dynamic-planning sibling — the agent builds and revises its own step plan each iteration, finalizing when the plan is complete. See Skill 10 in SKILLS.md for usage and the SA decision guide.

One contract, two out-of-box convergence strategies: domain SBBs extend K9ValidationLoopAgent when the question is "is this hypothesis true, and am I confident enough?" (e.g. FraudDetectionAgent in the EOC example), or K9PlanningLoopAgent when it is "what's left on my plan?" (InvestigationAgent is an illustrative name).

Prompt Evaluation Pattern

A development-time pipeline for grading authored prompts — system prompts, agent instructions, and guided-flow templates — before they reach a workflow.

BasePromptEvaluator defines the ABB contract: evaluate(), compare(), and run_suite(). K9PromptEvaluator is the OOB SBB — LLM-as-judge, five weighted dimensions (correctness 35%, completeness 25%, format compliance 15%, clarity 15%, relevance 10%), grade scale A–F, configurable PASS threshold. EvaluationFactory.create(config) provisions the right implementation.

This is a design-time and measurement-time tool, not a runtime gate. Runtime quality enforcement is K9ValidationLoopAgent's responsibility. The K9Chat reference application ships with an evaluation toggle that grades every response in real time during development.

Implemented in k9_aif_abb/k9_agents/evaluation/. Config key: evaluation.provider: k9.

Intelligent Model Routing

Agents never name a model. Every call goes through llm_invoke to K9ModelRouter, which picks one from the model catalog in two layers.

Rules (cold start). Weighted scoring on the request: task-type capability (+3), latency tier (+2) and cost tier (+2). The default_model is the fallback. On a tie, the conversation's current model wins (session affinity).

Evidence (learned routing, since 1.13). This works like evaluation-trained routers such as Not Diamond and RouteLLM. The router keeps graded outcomes: which model scored what, 0 to 100, on which prompt. For a new prompt, it predicts each model's quality from its scores on the most similar prompts it has seen. It then subtracts a penalty for latency or cost the request can't afford. If the best prediction beats the rules' pick by a margin, the evidence decides. Routing is per prompt: two reasoning prompts can go to different models.

router.record_feedback(prompt, model_alias="smart", quality=88, task_type="reasoning")

Graders, evaluators, HIL reviewers or K9X Arena (head-to-head model matches) supply the evidence. With none, the router behaves exactly as the rules say.

Guard rails evidence can't cross. A confidential request goes only to confidential-capable models when the catalog has any. A model whose recent calls mostly failed is skipped (circuit breaker). Every decision records why it was made.

Configure under inference.router.learning (all keys optional; see config.yaml). Inference-layer documentation: k9_aif_abb/k9_inference

Multi-Provider LLM Support

K9-AIF uses a Provider Adapter pattern to support multiple LLM backends without coupling any framework component to a specific provider.

LLMFactory remains provider-agnostic — it resolves the correct adapter from ProviderAdapterRegistry and asks it to construct the BaseLLM. Agents, squads, orchestrators, and the model router require no changes when switching providers.

Click to view full resolution.

Supported out of the box

Switching provider — config only, no code changes

Ollama (default):

inference:
  llm_factory:
    backend: ollama
    base_url: "http://localhost:11434"
    models:
      general:
        model: "llama3.2:1b"

OpenAI:

inference:
  llm_factory:
    backend: openai
    api_key_env: OPENAI_API_KEY    # resolved from environment — never hardcode
    models:
      general:
        model: "gpt-4o-mini"

Grok / xAI:

inference:
  llm_factory:
    backend: openai-compatible
    base_url: "https://api.x.ai/v1"
    api_key_env: GROK_API_KEY
    models:
      general:
        model: "grok-3-mini"

Adding a new provider — no framework changes required

Extend BaseProviderAdapter, implement two methods, register once:

from k9_aif_abb.k9_core.inference.base_provider_adapter import BaseProviderAdapter
from k9_aif_abb.k9_core.inference.provider_registry import ProviderAdapterRegistry

class BedrockProviderAdapter(BaseProviderAdapter):

    @property
    def provider_name(self) -> str:
        return "bedrock"

    def create_llm(self, model_name, factory_cfg, extra_kwargs):
        return BedrockLLM(model=model_name, **extra_kwargs)   # your BaseLLM implementation

ProviderAdapterRegistry.register("bedrock", BedrockProviderAdapter)

Then set backend: bedrock in config.yaml. Nothing else changes.

API keys are always resolved from environment variables (api_key_env: MY_KEY) — never stored in config files.

Example Use Cases

K9-AIF can be applied to enterprise AI systems that require governed orchestration of multiple AI capabilities.

Examples include:

• Enterprise architecture and technology landscape analysis
• Document intelligence and large-scale document processing
• Insurance claims analysis and decision support
• Automated systems engineering workflows
• Knowledge synthesis and research assistance

Scaffold Generation

K9X Studio — Visual Builder

K9X Studio is a browser-based drag-and-drop architecture builder for K9-AIF systems.

This is where every K9-AIF application starts: design your architecture visually → generate a production-ready scaffold → implement the SBBs (VS Code + Claude Code recommended).

• Drag Router → Orchestrator → Squad → Agents onto the canvas
• Configure each node in the inspector
• Click Generate Scaffold — a ready-to-run project lands in k9_projects/<your-project>/
• Supports Ollama, OpenAI, and Grok backends out of the box

➡️ https://studio.k9x.ai — source: k9aif/k9x-ecosystem

K9X Ecosystem

K9X Studio generates the framework-compliant scaffold and hands it to the SBB Architect / PM, who builds on K9-AIF and publishes the finished SBB to K9X Enterprise Continuum for SBB → ABB promotion. At runtime, K9-AIF publishes human-review tasks over Kafka to K9X HIL. Continuum's artifact governance is separate from the framework's runtime execution governance (k9x_Shield governance on every agent by construction, and the opt-in Zero Trust layer).

Products built on top of K9-AIF, beyond the framework itself:

In the pipeline: dashboard.k9x.ai (read-only ecosystem catalog + launch point), inspector.k9x.ai (architectural conformance scanner for any K9-AIF solution).

Source for all of the above: k9aif/k9x-ecosystem

K9-AIF Developer Journey

Every K9-AIF application follows the same lifecycle, whether or not you use Claude Code:

1. Architect — provides the project requirements, current state, context, and scope.
2. K9X Studio — generates a framework-compliant scaffold from that specification. Studio is the starting point for every new K9-AIF application.
3. SBB Architect / PM — implements the domain business logic on the generated scaffold (VS Code + Claude Code recommended), tests and iterates, then creates the project and instance in K9X Enterprise Continuum and submits the SBB for review.
4. K9X Enterprise Continuum — records the submission under the project's catalog and notifies Enterprise Architects via K9X HIL.
5. Enterprise Architect — reviews the submitted SBB. Approved SBBs are promoted to the shared tier (or their pattern is harvested into a new framework ABB) and the catalog entry is updated; rejected SBBs return with feedback for rework.

Framework Implementation

The core implementation of the K9-AIF architecture is provided in the k9_aif_abb package, where ABB refers to Architecture Building Blocks.

This package contains the Architecture Building Blocks (ABB) and supporting framework components used to construct K9-AIF applications.

Location: k9_aif_abb

Developer Guide

A comprehensive developer guide for contributors and solution developers building on K9-AIF is available in the docs/developers/ folder.

The guide covers all 31 chapters — from core architecture and ABB/SBB development model through agent, orchestrator, and router development; the Validation Loop and Critic-Actor iterative reasoning patterns; model routing, governance, testing standards, and developer workflow. It includes accurate class signatures, config examples, and code drawn directly from the k9_aif_abb source.

Using Claude Code with K9-AIF

K9-AIF is designed to work with Claude Code — Anthropic's AI coding assistant. The repository includes context files that give Claude Code an immediate, accurate understanding of the framework so you can build new applications without re-explaining the architecture every session.

Context files included

Generating a new example with Claude Code

Open the repository in VS Code with Claude Code and run this prompt:

You are building a new application example on top of the K9-AIF framework located at k9_aif_abb/.

Project details:
- Application name: [e.g., K9X_Healthcare_ClaimsProcessor]
- Create all files under: examples/K9X_Healthcare_ClaimsProcessor/
- Spec doc location: examples/K9X_Healthcare_ClaimsProcessor/docs/your-spec.docx

Before writing any code, read CLAUDE.md and SKILLS.md, then read the canonical reference example:
  examples/K9X_Enterprise_Insurance_OperationsCenter/

Then implement the new example following the same structure and conventions. Rules:
- Every agent must extend BaseAgent and implement execute()
- Every squad must be defined in a squad YAML with a flow
- The router must route by event_type
- Enable security.shield (with ingress and egress check lists) in the app's config.yaml — every agent is governed by construction, and production refuses ungoverned agents
- Folder structure, naming, and config patterns must match the reference example

The combination of CLAUDE.md, SKILLS.md, and the reference example gives Claude Code enough context to generate architecturally consistent, governed, runnable K9-AIF applications from a spec document alone.

Read more: Build a K9-AIF Example App in Minutes Using Claude Code

Automated hooks (.claude/settings.json)

The repository also ships .claude/settings.json, which wires seven PostToolUse hooks — Python syntax check, YAML validation, ABB test run, governance check, __init__.py docstring check, single-model-path (llm_invoke) check, and README link check (see the Hooks section of CLAUDE.md) — that run automatically whenever Claude Code writes or edits a file.

Each hook command uses an absolute path (e.g. /Users/<you>/k9-aif-framework/.claude/hooks/check-python.sh). After cloning, edit .claude/settings.json and replace the path prefix with the absolute path of your own clone, or the hooks will fail with "command not found".

Quick Start (Linux / Ubuntu)

To use the framework in your own project, install it from PyPI:

pip install k9-aif                      # core
pip install "k9-aif[kafka,postgres]"    # with extras; "k9-aif[all]" for everything

To run the bundled demos, clone the framework and create a Python virtual environment:

git clone https://github.com/k9aif/k9-aif-framework.git
cd k9-aif-framework

python3.11 --version
python3.11 -m venv .venv
source .venv/bin/activate

python --version
python -m pip install --upgrade pip
python -m pip install -r requirements.txt

Then run the bundled demo from the k9-aif-framework folder:

./run_acme_support_center.sh

(k9chat moved to its own repo, k9-aif-examples — clone it as a sibling directory and see its k9chat/README.md for setup and run instructions.)

Run the framework tests with pytest:

pytest k9_aif_abb/tests/ -v                          # all
pytest k9_aif_abb/tests/test_framework.py -v         # one file

Project Status

K9-AIF is an actively evolving framework. The repository contains reference architecture material, prototype implementations, and example applications used to explore practical approaches to building governed agentic AI systems.

License

This repository is released under the Apache License 2.0.

The framework concepts may be used, adapted, and extended for research and development of agentic AI systems.

Contributions

Contributions, discussions, and architectural ideas related to agentic AI systems and multi-agent orchestration are welcome.

Architectural Foundations

K9-AIF draws inspiration from established software architecture and enterprise architecture practices, including:

• Booch, G. Object-Oriented Analysis and Design with Applications
• Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software
• The Open Group. TOGAF Standard

Architecture Notes & Blog

The K9-AIF blog contains architecture discussions, design evaluations, and evolving ideas related to building governed agentic AI systems.

➡️ https://blog.k9x.ai

Author's Recommendation

1. Know the Framework

Before building, understand the architecture. K9-AIF is built on a strict ABB/SBB separation — Architecture Building Blocks define the contracts, Solution Building Blocks implement the domain. Read CLAUDE.md for architecture and SKILLS.md for step-by-step recipes. These are the two documents that will make you productive fast.

2. Create Your Application in K9X Studio

Every K9-AIF application starts in K9X Studio — with or without Claude Code. Describe the architecture on the drag-and-drop canvas and click Generate Scaffold to get a framework-compliant, runnable project. See the K9-AIF Developer Journey section above for the full lifecycle.

➡️ https://studio.k9x.ai

3. Implement with Claude Code in VS Code

To implement domain logic on the Studio scaffold, the most effective tool is Claude Code inside VS Code.

K9-AIF ships with CLAUDE.md and SKILLS.md — these are loaded automatically by Claude Code, giving it a deep understanding of the framework's architecture, conventions, and code generation rules. Claude Code will extend the generated agents, squads, orchestrators, and config in ways that comply with the framework, without you having to explain the patterns each time.

Download and install Claude Code from: https://claude.ai/code

It is available as a VS Code extension, a desktop app, and a CLI. Once installed, open your solution folder in VS Code and Claude Code is ready to use.

Claude Code understands:

• ABB contracts and how to extend them correctly
• Squad YAML format, agent registration, flow structure
• Kafka ownership (Router publishes, Orchestrator consumes)
• Governance by construction (security.shield in config)
• The full inference pipeline through llm_invoke

To check a solution, run k9aif inspect <folder>: the framework's k9_inspect checks it statically against 28 conformance rules (ABB contracts, three-layer decoupling, llm_invoke, Kafka ownership, governance by construction, secrets, private IPs, squad/agent YAML). Add --fail-on violation in CI to fail the build on a violation; K9X Inspector runs the same rules on every push.

Happy Coding!

Building Architecture-First Agentic Applications — done right, that really works.

Author

Ravi Natarajan AI Systems Architect Agentic AI • Multi-Agent Systems • LLM Applications

Email: ravinatarajan@k9x.ai Website: https://k9x.ai