Your agent service works on a laptop. It accepts a prompt, runs a model, and returns JavaScript Object Notation (JSON) in less than a minute. Then a second team asks to operate it on a remote machine, and the easy part disappears.
Which process owns the job when the Hypertext Transfer Protocol (HTTP) request ends? Which artifact did the remote service team start? What happens when payment succeeds but the execution process crashes before producing a result? How do you know whether a timeout happened at the client, the payment service, the queue, or the model runtime?
This is the deployment problem for an AI agent service. The answer is a deliberate boundary between the public request, the paid ingress, the Tangle service, and the machine that runs the work.
Deploy around the job lifetime
Use a long-lived runner when the service must receive jobs from Tangle and from paid HTTP (Hypertext Transfer Protocol) clients. Place that runner on a virtual machine when you need the simplest remote control plane, or on managed Kubernetes when you need replica management, rolling updates, and stronger scheduling. Keep the payment gateway at the edge of the runner, settle the payment before invoking a paid job, and make the artifact, configuration, health signal, and rollback version explicit.
Do not choose a deployment target from the word “AI.” Choose it from the job’s lifetime, state, accelerator needs, network boundary, and recovery plan.
Define the boundaries before choosing a host
A Blueprint is a public service definition that describes the jobs a Tangle service can run and the rules around operators, payments, and verification.
An operator is the person or team that supplies infrastructure and runs a Blueprint service instance. A service instance is one deployed copy of that Blueprint with its own configuration, identity, and job queue.
A runtime is the process and execution environment that turns a job into a result. It includes the runner, dependencies, model files, network permissions, and any accelerator driver.
A GPU, or graphics processing unit, is an accelerator that may be required for model inference.
A job router is the dispatch table that maps an incoming job type to the function or worker that handles it. It is not an internet router or a model/provider router, and it does not decide which cloud provider to use.
An agent profile is client-side configuration for an agent, such as its endpoint, wallet, accepted networks, budget, timeout, and result checks. It tells the agent how to call a service, while the Blueprint tells an operator what service to run.
An x402 payment is an HTTP payment flow built around status code 402, in which a service explains what payment it accepts and a client retries with payment authorization. The payment is an authorization to perform work, not proof that the work was correct.
A trace is the record of one request and job, with identifiers and timestamps for payment, queueing, execution, and result delivery. Without a trace, “the service was slow” is only a guess.
Boundary map for a paid Job
Suppose an agent asks for a private document to be summarized.
The agent sends an HTTP request to https://summarize.example.com/jobs.
The sample service quotes 0.05 USD Coin (USDC), receives a valid payment authorization, queues a job, runs the model, and returns a result.
The request crosses the client, gateway, runner, and remote provider:
| Boundary | Responsibility | Failure to make visible |
|---|---|---|
| Client to edge | Discover price, sign payment, retry safely | The client paid twice or used an expired quote |
| Edge to runner | Authenticate, settle, and enqueue one job | A paid request vanished after settlement |
| Runner to runtime | Load the artifact and execute the handler | The wrong model or dependency ran |
| Runtime to consumer | Return a result with evidence and status | A timeout is mistaken for a bad answer |
The same shape can receive a job from Tangle instead of HTTP. The useful design property is that both sources reach the same typed job handler after their own admission checks. The HTTP payment path does not need to become a second implementation of the computation.
agent profile
|
| 1. request
v
public edge ---- 2. 402 payment requirements
|
| 3. payment authorization
v
x402 gateway ---- 4. verify and settle
|
| 5. one admitted job
v
Blueprint runner ---> job router ---> agent runtime ---> result
^ |
| |
+------ Tangle job source -------------+In Tangle’s public Blueprint implementation, the x402 gateway is a background service paired with a producer that feeds verified payments into the runner. The x402 gateway source and quote registry are the public references for that integration. The exact deployment wrapper is your responsibility.
Pick the machine from the job
The Blueprint remote-provider README currently documents virtual-machine and managed-Kubernetes targets across several public cloud providers. That package is useful for provisioning and tracking infrastructure, but it does not erase the differences between the targets.
| Target | Good fit | Main operational cost | First failure to rehearse |
|---|---|---|---|
| Local process | Development, private experiments, deterministic tests | No remote redundancy or independent operator | Restart loses the in-memory process |
| Virtual machine | One runner, a GPU, persistent local cache, simple networking | You own patching, disk recovery, and process supervision | Machine or disk disappears |
| Managed Kubernetes | Several replicas, rolling releases, queue workers, mixed workloads | More networking, identity, and scheduling complexity | A rollout sends traffic to an unready pod |
| Short-lived HTTP worker | Stateless, bounded jobs with external queue and storage | You must rebuild runner identity and long-job handling | Request lifetime ends before computation |
A virtual machine is often the right first remote target for an agent service with a single GPU. It gives the operator a stable host, a straightforward private tunnel, and a place to cache model weights. The price is that the host becomes a larger unit of failure.
Managed Kubernetes becomes worthwhile when replicas, rolling updates, workload isolation, or multiple accelerator pools are real requirements. It is not automatically more reliable. A cluster with an incorrect readiness probe is a faster way to route paid jobs into a broken release.
A short-lived worker can be a sensible adapter for a stateless function, but do not confuse an HTTP request lifetime with a job lifetime. If the work can outlive the request, persist the job and result outside the worker and make retries idempotent. If it cannot, reject work before taking payment when the remaining execution window is too small.
Make the artifact and runtime reproducible
An operator should be able to answer three questions before starting your service.
- What exact artifact am I running?
- What inputs and credentials does it require?
- How do I know that a result came from this version?
Publish an immutable image digest or release artifact, a dependency lockfile, a configuration schema, and a short startup procedure. The Cargo lockfile guide explains why a Rust service should keep its resolved dependency graph with the project. For container deployments, the Docker image reference explains image identity and pull behavior.
The following is an illustrative deployment contract, not a claim that every field is a current Blueprint SDK setting. It shows the information an operator needs to reproduce the runtime.
artifact:
image: registry.example.com/summarizer@sha256:<immutable-digest>
source_revision: public-release-2026-03-30
model_id: example-summarizer-7b
model_digest: sha256:<model-digest>
network:
tangle_rpc: https://rpc.example.org
public_http: https://summarize.example.com
jobs:
summarize:
max_input_bytes: 200000
timeout_seconds: 90
payment: x402
health:
startup_timeout_seconds: 180
readiness_interval_seconds: 10
rollback:
previous_artifact: registry.example.com/summarizer@sha256:<previous-digest>The model digest matters as much as the service image when the model changes the answer. The timeout belongs in the job policy because an agent needs to know whether retrying is sensible. The previous artifact belongs in the release record because “we can rebuild the old version” is not the same as having tested a rollback.
Put x402 at the admission boundary
The current x402 flow uses three HTTP messages with distinct roles.
The resource server returns PAYMENT-REQUIRED in a 402 response.
The client retries with PAYMENT-SIGNATURE.
The server returns PAYMENT-RESPONSE after verification and settlement.
The x402 protocol repository documents this sequence and the optional role of a facilitator.
For a paid Blueprint job, decide the order explicitly. One safe sequence is:
- Validate the request shape and reject clearly oversized input.
- Return payment requirements without running the job.
- Verify the client’s payment authorization.
- Settle the payment before execution when the job policy requires it.
- Insert one idempotent job record and enqueue it.
- Execute through the job router and return the result with a trace identifier.
The public Tangle gateway exposes a settle-before-execution path for its x402 integration. That choice reduces the risk of doing expensive work for an authorization that cannot settle. It also creates a sharper failure case: after settlement, the system owes the client a durable result or a clearly defined recovery path.
Do not treat the 402 response as an independent price source. The client should check the network, token, amount, recipient, expiration, and job identity against its agent profile before signing. An agent profile that only says “pay USDC” is incomplete because the chain, contract, amount, and recipient are part of the decision.
A paid job needs an outcome policy
Payment and execution are different state machines. Write the state transition before wiring the HTTP handler.
REQUESTED
|
+-- invalid input ------------------> REJECTED
|
+-- no payment ---------------------> PAYMENT_REQUIRED
|
+-- payment cannot settle -----------> PAYMENT_FAILED
|
+-- settled ------------------------> ADMITTED
|
+--> RUNNING --> SUCCEEDED
|
+--> FAILED
|
+--> EXPIRED_OR_CANCELLEDThe important transition is SETTLED -> ADMITTED.
It should be durable before the worker begins, so a process restart can find the obligation again.
An in-memory queue is acceptable for a local experiment and dangerous as the only record after accepting production money.
Idempotency is equally important. If the client times out after settlement, it may retry with the same payment authorization. The service should recognize the payment and job key it already admitted rather than charging twice or running the job twice. Whether that key is a payment digest, a client request ID, or a protocol-specific identifier depends on the integration. The invariant does not change: one accepted authorization must map to one known job outcome.
Remote providers add a control plane
The operator’s machine needs two networks, even if they share one host.
The data plane carries job inputs, model calls, and results. The control plane carries deployment commands, health checks, artifact updates, and recovery actions.
An RPC, or remote procedure call, endpoint is the chain service the runner uses to read state and submit transactions.
Keep the control plane private where possible. Use mutually authenticated transport for a private runner connection when the provider supports it, and rotate credentials independently from the payment wallet. Do not put a cloud SSH key, facilitator credential, and operator signing key into one undifferentiated secret.
The remote-provider package documents deployment tracking, health checks, blue-green updates, and rollback primitives. Those are operational mechanisms, not a guarantee that a particular provider is available or that a service is healthy. The remote-provider README is the appropriate place to verify current target support.
For a VM, a useful release sequence is:
- Provision a replacement machine with the required accelerator and disk.
- Install the immutable artifact and configuration.
- Start the runner without public paid ingress.
- Run a startup check and one known job.
- Confirm the trace reaches execution and result delivery.
- Shift traffic or enable the public gateway.
- Keep the old machine available until the new one has survived the agreed observation window.
For Kubernetes, the same sequence becomes a deployment with a readiness check and a rollback revision. Both targets must expose readiness, rollout, rollback, and trace evidence even though their resource names differ.
Test the path a user will pay for
A unit test that squares 4 proves a handler can square 4.
It does not prove that an agent can discover the price, authorize payment, survive a retry, reach the runner, execute the model, and receive a result.
Use a small test matrix before production.
| Test | What it answers | Failure that should stop promotion |
|---|---|---|
| 402 discovery | Does the client learn the exact payment requirements? | Wrong chain, token, recipient, or amount |
| Valid paid request | Does settlement admit one job? | Payment succeeds but no durable job exists |
| Retry after timeout | Is the request idempotent? | Duplicate charge or duplicate execution |
| Invalid input | Does validation happen before expensive work? | Model starts on unbounded input |
| Worker restart | Can the runner recover an admitted job? | Paid job is lost in process memory |
| Stale quote | Does expiration fail closed? | Old authorization is accepted |
| Artifact rollback | Can the last known version serve a test job? | Recovery depends on an untested build |
An evaluation is a check with an expected condition, such as “a 402 contains the approved token and a 90-second job timeout.” An evaluation does not prove a broad property merely because one request passed. Record the input, version, environment, and observed result for each important evaluation.
The trace should let you reconstruct a paid request like this:
request_id: req_8f2
payment_required_at: 12:00:00.102Z
payment_verified_at: 12:00:01.417Z
payment_settled_at: 12:00:02.031Z
job_admitted_at: 12:00:02.044Z
runner_started_at: 12:00:02.090Z
runtime_finished_at: 12:00:18.772Z
result_returned_at: 12:00:18.901Z
outcome: succeeded
artifact: sha256:<immutable-digest>The trace contains operational evidence, not the user’s private prompt. Redact sensitive inputs and retain only the identifiers needed to correlate the payment, job, runtime, and result.
Failure cases that change the architecture
The model takes longer than the HTTP timeout. Persist the job and return a status handle, or reject the request before payment when asynchronous delivery is not supported. Do not leave the client guessing whether a timeout means “still running” or “lost.”
Payment settles and the GPU disappears. The service needs a recovery policy that can retry on a replacement worker, refund when the payment system supports it, or expose a compensation path. An HTTP 500 cannot erase an already-settled payment.
The artifact starts but the model is missing. Make model identity and readiness a startup check, not a warning after the first paid request.
A new release passes a health probe but returns the wrong schema. Use a known job with an expected response shape during rollout. Process liveness is not job correctness.
The remote host can execute but cannot reach the chain. Separate provider networking from application networking and test the actual RPC path from the runner. “The port is open” does not prove that payment or result submission can complete.
The facilitator is slow or unavailable. The gateway must fail closed when payment status is unknown. Retry verification according to the payment integration’s idempotency rules, and never execute merely because a client supplied a plausible header.
Choose the host you can recover
Choose a VM for the first serious deployment when one operator needs a stable runner, a GPU, and a simple rollback. Choose managed Kubernetes when replica scheduling and release management are already concrete requirements. Use a short-lived worker only when job durability, payment recovery, and result delivery live outside the request process.
In every target, keep the same contract: the client sees payment requirements, the gateway admits one settled job, the job router selects one handler, the runtime identifies its artifact, and the trace records the result. That contract is what makes an AI agent service operable by someone who did not build it on their laptop.
Can an x402 payment directly execute a Blueprint job?
It can be the admission signal for a paid HTTP path. The gateway still needs to verify and settle the payment, create a durable job record, and pass the admitted job to the runner. Payment alone does not define the handler, guarantee execution, or prove the result.
Should I deploy a Blueprint on Kubernetes from day one?
Only if you already need its scheduling and rollout features. A VM is easier to reason about for one long-lived runner, while Kubernetes adds useful control at the cost of more network and identity state.
Does a remote provider verify my AI result?
No. A provider supplies machines and deployment mechanisms. Result correctness requires a Blueprint-specific verification method, such as deterministic checks, a proof, redundant execution, or a TEE attestation.
Is a health check enough to accept paid traffic?
No. A health check can show that a process responds. It should be paired with a known job, payment-path test, artifact identity, and rollback test before enabling production ingress.
What should an agent profile contain?
It should contain the endpoint, accepted network and token, recipient, budget, timeout, retry policy, and the result checks the agent expects. Those values let the agent decide whether a sample 402 request is safe to authorize.
For accountable provider selection before submission, continue with RFQ job quotes and operator accountability.
Public sources
The x402 protocol repository documents the current HTTP payment flow. The Tangle Blueprint repository contains the public SDK and gateway implementation. The remote-provider package documents current infrastructure targets and deployment capabilities. The Tangle pricing and payments guide explains how payment becomes a job. The Blueprint SDK deployment guide covers artifact publication and testnet promotion.