Evidence

Every claim on this site, with its receipts.

How Krateos is built, how it is governed, and the numbers behind the claims — including the ones that went against us. Every figure below comes from a repository, a benchmark run, or a production log. No source code, prompts, or engine internals are published here.

See the tournament →Cost telemetry
The system

Eight agents, one runtime, one governance layer.

Krateos runs on an open-source agent runtime through an official-SDK plugin. The runtime gives agents tools and memory; the plugin adds what an ERP deployment needs and a general runtime does not — governance, approvals, audit, and the portal operators run it from.

Agents
Eight domain agents, two utility agents
Procurement, customer service, production, quality, warehouse (DDMRP), accounts payable, accounts receivable, and demand planning. 31 agent skills · 55 scheduled jobs · agent-to-agent mailbox
MCP servers
Five servers, seventy-one tools
IFS Cloud (33 tools behind 3 meta-tools), live Sage X3 over GraphQL (18), the forecast engine (12), the DDMRP buffer engine (7), and email. An OAuth connection registry covers IFS Cloud, Sage X3, and Dynamics 365 BC, with health monitoring and automatic respawn of dead sessions.
Plugin
Governance hooks on every tool call
Hooks on before_tool_call · before_prompt_build · after_tool_call · agent_end enforce the risk ladder below, run the approval queue, extract entities into memory, and write an append-only audit log.
Portal & jobs
The operator's control plane
Runs, approvals, schedules, tools, skills, MCP health, traces, per-call cost, audit, users, and permission sets. Background jobs run the nightly forecast refresh, the weekly model bake-off, DDMRP buffer recompute, and document intake. Traces are joined to cost and cache-tier telemetry.

Scale, for calibration: 2,867 commits and 752 pull requests on the main branch; roughly 6,000 automated tests across plugin, portal, and jobs. Developed independently, February–August 2026.

Governance

Autonomy is earned, one tier at a time.

An agent inside an ERP can create purchase orders, move inventory, and touch money. Krateos assumes it will sometimes be confidently wrong. Every tool call is classified on a six-tier risk ladder and runs in one of three modes the operator sets per tool: observe (log only), suggest (queue for approval), or act.

Tier 1
Read
Look things up. Always allowed.
auto
Tier 2
Notify
Send a brief, raise a flag, message a coworker agent.
auto
Tier 3
Update
Change an existing record — a date, a quantity, a status.
suggest → act
Tier 4
Create
Create a record — a purchase order, a work order, an inspection.
suggest → act
Tier 5
Financial
Anything that moves money. Queued for a named human regardless of mode.
always human
Tier 6
Delete
Not available to agents.
blocked
  • Before the ladderA per-agent tool allowlist. Tools the role doesn't need are blocked before any risk evaluation.
  • Entity rulesHard rules scoped to specific suppliers, customers, parts, or sites, in a rulebook the customer owns.
  • Approval queueA suggested action waits for a named approver. On approval a one-time token wakes the original agent session, the gate lets that one action through, and the approver is notified. Denials are fed back as agent memory.
  • Anti-hallucinationRead-before-write interlock; HTTP ≥ 400 is an error, never a success; a verify-claim tool; and an end-of-run check that flags any brief claiming an action when no write tool actually fired.
  • AuditAppend-only log per workspace. Every tool call, verdict, and approval is traceable. 156 automated tests cover the governance layer.
The tournament · foundation models vs. the incumbent

The incumbent won. We published it anyway.

Dana's forecasts come from a tournament: every model competes on each series' own held-out history, and nothing ships unless it beats a naive baseline. In August 2026 we entered three time-series foundation models against the incumbent statistical menu on our demo catalog — 69 series, seven demand archetypes, pinned model revisions, identical scoring windows. A tournament only means something if the results are allowed to say no.

Chronos-2Amazon · foundation model
incumbent 39 · tied 5 · Chronos-2 10 · median error +5.5% worse
80% band held 74.6% (n = 2,784) · ties within ±2%
Chronos-2-smallAmazon · foundation model
incumbent 44 · tied 5 · Chronos-2-small 8 · median error +4.8% worse
80% band held 73.3% (n = 2,928) · ties within ±2%
TimesFM-2.0Google · 500M foundation model
incumbent 35 · tied 17 · TimesFM-2.0 8 · median error +4.8% worse
80% band held 78.9% (n = 3,120) · ties within ±2%
incumbent winstiechallenger wins

Error is MASE vs. naive; delta is the challenger's error relative to the incumbent's. The foundation models did win individual series — notably seasonal ones — which is why they stay in the tournament as contenders. A separate deployability run measured Chronos-2 at ~9.4 s median inference on a 2-core machine vs. 56 ms for Chronos-Bolt-small.

Public data · May 2026

Two hundred series it had never seen.

To check that the engine works outside our own data, we ran it on 200 series from three public benchmark datasets. Pass means a model beat naive on held-out history and the forecast shipped. Staged means the engine refused — the right answer when the history can't support a forecast.

Monash Car Partsintermittent · ~39 observations per series
50 series · 0 pass · 50 staged · 0 errors
Histories too short for the 52-week baseline. The engine refused every one — it knows when not to forecast.
M4 Weeklysmooth and seasonal · 392–2,296 observations
50 series · 50 pass · 0 staged · 0 errors
Fourteen different winning models across fifty series — real selection, not a one-model default.
M5 Walmartgrocery · daily aggregated to weekly
100 series · 96 pass · 4 staged · 0 errors
Croston-SBA leads on slow movers. The four staged series had no model beating naive, so none was passed.
Favoritaregime shift
blocked
An upstream loader incompatibility stopped the run. Recorded as blocked, not left out.
Total
200 series · 146 pass · 54 staged · 0 errors
Zero engine exceptions across 200 cross-validation rounds.

Not validated by this run: hierarchical reconciliation, exogenous regressors, and structural breaks. The purchase-order intake pipeline has its own harness — 17 ground-truth cases rendered to synthetic PDFs and degraded to simulate scans, with deliberate traps (buyer-logo prominence, invoice-style POs, OCR confusables like RP5-100 vs RPS-100, European decimals).

Cost telemetry · Claude API

Every call priced. Reconciled to the token.

Each model call is logged with its cache tier and reconciled against the Anthropic console. These are production numbers, not estimates.

  • 181 sessions · 1,602 turnsParsed off the live container in April 2026: $0.14 mean and $0.24 p95 per session, with 83% of input tokens served from cache.
  • Context vs. costContext grows about 11× from turn 1 to turn 16; cost per turn stays flat at $0.01–0.02 because of prompt caching.
  • 1-hour cache TTLOn the stable prefix (May 2026): a turn-2 cache read of ~42K tokens at $0.015 — about 10× cheaper than the cold turn. Cross-session content-addressed hits confirmed.
  • Keep-warm daemonConnects as a chat client to warm the exact prefix real chats read. First turn after more than an hour idle: $0.0146 vs. ~$0.20 cold.
  • Executor / advisorA small model executes, a large model advises: ~$0.19 per run vs. ~$3.60 with the large model everywhere.
  • A number we retractedA controlled test suggested cross-agent wake-ups were 62% of spend. Re-measured over a real seven-day window: ~4%. The docs now carry the 4%.
  • A leak we foundA cache-control object applied by reference to two message blocks leaked the 1-hour TTL onto conversation turns. Found in telemetry, fixed, verified on the wire, and the test rewritten to replicate production.