Blueprint protocol is the on-chain and operator-facing side of Tangle. It should not be confused with Blueprint Agent, the developer onboarding product at ai.tangle.tools. A protocol Blueprint is a reusable service definition. Operators register for it, run the service, accept jobs, and receive payment according to the network rules.
For deployment details, read Blueprint SDK Deployment Guide. For product onboarding, read AI Coding Assistant With Deployment Evidence.
Protocol Roles
| Role | Job |
|---|---|
| developer | defines the Blueprint and artifact |
| operator | runs the service |
| user or app | requests work from a service instance |
| staker | supports operator security and economics |
| protocol | coordinates registration, payments, and accountability |
The useful mental model is “service definition plus operator market,” not “template page.”
Blueprint Lifecycle
define service
-> publish Blueprint
-> operators register
-> service instance receives jobs
-> jobs run and return evidence
-> payments and operator accountability settleThat lifecycle is why protocol Blueprints are a strong fit for AI services, agent sandboxes, inference, code audit, and payment-native APIs.
What A Good Blueprint Defines
| Definition area | Why it matters |
|---|---|
| job interface | users need predictable inputs and outputs |
| artifact source | operators need to know what to run |
| runtime config | services need required env vars and endpoints |
| pricing | users and operators need economics before execution |
| verification | the result needs appropriate proof |
| failure policy | users need to know what happens when a job fails |
For operator economics, read Operator Staking For AI Blueprints. For compute framing, read Decentralized Compute Protocol For Blueprints.
Builder Checklist
Before publishing a Blueprint, a builder should be able to answer these questions without private explanation.
| Question | Good answer |
|---|---|
| what does the job do? | one input/output contract and clear error states |
| who can run it? | operator requirements, keys, ports, and environment variables |
| how is it priced? | fixed price, quote flow, or payment challenge |
| how is it verified? | job-specific evidence, test, attestation, or result check |
| how does rollback work? | previous artifact and operator downgrade path |
| what should users monitor? | service health, request latency, failure rate, and payment status |
This is why the Blueprint SDK repository and the Tangle docs matter to protocol pages. A protocol Blueprint is not a marketing label; it is an artifact that operators must run.
Operator Acceptance
Operators should not accept a Blueprint until the runbook is clear.
| Runbook item | Operator risk if missing |
|---|---|
| artifact hash or source | running unreviewed code |
| required environment | failed startup |
| health endpoint | invisible downtime |
| pricing path | unpaid or mispriced jobs |
| logging policy | impossible incident review |
| version policy | mismatched service behavior |
The same logic appears in Operator Health Monitoring For Tangle: heartbeat and quote data only help if the service is instrumented well enough to interpret them. Protocol contracts in tnt-core give the network coordination layer; the Blueprint has to supply service-specific operating detail.
User-Facing Contract
Users should not need to understand every protocol detail to call a Blueprint. The service page should expose the job name, accepted inputs, price or quote rule, expected latency, result format, failure policy, and evidence returned. That user-facing contract is what lets agents choose services safely. It also gives operators a clear target for support and monitoring.
The protocol page and the user page should stay linked. When the Blueprint definition changes, the user-facing contract should change with it. Drift between those two pages is how operators end up running one service while buyers think they purchased another.
What This Does Not Prove
A Blueprint protocol does not make every service high quality. It gives developers and operators a coordination layer. Service quality still depends on code, operators, pricing, monitoring, and verification.
Decision Rule
Use protocol Blueprints for services that benefit from independent operators, payment-native access, and reusable job definitions. Use a normal app backend for private, single-operator services.
FAQ
What is Blueprint protocol?
It is Tangle’s model for defining services that operators can run under protocol rules.
Is Blueprint Agent the same thing?
No. Blueprint Agent is a developer workbench. Protocol Blueprints are service definitions run by operators.
Who runs a Blueprint?
Independent operators register for Blueprints and run the services.
What makes a Blueprint useful?
Clear job interface, runtime requirements, pricing, verification, and operator instructions.