AI Fusion 3 Architecture

AI Fusion 3 runs entirely inside K2view Fabric. Agents are defined as files in your Data Products, executed by an agent runtime delivered in the aifusion Data Product, and reached through Fabric web services. LLM providers are accessed through Fabric AI interfaces, and every conversation is persisted for trace, evaluation and observation.

This article describes the components and how a request flows through them.

Components

 ┌──────────────────────────┐   ┌──────────────────────────┐   ┌─────────────────────┐
 │ AI Fusion Studio         │   │ Observation web app      │   │ Your application /  │
 │ (Agent Editor, Preview,  │   │ (dashboard, conversation │   │ channel (REST, SSE) │
 │  Eval Editor)            │   │  review)                 │   │                     │
 └────────────┬─────────────┘   └────────────┬─────────────┘   └──────────┬──────────┘
              └───────────────┬──────────────┴────────────────────────────┘
                              ▼
               Fabric web services (k2_ws):  agent (SSE), stop-session, agents,
               chats, feedback, observation, evaluation, trace-history ...
                              ▼
 ┌────────────────────────────────────────────────────────────────────────────────────┐
 │ Agent runtime  (aifusion Data Product, flow aifusion.Agent)                         │
 │  session = aifusion LU instance · hooks · tools · sub-agents · skills · references   │
 └───────┬───────────────────┬──────────────────────┬──────────────────────┬──────────┘
         ▼                   ▼                      ▼                      ▼
  Agent definitions    Business Data Products   LLM interfaces          MCP servers
  <LU>/AI/Agents/...   (entity micro-DB, flows) (Anthropic, Bedrock,    (Mcp interface)
                                                 OpenAI, Google, Ollama)
         │
         ▼
  Persistence: aifusion LU (per-session trace) + insights DB (sessions, signals, evaluation)

Component	Role
Agent definitions	Files under `<LU>/AI/` in each Data Product: `agent.yaml`, sub-agents, skills, reference packs, eval suites and observation configuration. Fabric captures them when the LU is deployed. See Agents Overview.
aifusion Data Product	Delivered by the `aifusion` extension. Contains the agent runtime, the session tables, the observation and evaluation flows, and the Observation web application.
Web services	Delivered in the `k2_ws` LU. They expose the agent API, session management, feedback, observation, evaluation and trace endpoints. See Invoking Agents.
Business Data Products	The LUs that hold your entity data (customer, account, policy). A hook flow loads the relevant instance into the session, and the agent queries it with the built-in `query` tool or calls its Broadway flows as tools.
LLM connectors	Separate extensions that add AI interface types for each provider. Agents refer to an interface by name. See LLM Connectors.
MCP client	The optional `mcp` extension adds the MCP interface type, so agents can use tools from MCP servers.
Pipeline	The `pipeline` extension executes evaluation runs and observation analysis pipelines.
AI Fusion Studio	The `aifusion-studio` extension for K2view Web Studio. See AI Fusion Studio.

The Life of a Request

A client sends a message. Studio Preview or your own application calls the agent web service with the agent name, its Data Product, a session ID, the user's message and, optionally, the agent inputs (initParams, for example {"customerId":"1001"}). The response is a Server-Sent Events stream.
The session is opened. The runtime gets the aifusion LU instance whose ID is the session ID, and claims the session so that only one request at a time is processed per conversation. A new turn (step) is recorded.
The agent is loaded. The runtime reads the agent's agent.yaml from the deployed Data Product, resolves its tools, skills, sub-agents and hooks, and builds the system prompt.
Hooks prepare the context. The step_start hook flow typically loads the customer's instance of the business Data Product, so its micro-database is available to the query tool, and may enrich the user message.
The reasoning loop runs. The runtime calls the LLM through the agent's interface. The model answers or calls tools: SQL queries over the entity data, Broadway flow tools, MCP tools, skills, reference search, planning, widgets, or sub-agents. Each tool result is fed back until the model produces a final answer, or a limit is reached.
The answer is streamed. Text, reasoning, tool activity, sub-agent activity, to-do lists, questions to the user and widgets are streamed as SSE events, ending with a done event.
Everything is recorded. Messages, executions, tool calls and token usage are written to the session's aifusion LU instance; session-level metrics are written to the insights database. The step_end hook can post-process the answer.
Later, Observation analyzes the conversation. An analysis run summarizes the session and classifies it on the configured signals for the dashboard. See Observation.

Data Stored

Per Session — the aifusion LU

Each conversation is one instance of the aifusion LU; the instance ID is the session ID. Its main tables are:

Table	Content
`chat`	Root table of the session.
`step`	One row per turn: the user message, the final answer, duration and time to first token.
`executions`	Each agent and sub-agent execution within a turn, with its status and inputs.
`messages`	All system, user, assistant and tool messages — the conversation history replayed on the next turn.
`tool_calls`	Executed tool calls with arguments, responses and durations.
`usage`	Token usage per LLM call (input, output, cache read/write) and the interface used.
`feedback`	User ratings and notes per turn.
`compaction`, `plans`, `tasks`, `summary`, `snaps`, `memory_blocks`, `agent_memory`	Context-compaction checkpoints, plans and to-dos, summaries, snapshot catalog and memory records.

Across Sessions — the Insights Database

Session-level data used by Observation and Evaluation is kept in a relational database, SQLite by default (assurance interface) or PostgreSQL. The tables are created by the deploy of the aifusion LU. See Insights Database Schema.

Where Agents Live

Agents belong to the Data Product whose data they work on:

<LU>/AI/
├── Skills/                     LU-wide skills
└── Agents/<agent>/
    ├── agent.yaml              the agent definition
    ├── Skills/                 agent-private skills
    ├── Subagents/              sub-agent definitions (*.yaml)
    ├── References/<pack>/      reference documents (e.g. KB/, Procedures/)
    ├── Evals/                  evaluation suites (*.csv)
    └── Observation/            signals.yaml, widgets.yaml

Because the definitions are files in the project, they are version-controlled with the rest of the implementation and promoted between environments with a regular deploy. Changes take effect after the LU is deployed (a soft deploy is enough).

Next article: Installation and Setup