An agent uploads a private contract to an analysis service and receives a recommendation a few seconds later. The recommendation looks plausible, and the invoice is small enough that nobody wants to negotiate a bespoke contract for every request. Then the agent finds a second provider with a lower price and has to decide whether the two services offer the same thing.
It cannot answer that question from the price alone. One provider might run a different model, retain the document, change the input, or return an answer without running the advertised computation at all. The customer may discover a bad result, but still lack a record that explains what happened.
AI agent infrastructure is the software around an agent’s model and tools: the runtime, meaning the process and execution environment that gives it a place to execute, the services it calls, the records it leaves, and the rules that handle payment and failure. Independently operated AI infrastructure spreads some of those responsibilities across separate machines and a shared protocol. Use shared service contracts when they expose provider selection, payment state, result evidence, or dispute state that a customer could not inspect through one provider alone.
Tangle is a coordination network for services that independent parties run. Its contracts record selected registration, service, payment, verification, and lifecycle state while application work runs outside the chain. Off-chain means computed outside the blockchain, while on-chain means recorded in blockchain state. A Blueprint is a reusable service template, a Service is a configured running instance, and a Job is a callable unit of work. An operator is the party that runs the service artifacts and returns job results. The Blueprint introduction describes how those objects fit together.
The decision this article helps with is narrower than “should all AI use blockchains?” Use independently operated infrastructure when independent execution, confidentiality, payment without a standing account, or an inspectable failure process is worth the extra coordination. Use a conventional hosted service when those properties do not change the product decision.
Separate the claims behind a service response
When a provider returns an answer, the customer often needs four separate answers about what happened. One response can hide those distinctions.
An evaluation is a test or judging procedure for a task. For an invoice extractor, it might check that the vendor, date, and total match labeled examples. For a code runner, it might compare the output with a known result. For a language model, it may combine reference answers, rules, and human review. An evaluation measures a chosen property; it does not turn every other property into a fact.
A trusted execution environment, or TEE, is a hardware-backed area that isolates a workload from ordinary host software. An attestation report is signed evidence about that protected environment and the measurements of the code or configuration that started there.
| Claim | The customer asks | Evidence that could address it |
|---|---|---|
| Availability | Could I submit this job and get a response? | Health data, service state, timeout behavior, and retry records |
| Execution identity | Did the advertised program or model run? | A pinned artifact, a measurement, an attestation report, or reproducible execution |
| Confidentiality | Could the operator read the input while the job ran? | A tested isolation policy, hardware-backed protection, or a multi-party protocol |
| Result correctness | Does the output satisfy the task? | A deterministic check, a proof, redundant execution, or a task-specific evaluation |
A trace is a time-ordered record of a run. It can connect the request, model call, files, tool actions, policy decisions, output, and evaluation result. A trace makes a failure easier to inspect, but the record is only as trustworthy as the system that writes and protects it.
In a centralized service, one provider is usually responsible for all four answers. That arrangement is often sensible because one company can operate the servers, control the software, and support the customer. It also creates one place where a silent change can affect every claim at once.
Decentralization moves the trust boundary
In a centralized service, the provider controls the host, the deployment, the logs, and the response path. The customer can add contracts, audits, and monitoring, but the provider still sees more of the system than the customer does.
In an independently operated service, independent operators run the same service definition or satisfy the same protocol rules. A shared set of contracts records coordination state such as registration, services, jobs, payments, or dispute steps. The work itself usually remains off-chain because model inference, code execution, and data processing are too large or private for a smart contract.
A smart contract is a program whose state transitions are executed by a blockchain network. It can enforce the rules that are expressible in code, such as who may register, what payment was offered, or which evidence is required before a state change. It cannot inspect a private accelerator’s memory by itself, and it cannot decide whether a prose answer is useful without a defined test.
Tangle’s Blueprint documentation describes this split directly. The protocol coordinates discovery, operator registration, service creation, payment, incentives, and lifecycle tracking, while operators run the application logic off-chain.
The benefit appears when the customer needs more than a provider’s statement. The customer can inspect the service definition, compare operators, require an execution policy, and choose a result rule that matches the job. The cost is a larger system with more participants, more failure states, and more latency.
When independent operation earns its cost
Decentralization earns its cost only when it changes a concrete decision. Three tests help expose that decision.
Can the customer choose among operators?
Different operator names do not create independence by themselves. The parties must run the same declared service while retaining independent failure domains and incentives. Independence matters only if the parties do not share the same unobserved failure.
Three operators using the same cloud account, container image, and region may provide less independence than three operators with different operational boundaries. The protocol can record an operator set, but the customer still has to assess correlated infrastructure and shared software.
Can the customer inspect the service agreement?
A service is a configured instance of a Blueprint. It can specify the operators, payment terms, time-to-live, job permissions, and execution confidentiality intent. The service lifecycle documentation explains why expiration and operator changes belong in the design rather than in an afterthought.
If a service can expire while it still holds state or funds, the customer needs an exit or migration path. That is a protocol and application design issue, not something that decentralization solves automatically.
Is there a consequence that can be triggered by evidence?
Staking means an operator commits assets to a service or protocol. Slashing is the process that burns or redistributes part of that stake after a defined proposal and dispute process. Tangle’s public slashing documentation describes a proposal, a dispute window, and an executable outcome.
Stake creates recourse only when defined evidence can trigger a documented penalty. It does not detect every bad result, recover leaked information, or make an unclear rule fair. The service still needs evidence that a contract can evaluate.
If the answer to all three tests is no, a conventional hosted service may deliver the same user outcome with less machinery.
What Tangle contributes to an agent call
Consider an agent that needs to extract the parties, dates, and obligations from a private contract. The agent profile is the versioned configuration that names the model, instructions, tools, limits, and output schema for that workflow. The runtime carries out the profile in its process and execution environment. The Blueprint Manager is the operator-facing process that watches protocol state, obtains artifacts, and runs assigned services. The Blueprint Runner is the job-execution process that receives calls and routes them to handlers.
The profile may call a Tangle service for the extraction job. The Blueprint defines the job interface and the artifact that operators run. The service instance chooses the operator set and payment policy. The operator runs the job. The job router is the component that maps a job identifier to the intended handler inside the operator runtime. The result can return with a trace identifier and the evidence fields that the Blueprint promises to produce.
The chain does not need to see the contract text. It can record that a service exists, that a job was submitted, and that a payment or verification transition occurred. The operator runtime handles the private computation.
This makes the roles easier to reason about:
| Part of the call | Tangle-facing responsibility | Remaining application responsibility |
|---|---|---|
| Blueprint | Publish the job, artifacts, metadata, and protocol hooks | Define a useful extraction contract |
| Service | Bind an owner, operator set, configuration, payment, and lifecycle | Select operators and set acceptable risk |
| Operator | Run the artifact and submit the result | Operate the machine, keys, dependencies, and data boundary |
| Job | Identify one callable unit of work | Validate inputs and return a typed result |
| Verification | Apply the rule chosen by the Blueprint | Define what counts as correct for contract extraction |
The Blueprint Manager documentation describes the off-chain operator process. It watches protocol events, obtains the Blueprint artifacts, and executes services according to the definition and confidentiality policy.
Payment and execution are separate claims
x402 is an open protocol for programmatic payments over the Hypertext Transfer Protocol (HTTP).
The standard flow is a request, an HTTP 402 Payment Required response with payment requirements, a signed payment payload, payment verification, and a response containing the resource.
The current Coinbase x402 flow documents those steps.
Tangle’s x402 gateway is an optional off-chain ingress path.
A facilitator is the service that verifies and settles an x402 payment for the gateway.
A JobCall is the internal message that carries an accepted paid request into the Blueprint Runner.
The Tangle x402 documentation says that a valid payment can be verified and settled by a facilitator before the gateway injects a JobCall into the Blueprint Runner.
That is useful for an agent because it can pay per request without opening an account for every provider.
Payment still does not prove that the job completed correctly.
The Tangle documentation also states that a 202 Accepted response means the paid request was accepted and enqueued, not that the job has finished.
The boundary is worth drawing explicitly:
agent -> HTTP request -> x402 payment check -> queued JobCall
|
v
operator runtime executes
|
v
result + evidence + evaluationIf the agent treats the payment receipt as a correctness receipt, it has collapsed two different claims. Payment answers “was this request authorized and settled?” Verification answers “which execution and result rule should determine completion?”
A contract-extraction Job with redundant execution
Assume a contract-extraction Blueprint accepts a document and returns structured fields. The example below is illustrative; the amounts and operator names are not a Tangle benchmark.
- The agent requests a paid extraction job and receives
402with a price and accepted payment scheme. - The agent signs the payment and retries the request with the payment header.
- The gateway verifies the payment, settles it through the configured facilitator, and returns
202with a call identifier. - Two operators receive the same job and run the pinned container.
- Their results are normalized into a stable field order before comparison.
- The service accepts the result only if the two structured outputs agree on required fields.
- A task evaluation checks the extracted fields against a labeled test document or a customer-approved rule set.
- The trace stores the job identifier, artifact reference, operator submissions, evaluation outcome, and any disagreement.
Suppose both operators return the same incorrect date because the container has the same parsing bug. Agreement detects no disagreement. The evaluation can still reject the result if the labeled test catches that error.
Suppose one operator returns a different date. The service can mark the result as disputed or incomplete, depending on its protocol rules. The trace shows the disagreement, but it does not identify the correct date unless the evaluation or another proof supplies that information.
Suppose the operator leaks the original contract before the result check. Redundant execution does not undo the leak. A TEE or a multi-party privacy protocol would address a different part of the threat model.
This is the core discipline: name the claim, choose evidence for that claim, and document what the evidence leaves open.
The mechanisms solve different problems
Independently operated AI infrastructure combines several mechanisms, each aimed at a different trust question. A zero-knowledge proof, or ZK proof, lets someone prove a formally defined statement without revealing the private input used to produce it. A public Ethereum overview of zero-knowledge proofs explains this proof-system boundary. Multi-party computation (MPC) lets several parties compute from private inputs without giving the complete input to one party. The NIST definition of MPC describes the same privacy boundary.
| Mechanism | Good at showing | Boundary or failure case |
|---|---|---|
| Redundant execution | Multiple operators produced the same result | Shared software can produce the same wrong result |
| TEE attestation | An approved workload started in a hardware-backed protected environment | It does not prove the workload’s answer is useful |
| MPC | Parties can compute from split inputs under an honest-party assumption | Protocol cost and threshold assumptions can be substantial |
| ZK proof | A formally specified computation satisfied a mathematical relation | Proving the wrong specification still proves the wrong thing |
| Task evaluation | A result meets selected examples, rules, or human criteria | Uncovered cases and judge error remain |
| Stake and slashing | Misbehavior can have a defined financial consequence | Detection, governance, and recovery still need design |
An attestation report is a signed statement from a protected execution environment about measurements and configuration. The client must validate the signature, freshness, and expected measurements before treating it as evidence. The TEE explainer in this series covers that boundary in more detail.
An evaluation can be automated or human-assisted. A canary is a known test input used to detect a selected behavior change. Canaries can catch an obvious model substitution while missing a subtle one. Neither term means “the service is correct.”
Where decentralization makes the product worse
There are good reasons to keep a service centralized.
If a request must complete in a few milliseconds, multiple operators and chain coordination may miss the latency budget. If a company already has a clear legal agreement, audited controls, and a single data owner, adding a public protocol may add work without reducing its main risk. If the output is easy to verify and the input is public, redundant execution may cost more than it saves. If one team needs tight control over upgrades, incident response, and data residency, a hosted deployment may be easier to govern.
The tradeoff can be stated plainly:
| Choose a single-provider service when | Choose a Tangle-coordinated service when |
|---|---|
| One accountable provider is acceptable | The customer needs operator choice or independent execution |
| Low latency dominates the decision | Evidence and recourse matter more than the lowest latency |
| The input is public or the provider is already trusted | Private input needs a TEE or multi-party execution policy |
| A private agreement can handle disputes | Machine-speed payment and protocol-defined outcomes matter |
Decentralization also adds failure modes. Operators can go offline. The service can expire. Quotes can be stale. The chain can be congested. Different operators can collude or share a faulty dependency. Stake can lose value before a dispute is resolved. The protocol may expose state that the application hoped to keep private.
Those are design inputs, not footnotes.
The decision rule
Start with the smallest trust boundary that changes a real customer decision. Write down whether the customer needs operator choice, input confidentiality, independent result checks, payment without an account, or a defined dispute path. Then map each requirement to a mechanism and name the assumption behind it.
For a low-risk, public, latency-sensitive service, a normal hosted service is likely the better choice. For a paid agent service that processes private inputs and needs evidence across independent operators, a Tangle Blueprint gives the application a place to encode those boundaries. For a service with no meaningful independent check, additional operators add coordination cost but no new evidence.
The right starting artifact is a one-job Blueprint with one clear output, one explicit evaluation, one documented operator policy, and one failure path that a customer can inspect. If that small system changes the trust decision, add payment, redundancy, confidentiality, or stronger proofs one at a time.
Does independently operated AI infrastructure make an AI answer trustworthy?
No. It can make operator choice, execution conditions, payment, and selected verification steps more inspectable. The answer still needs a task-specific evaluation and a clear statement of its uncertainty.
Is Tangle a replacement for a cloud provider?
Not in every workload. Operators still need machines, networks, storage, and operational skills. Tangle coordinates services that those operators run and records protocol state around them. The cloud may remain part of an operator’s infrastructure.
Does staking guarantee that an operator will behave correctly?
No. Staking creates a possible financial consequence when a defined violation is detected and processed. It does not prevent every violation, compensate every loss, or decide an ambiguous case by itself.
What should an agent inspect before paying for a job?
It should inspect the job schema, price and payment network, operator set, execution policy, expected evidence, completion rule, timeout, and recovery path. The agent should treat a payment response as payment evidence until the job result and its evaluation have arrived.
Public sources and the next article
The Tangle Blueprint documentation defines the core objects used throughout this series. The x402 protocol documentation documents machine-to-machine payments over HTTP. The Tangle slashing guide describes the proposal and dispute lifecycle rather than promising instant punishment for every failure. The NIST MPC definition defines the MPC privacy boundary. The Ethereum zero-knowledge overview explains the proof-system boundary.
The next article follows one request through a Blueprint, a Service, an operator runtime, and a Job result in How Blueprints Work.