The delivery system for forward-deployed AI

From business process to proven AI worker.

Map the real process, author its agent harness, prove its decisions and actions, deploy the exact tested release, and operate it with approvals and evidence.

FDEs and AI teams drive the system today. The Architect progressively performs the same governed delivery work.

scopethe outcome→ authorthe harness→ provethe behavior→ operatethe worker

Request access See the Builder MCP
invoice-review · delivery record live
resolvelint · deps · validation ✓
qa run16 / 16 scenarios
forbidden events0 emitted
releasev12 · immutable pin-set
deployinstance live · policy loaded
The release that passed QA is the release that runs.
author resolve qa release deploy operate
The Deflation Studio build view: the left panel lists an agent's components — process docs, context, skills, tools, channels, policies, QA scenarios, extensions — and the editor shows the agent's spec file, with draft validation, QA results, and the live release version in the header.
This is the Studio — the IDE for agent delivery. A real agent mid-delivery: 34 draft changes, shape validated, QA on the candidate, v9 live in production.
The delivery lifecycle

The whole implementation path. One system.

Models can reason. Reliable delivery is still manual. Stop rebuilding the machinery around every agent: author, prove, deploy, govern, and improve workers on shared infrastructure that compounds.

Studio + Builder MCP

Author every component — in the IDE, or from your own coding agent.

→ 01 author · 03 build

Extensible runtime

Native primitives: channels, typed tools, plugins, policies — first-class, not glue code.

→ 02 execute

QA Lab

Behaviour and reliability testing against a real deployed test instance.

→ 04 prove

Deployments

Immutable releases — every agent ships to its own live instance.

→ 05 run

Operations

Chat with the agent, approve held actions, follow every activity.

→ 06 operate

Observability

Traces, receipts, and cost — per agent, per run.

→ 06 operate
01 Author · The components

What an agent is made of.

Not a prompt — eight components, versioned together as one unit. Change them like code, review them like code.

Anatomy of an agent: eight components — workspace files, skills, typed tools, plugins and extensions, channels, QA scenarios, prompt mounts, runtime policy — versioned together as one unit. AGENT eight components · versioned together as one unit Workspace files the process it follows, written down AGENTS.md · IDENTITY.md Skills procedures it can reuse across tasks imported from the catalog Typed tools actions it can take, with declared side effects typed inputs & outputs Plugins & extensions capabilities it gains, pinned per version no silent upgrades Channels where it talks to real people webchat · email · SMS · Telegram QA scenarios the hard cases it must pass, as repeatable tests expected + forbidden Prompt mounts exactly what its model sees, each turn explicit and reviewable Runtime policy which of its actions need human approval the operating boundary

typed tools CRM update ERP lookup calendar hold invoice draft

skills invoice triage tone & escalation rules

channels webchat email SMS Telegram

Typed primitives

Every component above has a schema — channels, tools, and policies are types, not free-form config.

Validated shape

resolve checks every component against its schema — lint, dependencies, validation — before anything ships.

Native execution

The runtime understands these primitives natively — channels, typed tools, plugins, prompt mounts, and policies are first-class runtime concepts, not glue code.

tools/erp_lookup.TOOL.yamlshape valid ✓
name: erp_lookup string ✓ inputs: invoice_id string · required ✓ side_effect: read_only enum ✓ approval: not_required policy ✓
An invalid shape never ships — validation runs before every release.

Authored and validated — next: what happens when the runtime executes them.

02 Execute · The loop

What happens on every run.

The harness defines it. The loop executes it. One run — context in, tools called, effects gated, every step recorded.

One run: a message arrives on a channel, context assembles from the harness, the model and typed tools loop until done, consequential actions are held for approval and produce receipts, the reply goes back out — and every step is recorded as facts, traces, and cost. CHANNEL message in webchat · email SMS · Telegram HARNESS context assembles process docs · skills · memory stacked per turn THE LOOP model decides typed tools act tool call ⇄ result · ×n repeats until the task is done ↺ consequential action? no yes held for approval ⏸ approved executes → receipt ✓ reply out back on the same channel every step recorded facts · traces · cost — the evidence each run leaves behind

Everything this loop executes gets authored somewhere — next: the Builder MCP, where your coding agent writes it.

03 Build · The MCP

A guidance system for your coding agent.

Connect Claude Code, Cursor, or any MCP client. It gets the methodology, the gates, and the tools to author every component above — and it cannot skip steps.

Methodology

Your agent learns the delivery method from the MCP itself — how to map a process, author components, write test scenarios, and when an action needs a human. No docs tab required.

Gates

The MCP refuses to skip steps. Evidence, not confidence, moves work forward — and because every component is schema-validated, an invalid shape never reaches a release.

resolve ✓ before releaseqa evidence before deployapproval before consequential actions

The components

It authors every component from the anatomy above — files, tools, channels, tests, policies — in one versioned workspace, like editing a repo.

coding agent · connected to Deflation Builder MCP
❯ learn the workflow ✓ author → verify → test → release → deploy ❯ write the components process doc · ERP lookup tool · QA scenario ❯ cut a release ✗ blocked · verification has not passed yet ❯ verify the agent ✓ lint · dependencies · harness validation ❯ run the test scenarios ✓ 16/16 passed · 0 forbidden events ❯ cut a release ✓ release v12 · immutable ❯ deploy ✓ live · own instance · release policy loaded

Connect once — the MCP walks any coding agent through the entire delivery workflow. Then what it built has to survive QA, next.

04 Prove · QA

QA that tells you what to fix.

You define how the agent must behave — and must never behave — and prove it against a real deployed instance before any customer sees it.

scenario · vendor-disputebehaviour
inbound "Invoice 2041 is wrong — we were billed twice." must look up the invoice · draft a reply must never void an invoice · send anything unapproved
Behaviour and its boundaries, written down as a repeatable test.
qa run #48 · candidate v1215/16
late-invoice ✓ pass duplicate-invoice ✓ pass vendor-dispute ✗ fail crm_update → tool not connected
Runs execute on a real deployed test instance — full trace per scenario.
✗ vendor-dispute fails→ classified · tool not connected→ repaired · credentials connected→ ✓ rerun · 16/16 · 0 forbidden events

Iterate in minutes

Dry runs while authoring; full reruns on demand.

Regression-proof releases

Scenarios rerun on every change — releases ship only on green evidence.

Cost visibility

Every run reports what it cost before it ships.

Green evidence in hand, the release ships — next: its own live instance.

Bring one agent. See it survive QA.

Request access
05 Run · Deployed

Deployed: your agent gets its own instance.

Deploying a release provisions a live server instance with the exact tested components, a worker identity, declared integrations, and connected channels. Consequential outbound actions are held for approval and produce receipts.

A deployed agent instance: channels connect through the middleware platform for model routing, approvals, receipts, and integration configuration. The exact tested release runs with its worker identity and declared tools against business systems such as ERP, CRM, and calendar. CHANNELS webchat email SMS Telegram PLATFORM middleware hub LLM proxy routes + bills model calls approval gate held for approval ⏸ receipts ✓ recorded per action integration config declared providers runtime configuration relays AGENT INSTANCE its own server release v12 immutable pin-set worker identity acts as itself declared tools typed side effects direct API calls · declared tools fact-backed effects SYSTEMS called directly ERP CRM Calendar supplies runtime config

The release declares its tools and side effects. Communications and consequential actions flow through the platform, where approvals hold them and receipts record what happened. Stronger network and credential isolation remains an active hardening track.

own server instanceworker identitydeclared toolschannels connectedapprovals + receipts

Deployment is not the finish line — next: operating the agent, day to day.

06 Operate · The Business OS

One surface to run every agent.

A deployed agent is not a black box. You chat with it directly, follow everything it does as fact-backed activity, approve or reject its held actions from one inbox — and see what each agent costs.

The operations surface: an agent's activity feed — a drafted reply held for approval with a release button, an offer created as a draft in the ERP, a clarifying question back to the team, and an approved calendar booking with its receipt — with overview and cost views in the sidebar.
The operations surface — an agent's working day. A drafted reply waiting for approval, an offer created as a draft in the ERP, a question asked instead of a guess — every entry backed by a receipt. Shown in German, as its team uses it.

Chat

Talk to the deployed agent directly — ask, instruct, correct, on the same channels its work arrives on.

Approvals

Consequential actions wait for you in one inbox — approve or reject, nothing goes out on its own.

Activity

Fact-backed traces of everything the agent did, with an artifact receipt per action.

Costs

Usage per agent, per action — you always know what a run cost before the bill does.

And we deliver on these same rails ourselves — the Architect, below.

07 The Architect · Same rails

The same delivery system, increasingly driven by our agent.

The Architect is Deflation's forward-deployed agent. Business stakeholders describe the process and the outcome; the Architect scopes the work, authors the components, proves them in QA, and deploys through the same contracts your engineers use.

stakeholder describes the process→Architect authors the components→QA proves it→release ships

No separate machinery, no privileged path. If the rails are good enough for our agent to deliver on, they are good enough for yours — early access, below.

08 Early access

Make every agent easier to deliver than the last.

For forward-deployed engineers and AI platform teams: one implementation system that turns field work into reusable infrastructure. Early access includes:

  • The Studio + the Builder MCP — the IDE for agent delivery, plus the MCP for your own coding agent
  • Managed deployment — every agent ships to its own live instance, secrets scoped to its identity
  • Usage-based compute and hosting — you pay for what your agents actually run

No newsletter drip. A short note when the platform is ready for another team.