Runtime kernel

FusionKit's runtime kernel is the programmatic substrate for model fusion. It executes typed operator graphs under explicit schedulers and emits replayable outcomes. The kernel is intentionally boring: artifacts, operators, graph execution, budgets, traces, evidence, and outcomes. SOTA behavior lives in schedulers and operators.

Advanced scheduler-family exports are extension points. They define where adaptive routing, tree search, agentic delegation, learned workflow policies, and offline architecture search plug in; they should not be read as full AB-MCTS/TreeQuest, Devin Fusion, or Fugu-style implementations by themselves.

What it gives you

• immutable typed artifacts;
• operator specs with side effects and input/output contracts;
• direct and DAG schedulers plus higher-level scheduler families;
• budget enforcement and single-writer discipline;
• public/private evidence leakage boundaries;
• trace events, outcome records, and replay records;
• a fluent graph builder and built-in workflow recipes.

Compose a direct fast path

import {
  DirectFastPathScheduler,
  ModelGenerateOperator,
  createTaskArtifact,
  graph,
  refs
} from "@fusionkit/ensemble";

const task = createTaskArtifact({ id: "task", prompt: "Say hi." });

const workflow = graph("direct")
  .task(task)
  .node("model", new ModelGenerateOperator({
    model: "demo",
    client: { generate: () => ({ model: "demo", content: "hi" }) }
  }), { inputs: [refs.artifact(task.id)] })
  .scheduler(new DirectFastPathScheduler())
  .compile();

const result = await workflow.run();

This path performs exactly one model call. It does not run hidden panel, judge, synthesis, ranker, verifier, or repair work.

Built-in recipes

import {
  listWorkflows,
  registerBuiltInWorkflows
} from "@fusionkit/ensemble";

registerBuiltInWorkflows();
console.log(listWorkflows());

Built-ins:

Workflow discovery

Application code can call registerBuiltInWorkflows(), listWorkflows(), and getWorkflow(id) from @fusionkit/ensemble. Running arbitrary graph JSON requires an application-provided operator registry, because operators are functions.

Evidence and leakage

Evidence sources record raw observations. Calibrators turn observations into signals. Public signals can guide runtime decisions; private labels are kept out of scheduler-visible state and belong in outcome/replay data.

A good operator should declare whether its output is public evidence, private evidence, or a decision artifact. Public evidence can be shown to schedulers and downstream operators. Private evidence belongs in replay and outcome records, not in scheduler-visible state. This distinction matters when a workflow uses test results, benchmark labels, or provider-specific diagnostics that should not leak into a model prompt.

When to use the kernel

Use the CLI and gateway when you want the normal product behavior: launch a coding agent, run a panel, synthesize a response, and persist session state. Use the kernel when you are building or testing a new fusion workflow and need explicit operators, typed artifacts, scheduler behavior, and replay records.

The kernel is especially useful for:

Recipe: panel capture

Panel capture takes one task artifact and produces candidate artifacts. Use it when you want to inspect or store the independent panel outputs before a judge or synthesizer runs.

import {
  panelCaptureWorkflow,
  registerBuiltInWorkflows,
  runWorkflow
} from "@fusionkit/ensemble";

registerBuiltInWorkflows();

const result = await runWorkflow("panel-capture", {
  task: { prompt: "Explain the release process." },
  models: [{ id: "gpt" }, { id: "sonnet" }, { id: "gemini" }],
  runner: async ({ model }) => ({
    modelId: model.id,
    content: `candidate from ${model.id}`
  })
});

console.log(result.status);

Recipe: rank and fuse

Rank and fuse is the pattern to reach for when you want separate phases for candidate generation, pairwise or scalar ranking, candidate selection, and final fusion. This keeps ranking evidence inspectable instead of burying it inside one large synthesis call.

import {
  rankFuseWorkflow,
  registerBuiltInWorkflows,
  runWorkflow
} from "@fusionkit/ensemble";

registerBuiltInWorkflows();

await runWorkflow("rank-fuse", {
  task: { prompt: "Design a retry policy for provider failures." },
  models: [{ id: "gpt" }, { id: "sonnet" }, { id: "gemini" }],
  panel: async ({ model }) => ({ modelId: model.id, content: "candidate" }),
  rank: async ({ candidates }) => ({ candidates, scores: [] }),
  fuse: async ({ selected }) => ({ content: selected?.content ?? "fallback" })
});

Recipe: execution-select-repair

Execution-select-repair is useful for coding and benchmark tasks where execution evidence matters. The workflow generates candidates, collects evidence, selects the most promising candidate, and repairs it when the repair predicate says the candidate is incomplete.

import {
  executionSelectRepairWorkflow,
  registerBuiltInWorkflows,
  runWorkflow
} from "@fusionkit/ensemble";

registerBuiltInWorkflows();

await runWorkflow("execution-select-repair", {
  task: { prompt: "Fix the parser and run the focused tests." },
  models: [{ id: "gpt" }, { id: "sonnet" }],
  panel: async ({ model }) => ({ modelId: model.id, content: "candidate" }),
  evidence: async () => ({ observations: [] }),
  selector: async ({ candidates }) => ({ candidateId: candidates[0]?.id }),
  repairWhen: async () => true,
  repair: async ({ candidate }) => candidate
});

Production status

The production gateway uses the kernel for panel capture today. The live trajectories:fuse synthesis step still runs through the existing gateway and Python synthesizer path. The workflow registry is the migration point for moving more flows behind explicit workflow IDs while preserving current gateway behavior.

Demo

Run the runtime-kernel example from the repository root:

pnpm build
pnpm demo runtime-kernel