Blog

Tangle Blueprints: How to Choose an Operator-Run Service

Tangle Blueprints describe operator-run services for inference, sandboxes, training, trading, cryptography, and other jobs. Choose one by its contract, operator boundary, payment rule, evidence, and failure behavior.

Drew Stone
blueprintscataloginfrastructuretangle
An editorial still life about choosing a runnable service

Maya gives an agent a private PDF and asks for a short summary before the agent decides what to do next. Her team does not want to build a model server, a browser runner, and a payment system for one workflow. It opens a service catalog and finds three names that sound close to the job.

One listing says “document intelligence.” Another says “private inference.” A third says “agent tools” and shows a polished screenshot.

None of those names tells Maya who receives the file, what the service can access, how much the request costs, what the result looks like, or what happens when the service stops halfway through.

That is the problem this guide solves. A Tangle Blueprint catalog is useful only when each candidate can be inspected as a runnable service rather than chosen by its label. A Tangle Blueprint is a public service template that another team can run. An operator is the person or service that supplies the machine and runs that Blueprint. A Service is a live instance of the template. A Job is one request sent to that Service. Tangle is the protocol network that coordinates Blueprint registration, operator participation, Services, Jobs, payments, and lifecycle records.

The public Blueprint catalog is useful for finding candidates. It is not a maturity ranking and it is not a quality certificate. Choose a Blueprint by the job contract and the evidence you can inspect, not by a category name.

A Blueprint is a service contract

A normal API documents a route, request body, response body, and authentication method. A Blueprint has to carry those application details plus the operator, resources, payment, lifecycle, and result evidence that sit outside one company’s API server.

For an inference job, inspect:

Contract fieldWhat you need to know
JobWhat exact work does the service perform?
InputWhich files, fields, sizes, and formats are accepted?
OutputWhich schema and version can the caller consume?
ResourcesDoes the job require a GPU, browser, trusted execution environment (TEE), chain access, or secret?
RuntimeWhere does the code run, and what can it reach?
OperatorWho supplies the machine and sees the request metadata?
PaymentIs the price fixed, quoted, prepaid, or settled after work?
EvidenceWhich result, receipt, trace, hash, or review artifact returns?
FailureWhat happens on invalid input, timeout, outage, or bad output?

The runtime is the environment where the job code executes. It may be a native process, container, virtual machine, or trusted execution environment. The runtime boundary decides whether the service can reach a public network, read a mounted directory, use a credential, or keep state after the job.

The public Tangle Blueprint introduction describes Blueprints, Services, Jobs, executable artifacts, triggers, and optional protocol logic. The Blueprint SDK repository is the source for the current Rust toolkit.

Start with the work, not the catalog

Catalog categories are useful only after the caller has written the job it needs. Maya’s job is “summarize this PDF without exposing it to an unapproved provider and return the summary with a reference to the input.”

The category tells her which questions to ask.

Job familyExample requestFirst boundary to inspect
Model inferenceSummarize a documentModel provider, context limit, data policy, and output check
Sandbox or browserRun a test against a web applicationFilesystem, network destinations, credentials, browser state, and screenshots
Training or data workTrain or transform a datasetData transfer, hardware, checkpoint format, and evaluation
Trading or chain workObserve state or submit an actionChain or market state, signing authority, limits, and recovery
CryptographyProduce a key-dependent resultKey holders, quorum, proof, artifact retention, and failure recovery

Two services can appear in the same category and have different risk. One inference service may run a fixed model inside a hardware-protected environment and return a signed measurement. Another may forward the prompt to an unlisted provider and return only text. Both can be called “inference.”

Follow Maya’s PDF from selection to result

Before sending the file, Maya should be able to answer six questions.

  1. What exact bytes and metadata leave the application?
  2. Which operator receives them, and what can that operator access?
  3. Where does the job run, and which model or provider is called?
  4. What price is offered, and when does the quote or payment expire?
  5. Which fields and artifacts return after execution?
  6. What should the agent do when the job fails or the result is weak?

The request path is:

caller selects a Blueprint and Service
  -> caller checks input, runtime, operator, price, and evidence
  -> caller submits one Job
  -> operator runtime executes the job
  -> Service returns a result and receipt
  -> caller evaluates the result
  -> caller accepts, retries, refunds, or escalates

This is a decision path, not a promise that every service supports every step in exactly this order. The service contract should name the real sequence.

Payment does not answer the trust question

x402 is an HTTP payment protocol for machine-to-machine requests. The client requests a paid resource, receives status 402 with payment requirements, retries with a signed payment payload, and receives the resource after the server or a facilitator verifies and settles the payment.

The current x402 documentation names the payment headers and settlement response. An x402 receipt can show that a payment was authorized and settled. It does not show that the operator used the expected model or that the summary is useful.

If confidentiality depends on a TEE, define that term before trusting it. A trusted execution environment is a hardware-backed execution boundary intended to isolate code and data from the host system. An attestation is a signed report that a checker accepted about the code or environment that ran. Attestation can support code identity and secret-release claims. It does not prove task quality.

A trace is a structured record of one run. It can include the request ID, operator, service version, steps, timings, artifacts, errors, and final state. The trace helps a caller investigate a result, but it is not a replacement for a result check.

An evaluation is a task-specific check against an explicit requirement. It may be a deterministic comparison, cryptographic proof, fixed test set, model rubric, or human review. The service should say which one it uses rather than displaying a generic “verified” badge.

A contract object makes selection reviewable

The following TypeScript is illustrative. It is not a copy of a current SDK type. It shows how an application can refuse a candidate that does not publish the evidence it needs.

type ServiceContract = {
  name: string
  input: string[]
  output: string[]
  resources: string[]
  evidence: string[]
  failure: string[]
}

type Candidate = ServiceContract & {
  operator: string
  quoteExpiresInSeconds: number
}

const privateSummarizer: Candidate = {
  name: 'private-document-summary',
  input: ['documentBytes', 'language'],
  output: ['summary', 'inputHash', 'outputHash'],
  resources: ['confidential-compute'],
  evidence: ['attestation-report', 'input-output-binding'],
  failure: ['retry-on-timeout', 'reject-expired-report'],
  operator: 'operator-example',
  quoteExpiresInSeconds: 60
}

function canSendSensitiveFile(
  candidate: Candidate,
  requiredEvidence: string[]
) {
  return requiredEvidence.every((item) =>
    candidate.evidence.includes(item)
  )
}

const allowed = canSendSensitiveFile(
  privateSummarizer,
  ['attestation-report', 'input-output-binding']
)

The function does not decide whether the service is safe. It makes a missing requirement visible before the caller sends the file. If the contract cannot name the execution boundary or result binding, Maya can choose a conventional provider or a less sensitive test input.

Read a public Blueprint repository as a buyer

The public repository is where the catalog description becomes a runnable artifact. Read it in the order a failure will reach you.

First, find the job interface. Look for typed inputs, typed outputs, size limits, and error behavior. A demo command with an untyped string leaves the production request unclear, so inspect what the caller sends.

Second, identify the runtime boundary. Check whether the service needs a GPU, browser, chain node, TEE, secret, or external model account. An operator requirement that is absent from the public release is an integration risk.

Third, follow the payment and retry path. Confirm whether the price is fixed or quoted, whether a payment happens before compute, how expiry works, and whether a failed paid Job can be retried.

Fourth, identify the evidence. Look for an artifact version, request ID, result hash, attestation, trace, logs, or evaluation output. An output without a way to connect it to the input is hard to support.

Fifth, read tests and maintenance instructions. Tests show what the project authors check. They do not prove every production failure is covered, but an absence of tests is important information. Maintenance notes show whether an operator can upgrade, roll back, and recover without the developer present.

The Tangle docs explain the network and operator concepts. The TNT Core repository is the public source for Tangle’s Ethereum Virtual Machine (EVM) contracts that coordinate service, staking, payment, and slashing behavior.

Catalog labels are not readiness signals

A catalog can tell you what a project says it does without telling you whether your team can safely run it. Treat the label as a discovery hint and look for evidence in the repository.

SignalWhat it can tell youWhat it cannot tell you
Recent commit or releaseSomeone changed or packaged the projectThe release is stable for your workload
Example commandA narrow path may workOperators can recover from a failed Job
Hardware requirementThe service has named resource needsThe stated throughput is measured on your hardware
Payment integrationA charge path existsA failed paid Job has a fair refund policy
Test suiteAuthors check selected behaviorThe service is correct outside those tests
Operator guideA provider can start the processThe provider can monitor, upgrade, and support it

The missing fields are not neutral. If no release identifies the model version, the caller cannot attribute a changed answer. If no test covers a restart, the operator cannot promise recovery. If no result check exists, a successful process exit is only evidence that a process exited successfully.

The catalog contains different kinds of service

The choice is easier when the resource boundary matches the work.

An inference Blueprint is usually a request and response service. The main risks are model identity, prompt visibility, output quality, provider failure, and cost.

A sandbox or browser Blueprint is an action service. The main risks are filesystem access, credentials, outbound network calls, browser state, destructive actions, and evidence of the final state. Read AI Agent Sandbox before treating a code-execution service as an agent workspace.

A training Blueprint is a long-running coordination service. The main risks are worker churn, data movement, checkpoint ownership, communication cost, malicious or stale updates, and evaluation capture. The distributed training article explains why training deserves a different contract from inference.

A cryptography Blueprint is a key-dependent service. The main risks are quorum, key custody, replay, proof verification, and recovery when one operator disappears.

A trading or chain-action Blueprint can move assets or submit transactions. The main risks are signing authority, limits, chain state, transaction simulation, and human approval. The cost of a wrong action changes the selection standard.

Operators have a separate decision

An operator should choose Blueprints by the work it can perform and support. The requirements include hardware, network, data sensitivity, credential handling, expected demand, monitoring, rollback, and margin.

A GPU operator might run inference, embeddings, voice, or training services. A security-focused operator might run cryptography or TEE-backed jobs. A general operator might start with low-resource services while learning the lifecycle.

One operator identity can serve several job markets. That does not make the services interchangeable. Each Blueprint still needs its own artifact, price, health check, data policy, and evaluation.

The operator introduction describes the Blueprint Manager, heartbeats, job responses, and isolation choices. A Blueprint Manager is the long-lived operator process that helps install, configure, and supervise Blueprint services. An operator is ready only when it can register, start a Service, run a non-mocked Job, and return the evidence the caller expects.

Run a deliberately small first integration

Maya’s first pass should use a public, low-sensitivity PDF. The team should exercise the entire path before sending a private document.

Pass one: inspect. Read the job schema, runtime requirements, payment policy, evidence fields, and failure table.

Pass two: exercise. Send one valid input and one invalid input. Confirm the result, request ID, version, timing, and failure code.

Pass three: narrow permissions. Remove unnecessary network access, credentials, file mounts, and model-provider permissions. Repeat the same job and inspect the trace and result evidence.

Pass four: test recovery. Force or simulate a timeout, expired payment requirement, unavailable operator, and malformed result. Confirm that the caller does not pay twice or accept an uncheckable output.

The first integration is complete when a reviewer can answer what left the application, who received it, what ran, what returned, and what happens next after failure.

When a hosted API is better

Choose a conventional hosted API when one company can own the machine, support path, data policy, payment relationship, and quality check without denying the buyer a meaningful choice. That arrangement can reduce data exposure when the provider’s retention, access controls, and contract cover the risk, because fewer parties handle the input.

Choose an operator-run Blueprint when independent providers add capacity, geography, hardware, price competition, availability, or a meaningful accountability record. The added coordination is worthwhile only when one of those properties changes the buyer’s decision.

Decision rule

Use the catalog to find a narrow capability. Use the public repository and docs to inspect the contract. Run one low-risk Job before sending valuable data or authorizing meaningful payment.

Keep the integration only if you can state, in plain language, what the job does, which operator receives the input, what the quote covers, which result evidence is sufficient, and what the caller does after each failure.

What is a Tangle Blueprint?

A Tangle Blueprint is a reusable service template that defines executable software, Jobs, metadata, artifacts, triggers, and optional protocol logic for operators to run.

Are all Tangle Blueprints production-ready?

No. The public catalog contains services at different stages. Inspect each project’s releases, tests, operator instructions, payment path, result checks, and failure behavior.

Why do Blueprints matter for AI agents?

Agents need callable capabilities beyond text generation, including inference, browsers, sandboxes, training, cryptography, and paid APIs. Blueprints give those capabilities a service contract that an application can request and inspect.

Does an operator see private input data?

That depends on the job’s runtime and data policy. Read the operator boundary and secret-release path. If confidentiality depends on a TEE, inspect the attestation policy and how it binds to the Job.

How do operators choose which Blueprints to run?

They should choose by hardware, data risk, expected demand, monitoring and evaluation work, recovery responsibility, and margin. An operator should run only the services it can keep healthy and support when a Job fails.

Where is the current catalog?

The awesome-tangle-blueprints repository is the public catalog. It changes over time, so use it to find candidates and then inspect each Blueprint’s source and release state.