EigenCloud

Orchestration Is the Moat. The Orchestrator Is Unverified

Fugu made orchestration the product. It decides which models to call, when, and how to combine the results. But today, those decisions are invisible. The next frontier is verifiable orchestration

Zeeshan Jawed

Jul 2, 2026 • 8 min read

Sakana Fugu shipped a 7B model that commands GPT-5.5 and Opus. EigenCompute is the piece that makes the conductor provable

Sakana AI shipped Fugu on June 22.

Fugu is a small model, on the order of 7B parameters, that does not answer your question. It decides which of the world's strongest models should, routes the task, sometimes calls itself, and merges the results behind one API. Fugu Ultra is reported shoulder to shoulder with the frontier on SWE-Bench Pro, LiveCodeBench, and Humanity's Last Exam. Salesforce shipped multi-agent orchestration to GA the same week and called orchestration the moat.

Not a slide. Shipped. And the framing is bold: one model to command them all.

Here is the question nobody asked at launch. The conductor makes a dozen decisions you never see, and you have no way to check it made the ones it claims.

The Conductor Is the Product Now. Nobody Verifies It.

A monolithic model has one trust question: did it answer well. An orchestrator adds a second, quieter one: did it route honestly. Those are not the same question, and the second is the one nobody is instrumenting.

Look at what the conductor can quietly do. Route your premium task to the cheap model and keep the margin. Claim a result came from the strong model when it came from the weak one. Skip the verifier step it said it ran. None of it shows up in the output. A good answer and a dishonestly routed answer are byte for byte identical.

💡

plan = conductor.route(task)
# which models, which roles, what order
model = pick_model(step) # the decision you never see
answer = conductor.merge(results) # and how they got combined

Every interesting decision lives in those three lines, and none of them leaves a trace you can check. When orchestration becomes the product, the routing decision becomes the thing you have to trust. Right now it is a claim, not a proof.

Did You Even Get the Model You Paid For?

A UC Berkeley team asked the plain version of this: when you call an API for a specific model, can you prove the provider actually ran it? Mostly no. They show that software-only detection, output statistics and log-prob checks, falls apart under quantization and the natural nondeterminism of inference. Their conclusion is the line to underline: a real guarantee needs hardware, specifically a TEE that attests to what ran.

Now stack a conductor on top. If you cannot verify a single model API served what it claimed, an orchestrator routing across a pool of those APIs is opacity compounded. Every routing decision is only as honest as the weakest API beneath it, and as the conductor that recorded it.

Why Verify the Conductor? Why Now?

Because the failure mode compounds, and the last few weeks already show the shape. None of these are orchestration's fault. All of them are structurally the same problem: "trust me, the operator ran it right."

June 22, 2026. The Taiko bridge lost roughly $1.7M when an Intel SGX enclave signing key was committed to a public GitHub repo and used to forge attestations. TEE attestation is worthless without key custody.
June 12, 2026. The US ordered Anthropic to cut off Fable 5 and Mythos for foreign nationals worldwide. A model your conductor routes to can disappear overnight, and "which model actually served this request" turned from trivia into a compliance question.
June 11, 2026. OWASP declared prompt injection a permanent architectural flaw. A conductor that pulls untrusted content into a routing decision inherits it.
2026 enterprise surveys. 88% of organizations had an agent security incident in the past year. 21% have runtime visibility. The other 79% are routing on faith.

Because routing now moves money and compliance, not just tokens. A conductor that picks the model of record for a regulated decision, or spends real budget mid-task, is no longer a research curiosity. It is a liability surface.Because "trust me, the operator" is the model that broke cleartext HTTP in the 2000s. The fix then was HTTPS. The fix now is verifiable execution. Same category of move, same timeline shape. The value of an autonomous conductor is capped, exactly, by how much a counterparty will let it do unsupervised, and that ceiling is set by how much they can verify.

3 Ways EigenCloud Makes the Conductor Provable

EigenCloud is the verifiability primitive. You deploy a standard Docker container, it runs inside an Intel TDX secure enclave, and it produces a hardware-signed attestation any counterparty can check without trusting the operator. It plugs into a Fugu-style orchestrator across three concrete edges, each in production today.

A) EigenCompute as where the conductor runs.

Put the routing logic in the enclave, not on a server you control. The host operator is isolated from the workload entirely. The orchestrator gets its own persistent wallet, generated by the KMS and bound to the enclave, that serves as its cryptographic identity. It can sign, hold funds, and act on its own. Deploying it is three commands.

💡

ecloud compute app create --name conductor --language typescript
cd conductor ecloud compute app deploy
# builds linux/amd64, runs in Intel TDX (g1-standard-4t)

There is no --verifiable flag, because verifiable execution is the default, not a premium add-on.

B) EigenCompute as the primitives you compose from.

You do not stand up an attestation stack. Four design choices do the work for you:

Dedicated app identity and wallet. Only the verified Docker image running inside the enclave can retrieve the app's MNEMONIC. The operator cannot extract it, an adjacent container cannot, a physically present attacker cannot. A cost-cutting variant of the router that always picks the cheap model boots a container that cannot sign anything.
Attestation and an onchain record by default. Every release records its Docker image digest on the AppController contract and produces a TEE attestation. Reproduce the image hash, do not just trust it.
Secrets sealed in the TEE. Environment variables are encrypted and only readable inside the enclave. API keys for the model pool never touch the operator.
The Verifiability Dashboard. verify.eigencloud.xyz shows the release history, image digests, attestations, and derived wallet addresses for any app, to anyone.

C) The routing receipt as the portable artifact.

This is the part that turns "trust me, I used the best model" into something a stranger can check. For every routing decision, the conductor signs a receipt with its enclave wallet. Same pattern as EigenCompute's attested API example, applied to routing.

💡

const wallet = ethers.Wallet.fromPhrase(process.env.MNEMONIC); // KMS-injected, enclave-bound

const receipt = { task_id, input_hash, chosen_model, policy_hash, response_hash };

const signature = await wallet.signMessage(JSON.stringify(receipt));

// anyone verifies the signature on Etherscan, then confirms the signer is a

// Derived Address for the app on the Verifiability Dashboard. No trust in you required.

A listing that publishes "here is the binary I run, here is the attestation, here is the receipt for the model I picked" is the listing other agents will prefer. That is HTTPS in 2006, not a nice-to-have.

What a Verifiable Orchestrator Unlocks

A verifiable conductor is not a more paranoid version of Fugu. It is a different set of products.

Real economics. A conductor that can prove what it routed can be trusted with a budget, insured, and signed into a contract. The ceiling on "orchestrator as a business" is exactly the floor of "verifiable execution."
Real liability. When a routing decision moves money and goes wrong, the postmortem starts with a receipt instead of "we think the conductor picked X." A $500K routing error needs an admissible record, not a vibe.
Real enterprise onboarding. The procurement teams blocking agent pilots greenlight them the moment the orchestrator produces an attestation their auditors can consume. Verifiability unlocks the buyer side, not just the seller side.
Real open competition. Without attestation, the market consolidates around a few brand-name orchestrators. With it, a solo builder's conductor competes with the incumbents on technical merit. This is exactly why open protocols win or lose.

This is the blog on Sreeram Kannan's framing that agents will become companies. A company made of software needs enforceable execution. Not "the operator pinky-promises this is the code," but a cryptographic answer to "prove it."

What the Receipt Proves, and What It Doesn't

The receipt proves the routing decision was made by the exact attested conductor, which model it chose, under which policy, and the hash of the response it received. It proves the log was not forged or reordered, and that the signer is a key only the enclave holds.

It does not prove the external provider actually served the model it claimed. Inference happens outside the enclave. If a provider swaps Opus for something cheaper, the conductor honestly records "I asked for Opus and got this," and the lie lives downstream, exactly the substitution the Berkeley paper describes. It also does not prove the answer is good.

So call it a verifiable Fugu-style orchestrator, never verifiable Fugu. You are attesting the conductor, not the pool it commands. That honesty is the product, not a hedge.

What’s next for builders now?

3 moves worth making this month, before the defaults harden.

1) Containerize your orchestrator with a deterministic entrypoint and a published image hash. That is the common denominator everything else builds on.

2) Deploy on EigenCompute. ecloud compute app deploy. Your conductor now runs in a TEE, holds its own KMS-bound wallet, and records its image digest onchain.

3) Sign a routing receipt for every decision, and expose it. The services that publish verifiability metadata are the ones other agents will filter for inside twelve months.

Get started here.

Where This Lands?

Sakana may be right that orchestration is the next frontier. If it is, the conductor is about to become the most powerful unverified component in your stack.
The marketplaces, the payments, the agent-to-agent commerce all assume the layer underneath can answer one question: prove the routing you claimed is the routing that ran.

Fugu made orchestration the product. EigenCompute is the piece that makes the conductor provable.

Tomorrow I am shipping a demo of exactly this: a Fugu inferenced orchestrator running attested on EigenCompute, signing a receipt for every routing decision, verifiable by anyone.

The conductor arrived. The race to make it provable starts now