Product

Orcher

The agentic control plane that makes frontier autonomy safe to actually deploy. Provider-neutral, role-bound, and evidence-producing by construction — the layer between your professionals' authority and the models that execute on it.

Seven components · Two layers · One verified execution cycle

Orcher — seven components, two layers

Fig. ORC-02

Layer 1 · Accountability

C0

Directive Interface

Where intent enters, attributed.

C1

Role Identity Fabric

Authority bound to a person.

C2

Logic Scrubber

Pre-commit verification.

C3

Immutable Audit Ledger

Hash-chained evidence.

Layer 2 · Operations

C4

Data Control Gateway

Data boundary and redaction.

C5

Cost Governance

Routing and spend ceilings.

C6

Observability

Cross-provider execution telemetry.

Model-agnosticDeploys beside existing agentsNo re-platforming

Full architecture

The whole control plane, in one view.

Directive in, four sequential gates, three continuous controls, a verified commit to your systems of record, and evidence that outlives the run.

Orcher — full architecture, intent to evidence

— / 13
100%

Layer 1 — sequential, gating

Layer 2 — continuous

GovernedintentSCOPEDLAYER 1 — SEQUENTIAL, GATINGC1Directive InterfaceTurns open-ended promptinginto governed workC2Role Identity FabricGives autonomy anaccountable identityC3Logic ScrubberMakes policy executableC4ImmutableAudit LedgerConverts activity into…Any gate fails → cycle halts. Nothing partial is written.LAYER 2 — CONTINUOUS, NON-BLOCKINGC5Data Control GatewayHolds the data perimeter. DataboundaryC6Cost GovernancePuts an economic boundaryaround autonomy. Ceilings per…C7ObservabilityOne control view across everymodelPROVIDER-NEUTRAL EXECUTIONFrontier modelsAgent frameworksInternal modelsTools & RPASystemsof recordCOMMIT

drag · pinch or scroll to zoom · double-tap to reset

Guided walkthrough

What the seven components enforce

Press Start walkthrough, or select any node, to step through the seven components. Each one closes a different gap that keeps enterprises from scaling agents: C1 scopes the work, C2 binds it to accountable identity, C3 makes policy executable before commit, C4 turns activity into defensible evidence, and C5–C7 hold enterprise data boundaries, cost and cross-provider visibility continuously. Together they are Dipp AI's position — Enterprise Superintelligence that is governable by construction.

Source: Vol. I, p. 19 — Component Schematic v1 — the seven components
One verified execution cycle: authority in, four gates in sequence, three continuous controls alongside, a commit to your systems of record, and evidence that outlives the run.
Orcher's two layers: gating components above, continuous components below
Seven components across two layers. Layer 1 gates execution; Layer 2 runs continuously.

Interactive · Vol. I sourced

Seven components, seven passages of evidence.

Select any component to reveal the passage from The Enterprise Superintelligence Report, Vol. I that specifies it, with its page citation and a link into the source.

Select a component to reveal its Vol. I excerpt.

Layer 1 — sequential gatesLayer 2 — continuous controls01Directive InterfaceIntent captured02Role Identity FabricAuthority bound03Logic ScrubberAction verified04Immutable Audit LedgerEvidence hashed05Data Control GatewayData boundary + no-training06Cost GovernanceCeilings on autonomy07ObservabilityCross-provider traceOrcher™ · Dipp AI Technologies

Fig. CP-01 · The seven-component control plane

Orcher · seven components

One control plane. Seven jobs it never delegates.#

Four sequential gates decide whether an action may commit. Three continuous controls hold data, cost and visibility while it runs. Each is a separate component with its own contract and its own evidence.

The strategy behind Orcher

Dynamic model routing.#

Binding a platform to one heavy frontier model wastes tokens and leaks proprietary data. Dipp AI's strategy — and the reason Orcher's seven components exist — is intelligent routing: decouple orchestration from any single provider, match each task to the cheapest model that can carry it, and keep prompts and data inside the enterprise's own tenant boundary.

DIPP AI / ORCHER

Seven components. One enterprise-owned control plane.

01 + 02 / AUTHORITY

A role-bound directive

Intent, named professional, permitted actions and systems of record.

06 / COST GOVERNANCE

Dynamic model routing

Select the least costly sufficient model within the task’s stakes, latency target and spend ceiling.

Explore Cost Governance

05 / DATA CONTROL GATEWAY

Boundary before egress

Region, redaction, retention and training-exclusion requirements determine which destinations qualify.

Frontier reasoning

  • GPT-6 Astra
  • Claude Fable 5.1
  • Claude Mythos 5.1
  • Muse Spark 1.3

Models discussed in Dipp AI Research · September 6, 2026

Open-weight & private

  • Llama
  • Qwen
  • DeepSeek
  • Mistral
  • Gemma
  • Enterprise-tuned models

Model families · exact versions and licences assessed per deployment

Compute destinations

  • AWS
  • Microsoft Azure
  • Google Cloud
  • CoreWeave
  • Lambda
  • Crusoe
  • Private infrastructure

Hyperscalers, neoclouds and enterprise infrastructure

03 / Logic Scrubber

Verify proposed actions before commit.

04 / Immutable Audit Ledger

Preserve the decision and refusal evidence.

07 / Observability

Trace cost, latency and outcomes across routes.

Illustrative routing architecture, not a live connection status or an exhaustive integration catalogue. Provider availability, model access and deployment readiness are confirmed during a technical briefing.
01

Decoupled orchestration

Switch providers in a week, not a quarter.

An orchestration layer sits in front of every AI task rather than inside one vendor's SDK. Directives, roles, policy and evidence live in Orcher, so a provider change is a routing-table change — a week of work rather than a quarter of re-platforming — and no model vendor becomes the system of record for how the enterprise operates.

The protocol stack
02

Task-to-model matching

Roughly 90% of workloads never need the frontier.

Cost Governance routes by the stakes of the action rather than the habits of the developer. Standard, routine queries — roughly nine in ten workloads — go to cheaper open-weight or small in-house models; expensive frontier models are reserved for genuinely complex, high-reasoning tasks. Across 400-plus models and 70-plus providers the price spread is 4,500× (Vol. I, p.25), so the routing decision is the economics.

Cost Governance
03

Private tenant boundaries

Providers never learn from your interaction data.

The Data Control Gateway forces data and prompt histories to stay inside the company's own cloud environment — a private tenant, in-region — and verifies training exclusion and the data boundary on every call before a token leaves. Using frontier capability never means donating enterprise interaction data to the firm that sells it back.

Data Control Gateway

Runtime workflow

Authority per directive.#

Routing is not a developer preference resolved in a config file. For every directive, Orcher resolves who is accountable, selects the cheapest model class that authority permits, carries the data boundary along the chosen route, and hashes the whole decision into one evidence chain that reads the same across every provider.

  1. 01

    Authority is resolved before a model is chosen

    Who is accountable, and what may they authorize?

    The directive arrives with a named issuer. The Role Identity Fabric resolves that professional's current entitlements and binds them to this cycle, so the routing decision is made against a known authority rather than a service account. Anything outside the role halts here — before a single token is spent.

    Enforced by

    Emits
    A role-bound authorization token scoped to this directive.

  2. 02

    The routing decision is a policy decision

    What is the cheapest model class this directive's stakes permit?

    Cost Governance classifies the workload by stakes, sensitivity and reasoning depth, then selects the cheapest sufficient model class within the ceiling in force for that role. Roughly nine in ten workloads clear on routine classes; frontier capacity is reserved for complex work. The chosen class, the alternatives considered and the ceiling applied are all recorded as part of the decision.

    Enforced by

    Emits
    A signed routing decision: class chosen, ceiling applied, rationale.

  3. 03

    The data boundary travels with the route

    May this payload reach that provider, in that region?

    The Data Control Gateway applies data-boundary, redaction and training-exclusion rules to the route that was chosen, not to a default path. If a class is otherwise optimal but its provider cannot satisfy the boundary, the route is refused and the next sufficient class is selected. Consistency across providers is enforced by the gateway, not negotiated per vendor SDK.

    Enforced by

    Emits
    A per-call boundary attestation: region, redactions, no-training terms.

  4. 04

    Every decision lands in one evidence chain

    Can this be replayed and defended months later?

    The Immutable Audit Ledger hashes the directive, the authority, the routing decision, the boundary attestation and the committed action into a single tamper-evident chain. Observability streams the same run across whichever providers were involved, so one query answers what was asked, who authorized it, where it ran and what it cost — regardless of vendor.

    Enforced by

    Emits
    A replayable, hashed execution record with cross-provider cost and latency.

Interactive · routing simulator

Enter a workload. See where it routes.#

Each workload type carries a different level of stakes, sensitivity and reasoning depth. Select one to see which Orcher component owns the decision, which model class it routes to, which gates run, and what that does to tokens and cost against a frontier-default baseline.

Workload type

Routing decision

Document classification and routing

High-volume intake: label the document, extract identifiers, route it to a queue. No irreversible write, no judgement call.

Decided by

Cost Governance

Routed to

In-house small model

Runs inside the tenant. No egress, lowest unit cost, deterministic latency.

Token reduction

42%

1,800 → 1,044 tokens

Cost per directive

$0.00013

baseline $0.0432 on frontier model

Cost saving

100%

2360ms faster median

Gates that run before commit

  1. Role scope check
  2. Cheapest-sufficient class
  3. In-tenant execution
  4. Hashed record

Stays inside the tenant entirely — the payload never reaches an external provider.

Indicative class prices per 1M tokens: In-house small model $0.12 · Open-weight mid model $0.60 · Commercial mid-tier $4.50 · Frontier model $24.00. Illustrative only; the 4,500× spread across 400+ models and 70+ providers is from The Enterprise Superintelligence Report, Vol. I, p.25.

Interactive · economics

What routing does to the bill.#

A frontier-default estate pays the top price band for every workload, including the nine in ten that never needed it. Move the inputs to your own volumes and see the token waste removed and the cost impact of the routine-versus-frontier split.

Your estate

250,000

One directive is one verified execution cycle.

5,000

Prompt plus completion, before scoping and redaction.

90%

Dipp AI's routing model puts this at roughly 90%; the remainder is frontier-only.

32%

Directive scoping, field redaction and cache reuse before a model is called.

$24

Your blended frontier rate.

$0.60

In-house or open-weight class hosted in your tenant.

Estimated impact

Monthly cost, frontier default

$30.0K

1.25B tokens at the top band

Monthly cost with routing

$2.5K

$459 routine · $2.0K frontier

Token waste removed

400.0M

32% of 1.25B never reaches a model

Cost reduction

92%

$27.5K per month

Annualised

$330.0K

Retained by routing 90% of directives to a routine class and reserving the frontier for the 10% that genuinely needs it — with every routing decision hashed into the same audit chain as the action it paid for.

Estimates only, for planning conversations rather than contract terms. The 4,500× price spread across 400+ models and 70+ providers, and the 68% of AI programmes running over budget, are from The Enterprise Superintelligence Report, Vol. I (pp. 25, 9).

Proof points

The strategy, in measurable terms.#

Dynamic model routing is only a strategy if it moves numbers a finance team and an auditor both recognise. These are the outcomes it is accountable to.

Cost

4,500×

price spread across 400+ models and 70+ providers

The spread between the cheapest sufficient model and the frontier default is the entire economic case for routing. A directive sent to the wrong class does not fail — it just costs orders of magnitude more than it had to.

Vol. I, p.25

Token waste

~90%

of workloads never need a frontier model

Routine classification, extraction, summarisation and drafting clear on in-house or open-weight classes. Reserving frontier capacity for genuinely complex work is what turns AI spend from a run-rate into a budget.

Dipp AI routing model · Vol. I, p.25

Budget

68%

of enterprise AI programmes run over budget

Overrun is a control failure, not a forecasting failure. Cost Governance applies a ceiling per role and per directive and halts loops at the step boundary rather than at the invoice.

Vol. I, p.9

Latency

10×

faster on routine classes than a frontier default

Cheaper classes are also materially faster. Routing the routine nine-tenths off the frontier shortens the median directive as a side effect of the economics.

Indicative class latencies, Orcher routing table

Auditability

28%

of enterprises can trace an agent action end to end today

Every routing decision Orcher makes — class chosen, alternatives considered, ceiling applied, boundary attested — is hashed into the same evidence chain as the committed action, so the economics are as auditable as the outcome.

Vol. I, p.6

Portability

1 week

to change providers, not a quarter of re-platforming

Because orchestration is decoupled from any vendor SDK, a provider change is a routing-table change. Directives, roles, policy and evidence stay in Orcher.

Dipp AI protocol stack contract

Layer 1 — sequential, gating

Four gates decide whether an action may commit.

Each runs in order. A failure at any gate halts the directive; nothing partial is written.

Layer 2 — continuous, non-blocking

Three controls govern the run itself.

Data control, cost, and observability operate for the life of the directive rather than at a single checkpoint.

Vol. I · p.13Orcher's two layers: sequential gating and continuous governance

Why it matters

The gap Orcher closes

92%

have no visibility into agent identities

Vol. I, p.6

86%

cannot enforce policy against them

Vol. I, p.6

68%

of AI programs are over budget

Vol. I, p.9

5%

of CISOs could contain a rogue agent

Vol. I, p.8

Dipp AI Research · September 6, 2026

Models advance. Enterprise control must endure.

Our September commentary examines GPT-6 Astra, Claude Fable 5.1, Claude Mythos 5.1 and Muse Spark 1.3 through one enterprise question: can advanced reasoning be trusted with real work—verifiable, cost-disciplined, and in control of the enterprise’s own data?

Choice without surrendering control

Frontier APIs, open-weight families such as Llama, Qwen, DeepSeek, Mistral and Gemma, and enterprise-tuned models belong behind the same authority and evidence requirements.

A neutral plane across compute

AWS, Microsoft Azure and Google Cloud; neoclouds such as CoreWeave, Lambda and Crusoe; private infrastructure. The destination may change. The enterprise’s boundary and budget must not.

Seven controls. Compounding intelligence.

Cost Governance chooses the sufficient route. The Data Control Gateway governs egress. Observability traces the run. Human-in-the-Role binds authority, while verified execution compounds into Dipp Intelligence.

Named release examples follow the September commentary. Model families and compute providers are ecosystem examples, not a claim of certified integrations or universal availability.

Read Frontier Autonomy Needs a Control Plane →

Execution path

What happens between a sentence and a committed action.

Orcher does not replace the agents, the orchestration framework, or the models already in the estate. It sits in front of them and decides, per directive, whether the work may proceed — and writes down what it decided.

  1. 01

    Directive received

    Plain-language intent arrives with the issuer's identity attached. Anonymous directives are refused at the door.

  2. 02

    Role resolved and bound

    The Role Identity Fabric resolves the professional's current entitlements and binds them cryptographically to this cycle.

  3. 03

    Proposed action verified

    The Logic Scrubber checks the plan against systems of record — eligibility, policy, licensure, limits — before anything is written.

  4. 04

    Data boundary applied

    The Data Control Gateway redacts, routes, and enforces the enterprise data boundary for every payload leaving the estate.

  5. 05

    Execution and metering

    Cost Governance selects a tier within the ceiling in force; Observability streams the run across whichever providers are involved.

  6. 06

    Commit and hash

    The result and the full decision trace are written to the Immutable Audit Ledger and retained as Dipp Intelligence.

Deployment

How Orcher lands in an existing estate.

No re-platforming, no model migration, no rewrite of the agents already in production.

Scope

Pick one workflow where a named professional already signs off today.

Bind

Map the roles and entitlements that workflow depends on into the identity fabric.

Verify

Point the Logic Scrubber at the systems of record the decision is judged against.

Prove

Run in shadow, compare refusals to human judgment, then move the gate in front of commit.

Output B · Dipp Intelligence

Every verified cycle leaves an asset behind.

OUT.B of the Verified Execution Cycle is Dipp Intelligence — the verified execution path, retained by the enterprise rather than absorbed by a model provider.

Path

The exact sequence that produced a verified outcome.

Role

The authority under which the action was permitted.

Cost

The model tier that actually proved sufficient.

Proof

The hashed evidence a regulator will accept.

Further reading · September 2026

The argument behind this page, published in full.

Two long-form pieces per week through September 2026 — sourced, dated, and attributed. Each one links back to the components it argues about.

See the schematic, then bring a workflow.

The Component Schematic v1 traces a single directive from plain language through to a hashed record and a retained intelligence asset.