> ## Content Index > Fetch the complete content index at: https://www.automatiqa.io/llms.txt > Use this file to discover other available public pages before exploring further. # Orchestriq Core - URL: https://www.automatiqa.io/orchestriq-core/ - Published: 2026-06-22T15:29:41.000Z - Updated: 2026-10-18T10:41:16.000Z - Description: Orchestriq Core is the kernel for agents that run real operations. Evals, approvals, earned autonomy and EU AI Act transparency live in the runtime, so every module inherits them. Spec, gate, park, earn - autonomy is a ladder climbed per action type on measured accuracy. - Author: Aleks Sidorecs - Tags: project, #wip, #readiness-15, kernel, agents, evals, LLMOps, MCP ## Every agent project bolts the controls on last The problem The demo works. Someone asks whether it actually works, so evaluation gets added. It writes something wrong to a live system, so approvals get added. The bill arrives, so cost tracking gets added. Each control is a retrofit, wired around a system that was never designed to carry it. Retrofitted controls are the ones that get switched off under deadline. And the second agent gets built the same way as the first, because nothing about the first one was reusable - the ops discipline lived in one team's habits, not in the runtime. Software takes its safety from reversibility. Operations have none to take. A dispatched truck, a sent supplier notice, a posted stock movement - none of them has a rollback, and the system of record only ever confirms what already happened. So safety has to come from governance applied before the action, not recovery after it. That's the whole reason the controls belong in the kernel: not tidiness, but the absence of an undo. ## The controls live in the kernel, so every module inherits them How it solves it Orchestriq Core is a runtime that knows nothing about your domain. No document schemas, no industry logic, no opinion about what a good answer looks like. What it does know is how to run an agent under supervision: typed actions, a tool registry that decides what a module may call, full transcripts, scorers, an eval gate, and an approval inbox where unattended runs park their requests instead of acting. Autonomy isn't a setting. Each module starts approval-gated on everything and widens only as its measured accuracy justifies it, per action type, with the evidence in the ledger. The kernel enforces this - a module can't opt out of its own governance. Transparency is part of that enforcement. Output the model wrote leaves the kernel carrying EU AI Act Article 50 marking - a line a person can read and metadata a machine can detect - and content a person wrote doesn't. A module can't publish unmarked model output, because the marking is emitted where the action is dispatched. Bring your own model. Cloud API, your own cloud tenancy, or a local model on your own hardware. Swapping providers is configuration, and the eval suite tells you what the swap cost you. ## Spec, gate, park, earn How it works 01 **Spec**A module declares its actions, its schemas and its test set before it runs → 02 **Gate**Changes re-run the test set; anything that degrades it doesn't ship → 03 **Park**Unattended runs stop at the approval inbox with the reasoning attached → 04 **Earn**Autonomy widens per action type as measured accuracy justifies it The kernel runs without any module. A module can't run without declaring how it will be judged. ## Governance in the runtime, not in the habits of the team What makes it different domain-free **The kernel stays empty** No schemas, no industry logic, no connectors to anything specific. The moment domain knowledge leaks into the kernel, every module inherits assumptions it never asked for. earned **Autonomy is measured, not granted** Most agent frameworks let you switch autonomy on. Here it's a ladder, climbed per action type on evidence from annotated cases. The ladder is the product. portable **The model is a parameter** Provider-agnostic transport, so the same module runs on a frontier API, an EU-resident tenancy, or a local model. What changes is cost and accuracy, and both are measured. compliant **Article 50 is a kernel concern** Disclosure marking is emitted by the runtime, not written per module. Every module is compliant on the day it ships because it never had the option not to be. ops-first **Evals before features** The test set is written with the spec, before the code. A module that can't say how it will be judged doesn't get built. ## Where Orchestriq Core is heading Where it stands in build**The loop and the registry** Typed actions, tool registry with central dispatch, provider-agnostic transport, run state and full transcripts. The parts every module sits on. in build**Scorers and the eval gate** Modules register their own checks - deterministic where code can decide, calibrated judges where it can't. Failing sets block the merge, enforced by the kernel. next**Approval inbox and the autonomy ladder** Approvals as first-class objects with a person, a timestamp and a reason. Autonomy widening per action type against recorded calibration. next**First module against the public interface** Document intake, built with nothing added to the kernel to make it fit. If the interface bends, the abstraction was wrong. next**Second module** The real test. A kernel proven by one module has proven nothing. next**Deployment breadth** Self-hosted, cloud, and EU-resident builds of the same artifact, with cost and latency documented per option.