Three-layer runtime
Runtime for Memory + Decision Engine.
How your agent’s outputs become typed, audited decisions.
Three layers, one contract with your CTO: tenants own their kernels · operators don’t see your data · reviewers see every choice.
01 · The Architecture
Compute. Ontologies. Decision-Orchestration.
Three layers, one runtime.
This is what your CTO sees when they review the architecture. The homepage names the three layers in a single line at the bottom of “How it ships.” Here they get their sections.
Decision-Orchestration
Typed decisions · HITL gates · audit rows · overrides
Ontologies
Per-tenant typed kernels · authored by the tenant
Compute
Per-tenant database · durable workflows · action dispatch
Compute
Per-tenant database, durable workflow runtime, typed action dispatch.
Your data lives in your tenant’s schema. Long-running operations survive crashes. Every side effect is a typed row in an audit table.
Ontologies
Per-tenant typed kernels. Your domain expert authors them; the platform compiles them to typed classes at runtime.
Your business vocabulary is yours. Not a prompt fragment. Not a config file. A schema.
Decision-Orchestration
Typed decisions surface as ChoiceArchitectures. HITL gates route human approvals. Audit rows record every choice.
Your agent outputs typed decisions, not strings. Your reviewer sees the trade-offs. Your CTO sees the trail.
02 · Authoring
Your domain expert writes the schema.
Through the IDE-agent they already use.
Most agent stacks push domain knowledge through prompts. That makes the schema implicit, brittle, and unowned. We expose kernel authoring as an MCP surface: Claude Code (or any MCP-capable IDE) can propose, validate, and apply kernel changes against your tenant. The tenant owns the kernel; the platform owns the compile pipeline.
# tenant/ind-sales-pilot/kernel.yaml
id: https://ind-sales-pilot.zunft.ai/kernel
imports:
- linkml:types
classes:
Lead:
slots:
- lead_score # 0..100
- fit_signals # multi-select from your industry taxonomy
- risk_flags # compliance, credit, geopolitical
- recommendation # QualifyingDecision output
QualifyingDecision:
is_a: Decision
slots:
- lead_id
- options # 2..5 typed alternatives
- trade_offs # named tensions between options
- default # prescriptive with justification
- hitl_gate # reviewer state machine
- audit_row # sha256 + timestampArchitectural note
The IDE-agent invokes zunft.author_kernel over MCP. The proposed kernel is diff’d against the current tenant kernel, validated against schema type rules and platform-universal invariants, then compiled to typed classes and runtime constraints. The pipeline is deterministic; the same YAML compiles to the same classes.
03 · Deciding
Your agent returns a decision.
Options, trade-offs, provenance — typed.
When the agent answers a real business question, it returns a ChoiceArchitecture — a typed object with two to five substantively different options, named trade-offs, predicted KPI deltas per option, provenance, and an agency-health score. Single-string answers are non-conformant: there is no API path that returns one.
result = zunft.generate_decision(
class_curie="lead:QualifyingDecision",
input={"lead_id": "L-4421"},
)
result.options # list[Option] — 2 to 5 substantively different
result.trade_offs # list[TradeOff] — cross-option tensions
result.default # Option — with prescriptive justification
result.options[0].pedigree # "conservative" | "novel" | "agency-preserving"
result.options[0].predicted_kpi # {conversion: +0.08, cycle_time: -0.05}
result.agency_health # 0.84
result.provenance # PROV-O chainArchitectural note
Option generation uses a quality-diversity search that surfaces substantively different paths, not variations of one answer. Each option is verified along multiple axes (formal shape, executable plan, KPI projection, choice-set diversity) before it surfaces. The ChoiceArchitecture is the API contract, not a hand-shaped JSON.
04 · Auditing
Every decision is a row.
Every override calibrates the next one.
Every decision Runtime emits writes an audit row: which tenant, which class, which options were considered, which was defaulted, whether HITL was triggered, whether the reviewer overrode, and why. Every override is a typed event that feeds the next iteration of the generator. Compliance answers “who told the AI to do that?” with a single query. Under EU AI Act Art. 13 (transparency), the audit row IS the trail.
proposed → reviewer:pending → approved
│
└──→ overridden → rationale captured
→ triad classification
→ generator calibration eventaudit_row {
decision_id: lead-qual-2026-06-25-001
class: lead:QualifyingDecision
tenant: ind-sales-pilot
proposed_at: 2026-06-25T11:42:18Z
options_hash: sha256 7a3f…
default_option: opt-2
hitl_status: approved
reviewer: u_9c2e…
reviewer_at: 2026-06-25T12:01:04Z
override: none
provenance: PROV-O:activity/…
}Architectural note
Reviewer state, override rationale, and provenance are the same row. There is no separate audit database, no separate override log, no separate provenance store. Compliance queries against the audit trail; the generator queries the same trail for calibration.
05 · In Production
From CRM optimization to decision engineering.
Runtime under real commercial use-cases.
The homepage teases the CRM optimization trap. Here it opens up. A sales-org running on a modern CRM has fields, workflows, integrations — everything a record-keeping system needs. What it lacks is a typed representation of the decision moments: which lead qualifies, which deal to escalate, which commercial term to concede. Those moments live as free text in the CRM, as Slack threads, as human tacit knowledge. That is what Runtime types.
01 · The optimization trap
A sales-org’s CRM captures activities. It does not capture the reasoning behind the activities. As AI floods the pipeline with drafts, briefings, and recommendations, the reasoning gap becomes the bottleneck — nobody can review, nobody can override, nobody can trace. The CRM’s answer is more fields and more workflows. That is optimization, not transformation.
02 · The decision-engine shift
Runtime types the decision moments the CRM leaves as text. Each moment becomes a class in the tenant kernel. Each invocation becomes a typed ChoiceArchitecture. Each reviewer sign-off becomes an audit row. The CRM stays; Runtime sits under the reasoning layer.
03 · Currently shipping
We are running Runtime against real industrial-services commercial use-cases in DACH. Deployments are under NDA — production, not proof-of-concept. If you have an industrial-services commercial use-case and are considering how to move the reasoning layer from CRM-text into typed decisions, apply to be a design partner.
Apply to be a design partner06 · Authored With
Author from Claude Code.
Or any MCP-capable IDE.
The homepage integrations strip names Claude Code as the primary author-time surface. Here is why: our Tenant-MCP server is a real, hosted MCP endpoint at api.zunft.ai/mcp/tenant/stream. Any client that speaks MCP over streamable-HTTP with OAuth 2.1 discovery can connect — we ship first-class support for Claude Code and gate other clients (Cursor, Cline, Codex) on stream-compat verification.
What the IDE-agent gets
zunft.author_kernel— propose, validate, apply kernel diffszunft.introspect_tenant— read the current tenant’s classes, slots, HITL gate statezunft.dry_run_kernel— compile a kernel diff without applying (checks types + invariants)
How auth works
The first MCP tool call returns 401 Bearer with a resource_metadata header. Your IDE-agent discovers our authorization server via /.well-known/oauth-protected-resource, dynamically registers as an OAuth client, PKCE-flows the user through their tenant’s sign-in in a browser, and caches the token locally. Subsequent calls attach the Bearer silently.
Standards: MCP spec 2025-03-26 · OAuth 2.1 (RFC 8252) · JWKS token verification.
07 · Runs On
Runtime is protocol-first.
We operate LangGraph and Windmill under the hood.
The homepage integrations strip Row 2 names three protocol surfaces and two operational frameworks. Protocols keep you framework-agnostic: any orchestrator that speaks HTTP or MCP can invoke a typed decision or read a typed schema. LangGraph and Windmill are named because we run them ourselves — they are not partnership badges, they are first-party operational truth.
Protocol surfaces
HTTP
REST endpoints for schema introspection, plan dispatch, action invocation, audit query. Framework-agnostic.
MCP
The same tool surface (author, generate, audit) exposed to IDE-agents (see Section 06).
Python SDK
Per-tenant typed classes emitted by the compiler.
importand use — no schema round-trip.
Operational frameworks we run
LangGraph
Used inside Runtime for multi-step agent flows that compose decisions with retrieval and action.
Windmill
Used as the durable workflow layer for long-running operations that must survive process restarts.
08 · Multi-Tenant, By Design
Per-tenant kernel. Per-tenant database.
Tenants own their kernels. Operators don’t see the data.
Adding a tenant is authoring a kernel and compiling. No platform code changes. The three-layer architecture operates identically against every tenant because the universal vocabulary is in scope via imports: and tenant types subclass from schema primitives. Per-tenant database schemas isolate data at the storage layer, not at the application layer.
01
Per-tenant kernel
Each tenant authors and owns its typed schema. The platform compiles it to typed classes at runtime. Cross-tenant patterns can be extracted as reusable primitives — but never as tenant data.
02
Data sovereignty
Per-tenant database schema. Operators do not see tenant rows. Reviewer, override, and audit surfaces run inside the tenant’s tenant identity, not the operator’s.
03
Compliance posture
GDPR · EU AI Act Art. 13 audit trail · Sovereign Cloud deployable · SOC 2 (in progress) · ISO 27001 (in progress). Compliance is a runtime concern, not a bolt-on.