EEMBD
Loading…
Loading…
Agents decide what to do; the runtime does it provably. Gates, lineage and metering fire on every run because they live in the engine beneath the agents, not in the skills that ride on top of it.
Everything an agent draws on is one of two things: knowledge it reasons with, or a procedure it runs. Keeping them distinct is what makes the guarantees enforceable, only one of them ever executes.
Component skills package structured domain knowledge, schemas, mappings, rules of thumb, reference material, and are loaded as context for an agent to reason over. They inform a decision, but they never execute. Think of them as what the agent knows, not what the agent runs.
Procedure skills are executable units of work, ingest this source, apply that mapping, validate against these checks. They run only through the executor, never on their own. That single entry point is what lets every procedure inherit the same gates, lineage and metering.
Every procedure runs through the same executor, in the same order. The skill supplies the work; the executor supplies the guarantees. A skill can't skip a gate or forge its own lineage, those steps aren't its to control.
The executor checks the request against the procedure's contract before any work begins, shape, types, required fields. A malformed input fails fast.
Quality and policy gates run and block. A failed gate stops the run; the skill has no way to disable, reorder or step around a gate.
Provenance is recorded by the executor, not by the skill, source → transform → validation → delivery. The skill can't forge its own lineage or omit a step.
On success, the work is metered per customer, per skill, per month. Nothing is counted on failure, so the number stays a measured fact.
A single append-only run record is written, binding the inputs, gates, lineage and metered result into one durable, auditable entry.
No agent talks to a provider SDK directly. Every model call passes through a provider-agnostic Model Gateway, so the model underneath is an implementation detail, swappable without touching an agent.
The gateway carries adapters for multiple providers, Bedrock and Claude, plus others, behind a single registry with fallback. If a provider is unavailable, the registry routes around it. Agents call the gateway; the gateway calls the provider.
A Prompt Compiler renders one model-neutral skill into the per-model payload each provider expects. You author a skill once; the compiler shapes it for whatever model runs it. Oliver starts on Bedrock + Claude and stays swappable from day one.
Agents never import each other's code. The only thing that crosses between stages is data that satisfies a contract, so stages stay independent and a change in one doesn't ripple into the next.
Each handoff is a versioned JSON-Schema contract, validated before it passes. If the data doesn’t match the contract, it doesn’t move, the mismatch surfaces at the seam, not three stages later.
Because the contract is the only coupling, each stage is free to change how it works internally as long as it still honors the schema. Versioning the contract makes a breaking change explicit rather than a surprise.
A versioned JSON-Schema contract sits between every pair of stages. Adding a stage means adding a contract, not rewiring the ones around it.
A skill doesn't become runnable by being written, it becomes runnable by being minted. Everything a skill does in production has passed through the same gated path first.
A skill starts as a draft, authored, named and versioned, but not yet allowed anywhere near a production run.
Changes land through a pull request. Nothing reaches the runtime by being edited in place; every change is proposed, reviewed and recorded.
Continuous integration builds and tests the skill. CI decides what code the executor will ever be allowed to run, a security boundary, not just a quality check.
A designated code owner reviews and approves. Ownership is explicit, so a change can't slip in without a responsible human signing off.
Only then is the skill minted, registered as a versioned, runnable procedure the executor will accept. Mint is the one door in.
CI is the decisive gate: it determines what code the executor will ever run, which makes it a security boundary as much as a quality one. The executor runs minted skills and nothing else.