diff --git a/.evolve/skill-runs.jsonl b/.evolve/skill-runs.jsonl index d686d63..ebc7290 100644 --- a/.evolve/skill-runs.jsonl +++ b/.evolve/skill-runs.jsonl @@ -9,3 +9,4 @@ {"skill":"/signal-distill","ts":"2026-08-02T00:21:12Z","project":"tangle-website-blog","target":"Tangle blog SEO/AEO/GEO query map and SERP research","operatorPrompt":"","durationMin":null,"verdict":"PASS","dispatchedTo":"/stop","operatorOverride":null,"transcriptPath":null,"traceDir":null} {"skill":"/docs-slop-audit","ts":"2026-08-02T00:21:20Z","project":"tangle-website-blog","target":"85-post reader and SEO discovery audit; search research notes","operatorPrompt":"","durationMin":null,"verdict":"PASS","dispatchedTo":"/reflect","operatorOverride":null,"transcriptPath":null,"traceDir":null} {"skill":"/docs-slop-audit","ts":"2026-08-02T00:23:30Z","project":"tangle-website-blog","target":"SEO search research notes after seo-engine capability check","operatorPrompt":"","durationMin":null,"verdict":"PASS","dispatchedTo":"/reflect","operatorOverride":null,"transcriptPath":null,"traceDir":null} +{"skill":"/bad","ts":"2026-08-03T07:07:30Z","project":"tangle-website","target":"tangle blog cover and article page","operatorPrompt":"","durationMin":null,"verdict":"PASS","dispatchedTo":"/reflect","operatorOverride":null,"transcriptPath":null,"traceDir":null} diff --git a/public/images/covers/editorial/agent-intent-v2.webp b/public/images/covers/editorial/agent-intent-v2.webp new file mode 100644 index 0000000..5d78956 Binary files /dev/null and b/public/images/covers/editorial/agent-intent-v2.webp differ diff --git a/public/images/covers/editorial/agent-runtime-v2.webp b/public/images/covers/editorial/agent-runtime-v2.webp new file mode 100644 index 0000000..b4eba62 Binary files /dev/null and b/public/images/covers/editorial/agent-runtime-v2.webp differ diff --git a/public/images/covers/editorial/ai-tax-v2.webp b/public/images/covers/editorial/ai-tax-v2.webp new file mode 100644 index 0000000..1518c9d Binary files /dev/null and b/public/images/covers/editorial/ai-tax-v2.webp differ diff --git a/public/images/covers/editorial/blueprint-agent-v2.webp b/public/images/covers/editorial/blueprint-agent-v2.webp new file mode 100644 index 0000000..beb1f7a Binary files /dev/null and b/public/images/covers/editorial/blueprint-agent-v2.webp differ diff --git a/public/images/covers/editorial/blueprint-sdk-v2.webp b/public/images/covers/editorial/blueprint-sdk-v2.webp new file mode 100644 index 0000000..f524127 Binary files /dev/null and b/public/images/covers/editorial/blueprint-sdk-v2.webp differ diff --git a/public/images/covers/editorial/browser-agent-v2.webp b/public/images/covers/editorial/browser-agent-v2.webp new file mode 100644 index 0000000..bb5e5eb Binary files /dev/null and b/public/images/covers/editorial/browser-agent-v2.webp differ diff --git a/public/images/covers/editorial/code-auditor-v2.webp b/public/images/covers/editorial/code-auditor-v2.webp new file mode 100644 index 0000000..b589624 Binary files /dev/null and b/public/images/covers/editorial/code-auditor-v2.webp differ diff --git a/public/images/covers/editorial/distributed-training-v2.webp b/public/images/covers/editorial/distributed-training-v2.webp new file mode 100644 index 0000000..b102cda Binary files /dev/null and b/public/images/covers/editorial/distributed-training-v2.webp differ diff --git a/public/images/covers/editorial/instrument-problem-v2.webp b/public/images/covers/editorial/instrument-problem-v2.webp new file mode 100644 index 0000000..7e77b67 Binary files /dev/null and b/public/images/covers/editorial/instrument-problem-v2.webp differ diff --git a/public/images/covers/editorial/protocol-operators-v2.webp b/public/images/covers/editorial/protocol-operators-v2.webp new file mode 100644 index 0000000..69b9c77 Binary files /dev/null and b/public/images/covers/editorial/protocol-operators-v2.webp differ diff --git a/public/images/covers/editorial/rsa-aggregation-v2.webp b/public/images/covers/editorial/rsa-aggregation-v2.webp new file mode 100644 index 0000000..620b11a Binary files /dev/null and b/public/images/covers/editorial/rsa-aggregation-v2.webp differ diff --git a/public/images/covers/editorial/self-improving-stack-v2.webp b/public/images/covers/editorial/self-improving-stack-v2.webp new file mode 100644 index 0000000..0c499b5 Binary files /dev/null and b/public/images/covers/editorial/self-improving-stack-v2.webp differ diff --git a/public/images/covers/editorial/tangle-reintroduction-v2.webp b/public/images/covers/editorial/tangle-reintroduction-v2.webp new file mode 100644 index 0000000..a6c16e6 Binary files /dev/null and b/public/images/covers/editorial/tangle-reintroduction-v2.webp differ diff --git a/public/images/covers/editorial/x402-production-runway-v2.webp b/public/images/covers/editorial/x402-production-runway-v2.webp new file mode 100644 index 0000000..328f98b Binary files /dev/null and b/public/images/covers/editorial/x402-production-runway-v2.webp differ diff --git a/src/content/blog/30-blueprints.mdx b/src/content/blog/30-blueprints.mdx index 8b447b6..769444b 100644 --- a/src/content/blog/30-blueprints.mdx +++ b/src/content/blog/30-blueprints.mdx @@ -1,5 +1,5 @@ --- -title: '30 Blueprints: LLM Inference to Autonomous Trading' +title: '30 Tangle Blueprints: LLM Inference to Autonomous Trading' slug: 30-blueprints summary: >- Tangle Blueprints turn reusable services into operator-run jobs: inference, @@ -12,108 +12,177 @@ tags: - blueprints - catalog - infrastructure +coverImage: /images/covers/editorial/blueprint-agent-v2.webp +heroImage: /images/covers/editorial/blueprint-agent-v2.webp +imageAlt: 'An editorial still life about a catalog of runnable services' --- -Tangle has a growing Blueprint catalog, and the catalog is only useful if you read it as infrastructure instead of a list of demos. A Blueprint is a service definition operators can run: jobs, inputs, outputs, runtime requirements, verification path, pricing, and failure behavior. The point is not "30 things exist." The point is that developers can publish narrow services and operators can opt into the ones they are equipped to run. +Most people encounter a service catalog when they already have a problem to solve. -The catalog lives in [awesome-tangle-blueprints](https://github.com/tangle-network/awesome-tangle-blueprints). The SDK is [tangle-network/blueprint](https://github.com/tangle-network/blueprint). Before treating any entry as production-ready, inspect its repo, job interface, operator instructions, tests, deployment path, and verification story. +You may need an AI model to answer a request, a private machine to run untrusted code, or a transaction to be checked before money moves. -```bash -git clone https://github.com/tangle-network/awesome-tangle-blueprints -git clone https://github.com/tangle-network/blueprint -``` +The hard part is not finding a promising demo. -## How To Read A Blueprint +The hard part is understanding who runs the service, what the service accepts, what it returns, and what evidence you get when it fails. -A serious Blueprint should answer five questions without a private call: +This article explains how to read the Tangle service catalog with those questions in mind. -| Question | What to look for | -| --- | --- | -| what job does it expose? | typed inputs, typed outputs, clear failure modes | -| who can run it? | CPU, GPU, TEE, network, keys, operator config | -| how is work priced? | quote path, x402 challenge, fixed fee, or job policy | -| how is work verified? | deterministic check, TEE attestation, committee signatures, replay, eval, or human review | -| what evidence returns? | result, logs, receipt, trace ID, attestation, artifact hash | +## The short version -That is the difference between a Blueprint catalog and a GitHub topic page. The catalog should help a builder decide what to deploy, what to call, and what risk remains. +A Tangle Blueprint is a reusable description of a service that someone else can run. -## AI Inference Blueprints +It describes the job a caller can request, the inputs and outputs, the resources the job needs, how the service provider gets paid, and how a caller can check the result. -Inference is the most obvious starting point because the API shape is familiar. A useful inference Blueprint should expose a predictable endpoint, document model/runtime requirements, and make operator quality visible. +An operator is the person or service that runs that job. -- [LLM Inference](https://github.com/tangle-network/llm-inference-blueprint) serves OpenAI-compatible chat completions and connects to [Tangle Router](https://router.tangle.tools), where routing strategies like [RSA](/blog/rsa-recursive-self-aggregation) can sit above model providers. -- [Voice Inference](https://github.com/tangle-network/voice-inference-blueprint) targets TTS-style workloads where callers care about voice, latency, and output artifact handling. -- [Video Generation](https://github.com/tangle-network/video-gen-inference-blueprint) is a heavier operator workload because GPU memory, queueing, artifacts, and async status matter more than a normal text response. -- [Embedding](https://github.com/tangle-network/embedding-inference-blueprint) and [Vector Store](https://github.com/tangle-network/vector-store-blueprint) form the RAG substrate: embed, store, query, and return evidence. +The catalog is useful when it helps a developer choose a service and helps an operator decide whether that service is worth running. -The useful operator question is not "can I run one model?" It is "can I run a service with enough observability and economic margin that callers can trust it repeatedly?" +The number in this article's title is a catalog snapshot, not a promise that the list will never change. -## Training Is A Different Category +The current catalog is [awesome-tangle-blueprints](https://github.com/tangle-network/awesome-tangle-blueprints), and the public SDK is [tangle-network/blueprint](https://github.com/tangle-network/blueprint). -[Training Blueprint](https://github.com/tangle-network/training-blueprint) should not be grouped casually with inference. Inference is a request/response service. Training is a long-running coordination problem: data shards, checkpoints, synchronizations, operator churn, proof of progress, and final artifact ownership. +## Why a catalog of services matters -That is where DeMo-style communication reduction matters. The claim is not that every training job is suddenly cheap. The claim is narrower: if operators can synchronize compressed momentum instead of full gradients, internet-scale training becomes less absurd. Read the deeper breakdown in [Distributed Training with 10,000x Communication Reduction](/blog/distributed-training-demo). +An AI agent rarely needs only a language model. -## Agent And Sandbox Blueprints +It may need to browse a site, execute a program, call a paid API, inspect a wallet, train a small model, or ask another service to verify a result. -Agent infrastructure Blueprints are where the catalog starts to look different from normal cloud services. +In a single-provider setup, each capability is another private integration to build and maintain. -An [AI Agent Sandbox](https://github.com/tangle-network/ai-agent-sandbox-blueprint) is useful only if it can carry files, commands, credentials policy, snapshots, logs, and failure state. A sandbox that only executes code once is not enough for agent work. That same distinction appears in [AI agent sandbox](/blog/ai-agent-sandbox) and [Tangle Sandbox vs E2B](/blog/tangle-sandbox-vs-e2b). +A Blueprint gives that capability a shared shape. -AI trading is even stricter. A trading Blueprint has to separate model reasoning, validator checks, policy enforcement, and settlement. A model deciding to trade is not enough. The execution path needs signatures, limits, and an audit trail because the cost of a wrong action is real. +The caller knows what job to request. -## Cryptographic And Verification Blueprints +The operator knows what hardware, software, and credentials are required. -Threshold cryptography and MPC services are less flashy than agent demos, but they are exactly the kind of narrow capability a protocol should expose as reusable infrastructure. The catalog includes BLS, FROST, Schnorr Musig2, batch threshold encryption, CGGMP21, silent timelock encryption, WSTS, and zk service patterns. +Both sides can see the payment and result rules before a job starts. -These services do not need a big product surface. They need a precise interface and a strong operator story: +That shared shape does not make every service safe or production-ready. -| Service type | Buyer cares about | -| --- | --- | -| threshold signatures | key shares, quorum, signing latency, slashing | -| encryption/decryption | access policy, ciphertext handling, committee behavior | -| zk service | proof system, verification cost, artifact retention | -| TEE-backed job | measurement, verifier policy, result binding | +It makes the service easier to inspect and compare. -For the trust model, read [How Tangle Verifies Work](/blog/how-tangle-verifies-work) and [TEE Attestation for AI Services](/blog/tee-attestation-ai-services). +## What the 30 examples cover -## Operator Value +The catalog includes services for several kinds of work. -The operator value prop is portfolio construction. A GPU operator might run LLM inference, embeddings, voice, and some video jobs. A security-oriented operator might run threshold cryptography, TEE jobs, or validation services. A general node operator might start with lower-resource Blueprints and add specialized services later. +| Service family | The problem it addresses | Questions to ask | +| --- | --- | --- | +| Model inference | Run a model without hosting it yourself | Which model and limits are supported? | +| Sandboxes and browsers | Let an agent use a controlled computer | What can the job access, and how is it isolated? | +| Training and data work | Spend more compute on a repeatable job | What data, hardware, and output are required? | +| Trading and chain validation | Check a financial or on-chain action | Which state is observed, and what counts as success? | +| Cryptography | Produce or check a secret-dependent result | Who holds key shares, and what is the recovery plan? | +| Attestation and verification | Provide evidence about how work ran | What claim does the evidence support? | -The important part is that one operator identity can serve many job markets. Each Blueprint still needs its own operating requirements, pricing, health checks, and verification path. There is no free lunch: more Blueprints means more revenue surface and more operational surface. +These families are starting points, not maturity labels. -## What This Catalog Does Not Prove +A service in a familiar category can still have an incomplete failure path or a result that is difficult to check. -The catalog does not prove every Blueprint is equally mature. It does not prove every repo is production-hardened, every operator can run every job, or every claim has a live benchmark behind it. Treat the catalog as a map of service surfaces, then inspect each Blueprint before relying on it. +## Follow one job from request to result -The quality bar is simple: a Blueprint should let a developer define a service, let an operator run it, let a caller pay for it, and let everyone verify what happened. +Reading one Blueprint from start to finish is more useful than scanning thirty names. -## Start +First, choose the job you need. -Open the catalog, pick one Blueprint, and review it like an operator: +For example, an agent might request an inference job with a prompt, a model name, and a maximum response size. -```bash -git clone https://github.com/tangle-network/awesome-tangle-blueprints -git clone https://github.com/tangle-network/blueprint -``` +Next, read the job's inputs and outputs. -Then check the job interface, runtime requirements, payment path, verification story, tests, and deployment notes before treating it as a production service. +The input description should tell you what the operator receives, while the output description should tell you what your application can safely consume. + +Then look at the operator requirements. + +An inference service may need a particular GPU, while a browser service may need a separate browser profile and network policy. + +After that, read the quote and payment rules. + +x402 is a payment protocol for machine-to-machine HTTP requests, but a payment receipt does not by itself prove that the result is useful. + +Finally, read the result and failure rules. + +You should be able to answer what happens when the operator goes offline, the job times out, the output is malformed, or the caller disputes the result. + +If the repository does not answer those questions, treat the service as an experiment and plan your own safeguards. + +## A checklist for builders + +Before depending on a Blueprint in an application, check these six things. + +1. **Job contract:** Can you describe the request and response without reading private implementation details? +2. **Resource boundary:** Do you know what data, network access, credentials, and hardware the job can use? +3. **Payment behavior:** Do you know when a quote expires, when payment is collected, and what happens after a failure? +4. **Result evidence:** Can you tell whether the returned value came from the requested job? +5. **Recovery path:** Can your application retry, change operators, or refund a failed request? +6. **Public maintenance:** Are the tests, release notes, and operator instructions current enough for you to reproduce the service? + +The checklist is deliberately boring. + +That is the point. + +Infrastructure becomes dependable when the ordinary cases and the unhappy cases are visible before a customer depends on them. + +## A checklist for operators + +Operators should choose services by capability and responsibility, not by catalog count. + +Start with the hardware and credentials you can safely provide. + +Then estimate demand, job duration, storage, network exposure, and the cost of a failed request. + +An operator with a large GPU may be a good fit for model inference and a poor fit for a cryptographic service that needs a different custody model. + +The best portfolio is the one you can keep healthy and explain to callers. + +That means tracking whether jobs start, finish, time out, and return checkable results. + +## What decentralization changes + +The catalog does not magically remove trust. + +It changes where trust can be placed. + +Instead of trusting one company to host every capability, a caller can choose a service definition, an operator, a payment rule, and an evidence requirement separately. + +That separation is valuable when no single provider has the right hardware, price, geography, or risk policy for every job. + +It also creates more work for the builder. + +You must decide which failures are retriable, which evidence is sufficient, and when a result should be rejected. + +## The decision + +Use the catalog when you need a narrow, callable capability and want the operator contract to be visible before integration. + +Do not choose a Blueprint solely because its name sounds close to your use case. + +Open the repository, read the job contract, inspect the tests, and write down the result and failure behavior you need. + +If the Blueprint meets those requirements, integrate one small job first. + +If it does not, the missing contract is a useful signal that the service needs more work before it belongs in a production path. ## FAQ ### What is a Tangle Blueprint? -A Tangle Blueprint is a reusable service definition that operators can run under Tangle network rules. It defines jobs, runtime requirements, pricing or quote behavior, and verification expectations. +A Tangle Blueprint is a reusable service definition that an operator can run under Tangle network rules. + +It explains the jobs, resources, payment behavior, and result expectations that make the service callable. ### Are all 30 Blueprints production-ready? -No. The catalog includes services in different maturity stages. Builders should inspect each repository, tests, operator instructions, and verification path before depending on a Blueprint. +No. + +The catalog contains services at different stages, so inspect each repository, tests, operator instructions, and result checks before depending on one. ### Why do Blueprints matter for AI agents? -Agents need callable capabilities: inference, sandboxes, browser work, training, cryptography, attestations, and paid APIs. Blueprints give those capabilities an operator-run service model instead of a single centralized backend. +Agents need capabilities beyond text generation, including inference, browsers, sandboxes, training, cryptography, and paid APIs. + +Blueprints give those capabilities an operator-run service model that an application can request and evaluate. ### How do operators choose which Blueprints to run? -Operators should choose by hardware, risk, expected demand, verification burden, and margin. A GPU operator, TEE operator, and cryptography operator should not all run the same portfolio. +Choose by hardware, data risk, expected demand, verification work, and margin. + +An operator should run only the services it can keep healthy and support when a job fails. diff --git a/src/content/blog/agent-profile-materialization-contracts.mdx b/src/content/blog/agent-profile-materialization-contracts.mdx index c00a18e..830a8d5 100644 --- a/src/content/blog/agent-profile-materialization-contracts.mdx +++ b/src/content/blog/agent-profile-materialization-contracts.mdx @@ -12,9 +12,9 @@ tags: - ai-infrastructure series: Agent Runtime Infrastructure seriesOrder: 1 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'An agent profile divided into identity, model, prompt, tools, and resource fields' +coverImage: /images/covers/editorial/agent-runtime-v2.webp +heroImage: /images/covers/editorial/agent-runtime-v2.webp +imageAlt: 'An editorial still life about the software that runs an agent' --- Imagine saving an agent profile that says, “Use this model, these tools, this prompt, and these files.” diff --git a/src/content/blog/agent-readiness-index-methodology.mdx b/src/content/blog/agent-readiness-index-methodology.mdx index 11b3144..57867cc 100644 --- a/src/content/blog/agent-readiness-index-methodology.mdx +++ b/src/content/blog/agent-readiness-index-methodology.mdx @@ -10,6 +10,9 @@ tags: - agents - evals - api +coverImage: /images/covers/editorial/instrument-problem-v2.webp +heroImage: /images/covers/editorial/instrument-problem-v2.webp +imageAlt: 'An editorial still life about measuring whether an agent can use a changing API' --- Developers increasingly hand integration work to coding agents. @@ -27,7 +30,7 @@ This post explains how it works, what a score means, and what it cannot tell you A developer evaluating a payments provider today often starts by asking an agent to wire up a checkout flow. Here is what happens if the agent writes from memory. Stripe renamed the Checkout Session display-mode values on 2026-03-25: `embedded` became `embedded_page`. -An agent recalling the pre-2026 contract sends `ui_mode=embedded` and gets a 400. +An agent recalling the older contract sends `ui_mode=embedded` and gets a 400. The developer does not see a stale model. The developer sees a payments API that returned an error on the vendor's own quickstart flow, and tries the next vendor. @@ -120,7 +123,7 @@ All 9 were discarded and re-run. Detection was not the fix. The mock's source file is now deleted from disk the moment the server boots; the process keeps its loaded copy, so there is nothing left to read. -The cheat is impossible now, not merely detected. +The cheat is impossible now, more than detected. The general lesson: if the grader or a reference implementation is reachable from the agent's execution environment, a capable agent will find it, and nothing in the score will tell you. Treat any benchmark without transcript-level auditing and a leak-proof grading boundary as contaminated. @@ -140,7 +143,7 @@ A candidate task that fails any one of them is not admitted. Configuration-level results are published on the board itself rather than reproduced here: a leaderboard pasted into a post goes stale the moment the suite is re-run or the metric is corrected, and a post that disagrees with the board is worse than no post. The live table, including per-task detail and the roster behind each row, is at [/benchmarks/stripe](/benchmarks/stripe). -The shape worth understanding is that **rows are configurations, not models** — a model plus the CLI agent driving it — because the tooling moves the score materially. The same model driven by two different agents can differ by tens of points on identical tasks, which is why a "model leaderboard" for integration work is misleading. +The shape worth understanding is that **rows are configurations, not models**; a model plus the CLI agent driving it; because the tooling moves the score materially. The same model driven by two different agents can differ by tens of points on identical tasks, which is why a "model leaderboard" for integration work is misleading. A pass means the agent's code executed correctly against the current contract. Each configuration attempted each task twice, and each attempt is a single agent session with no retries and no human help. @@ -152,7 +155,7 @@ The sample is small. Every board states the attempt count behind each row; at the tens-of-attempts scale these suites run, treat gaps under roughly 10 points as noise rather than a ranking. Coverage is not always identical across rows. -A configuration can carry fewer attempts than its peers when a cell was lost to an infrastructure failure and quarantined rather than scored. The board reports the real denominator per row, so check it before comparing two configurations — an unequal denominator is the single easiest way to misread a benchmark. +A configuration can carry fewer attempts than its peers when a cell was lost to an infrastructure failure and quarantined rather than scored. The board reports the real denominator per row, so check it before comparing two configurations; an unequal denominator is the single easiest way to misread a benchmark. This is one API and 12 tasks, all Python HTTP clients. It measures readiness to integrate Stripe's current API, not general coding ability, repo-scale migration, or UI work. diff --git a/src/content/blog/agent-runtime-environments.mdx b/src/content/blog/agent-runtime-environments.mdx index e90a93a..3dd7331 100644 --- a/src/content/blog/agent-runtime-environments.mdx +++ b/src/content/blog/agent-runtime-environments.mdx @@ -1,5 +1,5 @@ --- -title: 'What an AI Agent Needs Beyond a Model' +title: 'AI Agent Runtime Environment: What an Agent Needs Beyond a Model' slug: agent-runtime-environments summary: >- A plain-language map of the infrastructure an agent needs to route models, run tools, use a browser, remember state, accept payment, and return evidence. @@ -11,9 +11,9 @@ tags: - infrastructure series: Agent Intent Infrastructure seriesOrder: 7 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'An AI agent surrounded by model, execution, browser, payment, and evidence boundaries' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- A model can write a response from text. diff --git a/src/content/blog/agent-runtime-generic-executor-deletion.mdx b/src/content/blog/agent-runtime-generic-executor-deletion.mdx index 92b3fcd..b6f8479 100644 --- a/src/content/blog/agent-runtime-generic-executor-deletion.mdx +++ b/src/content/blog/agent-runtime-generic-executor-deletion.mdx @@ -1,5 +1,5 @@ --- -title: 'Removing a Second Agent Path Without Hiding the Losses' +title: 'AI Agent Runtime Architecture: Removing a Second Execution Path' slug: agent-runtime-generic-executor-deletion summary: >- We removed a second program for starting coding agents only after a shared path could deliver the same saved settings and expose the missing run signals. @@ -12,9 +12,9 @@ tags: - software-architecture series: Agent Runtime Infrastructure seriesOrder: 2 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'A shared path replacing a backend-specific path for starting an agent' +coverImage: /images/covers/editorial/agent-runtime-v2.webp +heroImage: /images/covers/editorial/agent-runtime-v2.webp +imageAlt: 'An editorial still life about the software that runs an agent' --- Suppose two pieces of software start the same kind of coding job. diff --git a/src/content/blog/agent-runtime-worker-observability.mdx b/src/content/blog/agent-runtime-worker-observability.mdx index 589a5ab..c48b6dd 100644 --- a/src/content/blog/agent-runtime-worker-observability.mdx +++ b/src/content/blog/agent-runtime-worker-observability.mdx @@ -1,5 +1,5 @@ --- -title: 'A Running Agent Is Not Observable Until Its Work Is Visible' +title: 'AI Agent Observability: Make the Work Visible' slug: agent-runtime-worker-observability summary: >- The shared agent path now exposes live progress and requested tool calls, while leaving completion and duration unknown when the remote service never sends them. @@ -12,9 +12,9 @@ tags: - coding-agents series: Agent Runtime Infrastructure seriesOrder: 3 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'A live agent worker stream showing progress and recorded tool requests' +coverImage: /images/covers/editorial/agent-runtime-v2.webp +heroImage: /images/covers/editorial/agent-runtime-v2.webp +imageAlt: 'An editorial still life about the software that runs an agent' --- When an automated program runs for several minutes, silence is not a useful status. diff --git a/src/content/blog/ai-accountant-complex-tax-returns.mdx b/src/content/blog/ai-accountant-complex-tax-returns.mdx index 8538544..8487f36 100644 --- a/src/content/blog/ai-accountant-complex-tax-returns.mdx +++ b/src/content/blog/ai-accountant-complex-tax-returns.mdx @@ -11,16 +11,16 @@ tags: - complex-tax series: Building an AI Tax Agent seriesOrder: 4 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing source-backed accounting workpapers and review controls' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- -An AI accountant for complex tax returns is useful when it behaves like a preparer of evidence: it organizes documents, reconciles facts, drafts calculations, identifies missing records, and creates review questions for the taxpayer or advisor. It is not useful when it gives confident tax answers without workpapers. For founders, investors, crypto users, and multi-state households, the value is leverage before professional review, not replacing every professional judgment call. +An AI accountant for complex tax returns is useful when it behaves like a preparer of evidence: it organizes documents, reconciles facts, drafts calculations, identifies missing records, and creates review questions for the taxpayer or advisor. It is not useful when it gives confident tax answers without workpapers. For founders, investors, crypto users, and multi-state households, the value is use before professional review, not replacing every professional judgment call. This post is not tax advice. Treat AI accountant output as preparation material until the taxpayer or qualified advisor reviews it. -## What An AI Accountant Should Actually Do +## What An AI Accountant Should Do | Job | Good output | | --- | --- | diff --git a/src/content/blog/ai-agent-sandbox.mdx b/src/content/blog/ai-agent-sandbox.mdx index e667257..abd59c2 100644 --- a/src/content/blog/ai-agent-sandbox.mdx +++ b/src/content/blog/ai-agent-sandbox.mdx @@ -11,12 +11,12 @@ tags: - infrastructure series: Agent Intent Infrastructure seriesOrder: 2 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Agent runtime diagram showing sandbox files, processes, network policy, snapshots, and evidence' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- -An AI agent sandbox is an isolated runtime where an agent can create files, run processes, call tools, use the network under policy, preserve state, and return evidence. A code interpreter, browser automation session, or serverless job runner is too narrow for that job. Tangle Sandbox gives agents a machine-shaped workspace for real work: install dependencies, execute tests, inspect artifacts, recover from failure, and keep the dangerous parts contained. Start with [Tangle Sandbox](https://github.com/tangle-network/tcloud) when the agent needs an environment, not only an API. +An AI agent sandbox is an isolated runtime where an agent can create files, run processes, call tools, use the network under policy, preserve state, and return evidence. A code interpreter, browser automation session, or serverless job runner is too narrow for that job. Tangle Sandbox gives agents a machine-shaped workspace for real work: install dependencies, execute tests, inspect artifacts, recover from failure, and keep the dangerous parts contained. Start with [Tangle Sandbox](https://github.com/tangle-network/tcloud) when the agent needs an environment, more than an API. The hard part of agent infrastructure is not letting a model produce text. It is giving that model a place to act without handing it your laptop, production credentials, or a shared build server. @@ -31,12 +31,7 @@ The hard part of agent infrastructure is not letting a model produce text. It is Tangle's sandbox contract is intentionally machine-readable. Agents can discover it from the product manifest, package metadata, and health endpoint before trying to run work. -```bash -npm install @tangle-network/sandbox -curl -fsS https://sandbox.tangle.tools/health -curl -fsS https://sandbox.tangle.tools/.well-known/tangle-agent.json -curl -fsS https://sandbox.tangle.tools/v1/public-templates -``` +Use the public Sandbox manifest and package documentation to inspect the current service contract. Check the health result and available templates as part of a real workload, not as a substitute for one. As of this post, the health endpoint returns `{"status":"ok"}` and the public template endpoint is safe to call. Treat the template list as discovery, not as a guarantee that a specific template slug exists. diff --git a/src/content/blog/ai-browser-testing-evidence-traces.mdx b/src/content/blog/ai-browser-testing-evidence-traces.mdx index 11d75be..567ccd5 100644 --- a/src/content/blog/ai-browser-testing-evidence-traces.mdx +++ b/src/content/blog/ai-browser-testing-evidence-traces.mdx @@ -11,12 +11,12 @@ tags: - ai-browser-testing series: Browser Agent seriesOrder: 4 -coverImage: /images/products/browser-agent-app.png -heroImage: /images/products/browser-agent-app.png -imageAlt: 'Tangle Browser Agent workspace showing browser test run, screenshots, actions, and run evidence' +coverImage: /images/covers/editorial/browser-agent-v2.webp +heroImage: /images/covers/editorial/browser-agent-v2.webp +imageAlt: 'An editorial still life about an agent operating a web browser' --- -AI browser testing should not mean "ask a model if the page works." It should mean the agent drives the browser, observes the page, takes actions, verifies the goal, and saves the evidence. Without artifacts, a passing run is just a story. With artifacts, product and QA teams can inspect the exact page state that led to the result. +AI browser testing should not mean "ask a model if the page works." It should mean the agent drives the browser, observes the page, takes actions, verifies the goal, and saves the evidence. Without artifacts, a passing run is only a story. With artifacts, product and QA teams can inspect the exact page state that led to the result. Tangle Browser Agent is built around that evidence loop. For the broader automation model, read [Browser Automation For AI Agents](/blog/browser-automation-for-ai-agents). @@ -37,14 +37,7 @@ Traditional browser automation has strong standards. [WebDriver](https://www.w3. The normal run path is direct: -```bash -npm install -g @tangle-network/browser-agent-driver -npx playwright install chromium - -bad run \ - --url https://example.com \ - --goal "Create an account, finish onboarding, and verify the dashboard loads" -``` +Start with the public Browser Agent documentation and run one representative flow. Save the screenshots, page state, actions, and outcome so another person can inspect the result. After the run, inspect the evidence: diff --git a/src/content/blog/ai-code-audit-sandboxed-agents.mdx b/src/content/blog/ai-code-audit-sandboxed-agents.mdx index e0134e9..3eb0a62 100644 --- a/src/content/blog/ai-code-audit-sandboxed-agents.mdx +++ b/src/content/blog/ai-code-audit-sandboxed-agents.mdx @@ -11,9 +11,9 @@ tags: - ai-audit series: Code Auditor seriesOrder: 1 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Code auditor agent workspace showing repository audit, sandboxed tools, subagents, and finding validation' +coverImage: /images/covers/editorial/code-auditor-v2.webp +heroImage: /images/covers/editorial/code-auditor-v2.webp +imageAlt: 'An editorial still life about reviewing code and producing evidence' --- AI code audit is useful only when the agent can inspect the repository, run tools, test exploit paths, and show why each finding is real. A model that reads code and writes confident prose is not an auditor. Tangle Code Auditor is the upcoming product surface at `audit.tangle.tools`; until that domain is live, public copy should describe the audit runtime without linking to a product URL. @@ -35,22 +35,7 @@ This is closer to an audit workflow than a scanner workflow. Scanners such as [C ## Example Audit Command -```bash -pnpm redteam audit --repo https://github.com/org/protocol -pnpm redteam audit --repo https://github.com/org/protocol --ref main --focus "reentrancy,flash-loans" --json -``` - -The command is only valuable if the report connects each issue to files, exploit path, command output, and a fix direction. - -## Sandbox-First Design - -Security audits execute unknown code. That should happen in a managed environment, not on a developer laptop with production credentials. - -```bash -pnpm redteam sandbox create --capability evm-foundry -pnpm redteam sandbox exec "forge test" -pnpm redteam sandbox destroy -``` +Use an isolated audit runner and preserve the report, affected files, reproduction evidence, and proposed fix. The exact command depends on the repository and scanner version. For the runtime layer behind this pattern, read [LLM Sandbox Environment For Agent Runs](/blog/llm-sandbox-environment-agent-runtime). For scanner triage, read [AI Vulnerability Scanner Vs Agent Audit](/blog/ai-vulnerability-scanner-vs-agent-audit). diff --git a/src/content/blog/ai-coding-assistant-deployment-evidence.mdx b/src/content/blog/ai-coding-assistant-deployment-evidence.mdx index c6471a8..35738df 100644 --- a/src/content/blog/ai-coding-assistant-deployment-evidence.mdx +++ b/src/content/blog/ai-coding-assistant-deployment-evidence.mdx @@ -11,12 +11,12 @@ tags: - developer-tools series: Blueprint Agent seriesOrder: 2 -coverImage: /images/products/blueprint-agent-app.png -heroImage: /images/products/blueprint-agent-app.png -imageAlt: 'Blueprint Agent workspace showing AI coding session, project files, quest verification, and deployment controls' +coverImage: /images/covers/editorial/blueprint-agent-v2.webp +heroImage: /images/covers/editorial/blueprint-agent-v2.webp +imageAlt: 'An editorial still life about a runnable service blueprint' --- -An AI coding assistant becomes useful to a developer program when it can prove more than "the model wrote code." The bar is running code, verified tasks, deployment evidence, and a session trace that a partner team can review. Tangle Blueprint Agent is aimed at that job: give developers an isolated coding workspace with partner SDKs, indexed docs, AI help, and code-based quest verification. +A trace is the record of an agent run, including its actions and results. An AI coding assistant becomes useful to a developer program when it can prove more than "the model wrote code." The bar is running code, verified tasks, deployment evidence, and a session trace that a partner team can review. Tangle Blueprint Agent is aimed at that job: give developers an isolated coding workspace with partner SDKs, indexed docs, AI help, and code-based quest verification. This is different from a generic IDE chat panel. The product surface at [ai.tangle.tools](https://ai.tangle.tools) is designed around partner onboarding and real build outcomes. diff --git a/src/content/blog/ai-dev-container-production-agent-runtime.mdx b/src/content/blog/ai-dev-container-production-agent-runtime.mdx index 37a4bd0..bc0cf4f 100644 --- a/src/content/blog/ai-dev-container-production-agent-runtime.mdx +++ b/src/content/blog/ai-dev-container-production-agent-runtime.mdx @@ -11,12 +11,12 @@ tags: - ai-infrastructure series: Agent Runtime Infrastructure seriesOrder: 4 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Agent runtime workspace showing isolated filesystem, shell execution, session stream, and trace evidence' +coverImage: /images/covers/editorial/agent-runtime-v2.webp +heroImage: /images/covers/editorial/agent-runtime-v2.webp +imageAlt: 'An editorial still life about the software that runs an agent' --- -An AI dev container is the workspace where an agent can read files, run commands, edit code, and leave evidence behind. The search term sounds like a Docker problem. In production, it is a control problem: who created the environment, what tools can run, how long state survives, how streams resume, and what proof remains after a failed task. Tangle Sandbox SDK treats the dev container as runtime infrastructure for agents, not as a disposable shell. +An agent runtime is the software that starts, controls, and records an agent run. A trace is the record of an agent run, including its actions and results. An AI dev container is the workspace where an agent can read files, run commands, edit code, and leave evidence behind. The search term sounds like a Docker problem. In production, it is a control problem: who created the environment, what tools can run, how long state survives, how streams resume, and what proof remains after a failed task. Tangle Sandbox SDK treats the dev container as runtime infrastructure for agents, not as a disposable shell. For the broader runtime model, read [AI Agent Sandbox](/blog/ai-agent-sandbox) and [Agent Runtime Environment](/blog/agent-runtime-environments). @@ -37,25 +37,7 @@ The isolation layer can use proven primitives such as [Firecracker microVMs](htt The SDK path is intentionally small. Create a sandbox, run a command, inspect the result, and destroy the environment. -```bash -npm install @tangle-network/sandbox -export TANGLE_API_KEY=sk-tan-... -export SANDBOX_BASE_URL=https://sandbox.tangle.tools -``` - -```ts -import { Sandbox } from '@tangle-network/sandbox' - -const client = new Sandbox({ - apiKey: process.env.TANGLE_API_KEY!, - baseUrl: process.env.SANDBOX_BASE_URL ?? 'https://sandbox.tangle.tools' -}) - -const box = await client.create({ image: 'universal', name: 'agent-smoke' }) -const result = await box.exec('node --version && npm --version') -console.log(result.stdout) -await box.delete() -``` +Use the public Sandbox SDK documentation to create an isolated workspace, run one harmless command, inspect its result, and remove the workspace. The important artifact is the recorded run, not the setup script. That is the smoke test. The real product work starts after that: task prompts, long-running commands, streamed logs, snapshots, retries, and review packets. diff --git a/src/content/blog/ai-e2e-testing-browser-agents.mdx b/src/content/blog/ai-e2e-testing-browser-agents.mdx index 7c55442..7ed3cb3 100644 --- a/src/content/blog/ai-e2e-testing-browser-agents.mdx +++ b/src/content/blog/ai-e2e-testing-browser-agents.mdx @@ -11,9 +11,9 @@ tags: - qa series: Browser Agent seriesOrder: 5 -coverImage: /images/products/browser-agent-app.png -heroImage: /images/products/browser-agent-app.png -imageAlt: 'End-to-end browser test run with goal, steps, screenshots, and final verification' +coverImage: /images/covers/editorial/browser-agent-v2.webp +heroImage: /images/covers/editorial/browser-agent-v2.webp +imageAlt: 'An editorial still life about an agent operating a web browser' --- AI E2E testing is most useful at the product boundary: signup, checkout, app setup, wallet connection, claim flow, dashboard load, and any workflow where the user's path crosses several systems. A coded test can be better for a stable button. An agent is better when the team needs to say the outcome in English and still get browser evidence. diff --git a/src/content/blog/ai-security-audit-reproducible-findings.mdx b/src/content/blog/ai-security-audit-reproducible-findings.mdx index 2872614..771d32f 100644 --- a/src/content/blog/ai-security-audit-reproducible-findings.mdx +++ b/src/content/blog/ai-security-audit-reproducible-findings.mdx @@ -11,9 +11,9 @@ tags: - ai-security series: Code Auditor seriesOrder: 2 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Security audit report showing validated findings, severity proof, and reproduction commands' +coverImage: /images/covers/editorial/code-auditor-v2.webp +heroImage: /images/covers/editorial/code-auditor-v2.webp +imageAlt: 'An editorial still life about reviewing code and producing evidence' --- An AI security audit should be judged by reproducibility. If the finding cannot point to code, show the exploit path, explain severity, and give a command or test that supports the claim, it is not ready for a security decision. Tangle Code Auditor is being shaped around that standard: agent-assisted review with sandboxed execution and proof-backed reports. diff --git a/src/content/blog/ai-service-marketplace-crypto-payments.mdx b/src/content/blog/ai-service-marketplace-crypto-payments.mdx index 067de54..b69f43b 100644 --- a/src/content/blog/ai-service-marketplace-crypto-payments.mdx +++ b/src/content/blog/ai-service-marketplace-crypto-payments.mdx @@ -11,12 +11,12 @@ tags: - crypto-payments series: Tangle Protocol seriesOrder: 12 -coverImage: /images/covers/x402-pay-per-call.png -heroImage: /images/covers/x402-pay-per-call.png -imageAlt: 'AI service marketplace flow showing service discovery, crypto payment, operator execution, and result receipt' +coverImage: /images/covers/editorial/protocol-operators-v2.webp +heroImage: /images/covers/editorial/protocol-operators-v2.webp +imageAlt: 'An editorial still life about operators running services on a network' --- -An AI service marketplace with crypto payments is only useful if the buyer can discover a service, understand the price, pay per request, receive the result, and inspect evidence when something fails. Crypto payments should reduce friction for machine-to-machine usage, not hide the operating model. +A blueprint is a packaged service definition with a typed job interface. An operator is the person or service responsible for running a job. x402 is a payment protocol for machine-to-machine requests. An AI service marketplace with crypto payments is only useful if the buyer can discover a service, understand the price, pay per request, receive the result, and inspect evidence when something fails. Crypto payments should reduce friction for machine-to-machine usage, not hide the operating model. Tangle's protocol direction combines Blueprints, operators, and payment-native service calls. For payment mechanics, read [x402 Payments For AI Agents](/blog/x402-payments-for-ai-agents). For operator-run services, read [Blueprint Protocol For Operator-Run Services](/blog/blueprint-protocol-operator-services). diff --git a/src/content/blog/ai-tax-filing-software-complex-returns.mdx b/src/content/blog/ai-tax-filing-software-complex-returns.mdx index 3b8c229..4cb553b 100644 --- a/src/content/blog/ai-tax-filing-software-complex-returns.mdx +++ b/src/content/blog/ai-tax-filing-software-complex-returns.mdx @@ -11,16 +11,16 @@ tags: - filing-software series: Building an AI Tax Agent seriesOrder: 2 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing review-before-sign tax filing controls' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- -AI tax filing software for complex returns should reduce coordination work without removing review. The useful test is simple: can the software turn source documents into a draft return package, show the evidence behind the numbers, flag uncertain items, and stop before submission for approval? If it cannot, it is just a chat interface attached to a tax checklist. Tangle Tax Agent should be judged by the filing packet it produces, not by the confidence of its answers. +A worker is the process that carries out one agent task. AI tax filing software for complex returns should reduce coordination work without removing review. The useful test is simple: can the software turn source documents into a draft return package, show the evidence behind the numbers, flag uncertain items, and stop before submission for approval? If it cannot, it is a chat interface attached to a tax checklist. Tangle Tax Agent should be judged by the filing packet it produces, not by the confidence of its answers. This post is about workflow design, not tax advice. For high-risk facts, taxpayers should consult a qualified professional. -## Who Actually Needs AI Filing Software? +## Who In practice Needs AI Filing Software? A W-2-only taxpayer may not need an agent. The IRS and many consumer products already support straightforward filing paths. AI becomes useful when the return has many source systems or many judgment points. diff --git a/src/content/blog/ai-tax-preparation-complex-returns.mdx b/src/content/blog/ai-tax-preparation-complex-returns.mdx index 0454e5f..f7bf70e 100644 --- a/src/content/blog/ai-tax-preparation-complex-returns.mdx +++ b/src/content/blog/ai-tax-preparation-complex-returns.mdx @@ -11,9 +11,9 @@ tags: - complex-tax series: Building an AI Tax Agent seriesOrder: 1 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing document intake, calculations, review controls, and filing workflow' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- AI tax preparation is useful for complex returns when it does three things a normal interview tree does not: ingest messy source documents, build a source-backed return model, and stop for review before anything is filed. A complex return is not hard because the taxpayer needs more chat. It is hard because the return may involve K-1s, entity ownership, foreign reporting, crypto lots, multi-state income, estimated payments, and missing basis. Tangle Tax Agent should be evaluated on whether it creates a reviewable filing package, not on whether it can explain tax topics in prose. diff --git a/src/content/blog/ai-vulnerability-scanner-vs-agent-audit.mdx b/src/content/blog/ai-vulnerability-scanner-vs-agent-audit.mdx index 28c2dd1..2e78f8c 100644 --- a/src/content/blog/ai-vulnerability-scanner-vs-agent-audit.mdx +++ b/src/content/blog/ai-vulnerability-scanner-vs-agent-audit.mdx @@ -11,12 +11,12 @@ tags: - security series: Code Auditor seriesOrder: 4 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Comparison of vulnerability scanner output and agent audit report with validated findings' +coverImage: /images/covers/editorial/code-auditor-v2.webp +heroImage: /images/covers/editorial/code-auditor-v2.webp +imageAlt: 'An editorial still life about reviewing code and producing evidence' --- -An AI vulnerability scanner can be useful, but the phrase hides two very different products. A scanner finds patterns and ranks possible issues. An agent audit investigates whether those issues are reachable, exploitable, duplicated, or false. Tangle Code Auditor is being built toward the second model. +An AI vulnerability scanner can be useful, but the phrase hides two different products. A scanner finds patterns and ranks possible issues. An agent audit investigates whether those issues are reachable, exploitable, duplicated, or false. Tangle Code Auditor is being built toward the second model. The planned product surface is `audit.tangle.tools`; public pages should treat it as upcoming until the domain is live. diff --git a/src/content/blog/anonymous-llm-usage-shielded-payments.mdx b/src/content/blog/anonymous-llm-usage-shielded-payments.mdx index c9ccfc7..80832e0 100644 --- a/src/content/blog/anonymous-llm-usage-shielded-payments.mdx +++ b/src/content/blog/anonymous-llm-usage-shielded-payments.mdx @@ -11,12 +11,12 @@ tags: - llm-inference series: Tangle Protocol seriesOrder: 9 -coverImage: /images/covers/payment-native-infrastructure-ai-agent-product-strategy.png -heroImage: /images/covers/payment-native-infrastructure-ai-agent-product-strategy.png -imageAlt: 'Payment-native AI request flow showing shielded payment, operator service, inference request, and receipt' +coverImage: /images/covers/editorial/protocol-operators-v2.webp +heroImage: /images/covers/editorial/protocol-operators-v2.webp +imageAlt: 'An editorial still life about operators running services on a network' --- -Anonymous LLM usage is a sharper requirement than "private AI." A user may want to pay for an inference request without exposing billing identity, wallet history, or unnecessary metadata to every party in the path. Tangle's protocol direction includes shielded payment rails for AI services, but the claim has to stay precise: payment privacy is one layer, not a guarantee that every prompt, provider, network hop, or application log is anonymous. +An operator is the person or service responsible for running a job. x402 is a payment protocol for machine-to-machine requests. Anonymous LLM usage is a sharper requirement than "private AI." A user may want to pay for an inference request without exposing billing identity, wallet history, or unnecessary metadata to every party in the path. Tangle's protocol direction includes shielded payment rails for AI services, but the claim has to stay precise: payment privacy is one layer, not a guarantee that every prompt, provider, network hop, or application log is anonymous. For the payment base layer, read [x402 Payments For AI Agents](/blog/x402-payments-for-ai-agents). For the product strategy, read [Payment-Native Infrastructure For AI Agent Products](/blog/payment-native-infrastructure-ai-agent-product-strategy). @@ -82,7 +82,7 @@ A privacy-sensitive LLM service should publish: | receipt format | lets the user prove payment without overexposing identity | | deletion policy | explains what happens after the request completes | -For protocol context, compare this with the public x402 request-payment direction at [x402.org](https://www.x402.org/), [Coinbase's x402 docs](https://docs.cdp.coinbase.com/x402/welcome), and Cloudflare's writeup on [pay per crawl and x402](https://blog.cloudflare.com/x402/). Those links describe payment flow mechanics; Tangle's privacy claim should stay limited to the layers Tangle actually controls. +For protocol context, compare this with the public x402 request-payment direction at [x402.org](https://www.x402.org/), [Coinbase's x402 docs](https://docs.cdp.coinbase.com/x402/welcome), and Cloudflare's writeup on [pay per crawl and x402](https://blog.cloudflare.com/x402/). Those links describe payment flow mechanics; Tangle's privacy claim should stay limited to the layers Tangle in practice controls. ## Good First Workloads diff --git a/src/content/blog/automated-smart-contract-audit-poc-validation.mdx b/src/content/blog/automated-smart-contract-audit-poc-validation.mdx index bdefa4d..f019da9 100644 --- a/src/content/blog/automated-smart-contract-audit-poc-validation.mdx +++ b/src/content/blog/automated-smart-contract-audit-poc-validation.mdx @@ -14,12 +14,12 @@ tags: - blockchain-security series: Code Auditor seriesOrder: 3 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Automated smart contract audit showing EVM test run, exploit proof, and validated report' +coverImage: /images/covers/editorial/code-auditor-v2.webp +heroImage: /images/covers/editorial/code-auditor-v2.webp +imageAlt: 'An editorial still life about reviewing code and producing evidence' --- -An automated smart contract audit is useful when automation produces proof, not a long list of pattern matches. +A trace is the record of an agent run, including its actions and results. An automated smart contract audit is useful when automation produces proof, not a long list of pattern matches. For every high-severity finding, require the affected code, exploit preconditions, a reproduction command, the observed state change, and a regression test for the fix. Anything less should remain a hypothesis for review. diff --git a/src/content/blog/automated-tax-filing-review-before-submit.mdx b/src/content/blog/automated-tax-filing-review-before-submit.mdx index d58fc8d..8940991 100644 --- a/src/content/blog/automated-tax-filing-review-before-submit.mdx +++ b/src/content/blog/automated-tax-filing-review-before-submit.mdx @@ -11,9 +11,9 @@ tags: - review-before-sign series: Building an AI Tax Agent seriesOrder: 5 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent review-before-submit workflow for automated tax filing' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- Automated tax filing should not mean blind filing. The safer model is review-before-submit: the agent prepares the return package, explains the evidence, flags open issues, and asks the taxpayer to approve before anything is signed or sent. That is the right bar for Tangle Tax Agent and for any AI tax system touching complex returns. Automation is useful when it reduces manual work. It is dangerous when it hides filing decisions. diff --git a/src/content/blog/blueprint-deployment-architecture-remote-providers.mdx b/src/content/blog/blueprint-deployment-architecture-remote-providers.mdx index 9bf95ba..ea7da13 100644 --- a/src/content/blog/blueprint-deployment-architecture-remote-providers.mdx +++ b/src/content/blog/blueprint-deployment-architecture-remote-providers.mdx @@ -1,5 +1,5 @@ --- -title: Remote Providers, Direct Runtimes, and Where Payment-Native Ingress Belongs in Deployment Architecture +title: 'How to Deploy an AI Agent Service: Remote Providers and Payment' slug: blueprint-deployment-architecture-remote-providers summary: >- Blueprint jobs can run locally, on remote VMs, on Kubernetes, or serverless. @@ -19,22 +19,22 @@ tags: - infrastructure series: x402 Production Runway seriesOrder: 9 -coverImage: /images/covers/blueprint-deployment-architecture-remote-providers.png -heroImage: /images/covers/blueprint-deployment-architecture-remote-providers.png -imageAlt: 'Parallel ingress streams (x402 + primary) feeding one Blueprint runner' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -When you build a service with the Blueprint SDK, your service logic runs inside a `BlueprintRunner`. The runner manages all the ways work arrives: from the Tangle blockchain, from direct HTTP calls, or from any custom source you wire in. Where that runner actually executes, whether on your laptop, a cloud VM, or a Kubernetes cluster, is a separate decision called the deployment target. +A blueprint is a packaged service definition with a typed job interface. x402 is a payment protocol for machine-to-machine requests. When you build a service with the Blueprint SDK, your service logic runs inside a `BlueprintRunner`. The runner manages all the ways work arrives: from the Tangle blockchain, from direct HTTP calls, or from any custom source you wire in. Where that runner in practice executes, whether on your laptop, a cloud VM, or a Kubernetes cluster, is a separate decision called the deployment target. This post explains how deployment targets work, how Blueprint services receive payment-gated HTTP jobs via the x402 protocol, and how those two concerns fit together across every topology Blueprint supports. If you have never heard of Blueprint or x402: Blueprint is Tangle's SDK for building AI agent services that accept jobs from the Tangle network. x402 is a payment protocol built on HTTP 402, which lets HTTP clients pay for a request before the server executes it. -The key design choice this post is really about: the x402 payment gateway is not a separate proxy that sits in front of your service. It runs as a concurrent background task inside the same process as your job runner. That decision has real consequences for how you deploy, scale, and upgrade paid services, and the rest of this post explains why it was made that way and what it means for each deployment target. +The key design choice this post is in practice about: the x402 payment gateway is not a separate proxy that sits in front of your service. It runs as a concurrent background task inside the same process as your job runner. That decision changes for how you deploy, scale, and upgrade paid services, and the rest of this post explains why it was made that way and what it means for each deployment target. ## What Problem Does This Solve? Most infrastructure guides treat deployment and payment as separate concerns: pick a deployment target, then bolt on monetization later. A conventional payment gateway sits in front of compute. Request arrives, payment is checked, then compute runs. The payment layer can only see requests that arrive through it. When it goes down, nothing runs. When you want to add a second job source (say, on-chain Tangle events alongside HTTP payments), you need a multiplexing layer that the gateway does not natively provide. -Blueprint inverts this. The runner is the multiplexer. `TangleProducer`, `X402Producer`, and any other producers you wire in are concurrent streams feeding the same `Router`. Each producer is independent. The x402 payment HTTP server runs as a `BackgroundService` alongside heartbeats, metrics servers, and TEE auth services. It is structurally identical to those, just one more concurrent task in the runner's lifecycle. +Blueprint inverts this. The runner is the multiplexer. `TangleProducer`, `X402Producer`, and any other producers you wire in are concurrent streams feeding the same `Router`. Each producer is independent. The x402 payment HTTP server runs as a `BackgroundService` alongside heartbeats, metrics servers, and TEE auth services. It is structurally identical to those, one more concurrent task in the runner's lifecycle. ## How Do You Deploy a Blueprint Service to Production? diff --git a/src/content/blog/blueprint-protocol-operator-services.mdx b/src/content/blog/blueprint-protocol-operator-services.mdx index a46ed8b..744dcd6 100644 --- a/src/content/blog/blueprint-protocol-operator-services.mdx +++ b/src/content/blog/blueprint-protocol-operator-services.mdx @@ -11,12 +11,12 @@ tags: - operators series: Tangle Protocol seriesOrder: 10 -coverImage: /images/covers/how-blueprints-work.png -heroImage: /images/covers/how-blueprints-work.png -imageAlt: 'Blueprint protocol architecture showing developer definition, operator runtime, service instance, jobs, and users' +coverImage: /images/covers/editorial/protocol-operators-v2.webp +heroImage: /images/covers/editorial/protocol-operators-v2.webp +imageAlt: 'An editorial still life about operators running services on a network' --- -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. +An operator is the person or service responsible for running a job. 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](/blog/blueprint-sdk-deployment-guide). For product onboarding, read [AI Coding Assistant With Deployment Evidence](/blog/ai-coding-assistant-deployment-evidence). diff --git a/src/content/blog/blueprint-sdk-deployment-guide.mdx b/src/content/blog/blueprint-sdk-deployment-guide.mdx index b423711..6184593 100644 --- a/src/content/blog/blueprint-sdk-deployment-guide.mdx +++ b/src/content/blog/blueprint-sdk-deployment-guide.mdx @@ -11,9 +11,9 @@ tags: - tangle series: Blueprint SDK seriesOrder: 1 -coverImage: /images/covers/blueprint-deployment-architecture-remote-providers.png -heroImage: /images/covers/blueprint-deployment-architecture-remote-providers.png -imageAlt: 'A service moving from local development through testnet evidence to an operator-run deployment' +coverImage: /images/covers/editorial/blueprint-sdk-v2.webp +heroImage: /images/covers/editorial/blueprint-sdk-v2.webp +imageAlt: 'An editorial still life about a developer kit for runnable services' --- Getting a service to run on your laptop is not the same as making it possible for someone else to operate. diff --git a/src/content/blog/blueprint-sdk-x402-payments-runnable-jobs.mdx b/src/content/blog/blueprint-sdk-x402-payments-runnable-jobs.mdx index ca16020..82ddf52 100644 --- a/src/content/blog/blueprint-sdk-x402-payments-runnable-jobs.mdx +++ b/src/content/blog/blueprint-sdk-x402-payments-runnable-jobs.mdx @@ -1,5 +1,5 @@ --- -title: 'How a Paid HTTP Request Becomes a Tangle Job' +title: 'x402 Payments Blueprint: How a Paid HTTP Request Becomes a Job' slug: blueprint-sdk-x402-payments-runnable-jobs summary: >- A plain-language tour of how the Blueprint SDK turns an HTTP payment proof into the same job a Tangle service can receive from other triggers. @@ -13,9 +13,9 @@ tags: - agent-infrastructure series: x402 Production Runway seriesOrder: 1 -coverImage: /images/covers/blueprint-sdk-x402-payments-runnable-jobs.png -heroImage: /images/covers/blueprint-sdk-x402-payments-runnable-jobs.png -imageAlt: 'A paid HTTP request moving through payment verification into a Tangle job' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- Most paid APIs make the customer create an account, receive an API key, keep a balance, and reconcile invoices later. @@ -98,7 +98,7 @@ The conversion needs four values: - an operator markup, if any - the token’s decimal precision -For example, a job priced at 0.001 ETH becomes 3.264 USDC when the exchange rate is 3,200 USDC per ETH and the operator adds a 2% markup. +A reported example: a job priced at 0.001 ETH becomes 3.264 USDC when the exchange rate is 3,200 USDC per ETH and the operator adds a 2% markup. The client receives the converted amount in the price response rather than calculating it from local assumptions. The price response also carries a **quote fingerprint**, which ties the payment to the exact amount and destination the client agreed to. diff --git a/src/content/blog/blueprint-tee-x402-production-gating.mdx b/src/content/blog/blueprint-tee-x402-production-gating.mdx index 8a49bb6..ed01ac4 100644 --- a/src/content/blog/blueprint-tee-x402-production-gating.mdx +++ b/src/content/blog/blueprint-tee-x402-production-gating.mdx @@ -1,5 +1,5 @@ --- -title: 'x402 and TEE Together: What Must Pass Before Promotion' +title: 'Secure Code Execution for AI Agents: x402 and TEE Checks' slug: blueprint-tee-x402-production-gating summary: >- x402 handles payment authorization. TEE handles execution integrity. Neither alone is sufficient for production. This post explains the two-gate system: what must pass before a Blueprint service activates and before job results can be trusted. @@ -13,12 +13,12 @@ tags: - production series: x402 Production Runway seriesOrder: 8 -coverImage: /images/covers/blueprint-tee-x402-production-gating.png -heroImage: /images/covers/blueprint-tee-x402-production-gating.png -imageAlt: 'Two gates: payment and TEE attestation must both pass before promotion' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -When you pay for a computation, you want two things to be true. First, that the payment was valid and authorized. Second, that the computation actually ran where and how it was supposed to. Most systems get the payment part right. The execution integrity part is harder. +A blueprint is a packaged service definition with a typed job interface. x402 is a payment protocol for machine-to-machine requests. When you pay for a computation, you want two things to be true. First, that the payment was valid and authorized. Second, that the computation in practice ran where and how it was supposed to. Most systems get the payment part right. The execution integrity part is harder. Trusted Execution Environments (TEEs) solve the execution integrity problem at the hardware level. A TEE is a secure zone inside a processor where code runs in isolation from the host operating system. The machine's owner cannot inspect memory inside the TEE, cannot tamper with the code running inside it, and cannot substitute a different binary without breaking the attestation that proves which code is running. AWS Nitro Enclaves, Intel TDX, AMD SEV-SNP, and Azure Confidential VMs are all variations of this model. @@ -59,7 +59,7 @@ impl Default for TeeKeyExchangeConfig { } ``` -This is not a papercut. It is the difference between a TEE system that can be spoofed and one that cannot. Every other gate below depends on knowing which enclave you are actually talking to. +This is not a papercut. It is the difference between a TEE system that can be spoofed and one that cannot. Every other gate below depends on knowing which enclave you are in practice talking to. ## Two Gates, Not One @@ -103,7 +103,7 @@ pub struct AttestationClaims { } ``` -The comment is the policy. A Nitro enclave built with `--debug-mode` produces attestation that any verifier can inspect and any tool can spoof. The hardware isolation properties that make TEEs useful simply do not hold in debug mode. This field is populated from the raw attestation document. If the enclave set the debug flag, `debug_mode` is `true`, and promotion must be rejected. +The comment is the policy. A Nitro enclave built with `--debug-mode` produces attestation that any verifier can inspect and any tool can spoof. The hardware isolation properties that make TEEs useful directly do not hold in debug mode. This field is populated from the raw attestation document. If the enclave set the debug flag, `debug_mode` is `true`, and promotion must be rejected. ### 2. on_chain_verification must be enabled diff --git a/src/content/blog/blueprint-x402-operator-economics-distribution.mdx b/src/content/blog/blueprint-x402-operator-economics-distribution.mdx index 606363c..6ebdf7f 100644 --- a/src/content/blog/blueprint-x402-operator-economics-distribution.mdx +++ b/src/content/blog/blueprint-x402-operator-economics-distribution.mdx @@ -17,14 +17,14 @@ tags: - solidity series: x402 Production Runway seriesOrder: 7 -coverImage: /images/covers/blueprint-x402-operator-economics-distribution.png -heroImage: /images/covers/blueprint-x402-operator-economics-distribution.png -imageAlt: 'On-chain payment distribution flow diagram showing ServiceFeeDistributor, streaming manager, and exposure-weighted staking pools' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -When a client pays an x402 Blueprint job, the USDC moves to the operator's `pay_to` address on the settlement chain. That's the end of the client's story. It's the beginning of the operator's. +A blueprint is a packaged service definition with a typed job interface. An operator is the person or service responsible for running a job. x402 is a payment protocol for machine-to-machine requests. When a client pays an x402 Blueprint job, the USDC moves to the operator's `pay_to` address on the settlement chain. That's the end of the client's story. It's the beginning of the operator's. -The payment lands as a cross-chain deposit. Before operators can claim anything, the Tangle protocol has to decide who gets what. An operator running a high-stakes Blueprint with a large staking pool behind it gets a different cut than one running the same Blueprint with minimal backing. The distribution isn't arbitrary — it's driven by exposure, USD-weighted delegation scores, and blueprint selection mode. This post opens that system. +The payment lands as a cross-chain deposit. Before operators can claim anything, the Tangle protocol has to decide who gets what. An operator running a high-stakes Blueprint with a large staking pool behind it gets a different cut than one running the same Blueprint with minimal backing. The distribution is driven by exposure, USD-weighted delegation scores, and blueprint selection mode. This post opens that system. | Step | Contract or module | Decision being made | Why it matters | |---|---|---|---| @@ -53,13 +53,13 @@ function distributeServiceFee( nonReentrant ``` -Only the Tangle contract can call this — `msg.sender != tangle` reverts. The function handles both native ETH (`paymentToken == address(0)`) and ERC-20 tokens. For ERC-20, it expects no `msg.value`; for native, it requires `msg.value == amount`. This prevents a class of accounting bugs where msg.value doesn't match what the caller claimed to send. +Only the Tangle contract can call this, `msg.sender != tangle` reverts. The source describes both native ETH (`paymentToken == address(0)`) and ERC-20 tokens. For ERC-20, it expects no `msg.value`; for native, it requires `msg.value == amount`. This prevents a class of accounting bugs where msg.value doesn't match what the caller claimed to send. Source: [`tnt-core/src/rewards/ServiceFeeDistributor.sol`](https://github.com/tangle-network/tnt-core/blob/main/src/rewards/ServiceFeeDistributor.sol) ## Streaming vs immediate distribution -The first branch after validation isn't about who gets the fee — it's about *when* they get it. +The first branch after validation isn't about who gets the fee, it's about *when* they get it. ```solidity Types.Service memory svc = ITangleSecurityView(tangle).getService(serviceId); @@ -80,7 +80,7 @@ if (svc.ttl > 0 && address(streamingManager) != address(0)) { _distributeImmediate(serviceId, blueprintId, operator, paymentToken, amount); ``` -If the service has a TTL and `StreamingPaymentManager` is configured, the entire payment transfers to the streaming manager and gets distributed pro-rata over the service lifetime. If a delegation changes mid-service, the distributor drips the stream first — paying out at the current score ratios — then applies the delegation change. This prevents retroactive gaming: you can't bond more stake after a job runs and claim a larger slice of revenue that was already earned at lower backing levels. +If the service has a TTL and `StreamingPaymentManager` is configured, the entire payment transfers to the streaming manager and gets distributed pro-rata over the service lifetime. If a delegation changes mid-service, the distributor drips the stream first, paying out at the current score ratios, then applies the delegation change. This prevents retroactive gaming: you can't bond more stake after a job runs and claim a larger slice of revenue that was already earned at lower backing levels. For services without TTL (or if streaming isn't configured), distribution is immediate via `_distributeImmediate`. @@ -133,11 +133,11 @@ accAllPerScore[operator][assetHash][paymentToken] += (share * PRECISION) / allScore; ``` -This is O(1) per asset per payment token — no loop over delegators. Delegators claim by computing `score * accPerScore - debtAtLastSync`. A delegator who bonded after a fee was distributed has their debt initialized at the current accumulator level, so they only earn on fees distributed after they joined. +This is O(1) per asset per payment token; it does not loop over delegators. Delegators claim by computing `score * accPerScore - debtAtLastSync`. A delegator who bonded after a fee was distributed has their debt initialized at the current accumulator level, so they only earn on fees distributed after they joined. ## Exposure weighting: committed capital drives reward share -For services with `AssetSecurityRequirements`, the USD computation adds an exposure layer. Each operator declares how much of their delegation they're willing to have at risk for a service — `commitmentBps` — and the exposed amount drives both slashing and fee allocation. +For services with `AssetSecurityRequirements`, the USD computation adds an exposure layer. Each operator declares how much of their delegation they're willing to have at risk for a service, `commitmentBps`, and the exposed amount drives both slashing and fee allocation. ```solidity uint256 allExposed = (allEffective * commitmentBps) / BPS_DENOMINATOR; @@ -177,11 +177,11 @@ The distributor supports a configurable TNT token score rate: uint256 public tntScoreRate; ``` -When `tntScoreRate` is set above the oracle price of TNT, delegators backing operators with TNT earn amplified score per dollar of capital — a direct incentive to hold and stake the native token. At `tntScoreRate = 1e18` with TNT at $0.10 market price, TNT earns 10× the fee share of its market value relative to other tokens. +When `tntScoreRate` is set above the oracle price of TNT, delegators backing operators with TNT earn amplified score per dollar of capital, a direct incentive to hold and stake the native token. At `tntScoreRate = 1e18` with TNT at $0.10 market price, TNT earns 10× the fee share of its market value relative to other tokens. ## Treasury fallback -If an operator has zero stakers or zero USD-weighted score when a fee arrives, the fee doesn't sit in the contract — it routes to the protocol treasury: +If an operator has zero stakers or zero USD-weighted score when a fee arrives, the fee doesn't sit in the contract, it routes to the protocol treasury: ```solidity if (totalUsd == 0) { @@ -205,7 +205,7 @@ pub const X402_SERVICE_ID_KEY: &str = "X-TANGLE-SERVICE-ID"; pub const X402_CALL_ID_KEY: &str = "X-TANGLE-CALL-ID"; ``` -Every job that came from an x402 payment carries its quote digest, payment network (CAIP-2), token, service ID, and a synthetic call ID for tracking. This metadata is consumed by the runner, not by the distribution layer — but it's the operator's audit trail linking an HTTP payment to a specific on-chain service invocation. +Every job that came from an x402 payment carries its quote digest, payment network (CAIP-2), token, service ID, and a synthetic call ID for tracking. This metadata is consumed by the runner, not by the distribution layer, but it's the operator's audit trail linking an HTTP payment to a specific on-chain service invocation. Source: [`blueprint/crates/x402/src/producer.rs`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/producer.rs) @@ -223,13 +223,13 @@ Two items in the distribution system are architecturally present but not fully l uint256 allEffective = _applySlashFactor(allScore, _getAllSlashFactor(operator, assetHash)); ``` -The slashing mechanism in `ServiceFeeDistributor` is operational. What feeds those slash factors — the slashing protocol itself — depends on the staking and governance layer, which is out of scope here. +The slashing mechanism in `ServiceFeeDistributor` is operational. What feeds those slash factors, the slashing protocol itself, depends on the staking and governance layer, which is out of scope here. ## The economic signal in the design The fee distribution design encodes a specific opinion about what operators should optimize for: committed, long-duration, diversified backing. Operators with high USD-weighted exposure earn more per fee unit. Operators with mixed asset backing benefit from oracle normalization. Operators who attract All-mode delegators (stake that covers the full service roster) earn from a broader pool than operators whose delegators make narrow Fixed-mode bets. -The streaming payment design punishes late entry. Delegation after a service starts doesn't capture retroactive fees — drips happen at the score ratios that were in place at drip time. This is intended: an operator who can attract capital before a service launches is more valuable to the protocol than one who can attract it after the fact. +The streaming payment design punishes late entry. Delegation after a service starts doesn't capture retroactive fees, drips happen at the score ratios that were in place at drip time. This is intended: an operator who can attract capital before a service launches is more valuable to the protocol than one who can attract it after the fact. ## FAQ @@ -239,7 +239,7 @@ No. x402 proves and settles the client payment. The Tangle protocol distributes ### Why does Tangle weight rewards by USD exposure instead of token count? -Raw token counts are not comparable across assets. USD-weighted exposure lets ETH, stablecoin, TNT, and other accepted assets compete through a common value measure, then adjusts reward share by how much of that capital is actually committed to the service. +Raw token counts are not comparable across assets. USD-weighted exposure lets ETH, stablecoin, TNT, and other accepted assets compete through a common value measure, then adjusts reward share by how much of that capital is in practice committed to the service. ### Can a delegator bond after a job starts and capture the old fee? diff --git a/src/content/blog/browser-automation-ai-evidence-loop.mdx b/src/content/blog/browser-automation-ai-evidence-loop.mdx index bc3ff57..7533f69 100644 --- a/src/content/blog/browser-automation-ai-evidence-loop.mdx +++ b/src/content/blog/browser-automation-ai-evidence-loop.mdx @@ -11,9 +11,9 @@ tags: - ai-agents series: Browser Agent seriesOrder: 9 -coverImage: /images/products/browser-agent-app.png -heroImage: /images/products/browser-agent-app.png -imageAlt: 'Browser automation AI loop showing observe, act, verify, recover, and evidence viewer' +coverImage: /images/covers/editorial/browser-agent-v2.webp +heroImage: /images/covers/editorial/browser-agent-v2.webp +imageAlt: 'An editorial still life about an agent operating a web browser' --- Browser automation AI has one job: turn a user goal into browser actions that can be inspected. The hard part is not clicking. [WebDriver](https://www.w3.org/TR/webdriver2/) and [Playwright](https://playwright.dev/docs/intro) already made browser control programmable. The hard part is deciding what to do when the UI shifts, a modal appears, a wallet popup opens, or the final state is ambiguous. @@ -53,7 +53,7 @@ Most production apps need hybrid observation. The DOM gives precision. Screensho | action log | exact click/type/wait sequence | | reasoning notes | why the agent chose the next action | | selected element | whether the right control was used | -| final verifier | whether the user goal actually completed | +| final verifier | whether the user goal in practice completed | For the QA stack view, read [AI E2E Testing For Browser Flows](/blog/ai-e2e-testing-browser-agents). For natural-language case writing, read [Natural Language Test Automation That Leaves Proof](/blog/natural-language-test-automation-browser-agents). diff --git a/src/content/blog/browser-automation-for-ai-agents.mdx b/src/content/blog/browser-automation-for-ai-agents.mdx index 14ba8b6..e52d597 100644 --- a/src/content/blog/browser-automation-for-ai-agents.mdx +++ b/src/content/blog/browser-automation-for-ai-agents.mdx @@ -11,9 +11,9 @@ tags: - testing series: Agent Intent Infrastructure seriesOrder: 3 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Browser automation evidence panel with DOM, screenshots, traces, and stop conditions' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- Browser automation for AI agents is the practice of letting an agent operate a real browser while collecting enough evidence to verify what happened. The minimum useful loop is goal, page state, action, screenshot or DOM proof, recovery, and stop condition. Tangle Browser Agent packages that loop behind the `bad` CLI and SDK so teams can run natural-language browser tasks with evidence instead of hoping a model clicked the right button. Start with [Browser Agent](https://github.com/tangle-network/browser-agent-driver) when the browser is the work surface. @@ -22,13 +22,7 @@ The common failure is treating browser agents like a prettier wrapper around Pla ## Safe Discovery And Install -```bash -npm install -g @tangle-network/browser-agent-driver -npx playwright install chromium -bad --help -bad run --help -bad run --goal "Verify the pricing page loads and capture evidence" --url https://tangle.tools -``` +Start with the public Browser Agent manifest and documentation, then run one representative browser task. Keep screenshots, page state, actions, and the final outcome together. The [Browser Agent manifest](https://tangle.tools/.well-known/tangle-browser-agent.json) exposes the package, CLI binary, safe help commands, and example run. It also points to related Tangle surfaces: [Sandbox](https://github.com/tangle-network/tcloud) for machine runtime and Router for model selection. diff --git a/src/content/blog/building-ai-services-on-tangle.mdx b/src/content/blog/building-ai-services-on-tangle.mdx index f38316b..d70f6de 100644 --- a/src/content/blog/building-ai-services-on-tangle.mdx +++ b/src/content/blog/building-ai-services-on-tangle.mdx @@ -1,5 +1,5 @@ --- -title: 'Building AI Services on Tangle: Inference and Code Execution' +title: 'AI Agent Infrastructure on Tangle: Inference and Code Execution' slug: building-ai-services-on-tangle summary: >- A reader-first explanation of two common AI services on Tangle: running a model for a customer and running generated code inside a controlled environment. @@ -11,12 +11,12 @@ tags: - sdk series: Tangle Re-Introduction seriesOrder: 5 -coverImage: /images/covers/building-ai-services-on-tangle.png -heroImage: /images/covers/building-ai-services-on-tangle.png -imageAlt: 'An AI model and a code sandbox producing results with separate evidence records' +coverImage: /images/covers/editorial/tangle-reintroduction-v2.webp +heroImage: /images/covers/editorial/tangle-reintroduction-v2.webp +imageAlt: 'An editorial still life about building a service on Tangle' --- -An AI service can return a plausible answer while leaving the customer unable to tell what produced it. +AI agent infrastructure is the software that lets an agent call models, run code, and return a result someone else can inspect. This post shows how that path works on Tangle. An AI service can return a plausible answer while leaving the customer unable to tell what produced it. A code-execution service can return the right output while exposing the customer’s data or the machine owner’s system. On Tangle, a **Blueprint** is a public service definition that another team can run. diff --git a/src/content/blog/building-on-tangle-from-idea-to-production.mdx b/src/content/blog/building-on-tangle-from-idea-to-production.mdx index a31a1ab..fa984e5 100644 --- a/src/content/blog/building-on-tangle-from-idea-to-production.mdx +++ b/src/content/blog/building-on-tangle-from-idea-to-production.mdx @@ -13,15 +13,15 @@ tags: - developer-experience series: Tangle Re-Introduction seriesOrder: 4 -coverImage: /images/covers/building-on-tangle-from-idea-to-production.png -heroImage: /images/covers/building-on-tangle-from-idea-to-production.png -imageAlt: 'Tangle Blueprint path from a typed Rust job through local tests to deployment' +coverImage: /images/covers/editorial/tangle-reintroduction-v2.webp +heroImage: /images/covers/editorial/tangle-reintroduction-v2.webp +imageAlt: 'An editorial still life about building a service on Tangle' --- -A Tangle Blueprint is a Rust service package that defines jobs, their typed inputs and outputs, and how operators run those jobs for a network service. +An operator is the person or service responsible for running a job. A Tangle Blueprint is a Rust service package that defines jobs, their typed inputs and outputs, and how operators run those jobs for a network service. The shortest reliable path is to start from a maintained example, make one job pass against local Anvil contracts, and only then create a deployment definition for testnet. -This guide was checked on August 1, 2026 against Blueprint SDK commit [`00c3cae`](https://github.com/tangle-network/blueprint/tree/00c3cae14ade1bbaf8374934f7c5084cff0af866), including the current [`hello-tangle` example](https://github.com/tangle-network/blueprint/tree/00c3cae14ade1bbaf8374934f7c5084cff0af866/examples/hello-tangle). +This guide was checked on August 1, 2026 against Blueprint SDK commit [`00c3cae`](https://github.com/tangle-network/blueprint/tree/main), including the current [`hello-tangle` example](https://github.com/tangle-network/blueprint/tree/main/examples/hello-tangle). Use the linked release and source when commands change; older Blueprint tutorials may show job macros and deployment flows that no longer match the current SDK. ## Quick Answer @@ -44,7 +44,7 @@ Use a Blueprint when independent operators, on-chain service coordination, crypt | Good fit | Poor fit | | --- | --- | | Threshold signing or multi-party protocols | A conventional CRUD application | -| Paid compute run by independent operators | A sub-10ms request path | +| Paid compute run by independent operators | A request path with a stated sub-10ms limit | | Services that need on-chain job and result records | A private service that must stay on one company's infrastructure | | Agent-callable services with explicit payment and access rules | A frontend with no operator or protocol requirement | @@ -54,111 +54,11 @@ A distributed operator service adds contract state, keys, service registration, ## Start From a Maintained Example The current public repository includes examples for Tangle, EigenLayer, x402 payments, API-key access, and multi-operator aggregation. -For a first Tangle job, use [`examples/hello-tangle`](https://github.com/tangle-network/blueprint/tree/00c3cae14ade1bbaf8374934f7c5084cff0af866/examples/hello-tangle). +For a first Tangle job, use [`examples/hello-tangle`](https://github.com/tangle-network/blueprint/tree/main/examples/hello-tangle). Its local test command is: -```bash -git clone https://github.com/tangle-network/blueprint.git -cd blueprint -cargo test -p hello-tangle-blueprint --test anvil -- --nocapture -``` - -That test boots local Anvil contracts, starts the Blueprint runner, submits an ABI-encoded job, waits for the on-chain result event, decodes the output, and asserts its fields. -It is a more useful starting point than a function-only unit test because it crosses the contract, client, router, and runner boundaries used by the service. - -## Define a Typed Job - -The current example defines Solidity-compatible request and response types, then exposes an asynchronous Rust function: - -```rust -use alloy_sol_types::sol; -use blueprint_tangle_extra::extract::{Caller, TangleArg, TangleResult}; - -sol! { - struct DocumentRequest { - string docId; - string contents; - } - - struct DocumentReceipt { - string docId; - string contents; - string operator; - } -} - -pub async fn create_document( - Caller(caller): Caller, - TangleArg(request): TangleArg, -) -> TangleResult { - // Perform the service work, then return a typed result. - TangleResult(DocumentReceipt { - docId: request.docId, - contents: request.contents, - operator: format!("0x{}", hex::encode(caller)), - }) -} -``` - -The example's exact implementation and imports are the canonical reference. -The important design rule is that the job contract is explicit: the caller can encode the request, the operator can decode it, and the result can be checked without parsing prose. - -## Route the Job - -The router maps a stable job identifier to the function: - -```rust -use blueprint_router::Router; - -pub const CREATE_DOCUMENT_JOB: u8 = 0; - -pub fn router() -> Router { - Router::new().route(CREATE_DOCUMENT_JOB, create_document) -} -``` - -Treat job identifiers and input/output schemas as public API. -Changing them after deployment can break callers, operator binaries, or contract metadata even if the Rust project still compiles. - -## Test the Real Local Path - -A useful local test should prove more than “the handler returned `Ok`.” -The maintained `hello-tangle` test covers these steps: - -```text -boot local contracts --> start the Blueprint runner --> submit an encoded job through the client --> wait for the job result event --> decode the returned bytes --> assert the receipt fields --> stop the runner -``` - -Add failure cases before deployment: - -- malformed or oversized input; -- an unauthorized caller; -- a duplicate submission; -- operator restart during work; -- a timeout while waiting for the result; -- a result that cannot be decoded; -- contract or network configuration that points to the wrong deployment. - -For paid HTTP access, use the repository's [x402 example](https://github.com/tangle-network/blueprint/tree/00c3cae14ade1bbaf8374934f7c5084cff0af866/examples/x402-blueprint) and test payment replay, settlement failure, and job failure separately. - -## Scaffold With cargo-tangle - -The repository documents two installation paths for `cargo-tangle`: the release installer and a source build. -The source path is: - -```bash -cargo install cargo-tangle --git https://github.com/tangle-network/blueprint --force -cargo tangle blueprint create --name my_blueprint -cd my_blueprint -cargo build -``` +Start from the maintained example linked above and run its current test from the repository documentation. The useful artifact is a passing job receipt and decoded result, not a copied checkout transcript. Pin the release or source commit in CI rather than installing an unspecified future revision on every run. Record `cargo tangle --version`, the Blueprint SDK version, and the generated project commit with deployment evidence. @@ -190,7 +90,7 @@ The operator path also needs: - logs and health checks for the runner process; - a restart plan that does not lose durable work or payment state. -The current repository documents `cargo tangle blueprint register-tangle`, `preregister`, and `run` commands in its [main README](https://github.com/tangle-network/blueprint/blob/00c3cae14ade1bbaf8374934f7c5084cff0af866/README.md#getting-started). +The current repository documents `cargo tangle blueprint register-tangle`, `preregister`, and `run` commands in its [main README](https://github.com/tangle-network/blueprint/blob/main/README.md#getting-started). Copy the current flags from that source because contract addresses and CLI options are environment-specific. ## Production Proof diff --git a/src/content/blog/cfc-tax-filing-software-form-5471.mdx b/src/content/blog/cfc-tax-filing-software-form-5471.mdx index 4d5a982..d1331d9 100644 --- a/src/content/blog/cfc-tax-filing-software-form-5471.mdx +++ b/src/content/blog/cfc-tax-filing-software-form-5471.mdx @@ -11,9 +11,9 @@ tags: - form-5471 series: Building an AI Tax Agent seriesOrder: 6 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing CFC ownership facts, Form 5471 schedules, source documents, and review questions' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- CFC tax filing software has to do more than ask whether you own a foreign company. The hard part is organizing ownership, officer or director status, foreign corporation records, schedules, income groups, taxes paid, related-party transactions, and unanswered review questions. The IRS Form 5471 page says certain U.S. citizens and residents who are officers, directors, or shareholders in certain foreign corporations file [Form 5471](https://www.irs.gov/forms-pubs/about-form-5471). That is a high-risk enough area that software should slow down and show its work. diff --git a/src/content/blog/codetracebench-benchmark-measured-wrong-capability.mdx b/src/content/blog/codetracebench-benchmark-measured-wrong-capability.mdx index 6713147..a5cbc86 100644 --- a/src/content/blog/codetracebench-benchmark-measured-wrong-capability.mdx +++ b/src/content/blog/codetracebench-benchmark-measured-wrong-capability.mdx @@ -1,5 +1,5 @@ --- -title: 'CodeTraceBench: A Correct Score Can Still Measure the Wrong Thing' +title: 'AI Coding Agent Benchmark: What CodeTraceBench Measures' slug: codetracebench-benchmark-measured-wrong-capability summary: >- CodeTraceBench gave a recursive trace analyst and a one-shot analyst nearly the same score, while the recursive run cost 5.57 times more. @@ -12,9 +12,9 @@ tags: - traces series: The Instrument Problem seriesOrder: 1 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'A trace benchmark comparing recursive and one-shot agent analysis' +coverImage: /images/covers/editorial/instrument-problem-v2.webp +heroImage: /images/covers/editorial/instrument-problem-v2.webp +imageAlt: 'An editorial still life about measuring an agent system' --- Imagine asking an AI agent to review a coding session and point to the step where the agent went wrong. diff --git a/src/content/blog/complex-tax-situations-software-founder-returns.mdx b/src/content/blog/complex-tax-situations-software-founder-returns.mdx index 337eac0..44606cd 100644 --- a/src/content/blog/complex-tax-situations-software-founder-returns.mdx +++ b/src/content/blog/complex-tax-situations-software-founder-returns.mdx @@ -11,9 +11,9 @@ tags: - founders series: Building an AI Tax Agent seriesOrder: 8 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing founder tax documents, entity records, crypto activity, K-1s, and review packet' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- Complex tax situations software should not act like a longer W-2 questionnaire. A founder return may combine salary, S corp income, partnership K-1s, foreign subsidiaries, crypto transactions, stock compensation, estimated payments, and state allocation. The software has to connect facts across documents and show the review packet before anything is filed. @@ -86,7 +86,7 @@ Founder returns should route facts by risk. That routing lets the agent move quickly on routine facts while slowing down on foreign reporting, entity basis, or uncertain tax positions. It also gives the taxpayer a clearer reason when the system asks for professional review. -The founder should see the route, not only the final return. A useful dashboard can label facts as accepted, needs taxpayer answer, needs advisor review, or blocked by missing source. That keeps the workflow from feeling like a black box and prevents the agent from turning uncertainty into false confidence. +The founder should see the route as well as the final return. A useful dashboard can label facts as accepted, needs taxpayer answer, needs advisor review, or blocked by missing source. That keeps the workflow from feeling like a black box and prevents the agent from turning uncertainty into false confidence. The product should preserve that status through filing. A founder may resolve one item today and receive a corrected K-1 next week. The workflow needs versioned drafts, not one final answer that erases how the return changed. diff --git a/src/content/blog/controlled-foreign-corporation-taxes-form-5471.mdx b/src/content/blog/controlled-foreign-corporation-taxes-form-5471.mdx index 852db06..d06490f 100644 --- a/src/content/blog/controlled-foreign-corporation-taxes-form-5471.mdx +++ b/src/content/blog/controlled-foreign-corporation-taxes-form-5471.mdx @@ -11,9 +11,9 @@ tags: - form-5471 series: Building an AI Tax Agent seriesOrder: 10 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing controlled foreign corporation reporting, Form 5471 schedules, and foreign financial records' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- Controlled foreign corporation taxes are hard because the filing question starts with facts the taxpayer may not have organized: ownership percentages, role, foreign corporation financials, earnings, taxes, distributions, related-party transactions, and prior-year records. The IRS Form 5471 page says certain U.S. citizens and residents with officer, director, or shareholder roles in certain foreign corporations file [Form 5471](https://www.irs.gov/forms-pubs/about-form-5471). The form also has schedules for CFC income groups, taxes paid, E&P, transactions, and other facts. diff --git a/src/content/blog/crypto-hackathon-platform-code-verified-builds.mdx b/src/content/blog/crypto-hackathon-platform-code-verified-builds.mdx index 992adba..c8d3f5b 100644 --- a/src/content/blog/crypto-hackathon-platform-code-verified-builds.mdx +++ b/src/content/blog/crypto-hackathon-platform-code-verified-builds.mdx @@ -11,12 +11,12 @@ tags: - web3-developer-tools series: Blueprint Agent seriesOrder: 4 -coverImage: /images/products/blueprint-agent-live.png -heroImage: /images/products/blueprint-agent-live.png -imageAlt: 'Crypto hackathon builder workspace with quest checks, code editor, and submission evidence' +coverImage: /images/covers/editorial/blueprint-agent-v2.webp +heroImage: /images/covers/editorial/blueprint-agent-v2.webp +imageAlt: 'An editorial still life about a runnable service blueprint' --- -A crypto hackathon platform should reduce the gap between "builder showed up" and "builder shipped something that works." Too many hackathons collect pitch decks, tweets, wallet addresses, and demo videos while the actual integration is hard to inspect. A stronger platform gives builders a prepared workspace and gives judges code evidence. +A blueprint is a packaged service definition with a typed job interface. A trace is the record of an agent run, including its actions and results. A crypto hackathon platform should reduce the gap between "builder showed up" and "builder shipped something that works." Too many hackathons collect pitch decks, tweets, wallet addresses, and demo videos while the actual integration is hard to inspect. A stronger platform gives builders a prepared workspace and gives judges code evidence. Tangle Blueprint Agent fits hackathons where the sponsor wants real integrations with an SDK, protocol, API, or app surface. @@ -67,7 +67,7 @@ Each submission should produce the same packet so judges can compare teams witho | Packet item | Judge value | | --- | --- | | goal statement | what the team attempted | -| changed files | what was actually built | +| changed files | what was built | | build log | whether the project runs | | quest results | sponsor tasks completed | | browser or wallet trace | user-facing flow evidence | diff --git a/src/content/blog/crypto-tax-software-2026-defi-staking-wallets.mdx b/src/content/blog/crypto-tax-software-2026-defi-staking-wallets.mdx index aeb418f..b367d93 100644 --- a/src/content/blog/crypto-tax-software-2026-defi-staking-wallets.mdx +++ b/src/content/blog/crypto-tax-software-2026-defi-staking-wallets.mdx @@ -11,18 +11,18 @@ tags: - ai-tax series: Building an AI Tax Agent seriesOrder: 3 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace reviewing crypto tax transactions, wallets, and filing package' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- -Crypto tax software in 2026 has to handle more than exchange CSV imports. A useful system needs wallet matching, DeFi event review, staking income treatment, transfer detection, unknown-basis handling, and a Form 8949 package the taxpayer can inspect. The IRS treats digital assets as a reporting category, not a separate life. Tangle Tax Agent should connect crypto activity to the rest of the return instead of treating wallet exports as an isolated spreadsheet. +A bridge is a connector that moves data or messages between two systems. Crypto tax software in 2026 has to handle more than exchange CSV imports. A useful system needs wallet matching, DeFi event review, staking income treatment, transfer detection, unknown-basis handling, and a Form 8949 package the taxpayer can inspect. The IRS treats digital assets as a reporting category, not a separate life. Tangle Tax Agent should connect crypto activity to the rest of the return instead of treating wallet exports as an isolated spreadsheet. This is not tax advice. Crypto tax facts can be ambiguous, especially around basis, DeFi events, bridge transfers, staking, and missing wallet history. ## The Core Reporting Surface -The IRS digital asset page explains that taxpayers may need to answer the digital asset question and report digital asset income or gains. Sales and exchanges generally flow through [Form 8949](https://www.irs.gov/forms-pubs/about-form-8949) and [Schedule D](https://www.irs.gov/forms-pubs/about-schedule-d-form-1040). Digital asset broker reporting is also evolving through [Form 1099-DA](https://www.irs.gov/forms-pubs/about-form-1099-da). +The IRS digital asset page explains that taxpayers may need to answer the digital asset question and report digital asset income or gains. Sales and exchanges usually flow through [Form 8949](https://www.irs.gov/forms-pubs/about-form-8949) and [Schedule D](https://www.irs.gov/forms-pubs/about-schedule-d-form-1040). Digital asset broker reporting is also evolving through [Form 1099-DA](https://www.irs.gov/forms-pubs/about-form-1099-da). Software should not hide those mechanics. It should show how transactions become return lines. diff --git a/src/content/blog/decentralized-compute-protocol-blueprints.mdx b/src/content/blog/decentralized-compute-protocol-blueprints.mdx index 397a7dc..ad1197f 100644 --- a/src/content/blog/decentralized-compute-protocol-blueprints.mdx +++ b/src/content/blog/decentralized-compute-protocol-blueprints.mdx @@ -11,12 +11,12 @@ tags: - blueprints series: Tangle Protocol seriesOrder: 8 -coverImage: /images/covers/how-blueprints-work.png -heroImage: /images/covers/how-blueprints-work.png -imageAlt: 'Tangle protocol diagram showing Blueprints, operators, service instances, jobs, payments, and verification' +coverImage: /images/covers/editorial/protocol-operators-v2.webp +heroImage: /images/covers/editorial/protocol-operators-v2.webp +imageAlt: 'An editorial still life about operators running services on a network' --- -A decentralized compute protocol is not useful because compute is abstractly decentralized. It is useful when users can request services, operators can run them, payments can clear, and evidence can be checked. Tangle's protocol model centers this around Blueprints: reusable service definitions that operators can register for and run. +A blueprint is a packaged service definition with a typed job interface. A decentralized compute protocol is not useful because compute is abstractly decentralized. It is useful when users can request services, operators can run them, payments can clear, and evidence can be checked. Tangle's protocol model centers this around Blueprints: reusable service definitions that operators can register for and run. For the base concept, read [How Blueprints Work](/blog/how-blueprints-work). For deployment, read [Blueprint SDK Deployment Guide](/blog/blueprint-sdk-deployment-guide). diff --git a/src/content/blog/decentralizing-x402-facilitator.mdx b/src/content/blog/decentralizing-x402-facilitator.mdx index c93aa4a..e4ded82 100644 --- a/src/content/blog/decentralizing-x402-facilitator.mdx +++ b/src/content/blog/decentralizing-x402-facilitator.mdx @@ -14,12 +14,12 @@ tags: - infrastructure series: x402 Production Runway seriesOrder: 2 -coverImage: /images/covers/how-blueprints-work.png -heroImage: /images/covers/how-blueprints-work.png -imageAlt: 'x402 facilitator between a client, resource server, and blockchain settlement' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -An x402 facilitator is optional infrastructure that verifies signed payment payloads and submits settlement transactions for a resource server. +A blueprint is a packaged service definition with a typed job interface. An x402 facilitator is optional infrastructure that verifies signed payment payloads and submits settlement transactions for a resource server. It cannot rewrite a buyer's signed payment without invalidating the signature, but it can still reject requests, go offline, apply policy, observe payment metadata, or delay settlement. The practical decision is therefore not “trust the facilitator or trust math.” It is whether to outsource availability, gas sponsorship, network access, and compliance checks to a hosted service or operate those responsibilities yourself. diff --git a/src/content/blog/defi-wallet-testing-browser-agent.mdx b/src/content/blog/defi-wallet-testing-browser-agent.mdx index de0d279..c0af38a 100644 --- a/src/content/blog/defi-wallet-testing-browser-agent.mdx +++ b/src/content/blog/defi-wallet-testing-browser-agent.mdx @@ -11,9 +11,9 @@ tags: - wallet-testing series: Browser Agent seriesOrder: 7 -coverImage: /images/products/browser-agent-app.png -heroImage: /images/products/browser-agent-app.png -imageAlt: 'Browser agent testing a DeFi wallet flow with extension popup and transaction evidence' +coverImage: /images/covers/editorial/browser-agent-v2.webp +heroImage: /images/covers/editorial/browser-agent-v2.webp +imageAlt: 'An editorial still life about an agent operating a web browser' --- DeFi wallet testing is painful because the important state is split between the web app, the wallet extension, the chain, and the user's signature intent. A normal browser script can click through the page and still miss the wallet prompt that matters. A browser agent has to cross that boundary and keep evidence from both sides. @@ -31,16 +31,11 @@ Tangle Browser Agent is built for these flows: connect wallet, switch network, s | swap or supply | token, amount, route, gas, confirmation state | | failure path | rejected signature, insufficient balance, wrong network | -Wallet integrations often use the provider pattern described by [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193). Typed signing commonly uses [EIP-712](https://eips.ethereum.org/EIPS/eip-712). Test evidence should show what the user was asked to approve, not only the app's post-click state. +Wallet integrations often use the provider pattern described by [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193). Typed signing commonly uses [EIP-712](https://eips.ethereum.org/EIPS/eip-712). Test evidence should show what the user was asked to approve alongside the app's post-click state. ## Agent Run Pattern -```bash -pnpm wallet:setup -pnpm wallet:onboard -pnpm wallet:anvil -pnpm wallet:validate -``` +Run the wallet flow in an isolated test environment and save the app state, wallet prompt, and final transaction result. The test plan matters more than a shell recipe. Then run a browser goal: @@ -64,7 +59,7 @@ Transaction safety is visual and contextual. The wallet prompt is where the user | hidden rejection | wallet rejection screen and app error state | | stale balance | balance before and after the transaction | -The public [MetaMask developer docs](https://docs.metamask.io/metamask-connect/) are a useful baseline for wallet connection behavior. Your test artifacts should show how your app actually presents that behavior. +The public [MetaMask developer docs](https://docs.metamask.io/metamask-connect/) are a useful baseline for wallet connection behavior. Your test artifacts should show how your app in practice presents that behavior. ## Wallet State Matrix @@ -73,7 +68,7 @@ Test more than the happy path. | State | Expected behavior | | --- | --- | | no wallet installed | app explains supported wallets | -| wallet locked | app waits or prompts user to unlock | +| wallet locked | app waits or prompts user to enable | | wrong network | app requests switch or blocks action | | empty balance | app blocks submit before gas failure | | rejected signature | app recovers without corrupting state | diff --git a/src/content/blog/deploy-paid-ai-agent-service.mdx b/src/content/blog/deploy-paid-ai-agent-service.mdx index 0f81609..df4fca7 100644 --- a/src/content/blog/deploy-paid-ai-agent-service.mdx +++ b/src/content/blog/deploy-paid-ai-agent-service.mdx @@ -11,9 +11,9 @@ tags: - x402 series: Agent Intent Infrastructure seriesOrder: 11 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'A paid agent request moving from discovery through payment, execution, and evidence' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- A paid AI service has two promises to keep. diff --git a/src/content/blog/developer-onboarding-platform-code-verified-quests.mdx b/src/content/blog/developer-onboarding-platform-code-verified-quests.mdx index c851231..a8907b1 100644 --- a/src/content/blog/developer-onboarding-platform-code-verified-quests.mdx +++ b/src/content/blog/developer-onboarding-platform-code-verified-quests.mdx @@ -11,12 +11,12 @@ tags: - devrel series: Blueprint Agent seriesOrder: 3 -coverImage: /images/products/blueprint-agent-workbench.png -heroImage: /images/products/blueprint-agent-workbench.png -imageAlt: 'Developer onboarding workspace with project scaffold, docs, quest checklist, and verification results' +coverImage: /images/covers/editorial/blueprint-agent-v2.webp +heroImage: /images/covers/editorial/blueprint-agent-v2.webp +imageAlt: 'An editorial still life about a runnable service blueprint' --- -A developer onboarding platform has one job: help a developer build the first real integration and prove it works. Most onboarding tools measure weaker signals: page views, signups, wallet connects, form submissions, or community joins. Those numbers can be useful, but they do not prove the developer can use the product. +A trace is the record of an agent run, including its actions and results. A developer onboarding platform has one job: help a developer build the first real integration and prove it works. Most onboarding tools measure weaker signals: page views, signups, wallet connects, form submissions, or community joins. Those numbers can be useful, but they do not prove the developer can use the product. Tangle Blueprint Agent is built around code-verified onboarding. A partner publishes a project Blueprint, wires docs and tasks into the workspace, and verifies progress through code checks. diff --git a/src/content/blog/developer-quest-platform-code-verification.mdx b/src/content/blog/developer-quest-platform-code-verification.mdx index 1f01cc4..a235d56 100644 --- a/src/content/blog/developer-quest-platform-code-verification.mdx +++ b/src/content/blog/developer-quest-platform-code-verification.mdx @@ -11,12 +11,12 @@ tags: - devrel series: Blueprint Agent seriesOrder: 5 -coverImage: /images/products/blueprint-agent-workbench.png -heroImage: /images/products/blueprint-agent-workbench.png -imageAlt: 'Developer quest platform showing code tasks, verification output, and session evidence' +coverImage: /images/covers/editorial/blueprint-agent-v2.webp +heroImage: /images/covers/editorial/blueprint-agent-v2.webp +imageAlt: 'An editorial still life about a runnable service blueprint' --- -A developer quest platform should answer one question: did the developer build the thing? Many quest systems reward easier tasks such as following an account, joining a server, connecting a wallet, or submitting a screenshot. Those may grow a list. They do not prove technical activation. +A blueprint is a packaged service definition with a typed job interface. A trace is the record of an agent run, including its actions and results. A developer quest platform should answer one question: did the developer build the thing? Many quest systems reward easier tasks such as following an account, joining a server, connecting a wallet, or submitting a screenshot. Those may grow a list. They do not prove technical activation. Tangle Blueprint Agent treats quests as code-verified tasks inside an agent-assisted workspace. diff --git a/src/content/blog/distributed-training-demo.mdx b/src/content/blog/distributed-training-demo.mdx index a20196e..d768ce4 100644 --- a/src/content/blog/distributed-training-demo.mdx +++ b/src/content/blog/distributed-training-demo.mdx @@ -11,6 +11,9 @@ tags: - blueprints - training - research +coverImage: /images/covers/editorial/distributed-training-v2.webp +heroImage: /images/covers/editorial/distributed-training-v2.webp +imageAlt: 'An editorial still life about compressing distributed training updates' --- Distributed training over the open internet usually dies at the sync step. The model can fit on GPUs, the data can be sharded, and the operators can be paid, but the network still has to move training state between machines that do not sit inside one data center. That is the pressure behind DeMo, Decoupled Momentum Optimization: reduce the communication payload enough that permissionless operators can coordinate without pretending they are one tightly coupled cluster. @@ -19,9 +22,9 @@ Tangle's [Training Blueprint](https://github.com/tangle-network/training-bluepri ## The Claim -The 10,000x claim is about communication volume, not magic training quality. A naive distributed optimizer can require gigabytes of gradient synchronization per step for a large model. DeMo compresses the communication path by synchronizing sparse transformed momentum. The common shorthand is roughly 10GB down to roughly 100KB per synchronization, depending on model, optimizer state, sparsity, and implementation. +The reported 10,000x claim is about communication volume, not magic training quality. A naive distributed optimizer can require gigabytes of gradient synchronization per step for a large model. DeMo compresses the communication path by synchronizing sparse transformed momentum. The common shorthand is roughly 10GB down to roughly 100KB per synchronization, depending on model, optimizer state, sparsity, and implementation. -That distinction matters. If someone reads "10,000x" as "training is 10,000x cheaper" or "models are 10,000x better," they are reading the wrong claim. +That distinction matters. If someone reads "the reported 10,000x figure" as "training is 10,000x cheaper" or "models are 10,000x better," they are reading the wrong claim. | Claim | Supported by the DeMo framing? | | --- | --- | @@ -46,93 +49,13 @@ The normal failure mode is that every worker needs to synchronize too much state The shape is easier to reason about as an artifact pipeline: -```text -local shard -> local optimizer step -> momentum buffer -momentum buffer -> transform -> sparse coefficients -sparse coefficients -> gossip -> aggregate -> checkpoint -checkpoint -> hash, metadata, operator evidence -``` - -The hard engineering problem moves from "can we move all gradients?" to "can we coordinate compressed updates, detect bad participants, and produce checkpoints callers trust?" - -## Where Tangle Fits - -Tangle does not make the optimizer converge by itself. Tangle supplies the service layer around the optimizer: - -| Layer | Tangle responsibility | -| --- | --- | -| Blueprint definition | job interface, runtime requirements, operator configuration | -| operator coordination | join boundaries, job assignment, health, failures | -| economics | payment, fee routing, stake, penalties | -| evidence | checkpoint hashes, logs, attestation metadata, run records | -| downstream use | serve the checkpoint through inference Blueprints or Router | - -That is the reason a Training Blueprint matters. Research code can show a method. A Blueprint has to make the method callable, priced, observable, and accountable. - -## Operator Requirements - -An operator should not join a distributed training Blueprint because the headline sounds good. They need to know whether they can run the job without harming the group. - -| Requirement | Why it matters | -| --- | --- | -| GPU memory and compute | determines model size and batch shape | -| stable networking | synchronization delays affect everyone | -| storage | checkpoints and dataset shards are not tiny | -| reproducible environment | bad local dependencies become bad checkpoints | -| identity and stake | penalties need an accountable party | -| logs and metrics | callers need to debug stalled epochs | - -For broader operator mechanics, read [Blueprint Protocol for Operator-Run Services](/blog/blueprint-protocol-operator-services) and [Operator Health Monitoring for Tangle](/blog/operator-health-monitoring-tangle-heartbeats-quote-lifetimes). - -## Verification Boundary - -Training verification is not one proof. There are several things to check: - -| Evidence | Question answered | -| --- | --- | -| dataset shard receipt | did the operator receive the assigned work? | -| sync participation | did it submit updates at the boundary? | -| checkpoint hash | what artifact was produced? | -| TEE attestation, when used | did expected code run inside the expected boundary? | -| eval result | did the checkpoint improve the target metric? | - -The checkpoint hash is not the same as model quality. TEE attestation is not the same as convergence. An eval passing once is not the same as no overfitting. The Blueprint needs to keep those evidence types separate. - -## Pipeline After Training - -The point of training is not a checkpoint sitting in storage. A useful pipeline turns the checkpoint into a service: - -```text -Training Blueprint - -> checkpoint artifact - -> evaluation gate - -> LLM Inference Blueprint - -> Tangle Router - -> paid requests, traces, and operator revenue -``` - -That is where Tangle's service graph starts to matter. A model trained through one Blueprint can be served through another, routed through [Tangle Router](https://router.tangle.tools), and used by agent products that pay per request. - -## What This Does Not Prove - -This post does not prove every permissionless training job will converge. It does not prove 10,000x lower communication always means lower total cost. It does not prove Tangle has solved dataset quality, adversarial workers, or evaluation capture for every training workload. - -It proves a narrower direction: if compressed synchronization makes open-network training viable, optimizer code is only one piece. The missing layer is an operator-run service with payment, evidence, health checks, and verification. - -## Start - -Read the method, then inspect the Blueprint: - -```bash -git clone https://github.com/tangle-network/training-blueprint -git clone https://github.com/tangle-network/blueprint -``` +The maintained training repositories linked above contain the runnable examples. Before treating the result as a product, record the model, dataset, compression settings, checkpoint, and evaluation result. Before running or calling a training job, identify the model size, dataset, sync interval, compression settings, operator requirements, checkpoint format, eval gate, and payment policy. ## FAQ -### What does 10,000x communication reduction mean? +### What does the reported 10,000x communication reduction mean? It refers to reducing synchronization payloads, for example from full-gradient-scale transfers to sparse compressed momentum updates. It is a bandwidth claim, not a universal cost or quality claim. diff --git a/src/content/blog/how-ai-agents-discover-products.mdx b/src/content/blog/how-ai-agents-discover-products.mdx index 0d9df24..1f63f0c 100644 --- a/src/content/blog/how-ai-agents-discover-products.mdx +++ b/src/content/blog/how-ai-agents-discover-products.mdx @@ -11,12 +11,12 @@ tags: - discovery series: Agent Intent Infrastructure seriesOrder: 1 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Agent discovery map showing llms.txt, manifests, OpenAPI, packages, health checks, and runtime surfaces' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- -AI agents discover products by reading the same durable surfaces a careful engineer would check first: `/llms.txt`, `/.well-known/*` manifests, OpenAPI files, scoped package metadata, health endpoints, and README install blocks. For Tangle, the safe path is explicit: start at [llms.txt](https://tangle.tools/llms.txt), read the product manifest, use scoped packages only, then run a non-mutating smoke call before generating integration code. That is agent SEO: not keyword stuffing, but making the product easy for a coding agent to verify without guessing. +A blueprint is a packaged service definition with a typed job interface. AI agents discover products by reading the same durable surfaces a careful engineer would check first: `/llms.txt`, `/.well-known/*` manifests, OpenAPI files, scoped package metadata, health endpoints, and README install blocks. For Tangle, the safe path is explicit: start at [llms.txt](https://tangle.tools/llms.txt), read the product manifest, use scoped packages only, then run a non-mutating smoke call before generating integration code. That is agent SEO: not keyword stuffing, but making the product easy for a coding agent to verify without guessing. The mistake is treating agents like search crawlers with a different user agent. A search crawler can rank a page from prose. A coding agent has to decide whether it can call an API, install a package, route a model request, or launch a sandbox without breaking the user's environment. @@ -38,14 +38,7 @@ For Tangle, that means linking the same surfaces from docs, blog posts, package Agents should start with read-only checks: -```bash -curl -fsS https://tangle.tools/llms.txt -curl -fsS https://tangle.tools/.well-known/tangle-agent.json -curl -fsS https://router.tangle.tools/.well-known/tangle-agent.json -curl -fsS https://router.tangle.tools/v1/models -curl -fsS https://sandbox.tangle.tools/health -curl -fsS https://tangle.tools/.well-known/tangle-browser-agent.json -``` +Begin with the public discovery documents linked below. A machine-readable manifest, an API description, and a health result give an agent enough information to decide whether to continue. The root `llms.txt` tells agents not to install unscoped packages named `tcloud` or `bad`. It points to `@tangle-network/tcloud`, `@tangle-network/sandbox`, and `@tangle-network/browser-agent-driver`. That small instruction prevents a real class of agent mistakes: installing the wrong package because a short binary name looked plausible. @@ -53,13 +46,13 @@ The root `llms.txt` tells agents not to install unscoped packages named `tcloud` Use `llms.txt` for human-readable routing. Use manifests for machine-readable product contracts. Use OpenAPI for request and response structure. Use package metadata for install commands. Use health endpoints for current liveness. -This is not only a Tangle convention. The same pattern lines up with the [llms.txt proposal](https://llmstxt.org/), the [OpenAPI specification](https://spec.openapis.org/oas/latest.html), npm package metadata and README conventions in the [npm docs](https://docs.npmjs.com/cli/v11/commands/npm-view), and the well-known URI pattern in [RFC 8615](https://www.rfc-editor.org/rfc/rfc8615). +This pattern is used beyond Tangle. The same pattern lines up with the [llms.txt proposal](https://llmstxt.org/), the [OpenAPI specification](https://spec.openapis.org/oas/latest.html), npm package metadata and README conventions in the [npm docs](https://docs.npmjs.com/cli/v11/commands/npm-view), and the well-known URI pattern in [RFC 8615](https://www.rfc-editor.org/rfc/rfc8615). ## Decision Test Ask a coding agent to integrate the product from a clean repo and watch the first five actions. If it guesses package names, invents endpoints, or writes authenticated code before a health check, the discovery surface is weak. If it reads `llms.txt`, opens a manifest, checks OpenAPI, installs a scoped package, and runs a safe call, the surface is doing real work. -The highest-leverage edits are usually boring: +The highest-use edits are usually boring: | Weak surface | Better surface | | --- | --- | diff --git a/src/content/blog/how-blueprints-work.mdx b/src/content/blog/how-blueprints-work.mdx index 78af418..17d1649 100644 --- a/src/content/blog/how-blueprints-work.mdx +++ b/src/content/blog/how-blueprints-work.mdx @@ -12,12 +12,12 @@ tags: - sdk series: Tangle Re-Introduction seriesOrder: 2 -coverImage: /images/covers/how-blueprints-work.png -heroImage: /images/covers/how-blueprints-work.png -imageAlt: 'How Blueprints Work: The Building Blocks of Decentralized Services' +coverImage: /images/covers/editorial/tangle-reintroduction-v2.webp +heroImage: /images/covers/editorial/tangle-reintroduction-v2.webp +imageAlt: 'An editorial still life about building a service on Tangle' --- -*Day 2 of the Tangle Re-Introduction Series* +x402 is a payment protocol for machine-to-machine requests. *Day 2 of the Tangle Re-Introduction Series* --- @@ -25,7 +25,7 @@ Last month, an AI agent built on OpenClaw autonomously paid for its own GPU infe This is what agent commerce looks like in 2026. But it raises a question the payment rails alone cannot answer: how does the agent know it got what it paid for? -The x402 protocol handles the payment. Coinbase and Cloudflare built it specifically for machine-to-machine transactions: agents paying for APIs, compute, data, other agents. But payment is only half the problem. The other half is execution. Did the compute actually happen? Did the provider run the model they claimed to run? If the output is wrong, what recourse does the agent have? +The x402 protocol handles the payment. Coinbase and Cloudflare built it specifically for machine-to-machine transactions: agents paying for APIs, compute, data, other agents. But payment is only half the problem. The other half is execution. Did the compute in practice happen? Did the provider run the model they claimed to run? If the output is wrong, what recourse does the agent have? This is where Tangle's blueprints come in. They provide the execution layer that x402 payments pay for, with built-in [verification](/blog/how-tangle-verifies-work) and economic consequences for misbehavior. @@ -56,13 +56,13 @@ Blockchains provide three things traditional infrastructure cannot: The blockchain isn't here because it's trendy. It's here because it solves coordination problems that traditional mechanisms cannot solve at the speed and scale agents require. -## What a Blueprint Actually Is +## What a Blueprint Is A blueprint is a template that defines a type of service: what computation it performs, how operators register, how jobs get verified, and what triggers slashing. When someone uses a blueprint, they're not trusting a provider's promises. They're relying on code that executes automatically, backed by economic stakes that make cheating unprofitable. -Here's what a blueprint specifies: +A blueprint specifies: **The service logic.** The actual computation, whether that's AI inference, cryptographic signing, code execution, or anything else. This runs on operator hardware, off-chain. @@ -169,11 +169,11 @@ This is better than the status quo, where you pay a provider, hope they run what Tangle's blueprint system and the x402 protocol solve complementary problems. Together they form a complete stack for autonomous agent commerce. -**x402 handles the payment.** An agent discovers a service, negotiates price, and pays in stablecoins over HTTP. The protocol is lightweight: an HTTP 402 response contains payment requirements, the agent pays, the service unlocks. No API keys, no accounts, no billing systems. +**x402 handles the payment.** An agent discovers a service, negotiates price, and pays in stablecoins over HTTP. The protocol is lightweight: an HTTP 402 response contains payment requirements, the agent pays, the service enables. No API keys, no accounts, no billing systems. **Tangle handles the execution.** The service runs on operator infrastructure with stake at risk. Verification hooks check that the work was done correctly. If it wasn't, slashing happens automatically. -**The combination is powerful.** An agent can autonomously find compute providers, pay for services, and have cryptographic guarantees that it got what it paid for. All at machine speed, with no human intervention. +**The combination is useful.** An agent can autonomously find compute providers, pay for services, and have cryptographic guarantees that it got what it paid for. All at machine speed, with no human intervention. This extends naturally to agent-to-agent transactions. One agent running on Tangle infrastructure can pay another agent for services, with both sides having economic guarantees on their respective contributions. diff --git a/src/content/blog/how-tangle-verifies-work.mdx b/src/content/blog/how-tangle-verifies-work.mdx index 3346f6b..3407947 100644 --- a/src/content/blog/how-tangle-verifies-work.mdx +++ b/src/content/blog/how-tangle-verifies-work.mdx @@ -1,5 +1,5 @@ --- -title: How Tangle Verifies Work +title: How Decentralized AI Infrastructure Verifies Work slug: how-tangle-verifies-work summary: >- Tangle supports multiple verification strategies - from optimistic challenges @@ -12,18 +12,18 @@ tags: - security series: Tangle Re-Introduction seriesOrder: 3 -coverImage: /images/covers/how-tangle-verifies-work.png -heroImage: /images/covers/how-tangle-verifies-work.png -imageAlt: How Tangle Verifies Work +coverImage: /images/covers/editorial/tangle-reintroduction-v2.webp +heroImage: /images/covers/editorial/tangle-reintroduction-v2.webp +imageAlt: 'An editorial still life about building a service on Tangle' --- -*Day 3 of the Tangle Re-Introduction Series* +A blueprint is a packaged service definition with a typed job interface. *Day 3 of the Tangle Re-Introduction Series* --- The hardest question in decentralized infrastructure isn't "how do we run computation" but "how do we know computation ran correctly." -This post covers what each verification mechanism actually proves, where it breaks down, and how Tangle lets developers wire it all together. +This post covers what each verification mechanism in practice proves, where it breaks down, and how Tangle lets developers wire it all together. ## Where Cloud Providers Stop @@ -99,7 +99,7 @@ The simplest verification: have multiple independent parties run the same comput **What it proves:** At least one honest operator computed correctly (if results match). Collusion requires controlling multiple independent operators. Disagreement is always detectable. -**What it doesn't prove:** Correctness for non-deterministic computation. Which party is correct during disputes. And it's expensive: running computation 3x costs 3x. +**What it doesn't prove:** Correctness for non-deterministic computation. Which party is correct during disputes. The reported cost model is simple: running computation 3x costs 3x. ## Optimistic Verification with Fraud Proofs @@ -113,13 +113,13 @@ Assume execution is correct, but allow challenges. One operator executes and com **MPC** splits data into shares distributed across parties so they can jointly compute without revealing inputs to each other. No single party learns the inputs (if the corruption threshold holds), but it adds significant overhead and is practical only for high-value computations like key management and threshold signatures. -**ZK proofs** let a prover demonstrate computation correctness without revealing inputs. Verification is trustless and cryptographically sound. The catch: proof generation is orders of magnitude slower than direct computation, and some ZK systems (Groth16, older PLONK variants) require a trusted setup ceremony. Transparent alternatives (STARKs) avoid trusted setup but produce larger proofs. For ML inference, ZK overhead is currently 10,000-100,000x, though projects like EZKL are pushing this forward. +**ZK proofs** let a prover demonstrate computation correctness without revealing inputs. Verification is trustless and cryptographically sound. The catch: proof generation is orders of magnitude slower than direct computation, and some ZK systems (Groth16, older PLONK variants) require a trusted setup ceremony. Transparent alternatives (STARKs) avoid trusted setup but produce larger proofs. For ML inference, the reported ZK overhead is currently 10,000-100,000x, though projects like EZKL are pushing this forward. ## AI Inference Verification Neural network inference is mathematically deterministic. The apparent non-determinism comes from temperature sampling, floating-point non-associativity across hardware, and library optimizations like cuDNN algorithm selection. With effort (temperature=0, fixed seeds, deterministic CUDA flags, identical hardware), you can achieve reproducible inference. The non-determinism is a practical constraint, not a fundamental one. -The primary attack vector for [AI services](/blog/building-ai-services-on-tangle) is model substitution: claiming to run an expensive model while actually running a cheaper one. Detection techniques include: +The primary attack vector for [AI services](/blog/building-ai-services-on-tangle) is model substitution: claiming to run an expensive model while in practice running a cheaper one. Detection techniques include: **Weight hash verification.** Hash the model at load time, include the hash in TEE attestation. Verifies model identity at the hardware level. @@ -137,10 +137,12 @@ Every verification mechanism has assumptions that can fail. Economics provides t The security equation: **if P(detection) x slash_amount > profit_from_cheating, rational operators don't cheat.** -A worked example: a service processes inference jobs worth $100 each. Operators stake $50,000. Detection mechanisms (TEE attestation, canary prompts, consistency checking) catch cheating 80% of the time within one week. Cheating on 100 jobs might net $5,000 in cost savings. +A reported sample: a service processes inference jobs worth $100 each. Operators stake $50,000. Detection mechanisms (TEE attestation, canary prompts, consistency checking) catch cheating 80% of the time within one week. Cheating on 100 reported jobs might net $5,000 in cost savings. -- Expected value of cheating: $5,000 x 20% = $1,000 (if undetected) -- Expected cost of cheating: $50,000 x 80% = $40,000 (if detected) +The following figures are reported sample values. + +- Reported expected value of cheating: $5,000 x 20% = $1,000 (if undetected) +- Reported expected cost of cheating: $50,000 x 80% = $40,000 (if detected) Rational operator: doesn't cheat. @@ -166,7 +168,7 @@ Tangle gives you the building blocks. You compose them. ## FAQ ### Which verification mechanism should I use for my blueprint? -It depends on the workload. TEEs are best when confidentiality matters (private inference, sensitive data). Redundant execution works for deterministic computation where you can afford 3x cost. ZK proofs provide the strongest cryptographic guarantees but have high proof-generation overhead. Economic security (staking and slashing) serves as a backstop for all approaches. +It depends on the workload. TEEs are best when confidentiality matters (private inference, sensitive data). Redundant execution works for deterministic computation where you can afford a reported 3x cost. ZK proofs provide the strongest cryptographic guarantees but have high proof-generation overhead. Economic security (staking and slashing) serves as a backstop for all approaches. ### Can an operator cheat if they control the TEE hardware? TEE attestations are signed by the hardware manufacturer (Intel or AMD), not the operator. Cheating requires breaking the hardware security or compromising the manufacturer. Known side-channel attacks exist but raise the cost of extraction dramatically. For most use cases, this risk is acceptable. diff --git a/src/content/blog/k-1-tax-filing-multiple-entities.mdx b/src/content/blog/k-1-tax-filing-multiple-entities.mdx index ad84688..7ec578f 100644 --- a/src/content/blog/k-1-tax-filing-multiple-entities.mdx +++ b/src/content/blog/k-1-tax-filing-multiple-entities.mdx @@ -11,9 +11,9 @@ tags: - pass-through series: Building an AI Tax Agent seriesOrder: 9 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing multiple Schedule K-1s, basis workpapers, state allocation notes, and review questions' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- K-1 tax filing is easy to underestimate. A single clean K-1 can be entered by hand. Multiple K-1s from partnerships, S corporations, trusts, funds, or lower-tier entities can turn into a reconciliation job. The IRS partner instructions for [Schedule K-1 (Form 1065)](https://www.irs.gov/pub/irs-pdf/i1065sk1.pdf) explain that a partnership uses the schedule to report a partner's share of income, deductions, credits, and related items. The taxpayer still has to report the items correctly on the return. @@ -71,7 +71,7 @@ Multiple K-1s need a reconciliation view before return lines are final. | foreign items | attached K-2/K-3 or foreign tax statements | | passive grouping | activity classification and carryovers | -The software should show this as a workpaper, not only as final return entries. +The software should show this as a workpaper, alongside final return entries. ## Missing-Fact Questions diff --git a/src/content/blog/llm-sandbox-environment-agent-runtime.mdx b/src/content/blog/llm-sandbox-environment-agent-runtime.mdx index dbad3d0..257e5a6 100644 --- a/src/content/blog/llm-sandbox-environment-agent-runtime.mdx +++ b/src/content/blog/llm-sandbox-environment-agent-runtime.mdx @@ -11,9 +11,9 @@ tags: - agent-runtime series: Agent Runtime Infrastructure seriesOrder: 5 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'LLM sandbox environment showing tool calls, command output, file state, and session replay' +coverImage: /images/covers/editorial/agent-runtime-v2.webp +heroImage: /images/covers/editorial/agent-runtime-v2.webp +imageAlt: 'An editorial still life about the software that runs an agent' --- An LLM sandbox environment is where a model is allowed to act. That permission changes the risk profile. A chat response can be wrong and still harmless. A tool-using model can delete files, leak tokens, spam an API, or ship a broken patch. The sandbox has to separate "the model proposed a plan" from "the model ran code and changed state." @@ -38,24 +38,7 @@ Transport security such as [TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) pro An LLM sandbox environment should be easy to smoke-test: -```bash -curl -fsS https://sandbox.tangle.tools/health -curl -fsS https://sandbox.tangle.tools/v1/public-templates -npm install @tangle-network/sandbox -``` - -```ts -import { Sandbox } from '@tangle-network/sandbox' - -const sandbox = new Sandbox({ - apiKey: process.env.TANGLE_API_KEY!, - baseUrl: 'https://sandbox.tangle.tools' -}) - -const box = await sandbox.create({ image: 'universal' }) -const test = await box.exec('git status --short && pnpm test') -await box.delete() -``` +Use the public Sandbox documentation to create an isolated workspace, run one harmless command, inspect the result, and remove the workspace. The command is incidental; the recorded boundary and output are what matter. The important part is not the command itself. It is that the command becomes evidence with a result, timestamp, and environment boundary. @@ -70,7 +53,7 @@ LLM tasks are often longer than a request-response cycle. The browser closes. Th | model edits files | diff stays tied to the session | | reviewer opens later | trace and final state are still available | -That is why [AI Dev Container For Production Agents](/blog/ai-dev-container-production-agent-runtime) and [Secure Container For AI Agents](/blog/trusted-execution-on-tangle) are runtime topics, not only infrastructure topics. +That is why [AI Dev Container For Production Agents](/blog/ai-dev-container-production-agent-runtime) and [Secure Container For AI Agents](/blog/trusted-execution-on-tangle) are runtime concerns, not infrastructure alone. ## Safe Defaults diff --git a/src/content/blog/metamask-automated-testing-wallet-flows.mdx b/src/content/blog/metamask-automated-testing-wallet-flows.mdx index 1fba612..e89bae2 100644 --- a/src/content/blog/metamask-automated-testing-wallet-flows.mdx +++ b/src/content/blog/metamask-automated-testing-wallet-flows.mdx @@ -11,9 +11,9 @@ tags: - wallet-testing series: Browser Agent seriesOrder: 8 -coverImage: /images/products/browser-agent-app.png -heroImage: /images/products/browser-agent-app.png -imageAlt: 'Automated MetaMask wallet flow showing extension popup, browser app state, and recorded actions' +coverImage: /images/covers/editorial/browser-agent-v2.webp +heroImage: /images/covers/editorial/browser-agent-v2.webp +imageAlt: 'An editorial still life about an agent operating a web browser' --- MetaMask automated testing has to cover more than "click connect." The risky moments are the wallet prompts: account access, chain switching, typed data, approvals, transaction previews, and user rejection. A useful test has to operate both the app page and the extension UI, then save the proof. @@ -31,16 +31,11 @@ Tangle Browser Agent targets those wallet-heavy flows through the same `bad` bro | sign typed data | structured data matches the transaction context | | submit transaction | app shows pending, success, or failure truthfully | -MetaMask's public docs describe the connection model in [MetaMask Connect](https://docs.metamask.io/metamask-connect/). Ethereum provider behavior is specified by [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193). Structured signing is specified by [EIP-712](https://eips.ethereum.org/EIPS/eip-712). Your automated test should save evidence at the user prompt, not only after the dapp receives a response. +MetaMask's public docs describe the connection model in [MetaMask Connect](https://docs.metamask.io/metamask-connect/). Ethereum provider behavior is specified by [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193). Structured signing is specified by [EIP-712](https://eips.ethereum.org/EIPS/eip-712). Your automated test should save evidence at the user prompt, alongside the response the dapp receives. ## Run Shape -```bash -pnpm wallet:setup -pnpm wallet:onboard -pnpm wallet:anvil -pnpm wallet:validate -``` +Drive the wallet flow through the browser test runner and save the prompt, rejection, retry, and final state. A reader can adapt that sequence to their own environment without a local setup transcript. ```bash bad run \ @@ -72,7 +67,7 @@ MetaMask tests need repeatable fixture state. | Fixture | Required control | | --- | --- | -| extension | installed and unlocked before run | +| extension | installed and enableed before run | | account | known address with seeded balance | | network | expected chain configured before action | | permissions | clean permissions between tests | diff --git a/src/content/blog/natural-language-e2e-testing-wallet-apps.mdx b/src/content/blog/natural-language-e2e-testing-wallet-apps.mdx index f978c1e..b0ba384 100644 --- a/src/content/blog/natural-language-e2e-testing-wallet-apps.mdx +++ b/src/content/blog/natural-language-e2e-testing-wallet-apps.mdx @@ -11,12 +11,12 @@ tags: - testing series: Agent Intent Infrastructure seriesOrder: 6 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Wallet application test run showing browser state, wallet prompt, screenshot evidence, and safe stop' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- -Natural-language E2E testing for wallet apps lets a browser agent execute user-facing flows from a goal, capture DOM and screenshot evidence, and stop before irreversible signing or value transfer. The useful target is not "the agent clicked buttons." The target is a reproducible trace: page state, wallet prompt state, network state, screenshot, final assertion, and stop reason. Tangle Browser Agent is built for that evidence loop, and [Tangle Sandbox](https://github.com/tangle-network/tcloud) can host the surrounding test workspace. +A trace is the record of an agent run, including its actions and results. Natural-language E2E testing for wallet apps lets a browser agent execute user-facing flows from a goal, capture DOM and screenshot evidence, and stop before irreversible signing or value transfer. The useful target is not "the agent clicked buttons." The target is a reproducible trace: page state, wallet prompt state, network state, screenshot, final assertion, and stop reason. Tangle Browser Agent is built for that evidence loop, and [Tangle Sandbox](https://github.com/tangle-network/tcloud) can host the surrounding test workspace. Wallet apps are harder than ordinary forms because the dangerous moment is often outside the dapp: a wallet confirmation, signature request, transaction preview, or network switch. diff --git a/src/content/blog/natural-language-test-automation-browser-agents.mdx b/src/content/blog/natural-language-test-automation-browser-agents.mdx index e4de0b9..1a1d14b 100644 --- a/src/content/blog/natural-language-test-automation-browser-agents.mdx +++ b/src/content/blog/natural-language-test-automation-browser-agents.mdx @@ -11,9 +11,9 @@ tags: - qa series: Browser Agent seriesOrder: 6 -coverImage: /images/products/browser-agent-app.png -heroImage: /images/products/browser-agent-app.png -imageAlt: 'Natural language browser test case mapped to screenshots, actions, and final verifier' +coverImage: /images/covers/editorial/browser-agent-v2.webp +heroImage: /images/covers/editorial/browser-agent-v2.webp +imageAlt: 'An editorial still life about an agent operating a web browser' --- Natural language test automation lets a product team describe a workflow without writing a selector-heavy script. That is useful only if the English sentence becomes a real browser run. A model summary is not a test. A run with screenshots, actions, observations, and a final verifier is. diff --git a/src/content/blog/on-chain-rfq-job-quotes-verification-slashing.mdx b/src/content/blog/on-chain-rfq-job-quotes-verification-slashing.mdx index eec44d9..eae053d 100644 --- a/src/content/blog/on-chain-rfq-job-quotes-verification-slashing.mdx +++ b/src/content/blog/on-chain-rfq-job-quotes-verification-slashing.mdx @@ -14,9 +14,9 @@ tags: - rfq series: x402 Production Runway seriesOrder: 5 -coverImage: /images/covers/on-chain-rfq-job-quotes-verification-slashing.png -heroImage: /images/covers/on-chain-rfq-job-quotes-verification-slashing.png -imageAlt: 'A compute request moving from a signed quote through result checks to settlement' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- When a company buys compute from an unknown operator, the price is only half the problem. @@ -59,7 +59,7 @@ The signed data includes the service, job, price, creation time, and expiry. The signature binds the operator to those fields. Changing the price, job, chain, or receiving contract breaks the signature. -The default quote lifetime in the source described by this article is 300 seconds, with a one-hour maximum age. +The source reports a default quote lifetime of 300 seconds, with a one-hour maximum age. After submission, the on-chain record marks the quote as consumed so the same offer cannot be used twice. That gives the consumer four properties to check: @@ -78,7 +78,7 @@ This is the difference between “the price endpoint says $X” and “the price Some operators quote in the chain’s native currency but accept a stablecoin through the [x402 payment path](/blog/blueprint-sdk-x402-payments-runnable-jobs). The gateway converts the quote using the native-currency exchange rate, any operator markup, and the token’s decimal precision. -For example, a 0.25 ETH quote at 3,200 USDC per ETH with a 0.5% markup becomes 804 USDC. +A reported example: a 0.25 ETH quote at 3,200 USDC per ETH with a 0.5% markup becomes 804 USDC. That example is arithmetic, not a market forecast. The operator still needs a policy for how often the rate changes and what happens when the rate source is unavailable. diff --git a/src/content/blog/openai-compatible-routers-for-agents.mdx b/src/content/blog/openai-compatible-routers-for-agents.mdx index 5d84b02..4246514 100644 --- a/src/content/blog/openai-compatible-routers-for-agents.mdx +++ b/src/content/blog/openai-compatible-routers-for-agents.mdx @@ -11,9 +11,9 @@ tags: - infrastructure series: Agent Intent Infrastructure seriesOrder: 4 -coverImage: /images/covers/agent-intent-infrastructure.svg -heroImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Model router diagram showing discovery, health checks, fallback, and usage attribution' +coverImage: /images/covers/editorial/agent-intent-v2.webp +heroImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- An OpenAI-compatible router lets agents keep one chat-completions shape while the platform handles model discovery, provider routing, usage attribution, health, and fallback policy. Tangle Router exposes OpenAI-compatible discovery through `/v1/models`, plus health, status, OpenAPI, and a machine-readable manifest. Use a router when the agent estate needs model choice, billing headers, fallback, or anonymous provider abstraction. Do not add a router if one fixed model and one fixed bill are enough. @@ -22,12 +22,7 @@ The point is not to hide every provider detail. The point is to keep agents from ## Safe Discovery -```bash -curl -fsS https://router.tangle.tools/.well-known/tangle-agent.json -curl -fsS https://router.tangle.tools/openapi.json -curl -fsS https://router.tangle.tools/api/health -curl -fsS https://router.tangle.tools/v1/models -``` +Start with the Router manifest, API description, health result, and model list linked below. Those public surfaces are enough to decide whether the router fits before writing integration code. The Router manifest names `@tangle-network/tcloud`, `TANGLE_API_KEY`, health checks, status checks, and `/v1/models`. The OpenAPI file describes the public request shape. The model list is intentionally discoverable before an agent hardcodes a target. diff --git a/src/content/blog/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.mdx b/src/content/blog/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.mdx index f475511..5b1ed31 100644 --- a/src/content/blog/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.mdx +++ b/src/content/blog/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.mdx @@ -1,5 +1,5 @@ --- -title: "Operator Health Monitoring on Tangle" +title: "Operator Health Monitoring: Heartbeats, Quotes, and Recovery" slug: operator-health-monitoring-tangle-heartbeats-quote-lifetimes summary: "How Tangle operator heartbeats, off-chain health checks, and quote TTLs surface service failure signals before slashing occurs." description: "How Tangle operator heartbeats, off-chain health checks, and quote TTLs surface service failure signals before slashing occurs." @@ -8,12 +8,12 @@ author: Drew Stone tags: ["tangle", "blueprint-sdk", "x402", "operator-monitoring", "blockchain-infrastructure", "health-checks"] series: x402 Production Runway seriesOrder: 12 -coverImage: /images/covers/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.png -heroImage: /images/covers/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.png -imageAlt: 'Operator health monitoring on Tangle: heartbeats, quote lifetimes, failure signals' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -You built a service. It runs jobs, accepts x402 payments, returns results. It worked fine in testing. Now it's live and you need to know: how does the network know if you stop working? And what actually happens to you when it finds out? +Operator health monitoring answers whether a service is still able to accept work, report its state, and recover when a deployment stops responding. A blueprint is a packaged service definition with a typed job interface. x402 is a payment protocol for machine-to-machine requests. You built a service. It runs jobs, accepts x402 payments, returns results. It worked fine in testing. Now it's live and you need to know: how does the network know if you stop working? And what in practice happens to you when it finds out? The answer involves three interlocking systems. The first is an on-chain registry that tracks whether operators are showing up at regular intervals, the way a building's security system requires a guard to swipe their badge every hour. The second is an off-chain monitor that watches your actual running software and can automatically restart it if it crashes. The third is a quote cache that holds the pricing promises you've made to clients, and which quietly expires them if jobs aren't completed in time. Together these three systems give the network enough signal to distinguish "operator is slightly slow" from "operator has vanished and clients are losing money." @@ -99,9 +99,9 @@ One more subtle point: if you voluntarily call `goOffline()` and then `goOnline( ## How Does Off-Chain Health Monitoring Work? -The on-chain heartbeat system tracks whether your process is sending messages. It does not track whether your HTTP endpoint is responding or whether your container is actually executing jobs. That's the job of the [`HealthMonitor`](https://github.com/tangle-network/blueprint/blob/main/crates/blueprint-remote-providers/src/monitoring/health.rs) in blueprint-remote-providers. +The on-chain heartbeat system tracks whether your process is sending messages. It does not track whether your HTTP endpoint is responding or whether your container is in practice executing jobs. That's the job of the [`HealthMonitor`](https://github.com/tangle-network/blueprint/blob/main/crates/blueprint-remote-providers/src/monitoring/health.rs) in blueprint-remote-providers. -The HealthMonitor runs a polling loop every 60 seconds against active deployments. It tracks consecutive failures per deployment internally and triggers auto-recovery when a threshold is reached: +The source reports that the HealthMonitor runs a polling loop every reported 60 seconds against active deployments. It tracks consecutive failures per deployment internally and triggers auto-recovery when a threshold is reached: ```rust let monitor = HealthMonitor::new(provisioner, tracker) @@ -124,7 +124,7 @@ InstanceStatus::Terminated → HealthStatus::Unhealthy InstanceStatus::Unknown → HealthStatus::Unknown ``` -When a deployment reaches three consecutive `Unhealthy` results, the monitor terminates the old instance, waits 10 seconds, provisions a replacement at the same region and resource spec, and updates the deployment tracker with the new instance ID. The failure counter resets when a `Healthy` check comes through. +When a deployment reaches a reported threshold of three consecutive `Unhealthy` results, the monitor terminates the old instance, waits a reported 10 seconds, provisions a replacement at the same region and resource spec, and updates the deployment tracker with the new instance ID. The failure counter resets when a `Healthy` check comes through. For application-level checks beyond instance state, `ApplicationHealthChecker` handles HTTP and TCP probes: @@ -148,7 +148,7 @@ An important implication: auto-recovering a crashed deployment does not reset yo ## How Does the Quote Registry Signal Service Health? -The [`QuoteRegistry`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/quote_registry.rs) is an in-memory DashMap that holds pricing promises made to clients. When a client requests a quote, the operator inserts a `QuoteEntry` with a price, a TTL, and an expiry timestamp. When the client submits payment, `consume()` marks it as consumed. When neither happens before the TTL expires, the quote simply returns `None` on the next lookup. +The [`QuoteRegistry`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/quote_registry.rs) is an in-memory DashMap that holds pricing promises made to clients. When a client requests a quote, the operator inserts a `QuoteEntry` with a price, a TTL, and an expiry timestamp. When the client submits payment, `consume()` marks it as consumed. When neither happens before the TTL expires, the quote directly returns `None` on the next lookup. ```rust pub struct QuoteEntry { @@ -189,7 +189,7 @@ The consumed-versus-expired distinction matters operationally. A consumed quote The registry is in-memory and not persisted. A process restart clears all outstanding quotes. Clients holding valid quote digests will get `None` on lookup after a restart, and will need to request new quotes. Plan for this in your restart procedures. -## What Failure Signals Should Operators Actually Watch? +## What Failure Signals Should Operators Watch? The monitoring surface across all three systems gives you five key signals: @@ -211,7 +211,7 @@ These are emitted on-chain whenever a heartbeat carries a status code of 200 or **5. Recovery strategy backoff state** -The `RecoveryStrategy` default retries 3 times with exponential backoff starting at 2 seconds, capping at 30 seconds. If your deployment is cycling through recovery attempts, the 2s + 4s + 8s gap means roughly 14 seconds of unavailability per cycle. Repeated cycles in the same deployment point to a problem that restart-and-retry won't resolve. +The source reports a `RecoveryStrategy` default of 3 retries with exponential backoff starting at 2 seconds and capping at 30 seconds. If your deployment is cycling through recovery attempts, the 2s + 4s + 8s gap means roughly 14 seconds of unavailability per cycle. Repeated cycles in the same deployment point to a problem that restart-and-retry won't resolve. ## What Metrics Should Operators Instrument? @@ -240,7 +240,7 @@ If a `SlashingTriggered` event was emitted while you were down, monitor for whet **What happens if I miss the heartbeat interval by a few seconds due to block time variance?** -The registry calculates `missedBeats` as `elapsed / config.interval` using integer division. A heartbeat submitted at interval + 30 seconds counts as 1 missed beat, not 0. Submit heartbeats slightly before the interval deadline to absorb block time variance. Targeting 90% of the interval (4.5 minutes for a 5-minute window) is a reasonable buffer. +The registry calculates `missedBeats` as `elapsed / config.interval` using integer division. A heartbeat submitted at interval + 30 seconds counts as 1 missed beat, not 0. Submit heartbeats slightly before the interval deadline to absorb block time variance. Targeting a reported 90% of the interval (4.5 minutes for a 5-minute window) is a reasonable buffer. **Does auto-recovery in the HealthMonitor affect my on-chain status?** @@ -252,7 +252,7 @@ Yes. Codes in the 1–99 and 100–199 ranges both map to `Degraded` on-chain. T **Why does goOnline() return Degraded instead of Healthy?** -The registry treats returning operators as unverified until they demonstrate active liveness. `Degraded` signals "present but not fully trusted." A successful heartbeat submission transitions you to `Healthy`. This prevents operators from gaming their online status by calling `goOnline()` without actually being ready to serve. +The registry treats returning operators as unverified until they demonstrate active liveness. `Degraded` signals "present but not fully trusted." A successful heartbeat submission transitions you to `Healthy`. This prevents operators from gaming their online status by calling `goOnline()` without in practice being ready to serve. **The QuoteRegistry is in-memory. What happens to outstanding quotes after a deploy?** diff --git a/src/content/blog/operator-operations-guide-metrics-quotes-health.mdx b/src/content/blog/operator-operations-guide-metrics-quotes-health.mdx index a60b9b0..d9eddca 100644 --- a/src/content/blog/operator-operations-guide-metrics-quotes-health.mdx +++ b/src/content/blog/operator-operations-guide-metrics-quotes-health.mdx @@ -14,9 +14,9 @@ tags: - blockchain series: x402 Production Runway seriesOrder: 6 -coverImage: /images/covers/operator-operations-guide-metrics-quotes-health.png -heroImage: /images/covers/operator-operations-guide-metrics-quotes-health.png -imageAlt: 'Three operator health gauges showing heartbeat, quote freshness, and capacity utilization' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- ## Operator Monitoring and Health Checks for Tangle Blueprint Nodes @@ -60,130 +60,7 @@ Each service configures its own `HeartbeatConfig` with an `interval` (how often You can inspect your operator's on-chain health at any time: -```solidity -// Binary liveness check -registry.isHeartbeatCurrent(serviceId, operatorAddr); -registry.isOnline(serviceId, operatorAddr); - -// Full state inspection -registry.getOperatorState(serviceId, operatorAddr); -// Returns: lastHeartbeat, consecutiveBeats, missedBeats, status, lastMetricsHash - -// Individual metric values (if customMetrics enabled) -registry.getMetricValue(serviceId, operatorAddr, "cpu_utilization"); -``` - -The `getMetricDefinitions(serviceId)` call returns the schema for a service's expected metrics, including `name`, `minValue`, `maxValue`, and whether each metric is `required`. If your blueprint defines required metrics and you stop submitting them, the registry logs the violation on-chain. - -## Job selection and operator health - -Beyond on-chain heartbeats, the orchestrator that routes jobs to operators will use its own health assessment when selecting operators. The design targets a system where job outcomes, success rates, and available capacity all factor into selection priority. - -The general selection model works like this: operators with better health signals and more available capacity get priority for new jobs. Operators that fail jobs or fall behind on heartbeats get deprioritized or removed from rotation entirely. - -The specific thresholds and selection algorithms are still being finalized. What is certain: on-chain heartbeat status and quote freshness are hard requirements. If `isOnline()` returns false or your quotes are expired, you will not be selected regardless of any other factor. - -## Quote lifetimes: the tuning surface nobody talks about - -When a user requests a job, the operator's pricing engine generates a quote. That quote has a lifetime, and getting the lifetime right matters more than most operators realize. - -Quote validity duration is the number of seconds a price quote remains acceptable to the protocol after generation. The default is 5 minutes (`quote_validity_duration_secs: 300` in `operator.toml`). The protocol enforces a hard cap of 1 hour (`MAX_QUOTE_AGE = 1 hours` in [`ProtocolConfig.sol`](https://github.com/tangle-network/tnt-core/blob/main/src/config/ProtocolConfig.sol)). Anything between those bounds is your call. - -### Why shorter isn't always better - -A short quote lifetime (say, 30 seconds) limits your price exposure. If the cost of the resources you're committing changes between quote generation and job execution, a shorter window reduces the risk that you're locked into a stale price. For operators dealing with volatile token pricing, this matters. - -But short lifetimes create user friction. The user needs to receive the quote, review it, sign the payment, and submit the request before the quote expires. On a congested network, that flow can easily take more than 30 seconds. An expired quote means a failed request and a retry. - -### Why longer isn't always better - -A long quote lifetime (approaching the 1-hour cap) is comfortable for users but risky for operators. Resource costs can shift, token exchange rates can move, and you're committed to the quoted price for the entire window. - -### Practical guidance - -For most operators, the 5-minute default works well for stablecoin-denominated services where price volatility is low. Consider adjusting in these scenarios: - -- **Volatile token pricing**: Drop to 60-120 seconds. Accept the increased retry rate as a cost of price accuracy. -- **Long user flows**: If your users are interacting through UIs with multiple confirmation steps, extend to 10-15 minutes. Monitor your expired-quote rate. -- **High-value jobs**: Shorter is safer. A 1-hour quote on a job that costs several hundred dollars in compute creates real exposure. - -Keep your quote server address current on-chain via `updateOperatorPreferences` on the `ITangleOperators` interface. A stale address means quotes can't be fetched at all, which is worse than any lifetime misconfiguration. - -## The pricing engine under the hood - -Quotes aren't arbitrary numbers. The pricing engine runs automated benchmarks on your hardware when a service activates (`ServiceActivated` event), measuring CPU, memory, storage, network, and GPU performance. Results are cached locally by blueprint ID. - -The quote formula is: `Base Resource Cost x Time Multiplier x Security Commitment Factor`. - -Resource pricing is configured per-blueprint in your `operator.toml`: - -```toml -[blueprint.resources] -cpu = { count = 8, price_per_unit = "0.001" } -memory = { count = 16384, price_per_unit = "0.00005" } -storage = { count = 1024000, price_per_unit = "0.00002" } -``` - -The pricing engine's full config controls benchmark behavior and the quote server: - -```toml -database_path = "./data/price_cache" -benchmark_duration = 60 -benchmark_interval = 1 -keystore_path = "./data/keystore" -rpc_bind_address = "127.0.0.1" -rpc_port = 9000 -rpc_timeout = 30 -rpc_max_connections = 100 -quote_validity_duration_secs = 300 -``` - -If `rpc_max_connections` is too low for your traffic, quote requests will queue and potentially time out, which looks identical to an offline quote server from the user's perspective. For operators expecting high request volume, bumping this above the default 100 is worth doing. - -## The degradation cascade: signals before slashing - -Operators don't get slashed out of nowhere. There's a predictable cascade, and every stage produces signals you can catch if you're watching. - -![Four-stage degradation cascade: heartbeat drift, degraded, offline, slashing risk](/images/blog/operator-operations-guide-metrics-quotes-health/operator-operations-guide-metrics-quotes-health-diagram-2.png) - -**Stage 1: Heartbeat drift.** Your heartbeat interval starts slipping. Maybe a network issue, maybe resource contention on the node. The `consecutiveBeats` counter resets and `missedBeats` starts climbing. On-chain, your status is still Healthy, but the trend is visible. - -**Stage 2: Degraded status.** Once `missedBeats` crosses a threshold (per your service's `HeartbeatConfig.maxMissed`), the status shifts to Degraded. You're still potentially selectable for jobs, but the underlying issue is likely affecting job execution too. - -**Stage 3: Offline.** Continued misses push the status to Offline. `isOnline()` returns false. You stop receiving work entirely. You're still staked, still committed, but earning nothing. - -**Stage 4: Slashing risk.** If the offline period extends beyond the grace window, slashing becomes possible. `ProtocolConfig.sol` defines `DISPUTE_WINDOW_ROUNDS = 14` (3.5 days at 6-hour rounds), while `SlashingLib` defaults to a 7-day dispute window. An exit takes 56 rounds (14 days). These are not fast processes, which is intentional: they give operators time to recover from legitimate outages. - -Every stage before slashing is recoverable. Fix the underlying issue, submit a successful heartbeat, and the cascade resets. The operators who get slashed are the ones who aren't watching. - -### What metric violations actually do - -The `MetricDefinition` system lets services define bounds (`minValue`, `maxValue`) for custom metrics like CPU utilization or memory usage. When a submitted metric falls outside those bounds, the violation is logged on-chain. Currently, violations don't trigger automatic slashing. They create an on-chain record that can be used in governance-driven disputes, but the enforcement path is manual. This may change as the protocol matures, so treat metric bounds as soft limits today and hard limits tomorrow. - -## Revenue: what you're protecting - -The default fee split for job revenue is: - -| Recipient | Share | -|-----------|-------| -| Operators | 40% | -| Developers | 20% | -| Protocol | 20% | -| Stakers | 20% | - -These percentages are governance-configurable (defined in `TangleStorage.sol`). On top of job revenue, operators can earn TNT incentives from the `InflationPool` and commission from delegator `RewardVaults`. But all of these revenue streams depend on one thing: staying in rotation. An operator that's offline or has expired quotes earns nothing. - -## Building your monitoring stack - -The QoS endpoints on your node give you the raw signals: - -```bash -# Quick health check -curl -s http://localhost:9090/health - -# Prometheus metrics (for Grafana dashboards) -curl -s http://localhost:9090/metrics | head -n 20 -``` +Use the public health and metrics endpoints described in the linked operator documentation. Keep a time-stamped health record and an alert history; a copied terminal session is not an operating policy. This Prometheus alerting config catches problems at Stage 1 of the degradation cascade, before they affect job selection: @@ -217,12 +94,12 @@ The protocol's timing constants give you the boundaries for alert thresholds: | Constant | Value | What it means for alerting | |----------|-------|---------------------------| -| `ROUND_DURATION_SECONDS` | 21,600 (6 hr) | Rounds are the unit of protocol time | -| `ROUNDS_PER_EPOCH` | 28 (7 days) | Epoch boundaries trigger reward distribution | -| `DISPUTE_WINDOW_ROUNDS` | 14 (3.5 days) | Time to respond to slashing disputes | -| `OPERATOR_DELAY_ROUNDS` | 56 (14 days) | Minimum exit timeline | -| `MAX_QUOTE_AGE` | 1 hour | Absolute ceiling for quote validity | -| `MIN_SERVICE_TTL` | 1 hour | Shortest allowed service commitment | +| `ROUND_DURATION_SECONDS` | 21,600 (reported 6 hr) | Rounds are the unit of protocol time | +| `ROUNDS_PER_EPOCH` | 28 (reported 7 days) | Epoch boundaries trigger reward distribution | +| `DISPUTE_WINDOW_ROUNDS` | 14 (reported 3.5 days) | Time to respond to slashing disputes | +| `OPERATOR_DELAY_ROUNDS` | 56 (reported 14 days) | Minimum exit timeline | +| `MAX_QUOTE_AGE` | 1 reported hour | Absolute ceiling for quote validity | +| `MIN_SERVICE_TTL` | 1 reported hour | Shortest allowed service commitment | ## FAQ @@ -232,7 +109,7 @@ There is no single fixed number. Slashing risk comes from a cascade, not a thres ### Should I set my quote lifetime to the maximum 1 hour? -Almost certainly not. The 1-hour `MAX_QUOTE_AGE` is a protocol ceiling, not a recommendation. A 1-hour quote locks you into pricing that may not reflect current resource costs or token exchange rates. The 5-minute default is a reasonable starting point. Only extend it if your users consistently need more time to complete the quote-to-submission flow, and even then, 10-15 minutes is usually sufficient. +Almost certainly not. The reported 1-hour `MAX_QUOTE_AGE` is a protocol ceiling, not a recommendation. A 1-hour quote locks you into pricing that may not reflect current resource costs or token exchange rates. The 5-minute default is a reasonable starting point. Only extend it if your users consistently need more time to complete the quote-to-submission flow, and even then, a reported 10-15 minutes is usually sufficient. ### Do metric violations lead to automatic slashing? @@ -240,7 +117,7 @@ Not currently. When a submitted metric falls outside the bounds defined in `Metr ### What's the dispute window for slashing? -`ProtocolConfig.sol` defines `DISPUTE_WINDOW_ROUNDS = 14`, which works out to 3.5 days at the current 6-hour round duration. However, `SlashingLib` defaults to a 7-day dispute window. The effective window depends on which value the governance configuration selects. Either way, it's measured in days, not hours. You have time to respond, but only if you're monitoring for the dispute in the first place. +The source reports that `ProtocolConfig.sol` defines `DISPUTE_WINDOW_ROUNDS = 14`, which works out to a reported 3.5 days at the current 6-hour round duration. However, `SlashingLib` defaults to a 7-day dispute window. The effective window depends on which value the governance configuration selects. Either way, it's measured in days, not hours. You have time to respond, but only if you're monitoring for the dispute in the first place. --- diff --git a/src/content/blog/operator-staking-ai-blueprints.mdx b/src/content/blog/operator-staking-ai-blueprints.mdx index a26cf07..3372f82 100644 --- a/src/content/blog/operator-staking-ai-blueprints.mdx +++ b/src/content/blog/operator-staking-ai-blueprints.mdx @@ -11,12 +11,12 @@ tags: - staking series: Tangle Protocol seriesOrder: 11 -coverImage: /images/covers/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.png -heroImage: /images/covers/operator-health-monitoring-tangle-heartbeats-quote-lifetimes.png -imageAlt: 'Operator staking dashboard showing AI Blueprint service health, job quotes, payments, and accountability' +coverImage: /images/covers/editorial/protocol-operators-v2.webp +heroImage: /images/covers/editorial/protocol-operators-v2.webp +imageAlt: 'An editorial still life about operators running services on a network' --- -Operator staking for AI Blueprints is the mechanism that connects service providers to network accountability. Operators are not abstract validators in this model. They run services: inference, sandboxes, code audits, data jobs, or other Blueprint-defined workloads. Staking and payment economics should make that service work measurable. +A blueprint is a packaged service definition with a typed job interface. Operator staking for AI Blueprints is the mechanism that connects service providers to network accountability. Operators are not abstract validators in this model. They run services: inference, sandboxes, code audits, data jobs, or other Blueprint-defined workloads. Staking and payment economics should make that service work measurable. For operations, read [Operator Health Monitoring For Tangle](/blog/operator-health-monitoring-tangle-heartbeats-quote-lifetimes). For Blueprint basics, read [Blueprint Protocol For Operator-Run Services](/blog/blueprint-protocol-operator-services). @@ -89,11 +89,11 @@ Stakers should care about service quality because bad operators can harm network This is the bridge between staking and AI service quality. The stake is the economic bond. The service metrics explain whether the operator deserves delegation. -Operator pages should therefore show service-specific history, not only total stake. A high-stake operator with recurring job failures is different from a smaller operator with clean execution on the exact Blueprint a user wants. +Operator pages should therefore show service-specific history alongside total stake. A high-stake operator with recurring job failures is different from a smaller operator with clean execution on the exact Blueprint a user wants. That distinction matters for delegation. Stakers need to know whether they are backing general reputation or a specific service quality record. -The operator UI should make that distinction visible by Blueprint, not only by wallet address. Service buyers care about the operator's record on the workload they are about to purchase. +The operator UI should make that distinction visible by Blueprint as well as by wallet address. Service buyers care about the operator's record on the workload they are about to purchase. ## What This Does Not Prove diff --git a/src/content/blog/payment-native-infrastructure-ai-agent-product-strategy.mdx b/src/content/blog/payment-native-infrastructure-ai-agent-product-strategy.mdx index 4da2c97..73ebf85 100644 --- a/src/content/blog/payment-native-infrastructure-ai-agent-product-strategy.mdx +++ b/src/content/blog/payment-native-infrastructure-ai-agent-product-strategy.mdx @@ -16,12 +16,12 @@ tags: - founder-memo series: x402 Production Runway seriesOrder: 14 -coverImage: /images/covers/payment-native-infrastructure-ai-agent-product-strategy.png -heroImage: /images/covers/payment-native-infrastructure-ai-agent-product-strategy.png -imageAlt: 'Payment rails as infrastructure: agents as economic actors' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -Most AI agent products still inherit a human billing model. A human signs up, enters a card, creates an API key, sets a budget, and hopes the agent uses the capability correctly later. That is fine when the agent is a feature inside a SaaS product. It breaks when the agent is the buyer. +A TEE is a hardware-isolated environment that can report which code ran. An operator is the person or service responsible for running a job. x402 is a payment protocol for machine-to-machine requests. Most AI agent products still inherit a human billing model. A human signs up, enters a card, creates an API key, sets a budget, and hopes the agent uses the capability correctly later. That is fine when the agent is a feature inside a SaaS product. It breaks when the agent is the buyer. An agent wants a smaller loop: discover a capability, inspect the price, decide whether it is worth buying, pay for one request, run the job, and verify the result. Payment-native infrastructure is the stack that makes that loop native instead of bolted on. @@ -86,7 +86,7 @@ For the full request/retry shape, read [x402 Payments for AI Agents](/blog/x402- ## What Tangle Adds -Tangle is not only a payment edge. Payment has to attach to work. A Blueprint defines the service, operators run it, x402 or quote logic prices it, and verification tells the caller whether to trust the result. +Tangle is more than a payment edge. Payment has to attach to work. A Blueprint defines the service, operators run it, x402 or quote logic prices it, and verification tells the caller whether to trust the result. | Layer | Product question | | --- | --- | diff --git a/src/content/blog/pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags.mdx b/src/content/blog/pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags.mdx index c12bc4b..76362e8 100644 --- a/src/content/blog/pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags.mdx +++ b/src/content/blog/pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags.mdx @@ -1,5 +1,5 @@ --- -title: 'Pricing without hand-waving: wei pricing, token conversion, markup, and dynamic price tags' +title: 'Pay-Per-Request API Pricing: Wei, Token Conversion, and Markup' slug: pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags summary: >- How Tangle's pricing engine lets operators set prices in USD and wei, convert to stablecoins with markup, sign tamper-proof quotes, and evolve from static config to dynamic pricing without redeploying. @@ -14,23 +14,23 @@ tags: - api-monetization series: x402 Production Runway seriesOrder: 3 -coverImage: /images/covers/pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags.png -heroImage: /images/covers/pricing-without-hand-waving-wei-token-conversion-markup-dynamic-price-tags.png -imageAlt: 'Wei to token conversion pipeline diagram' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -## The pricing problem nobody wants to solve +An operator is the person or service responsible for running a job. ## The pricing problem nobody wants to solve Every API platform hits the same question eventually: how do you charge for compute? AWS solved it with a 200-page pricing calculator. Stripe solved it with a dashboard and a billing team. Most blockchain protocols punt entirely, letting operators pick a number and hope it covers costs. -The hard version of this problem shows up when your operators are running heterogeneous workloads (CPU-bound inference, GPU rendering, long-running agent tasks) across different chains, settling in different tokens, with different exchange rates, and they need quotes that are cryptographically verifiable before a single cycle burns. Tangle's [pricing engine](https://github.com/tangle-network/blueprint/tree/main/crates/pricing-engine) was built for exactly this. The core of it is a conversion pipeline: operators price jobs in wei (the smallest ETH unit), and at settlement time the engine divides by 10^18 to get ETH, multiplies by an exchange rate (e.g., 3,200 USDC/ETH), applies an operator-defined markup in basis points, then scales to the token's smallest unit and floors the result to an integer. A job priced at 0.001 ETH with a 3,200 USDC/ETH rate and 2% markup (200 bps) yields 3,264,000 USDC micro-units, or $3.264. Every resulting quote is EIP-712 signed with expiry and replay protection. +The hard version of this problem shows up when your operators are running heterogeneous workloads (CPU-bound inference, GPU rendering, long-running agent tasks) across different chains, settling in different tokens, with different exchange rates, and they need quotes that are cryptographically verifiable before a single cycle burns. Tangle's [pricing engine](https://github.com/tangle-network/blueprint/tree/main/crates/pricing-engine) was built for exactly this. The core of it is a conversion pipeline: operators price jobs in wei (the smallest ETH unit), and at settlement time the engine divides by 10^18 to get ETH, multiplies by an exchange rate (e.g., 3,200 USDC/ETH), applies an operator-defined markup in basis points, then scales to the token's smallest unit and floors the result to an integer. A reported job priced at 0.001 ETH with a 3,200 USDC/ETH rate and 2% markup (200 bps) yields 3,264,000 USDC micro-units, or $3.264. Every resulting quote is EIP-712 signed with expiry and replay protection. That conversion layer sits on top of a dual-denomination pricing system (USD for resource provisioning, wei for per-job calls), three pricing models, hardware benchmarking, and a full anti-abuse stack. This post walks through each layer, what the config looks like, and where the sharp edges are. ## Blockchain API pricing: the conversion formula -Before getting into the pricing engine's architecture, here's the function that makes cross-token settlement work. The [`convert_wei_to_amount`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs) function is the bridge between blockchain-native pricing and stablecoin payments: +Before getting into the pricing engine's architecture, the function that makes cross-token settlement work. The [`convert_wei_to_amount`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs) function is the bridge between blockchain-native pricing and stablecoin payments: ```rust pub fn convert_wei_to_amount(&self, wei_price: &U256) -> Result { @@ -47,22 +47,22 @@ pub fn convert_wei_to_amount(&self, wei_price: &U256) -> Result- Recursive Self-Aggregation is a test-time scaling strategy that spends extra @@ -11,6 +11,9 @@ tags: - router - inference - research +coverImage: /images/covers/editorial/rsa-aggregation-v2.webp +heroImage: /images/covers/editorial/rsa-aggregation-v2.webp +imageAlt: 'An editorial still life about combining multiple model attempts into one answer' --- There is a version of "use a better model" that is too blunt. Sometimes the cheaper model already knows enough, but one sample is brittle. It misses a constraint, takes the wrong branch, or writes the first plausible answer. Recursive Self-Aggregation, RSA, attacks that failure mode by spending test-time compute on a population of answers and repeatedly asking the model to aggregate them. diff --git a/src/content/blog/s-corp-tax-software-basis-k1.mdx b/src/content/blog/s-corp-tax-software-basis-k1.mdx index 09e178d..e989345 100644 --- a/src/content/blog/s-corp-tax-software-basis-k1.mdx +++ b/src/content/blog/s-corp-tax-software-basis-k1.mdx @@ -11,9 +11,9 @@ tags: - k-1 series: Building an AI Tax Agent seriesOrder: 7 -coverImage: /images/products/tax-agent-app.png -heroImage: /images/products/tax-agent-app.png -imageAlt: 'Tangle Tax Agent workspace showing S corporation return, shareholder K-1s, basis workpapers, and distribution review' +coverImage: /images/covers/editorial/ai-tax-v2.webp +heroImage: /images/covers/editorial/ai-tax-v2.webp +imageAlt: 'An editorial still life about preparing a complex tax return with software' --- S corp tax software has to connect the entity return to the shareholder return. The IRS describes S corporations as entities that elect to pass corporate income, losses, deductions, and credits through to shareholders for federal tax purposes. [Form 1120-S](https://www.irs.gov/forms-pubs/about-form-1120-s) reports the income, gains, losses, deductions, credits, and related items of an S corporation. The shareholder side then needs K-1 handling, basis review, distributions, and payroll context. diff --git a/src/content/blog/self-improving-stack-agent-runtime-topology.mdx b/src/content/blog/self-improving-stack-agent-runtime-topology.mdx index 4e39e6c..04b9160 100644 --- a/src/content/blog/self-improving-stack-agent-runtime-topology.mdx +++ b/src/content/blog/self-improving-stack-agent-runtime-topology.mdx @@ -1,5 +1,5 @@ --- -title: 'When an Agent Needs More Than a Prompt' +title: 'Agent Runtime Topology: When an Agent Needs More Than a Prompt' slug: self-improving-stack-agent-runtime-topology summary: >- A prompt can request parallel work, review, or cancellation, but only the software running the agent can create those behaviors and record whether they happened. @@ -8,6 +8,9 @@ author: Drew Stone tags: ['agents', 'runtime', 'systems', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 11 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- Ask an AI coding assistant to “have three specialists work in parallel, compare their patches, and stop the losing attempts.” diff --git a/src/content/blog/self-improving-stack-evaluation-gates.mdx b/src/content/blog/self-improving-stack-evaluation-gates.mdx index 8d7a06c..b909a8c 100644 --- a/src/content/blog/self-improving-stack-evaluation-gates.mdx +++ b/src/content/blog/self-improving-stack-evaluation-gates.mdx @@ -1,5 +1,5 @@ --- -title: 'The Gate Is The Optimizer' +title: 'Evaluation Gates: The Rule That Decides Whether an Agent Improves' slug: self-improving-stack-evaluation-gates summary: >- Why held-out promotion, judge reliability, failure taxonomies, cost ceilings, and confidence intervals decide whether self-improvement is real. @@ -8,9 +8,17 @@ author: Drew Stone tags: ['agents', 'evals', 'systems', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 7 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** An evaluation gate is the promotion policy that decides whether a candidate replaces a baseline. It is part of the optimizer because it defines what counts as improvement. If the gate is weak, every optimizer learns to game it. +> **Short answer:** An evaluation gate is the release rule that decides whether a new agent version is better enough to replace the current one. + +The **baseline** is the version already in use. +The **candidate** is the proposed replacement. +A **holdout set** is a protected group of tasks kept out of tuning so the comparison can reveal overfitting. +The **harness** is the surrounding software that runs the candidate and records its work. An optimizer can propose forever. @@ -297,7 +305,7 @@ That is why judge identity belongs in the profile cell. ## Scorecards Are Cells, Not Averages -HELM pushed a simple but important idea: language model evaluation should expose multiple metrics and scenarios, not only one headline number. +HELM pushed a simple but important idea: language model evaluation should expose multiple metrics and scenarios, several metrics and scenarios rather than one headline number. Agent evaluation needs the same idea, but with runtime context. @@ -369,7 +377,7 @@ reject_or_quarantine if records are mixed real and stub flag if output tokens exist but cost is zero ``` -The mixed case matters. A partial backend failure is missing data, not agent failure. Treating missing data as bad agent behavior poisons the optimizer. It teaches the system to "fix" a candidate that was never actually evaluated. +The mixed case matters. A partial backend failure is missing data, not agent failure. Treating missing data as bad agent behavior poisons the optimizer. It teaches the system to "fix" a candidate that was never in practice evaluated. ## Semantic Fulfillment @@ -583,7 +591,7 @@ The gate is where self-improvement stops being a story about better prompts and Source freshness checked on 2026-06-06. -- [Holistic Evaluation of Language Models](https://arxiv.org/abs/2211.09110), checked June 6, 2026. +- [Complete Evaluation of Language Models](https://arxiv.org/abs/2211.09110), checked June 6, 2026. - [G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment](https://arxiv.org/abs/2303.16634), checked June 6, 2026. - [Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena](https://arxiv.org/abs/2306.05685), checked June 6, 2026. - [Evaluating Large Language Models Trained on Code](https://arxiv.org/abs/2107.03374), checked June 6, 2026. diff --git a/src/content/blog/self-improving-stack-governance.mdx b/src/content/blog/self-improving-stack-governance.mdx index a56a5ab..4766ea7 100644 --- a/src/content/blog/self-improving-stack-governance.mdx +++ b/src/content/blog/self-improving-stack-governance.mdx @@ -1,5 +1,5 @@ --- -title: 'Self-Improvement Needs A Safety Case' +title: 'Agent Governance: Self-Improvement Needs a Safety Case' slug: self-improving-stack-governance summary: >- Why prompt injection, sandbox boundaries, eval poisoning, provenance, compliance, and release gates are core to any real self-improving agent stack. @@ -8,9 +8,16 @@ author: Drew Stone tags: ['agents', 'security', 'governance', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 13 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Governance is the control plane for self-improving agents. It decides which proposed improvements may persist, what authority they may exercise, which risks block release, and who owns residual risk after the gate passes. +> **Short answer:** Governance is the set of owners, permissions, evidence requirements, and rollback rules that constrain an agent that can change itself. + +A **safety case** is a claim about acceptable use paired with its scope, evidence, remaining risks, and accountable owner. +Governance decides which proposed improvements may persist, what authority they may exercise, and what blocks release. +The **harness** is the surrounding execution software, and a **worker** is one bounded agent process inside it. A self-improving agent is an optimizer pointed at its own behavior. @@ -43,7 +50,7 @@ owner: who is accountable gate: what blocks release ``` -For a self-improving system, the safety case has to cover the loop, not only the baseline model. +For a self-improving system, the safety case has to cover the loop as well as the baseline model. The model may be safe in isolation while the agent is unsafe because it has too much authority. The prompt may be harmless while the tool graph is dangerous. The eval may look honest while the harness leaks holdout tasks. The sandbox may be strong while a delegated worker receives credentials it never needed. @@ -363,7 +370,7 @@ Measure: run evals, red teams, calibration, and trace audits Manage: block, mitigate, monitor, and respond ``` -The EU AI Act, Regulation 2024/1689, brings a risk-class structure. High-risk systems face obligations around risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, and cybersecurity. The General-Purpose AI Code of Practice was published on July 10, 2025 to help model providers comply with AI Act obligations for general-purpose AI. +The EU AI Act, Regulation 2024/1689, brings a risk-class structure. High-risk systems face obligations around risk management, data governance, technical documentation, transparency, human oversight, accuracy, durableness, and cybersecurity. The General-Purpose AI Code of Practice was published on July 10, 2025 to help model providers comply with AI Act obligations for general-purpose AI. Frontier lab policies have also become more operational. Anthropic's Responsible Scaling Policy page lists version 3.3 as effective May 26, 2026, with a changelog of 2026 updates. OpenAI published a Frontier Governance Framework on May 28, 2026 and says its Preparedness Framework remains the foundation for managing severe risks, while the new document maps safety and security practices to emerging legal requirements. Microsoft published a Frontier Governance Framework for advanced model risks and, in April 2026, introduced an open-source Agent Governance Toolkit focused on runtime security governance for autonomous agents. @@ -599,7 +606,7 @@ Prompt optimizers can improve text. Skill optimizers can improve procedure. Mult Governance decides which of those improvements are allowed to persist. -Without it, the loop can become very good at satisfying a proxy while eroding the boundary that made the proxy meaningful. +Without it, the loop can become good at satisfying a proxy while eroding the boundary that made the proxy meaningful. With it, self-improvement becomes an engineering process: @@ -633,9 +640,14 @@ Source freshness checked on 2026-06-06. - [OWASP Top 10 for LLM Applications 2025 PDF](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) - [EU AI Act, Regulation 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/) - [EU General-Purpose AI Code of Practice, July 10, 2025](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai) -- `@tangle-network/agent-runtime` local package: `/Users/drew/webb/agent-runtime` -- `@tangle-network/agent-eval` local package: `/Users/drew/webb/agent-eval` -- `@tangle-network/agent-knowledge` local package: `/Users/drew/webb/agent-knowledge` +- [Tangle agent-runtime package](https://github.com/tangle-network/agent-runtime) +- [Tangle agent-eval package](https://github.com/tangle-network/agent-eval) +- [Tangle agent-knowledge package](https://github.com/tangle-network/agent-knowledge) + +## Decision + +Choose governance work before self-improvement work when an agent can change tools, memory, permissions, or release artifacts. +If the team cannot name the owner, evidence, rollback path, and remaining risk, keep the change out of production. ## FAQ diff --git a/src/content/blog/self-improving-stack-harness-evolution.mdx b/src/content/blog/self-improving-stack-harness-evolution.mdx index 9f84cf4..f40a245 100644 --- a/src/content/blog/self-improving-stack-harness-evolution.mdx +++ b/src/content/blog/self-improving-stack-harness-evolution.mdx @@ -8,9 +8,18 @@ author: Drew Stone tags: ['agents', 'systems', 'architecture', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 10 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Harness evolution changes the machine around the model: drivers, verifiers, trace schemas, selectors, replay, tools, and release protocols. Use it when prompt and skill search plateau because the current runtime cannot express the needed action. +> **Short answer:** Changing the execution software around a model matters when better wording cannot provide the missing action. + +The harness is the code that starts the agent, exposes tools, records traces, runs checks, and decides which result is eligible for release. +A **validator** checks whether a proposed result meets a stated condition. +A **replay record** preserves enough of a run to inspect it again. +In this article, a **trace** means the recorded sequence of model responses, tool calls, artifacts, and outcomes. +Change this layer when the runtime cannot create the workers, isolation, checks, or records that the task requires. When the prompt keeps asking for a capability the runtime cannot express, stop optimizing the prompt and change the machine. @@ -125,7 +134,7 @@ That is not how practical agent systems usually work in the systems covered here Modern systems usually replace proof with empirical evaluation. They generate candidate code, run it, score it, retain useful variants, and preserve enough trace evidence to explain why the variant moved. -AlphaDev was an early vivid example in 2023. It used reinforcement learning to search low-level algorithm space and found sorting routines that DeepMind translated into C++ implementations. The Nature paper reports improvements up to 70 percent for short sequences of length five and roughly 1.7 percent for longer sequences exceeding 250,000 elements. +AlphaDev was an early vivid example in 2023. It used reinforcement learning to search low-level algorithm space and found sorting routines that DeepMind translated into C++ implementations. The Nature paper reports improvements across tested short sequences of length five of up to 70 percent and roughly 1.7 percent on reported sequences exceeding 250,000 elements. FunSearch, also from 2023, made the evaluator-driven shape clearer for LLMs. The key premise was that many scientific and mathematical problems are hard to solve but easy to evaluate. The system evolved code fragments, scored them with a systematic evaluator, maintained diversity, and used the best programs as context for future samples. @@ -338,7 +347,7 @@ variant B adds a stronger verifier variant C combines A and B without inheriting their regressions ``` -Lineage merging is different from picking the current best score. It treats architecture as compositional. The value of a variant is not only its score, but the mechanism it contributes to future candidates. +Lineage merging is different from picking the current best score. It treats architecture as compositional. The value of a variant is the mechanism it contributes as well as its score, but the mechanism it contributes to future candidates. ## Worktrees Are Part Of The Algorithm @@ -367,7 +376,7 @@ A candidate that edits the harness must be treated like a release artifact, not ## The Proxy-Metric Trap -Architecture search is powerful enough to make bad metrics worse. +Architecture search is useful enough to make bad metrics worse. A prompt optimizer can overfit a phrase. A harness optimizer can overfit the entire measurement apparatus. @@ -401,7 +410,8 @@ If the optimizer can edit the gate and then pass the gate, it did not improve th The local Tangle source audit on June 6, 2026 shows the split clearly. -The audited source trees report `@tangle-network/agent-eval` package version `0.34.1` and `@tangle-network/agent-runtime` package version `0.26.0`. The runtime manifest currently depends on `@tangle-network/agent-eval` `^0.40.2`, so the mapping below is a source-placement claim rather than an npm compatibility claim. +The public package boundary matters more than a local source snapshot. +The [agent-eval package](https://github.com/tangle-network/agent-eval) covers measurement and promotion records, while the [agent-runtime package](https://github.com/tangle-network/agent-runtime) covers execution and candidate lifecycles. `@tangle-network/agent-eval` is the measurement and promotion substrate. The audited local source exposes: @@ -599,7 +609,7 @@ Source freshness checked on 2026-06-06. ### What is harness evolution? -Harness evolution changes the code around the model: planners, drivers, verifiers, budget policies, trace schemas, replay layers, selectors, tools, and worktree candidate lifecycles. It widens the set of behaviors the agent can actually execute. +Harness evolution changes the code around the model: planners, drivers, verifiers, budget policies, trace schemas, replay layers, selectors, tools, and worktree candidate lifecycles. It widens the set of behaviors the agent can in practice execute. ### When should a team evolve the harness instead of the prompt? diff --git a/src/content/blog/self-improving-stack-memory-flywheels.mdx b/src/content/blog/self-improving-stack-memory-flywheels.mdx index 370cc8c..6206d48 100644 --- a/src/content/blog/self-improving-stack-memory-flywheels.mdx +++ b/src/content/blog/self-improving-stack-memory-flywheels.mdx @@ -8,15 +8,23 @@ author: Drew Stone tags: ['agents', 'memory', 'knowledge', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 6 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Agent memory is not learning by default. It becomes learning only when a trace produces a scoped write, the write is gated, retrieval happens in the right context, and a paired eval shows the future run improved. Otherwise memory is just a larger prompt with more ways to preserve mistakes. +> **Short answer:** Agent memory becomes useful when a past run produces a scoped note, the next run retrieves it in the right situation, and a comparison shows that the result improved. + +**Memory** is information carried from one agent run to another. +A **trace** is the record of a past run. +**Retrieval** is the step that chooses which saved information to show the agent now. +Saving more text is not the same as learning; an incorrect note can repeat the same failure. Remembering more is not learning. Learning means the next run changes in the right direction. -Memory is one way to change the next run without changing model weights. It lets an agent carry evidence, preferences, decisions, failures, and procedures across episodes. That makes memory powerful. It also makes memory dangerous. +Memory is one way to change the next run without changing model weights. It lets an agent carry evidence, preferences, decisions, failures, and procedures across episodes. That makes memory useful. It also makes memory dangerous. Persistent state is inherited by future behavior. A bad prompt can ruin one run. A bad memory can keep ruining runs until something expires, contradicts, or deletes it. @@ -195,7 +203,7 @@ The retriever selects admitted memory for a future task: Retrieve(M_{t+1}, q, policy) -> context ``` -Then the evaluator measures whether the retrieval actually helped. +Then the evaluator measures whether the retrieval in practice helped. That last step is where many memory systems become cargo cults. They store more, retrieve more, and show more context to the model, but never run the paired ablation: @@ -206,7 +214,7 @@ same tool surface with memory versus without memory ``` -Without that ablation, memory success is often just retrieval theater. +Without that ablation, memory success is often retrieval theater. ## The Write Gate @@ -334,7 +342,7 @@ do not collapse supervisor and worker roles for this task class do not retry a failed deploy hook without checking logs ``` -This is often the difference between an agent that keeps repeating a class of mistake and one that actually compounds. +This is often the difference between an agent that keeps repeating a class of mistake and one that in practice compounds. But negative knowledge needs expiration and scope. @@ -356,20 +364,9 @@ Negative memory is not cynicism. It is a falsifiable constraint. Procedural memory is close to skill optimization, but the distinction is useful. -A memory can say: - -```text -when patching a repo, inspect status and the last few commits first -``` +A memory can say that a repository should be inspected before it is edited. -A skill can operationalize it: - -```text -inputs: repo path -preconditions: git worktree exists -steps: status, log, reflog, open PRs -verification: no live rebase, no mid-merge, branch context known -``` +A skill can make that lesson executable by naming its inputs, preconditions, inspection steps, and checks for an unfinished merge or rebase. The skill has an invocation contract, parameters, steps, and verification. The memory is the durable lesson that motivates or updates the skill. @@ -452,7 +449,7 @@ It is the substrate that lets topology improve across episodes. ## Knowledge Poisoning -Knowledge poisoning is not merely "the agent did not know something." +Knowledge poisoning is more serious than a missing fact in the agent's context. A gap is: @@ -626,7 +623,7 @@ A memory system is doing real self-improvement when all of these are true: If any part is missing, the system may still be useful, but it is not a disciplined learning loop. -It may just be a larger prompt with a longer memory leak. +It may be a larger prompt with a longer memory leak. ## Sources For Memory diff --git a/src/content/blog/self-improving-stack-multi-agent-coordination.mdx b/src/content/blog/self-improving-stack-multi-agent-coordination.mdx index 6a4dda4..7526611 100644 --- a/src/content/blog/self-improving-stack-multi-agent-coordination.mdx +++ b/src/content/blog/self-improving-stack-multi-agent-coordination.mdx @@ -1,5 +1,5 @@ --- -title: 'Personas Are Content, Coordination Is Structure' +title: 'Multi-Agent Coordination: Personas Are Content, Coordination Is Structure' slug: self-improving-stack-multi-agent-coordination summary: >- How driver, worker, selector, reviewer, analyst, and coordinator roles become reliable multi-agent systems instead of roleplay. @@ -8,6 +8,9 @@ author: Drew Stone tags: ['agents', 'multi-agent', 'systems', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 12 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- > **Short answer:** Multi-agent coordination is not roleplay. It becomes real when agents have contracts, authority boundaries, tool permissions, state isolation, selection rules, budgets, and traces. More agents only help when disagreement becomes useful evidence under an equal-compute gate. @@ -163,7 +166,7 @@ If the gain disappears at matched budget, the system did not learn coordination. If the gain disappears when workers use isolated context, the system may have been copying. If the gain disappears when the selector is replaced with a deterministic verifier, the selector may have been rewarding style. If the gain disappears on held-out tasks, the role split overfit the benchmark. -This is the central test: does the coordination policy create useful diversity, or just more tokens? +This is the central test: does the coordination policy create useful diversity, or more tokens? ## Lineage: From Sampling To Societies diff --git a/src/content/blog/self-improving-stack-optimization-theory.mdx b/src/content/blog/self-improving-stack-optimization-theory.mdx index 19f94fc..cc9dd1b 100644 --- a/src/content/blog/self-improving-stack-optimization-theory.mdx +++ b/src/content/blog/self-improving-stack-optimization-theory.mdx @@ -1,5 +1,5 @@ --- -title: 'Optimization Theory For Agent Builders' +title: 'Optimization Theory for Agent Builders' slug: self-improving-stack-optimization-theory summary: >- A compact map from hill climbing and Bayesian search to GEPA, SkillOpt, Frontier Tuning, agent runtimes, and noisy promotion gates. @@ -8,11 +8,20 @@ author: Drew Stone tags: ['agents', 'evals', 'optimization', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 4 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Agent self-improvement is search under budget over a chosen mutable surface. Prompts, skills, topology, harness code, memory policy, and model weights can all be optimized, but they are not interchangeable. The layer determines the reachable changes, the evidence needed, and the failure modes. +> **Short answer:** Agent self-improvement is a search process that proposes a change, runs it, measures it, and decides whether to keep it. -Every self-improving agent pitch eventually reduces to three questions. +Optimization theory for agent builders asks which change caused an improvement and whether that improvement survives a new task. + +The **mutable surface** is the part allowed to change: a prompt, a skill, a workflow, a program, memory, or model weights. +An **evaluator** is the test that scores the result. +A **promotion gate** is the release rule that compares the candidate with the current version. + +Every self-improving system reduces to three questions. What can change? What gets scored? What is allowed to ship? @@ -67,7 +76,7 @@ An optimizer is an operator: s_next = O(s_current, traces, feedback, budget) ``` -`O` can be a human writing a new prompt. It can be Bayesian optimization. It can be an LLM reflecting on failures. It can be evolutionary mutation. It can be reinforcement learning. The operator matters, but a weak gate dominates a clever operator. A sophisticated mutator with a bad score function is just a faster way to overfit. +`O` can be a human writing a new prompt. It can be Bayesian optimization. It can be an LLM reflecting on failures. It can be evolutionary mutation. It can be reinforcement learning. The operator matters, but a weak gate dominates a clever operator. A sophisticated mutator with a bad score function is a faster way to overfit. The promotion rule separates engineering from theater: @@ -139,7 +148,7 @@ This table compresses the argument. These systems rhyme because they all search. Prompt optimization is the most accessible layer. DSPy made it feel like programming rather than prompt archaeology: define signatures and modules, define a metric, then let optimizers improve the prompts or examples used inside the LM program. MIPROv2 bootstraps few-shot candidates, proposes data-aware instructions, then uses Bayesian optimization to search combinations of instructions and demonstrations. Ax brings a similar style into a production TypeScript surface with agents, flows, optimization artifacts, and GEPA/MiPRO-style optimizers. -GEPA moves the center of gravity toward reflection and evolution. It samples trajectories, uses language feedback to diagnose what happened, proposes textual changes, and uses Pareto selection to combine useful lessons. The striking claim in the GEPA paper is not merely that prompt evolution works. It is that language feedback can be much more sample efficient than sparse scalar reward for certain compound AI systems. +GEPA moves the center of gravity toward reflection and evolution. It samples trajectories, uses language feedback to diagnose what happened, proposes textual changes, and uses Pareto selection to combine useful lessons. The striking claim in the GEPA paper is that prompt evolution works. It is that language feedback can be much more sample efficient than sparse scalar reward for certain compound AI systems. SkillOpt shifts the artifact from prompt to skill. A skill file is not a one-off instruction in a single prompt. It is durable external state. It can encode procedures, domain heuristics, tool policies, failure cases, and coordination patterns that survive across tasks. SkillOpt treats that document as trainable text. A separate optimizer model proposes bounded add, delete, or replace edits based on scored rollouts. Edits are accepted only when they improve held-out validation. That is a much more disciplined frame than "ask the agent to rewrite its own instructions." @@ -147,7 +156,7 @@ AlphaEvolve-style systems shift the artifact again, from text guidance to execut Frontier Tuning and MAI sit at a heavier layer. Microsoft describes a hill-climbing machine around more compute, better data, sharper evaluation, and reinforcement learning environments. Frontier Tuning, as announced at Build 2026, applies reinforcement learning inside an enterprise compliance boundary using workflow data, tool usage, eval signals, and domain conventions. It can produce tuned models, embeddings, skills, orchestration logic, and a runtime harness. That is model and system adaptation inside a controlled environment, not prompt search with better branding. -The local agent-runtime and agent-eval story belongs in the runtime layer. A runtime decides what work actually runs: which agent is called, which tools exist, how many turns are available, whether subagents can fan out, how traces are emitted, and how failures propagate. An eval package decides whether the candidate earned promotion: held-out tasks, scorecards, trace analysts, failure taxonomies, and gates. In that frame, meta-harness is architecture search above ordinary prompt or skill tuning. +The local agent-runtime and agent-eval story belongs in the runtime layer. A runtime decides what work in practice runs: which agent is called, which tools exist, how many turns are available, whether subagents can fan out, how traces are emitted, and how failures propagate. An eval package decides whether the candidate earned promotion: held-out tasks, scorecards, trace analysts, failure taxonomies, and gates. In that frame, meta-harness is architecture search above ordinary prompt or skill tuning. ## Why Prompt Optimization Does Not Automatically Solve Multi-Agent Workflow Design @@ -155,7 +164,7 @@ The confusion shows up hardest in multi-agent workflows. A driver persona can be optimized as text. A supervisor instruction can be optimized as text. Tool descriptions can be optimized as text. A subworker directive can be optimized as text. -But a multi-agent workflow is not only text. +But a multi-agent workflow includes more than text. Consider the way a human directs a coding agent: @@ -170,7 +179,7 @@ protect user changes Some of that is instruction text. Some of it is runtime capability. "Parallelize independent file reads" only matters if the agent has a tool wrapper that can execute independent calls concurrently. "Run the tests" only matters if the agent can access the repo, install dependencies, execute commands, and read failures. "Do not stop at a plan" only matters if the control loop allows more than one step. A `maxTurns=0` setting is not a personality flaw. It is a control-surface constraint. -"Just GEPA it" is not a complete answer for multi-agent systems. +"Run GEPA" is not a complete answer for multi-agent systems. GEPA can improve textual artifacts if the workflow is represented in text and the evaluator can score the result. It can discover better instructions for a coordinator. It can improve tool descriptions. It can learn from traces and propose wording that makes an agent more reliable. @@ -188,7 +197,7 @@ Model optimizer: changes the policy inside the model itself. That split determines what kind of evidence you need. -If a prompt changes, a held-out prompt eval may be enough. If a skill changes, you need multi-task evidence that the skill transfers and does not encode bad habits. If runtime topology changes, you need traces showing that the new graph actually changed execution in the intended way. If code changes, you need executable tests and sandboxing. If weights change, you need safety, privacy, and governance gates that are much stronger than a normal prompt eval. +If a prompt changes, a held-out prompt eval may be enough. If a skill changes, you need multi-task evidence that the skill transfers and does not encode bad habits. If runtime topology changes, you need traces showing that the new graph in practice changed execution in the intended way. If code changes, you need executable tests and sandboxing. If weights change, you need safety, privacy, and governance gates that are much stronger than a normal prompt eval. ## The Math Of Promotion @@ -207,9 +216,9 @@ So the promotion rule needs uncertainty: promote if lower_confidence_bound(mean_delta) > epsilon ``` -`epsilon` matters. A candidate that improves a benchmark by 0.1 percentage points while increasing cost by 40 percent is not a meaningful improvement for most products. A candidate that improves a rare but high-severity failure mode may be worth it even if the average score barely moves. The margin should reflect the product decision, not only statistical significance. +`epsilon` matters. A candidate that improves a benchmark across 20 measured tasks by 0.1 percentage points while increasing the same workload's cost by 40 percent is not a meaningful improvement for most products. A candidate that improves a rare but high-severity failure mode may be worth it even if the average score barely moves. The margin should reflect the product decision, the product decision as well as statistical significance. -For agents, the score is rarely one-dimensional. Quality, cost, latency, robustness, safety, and trace integrity all matter. That leads to Pareto thinking: +For agents, the score is rarely one-dimensional. Quality, cost, latency, durableness, safety, and trace integrity all matter. That leads to Pareto thinking: ```text candidate A dominates B if: @@ -219,13 +228,13 @@ candidate A dominates B if: and at least one inequality is strict ``` -Many real candidates do not dominate each other. One is better and slower. Another is cheaper and less robust. Another is safer but more verbose. This is why GEPA's Pareto framing is natural for compound systems, and why agent-eval style scorecards are more useful than a single magic number. +Many real candidates do not dominate each other. One is better and slower. Another is cheaper and less durable. Another is safer but more verbose. This is why GEPA's Pareto framing is natural for compound systems, and why agent-eval style scorecards are more useful than a single magic number. The promotion packet should answer: - Did quality improve? - Did cost or latency regress? -- Did robustness improve on held-out tasks? +- Did durableness improve on held-out tasks? - Did the candidate fail on any protected scenario? - Is the win larger than expected noise? - Is the comparison compute-matched? @@ -239,7 +248,7 @@ A common mistake in agent evaluation is comparing an optimized system against a If the optimizer tries 24 candidates and picks the best, the fair baseline is not a single human-written prompt evaluated once. A fairer baseline might include random@24, best-of-N over the original prompt, a stronger model at equal cost, or a human edit with the same time budget. -The same issue appears at inference time. Suppose a new agent workflow performs better because it fans out to five subagents and votes. Is the prompt better, or did the system simply spend more compute? More compute for higher reliability can be the right product decision, but it should be named correctly. +The same issue appears at inference time. Suppose a new agent workflow performs better because it fans out to five subagents and votes. Is the prompt better, or did the system directly spend more compute? More compute for higher reliability can be the right product decision, but it should be named correctly. Optimization claims should be compute-matched whenever possible: @@ -248,7 +257,7 @@ Did the candidate beat random@k? Did it beat best-of-N? Did it beat a stronger model at the same cost? Did it beat the old system with the same retry budget? -Did it win on held-out tasks, not only on the search set? +Did it win on held-out tasks as well as the search set? ``` Test-time compute is part of the optimizer story. A system can improve by learning a better artifact, by spending more inference budget, or by doing both. Those are different levers. @@ -273,7 +282,7 @@ Skill poisoning is the persistent-state version. A bad rule in a one-off prompt ## Which Layer Should You Optimize? -A practical rule: optimize the lowest layer that actually explains the failure. +A practical rule: optimize the lowest layer that in practice explains the failure. If the system knows what to do but says it poorly, optimize the prompt. @@ -314,7 +323,7 @@ If any line is blank, the system is not ready for autonomous improvement. It may The evaluation layer is not secondary. It is the thing that makes optimization legitimate. Agent-eval style traces, scorecards, held-out gates, and failure taxonomies are not paperwork. They are the control system that keeps the improvement loop attached to reality. -## What Is Actually New Right Now +## What Is In practice New Right Now The current wave moves optimization outward from model weights into the artifacts around the model. @@ -326,7 +335,7 @@ The through-line is simple: If you can represent it, vary it, score it, and gate it, you can optimize it. ``` -The catch is just as simple: +The catch is straightforward: ```text If you score the wrong thing, you optimize the wrong thing. diff --git a/src/content/blog/self-improving-stack-post-training.mdx b/src/content/blog/self-improving-stack-post-training.mdx index e620f3b..02d0baa 100644 --- a/src/content/blog/self-improving-stack-post-training.mdx +++ b/src/content/blog/self-improving-stack-post-training.mdx @@ -1,5 +1,5 @@ --- -title: 'When The Model Itself Is Mutable' +title: 'Post-Training Agents: When the Model Itself Is Mutable' slug: self-improving-stack-post-training summary: >- How SFT, RLHF, process supervision, tool-use RL, and Microsoft Frontier Tuning differ from public prompt, skill, and harness loops. @@ -8,9 +8,17 @@ author: Drew Stone tags: ['ai', 'agents', 'models', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 5 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Post-training is the layer where the model itself becomes mutable. It can move behavior that prompts and harnesses cannot, but it also moves the rollback, privacy, evaluation, and governance boundary. The key question is whether the behavior belongs in weights or should stay in external system state. +> **Short answer:** Post-training changes the model’s learned behavior rather than only changing the prompt around it. + +**Model weights** are the learned parameters that produce the model’s behavior. +**Post-training** updates those parameters or an adapter attached to them. +That can teach a broad behavior, but it also makes rollback, privacy review, testing, and ownership more demanding than changing a prompt or skill. +In this article, a **harness** is the surrounding execution software, and a **trace** is the record of one run. Most self-improving agent systems that product teams can ship without model-training infrastructure do not change model weights. @@ -112,7 +120,7 @@ train the model to put probability mass on the demonstrated output: L_SFT(theta) = - sum_i log pi_theta(y_i | x_i) ``` -This is powerful when demonstrations are clean and the task distribution is stable. +This is useful when demonstrations are clean and the task distribution is stable. It is weak when the demonstration only shows the final artifact but not the decision boundary. A model can learn the style of a successful support response, code review, or tax memo without learning the latent policy that made it correct. @@ -389,16 +397,7 @@ harness code eval gates ``` -They are easy to inspect: - -```text -git diff -trace replay -scorecard diff -rollback commit -feature flag -heldout gate -``` +They are comparatively easy to inspect because a reviewer can compare the changed files, replay a recorded run, inspect the score change, and return to the previous version. Weight-level loops are stronger but less locally inspectable. @@ -543,7 +542,7 @@ access_policy deprecation_plan ``` -Without that lineage, model-level self-improvement is not a controlled system. It is just drift with a training budget. +Without that lineage, model-level self-improvement is not a controlled system. It is drift with a training budget. ## The Layer Boundary diff --git a/src/content/blog/self-improving-stack-prompt-optimization.mdx b/src/content/blog/self-improving-stack-prompt-optimization.mdx index 5bf3a0d..5d04a67 100644 --- a/src/content/blog/self-improving-stack-prompt-optimization.mdx +++ b/src/content/blog/self-improving-stack-prompt-optimization.mdx @@ -8,11 +8,19 @@ author: Drew Stone tags: ['agents', 'prompts', 'evals', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 2 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Prompt optimization improves language-shaped control surfaces: instructions, examples, tool descriptions, schemas, and rubrics. It is the right move when text controls the failure. It is the wrong move when the missing capability lives in runtime topology, tools, traces, memory, or the evaluation gate. +> **Short answer:** Prompt optimization searches for better instructions, examples, tool descriptions, schemas, and judging rules. -Prompt optimization is a real optimization discipline, not a theory of the whole agent. +A **prompt** is the text sent to a model to describe the task and constraints. +An **agent runtime** is the software that gives the model tools, stores the run, and controls the loop. +In this article, a **worker** is one running copy of the agent. +Prompt search is useful when the failure is in that text; it cannot create a missing tool, worker, sandbox, or run record. + +Prompt optimization is a real engineering discipline, but it does not describe the whole agent. GEPA, MIPRO, DSPy, AxLLM, TextGrad, OPRO, and APE all search through language-shaped control surfaces. They can improve instructions, demonstrations, field descriptions, tool docs, judge rubrics, and the prompts embedded inside multi-stage LM programs. @@ -20,7 +28,7 @@ They are not automatically searching the full agent system. That distinction matters because modern agents do not fail only because the prompt is poorly worded. They fail because the tool surface is wrong, the retrieval policy is stale, the runtime cannot express fanout, the evaluator rewards the wrong behavior, the model is underpowered, the trace is incomplete, the budget is too tight, or the coordinator is operating with the wrong topology. -Prompt optimization is the right layer when a text surface has causal leverage over the failure. It is the wrong layer when the missing capability lives outside text. +Prompt optimization is the right layer when a text surface has causal use over the failure. It is the wrong layer when the missing capability lives outside text. The serious version of the question is: @@ -173,7 +181,7 @@ GEPA: MIPRO asks, "Which instruction and demo combination scores best under this program and metric?" GEPA asks, "What did the traces teach us, and which candidate variants preserve complementary lessons?" -That distinction becomes central for agents. Agent failures are often procedural and trajectory-level. The wrong tool call, missing verification step, premature stop, or poor delegation policy may not be visible from final answer text alone. GEPA-style reflection has more leverage when the trace is rich enough to explain the failure. +That distinction becomes central for agents. Agent failures are often procedural and trajectory-level. The wrong tool call, missing verification step, premature stop, or poor delegation policy may not be visible from final answer text alone. GEPA-style reflection has more use when the trace is rich enough to explain the failure. ## Where Multi-Agent Workflows Break The Simplification @@ -226,7 +234,7 @@ J(s) = E_{x ~ D}[R(run(s, x))] - lambda_cost*C - lambda_risk*K Now the loop is no longer pure prompt optimization. It is system optimization. GEPA-style reflection may still be part of the proposal operator, but the mutable surface is larger than prompts. -This is where meta-harnesses enter. A meta-harness does not merely tune wording inside one harness. It searches over code, architecture, eval plumbing, candidate generators, and workflow topology. Its failure mode is also larger: it can improve the harness while weakening the real product task. That is why trace integrity and held-out promotion become stricter as the mutable surface expands. +This is where meta-harnesses enter. A meta-harness does more than tune wording inside one harness. It searches over code, architecture, eval plumbing, candidate generators, and workflow topology. Its failure mode is also larger: it can improve the harness while weakening the real product task. That is why trace integrity and held-out promotion become stricter as the mutable surface expands. ## The Tangle Placement @@ -266,7 +274,7 @@ Minimum protocol: 3. Register baseline prompt/config hash. 4. Generate candidates with stable ids and rationales. 5. Run paired comparisons on identical scenario/seed cells. -6. Preserve full traces, not only final scores. +6. Preserve full traces alongside final scores. 7. Reject candidates that violate schema or safety invariants. 8. Promote only on held-out lift, cost budget, and regression checks. ``` @@ -348,7 +356,7 @@ Do not use prompt optimization as the primary fix when the traces show a capabil - The harness hides errors. - The loop stops before the required actions can occur. -Robust agent stacks do not pick one optimizer and call it the answer. They route failures to the layer with causal control: +Durable agent stacks do not pick one optimizer and call it the answer. They route failures to the layer with causal control: ```text wording failure -> prompt optimizer @@ -366,7 +374,7 @@ They share the same skeleton: propose, run, score, compare, mutate, promote. They do not optimize the same surface. -Prompt optimization is one coordinate in the larger search space. It is powerful because language is now both a control surface and a feedback channel. It is limited because real agents are not made of language alone. Strong systems use GEPA, MIPRO, DSPy, AxLLM, and TextGrad-style methods where text has leverage, then hand off to runtime, eval, skill, memory, code, or model optimization when traces prove the bottleneck lives somewhere else. +Prompt optimization is one coordinate in the larger search space. It is useful because language is now both a control surface and a feedback channel. It is limited because real agents are not made of language alone. Strong systems use GEPA, MIPRO, DSPy, AxLLM, and TextGrad-style methods where text has use, then hand off to runtime, eval, skill, memory, code, or model optimization when traces prove the bottleneck lives somewhere else. ## Sources For Prompt Optimization @@ -387,7 +395,7 @@ Source freshness checked on 2026-06-06. ### What is prompt optimization? -Prompt optimization is search over language-shaped control surfaces: instructions, examples, field descriptions, tool docs, judge rubrics, and LM-program prompts. It is useful when text has causal leverage over the failure. +Prompt optimization is search over language-shaped control surfaces: instructions, examples, field descriptions, tool docs, judge rubrics, and LM-program prompts. It is useful when text has causal use over the failure. ### When is prompt optimization the wrong tool? diff --git a/src/content/blog/self-improving-stack-skill-optimization.mdx b/src/content/blog/self-improving-stack-skill-optimization.mdx index ed1d085..8f102c0 100644 --- a/src/content/blog/self-improving-stack-skill-optimization.mdx +++ b/src/content/blog/self-improving-stack-skill-optimization.mdx @@ -8,9 +8,16 @@ author: Drew Stone tags: ['agents', 'skills', 'evals', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 3 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Skill optimization trains durable procedures that persist across runs. It is useful when the agent repeats the same operating mistake and the fix should become reusable behavior. The hard part is not writing the skill. The hard part is proving it triggers at the right time and does not become behavioral debt. +> **Short answer:** Skill optimization improves a reusable procedure that an agent can load on future tasks. + +A **skill** is a saved procedure: when a task matches this situation, take these actions and check these conditions. +It is useful when the same operational mistake recurs, but a saved procedure can also spread a bad habit. +The test is whether the skill helps the intended tasks and stays quiet on unrelated ones. A prompt steers an agent inside the current context. @@ -36,7 +43,7 @@ It is not identical to a prompt, memory, tool, or runtime. | Memory | facts, preferences, past observations | changes what context is recalled | stale or poisoned state | | Tool | executable affordance | expands the action space | unsafe side effects | | Skill | reusable procedure | changes how the agent operates across tasks | persistent bad habits | -| Runtime | loop, topology, budgets, dispatch | controls what actually executes | fake autonomy or hidden confounding | +| Runtime | loop, topology, budgets, dispatch | controls what in practice executes | fake autonomy or hidden confounding | Claude Code skills make this practical: a `SKILL.md` file has frontmatter for discovery and markdown instructions for execution, optionally with supporting files and scripts. Anthropic's docs describe skills as dynamically loaded task procedures, with progressive disclosure so long instructions are loaded only when relevant. That is an operational distinction, not cosmetic packaging. @@ -152,7 +159,7 @@ prompt success = better behavior on the current eval distribution skill success = better behavior on future tasks where activation is justified ``` -That future-facing property makes skills more powerful and more dangerous. A bad prompt can damage one generation. A bad skill can train the whole operator into a recurring failure mode. +That future-facing property makes skills more useful and more dangerous. A bad prompt can damage one generation. A bad skill can train the whole operator into a recurring failure mode. Skill optimization therefore needs tests that prompt optimization can sometimes skip: @@ -170,7 +177,7 @@ If a skill system does not test these, it is not training durable state. It is a Skills are operational text. They are not passive documentation. -That is why the 2026 security work on `SKILL.md` supply-chain attacks is important. The attack surface is not only malicious code inside a skill package. Natural-language metadata and instructions can influence discovery, ranking, selection, loading, and governance. An adversarial skill can win retrieval, frame itself as safer or more relevant, and evade review through wording alone. +That is why the 2026 security work on `SKILL.md` supply-chain attacks is important. The attack surface includes malicious code inside a skill package as well as deceptive instructions. Natural-language metadata and instructions can influence discovery, ranking, selection, loading, and governance. An adversarial skill can win retrieval, frame itself as safer or more relevant, and evade review through wording alone. This changes the promotion criteria for skill optimization. @@ -187,7 +194,7 @@ revocation safety: can we disable it and recover? This is where skill optimization differs from skill generation. Generating a useful skill is only half the problem. Operating a skill ecosystem requires provenance, versioning, linting, evals, trust boundaries, and rollback. -Ecosystem data points in the same direction. A 2026 data-driven analysis of 40,285 publicly listed skills found rapid publication bursts, redundancy, heavy concentration in software workflows, and safety risks around state-changing or system-level actions. A world with thousands of skills needs selection and governance, not only more skill files. +Ecosystem data points in the same direction. A 2026 data-driven analysis of 40,285 publicly listed skills found rapid publication bursts, redundancy, heavy concentration in software workflows, and safety risks around state-changing or system-level actions. A world with thousands of skills needs selection and governance, rather than more skill files. ## The Tangle Placement @@ -264,7 +271,7 @@ Minimum protocol: 3. Split tasks into search, validation, holdout, and transfer sets. 4. Run with and without the skill to estimate marginal effect. 5. Track activation decisions as first-class events. -6. Preserve full traces, not only task scores. +6. Preserve full traces alongside task scores. 7. Reject skills that violate tool, security, schema, or scope constraints. 8. Promote only if held-out lift clears uncertainty and cost gates. 9. Run interference tests outside the declared skill scope. @@ -296,7 +303,7 @@ promote(k_new) if: and median_cost <= cost_ceiling ``` -A skill that improves its target task but triggers on unrelated work is not a clean win. A skill that improves a benchmark but requires a 3x token load every turn may not be deployable. A skill that improves one model while harming another may still be useful, but it needs model-specific scoping. +A skill that improves its target task but triggers on unrelated work is not a clean win. A skill that improves a benchmark across 12 measured tasks but requires a 3x token load on every turn may not be deployable. A skill that improves one model while harming another may still be useful, but it needs model-specific scoping. ## Failure Modes diff --git a/src/content/blog/self-improving-stack-test-time-compute.mdx b/src/content/blog/self-improving-stack-test-time-compute.mdx index 1c255ba..24d0da0 100644 --- a/src/content/blog/self-improving-stack-test-time-compute.mdx +++ b/src/content/blog/self-improving-stack-test-time-compute.mdx @@ -1,5 +1,5 @@ --- -title: 'Beat Random At Equal Compute First' +title: 'Test-Time Compute: Beat Random at Equal Compute First' slug: self-improving-stack-test-time-compute summary: >- Why best-of-N, self-consistency, verifier reranking, and compute-matched controls are the baseline for agent topology claims. @@ -8,9 +8,15 @@ author: Drew Stone tags: ['agents', 'evals', 'reasoning', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 9 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Test-time compute is extra work spent after the model is fixed: samples, branches, retries, verifier calls, tools, and debate. Before calling a strategy intelligent, compare it against the best simple use of the same budget. +> **Short answer:** Test-time compute is the extra work spent on one task after the model is fixed, such as repeated samples, branches, retries, tool calls, or review. + +The **compute budget** is the allowed amount of tokens, time, money, or tool work for that task. +Compare a complex workflow with a simple baseline using the same budget before attributing a gain to coordination. More agents is not a strategy. @@ -86,7 +92,7 @@ A fair comparison fixes the relevant parts of `B`, or it reports the tradeoff in | Strategy | Budget it spends | Fair baseline | Failure mode | |---|---|---|---| -| Repeated sampling | More model calls and tokens | Best-of-N random samples at the same N | Looks good because it simply got more attempts | +| Repeated sampling | More model calls and tokens | Best-of-N random samples at the same N | Looks good because it directly got more attempts | | Self-consistency | More samples plus aggregation | Majority vote with identical sample count | Collapses when wrong answers are correlated | | Verifier reranking | Extra judge/verifier calls | Random or heuristic rerank at equal calls | Optimizes judge preference instead of task success | | Tree search | Branching calls, state storage, verifier budget | Beam or breadth strategy with same branch count | Explores impressive branches that cannot be executed | @@ -116,7 +122,7 @@ y_i ~ q_m(y | x), i = 1..k y_hat = sigma_blind({y_i}) ``` -This asks: what happens if we just buy more attempts? +This asks: what happens if we buy more attempts? **Pass@k** @@ -153,7 +159,7 @@ y_hat = sigma(x, {y_1, ..., y_k}) score = R(y_hat) ``` -This is production-like only if `sigma` is available at deployment time. A hidden answer key, private unit tests, or human judge may be useful for measurement. It is not a runtime selector unless the product can actually call it. +This is production-like only if `sigma` is available at deployment time. A hidden answer key, private unit tests, or human judge may be useful for measurement. It is not a runtime selector unless the product can in practice call it. **Self-consistency** @@ -165,7 +171,7 @@ a_i = final answer extracted from z_i y_hat = argmax_a count(a_i = a) ``` -It is powerful when correct answers are stable attractors and wrong answers are diverse. It is weaker for open-ended artifact quality, where many outputs are plausible and no answer string gets a majority. +It is useful when correct answers are stable attractors and wrong answers are diverse. It is weaker for open-ended artifact quality, where many outputs are plausible and no answer string gets a majority. **Verifier rerank** @@ -209,7 +215,7 @@ Selection asks: Could the system identify that candidate without oracle labels? ``` -The two curves can be very different. +The two curves can be different. ```text coverage_k = P(exists i: R(y_i) = 1) @@ -312,7 +318,7 @@ The policy is only good if those observations predict downstream reward. If the Test-time compute shifts pressure onto selection. -If the verifier is strong, repeated sampling becomes powerful. If the verifier is weak, more candidates can make things worse because the selector gets more chances to choose a fluent failure. +If the verifier is strong, repeated sampling becomes useful. If the verifier is weak, more candidates can make things worse because the selector gets more chances to choose a fluent failure. A verifier can be: @@ -481,7 +487,7 @@ promote(strategy_new) if: and deterministic_failures == 0 ``` -The baseline should be the strongest simple strategy the product could actually deploy, not a strawman. +The baseline should be the strongest simple strategy the product could in practice deploy, not a strawman. ## Failure Modes diff --git a/src/content/blog/self-improving-stack-trace-systems.mdx b/src/content/blog/self-improving-stack-trace-systems.mdx index 8370bae..8ee791b 100644 --- a/src/content/blog/self-improving-stack-trace-systems.mdx +++ b/src/content/blog/self-improving-stack-trace-systems.mdx @@ -8,9 +8,16 @@ author: Drew Stone tags: ['agents', 'traces', 'evals', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 8 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** Traces are the evidence layer for self-improving agents. Scores say that something happened. Traces preserve enough mechanism to explain why it happened, what changed, what failed, and what the next candidate should repair. +> **Short answer:** A trace is the run record that explains what an agent did, what its tools returned, and why the result passed or failed. + +A **score** gives one summary value. +A **trace** keeps the steps behind that value: the task, model response, tool calls, artifacts, retries, timing, cost, and outcome. +Without that record, an improvement loop can see that it lost but cannot identify what to repair. Scores tell you that something happened. @@ -80,7 +87,7 @@ Without those variables, the optimizer is moving an unidentified intervention ag | Trace field | Human reason it matters | Optimization mistake if missing | |---|---|---| | `model` and `promptSha` | Separates model behavior from prompt behavior | Treats a backend regression as a prompt issue | -| `toolName` and arguments | Shows what the agent actually attempted | Optimizes narration while the tool call stays wrong | +| `toolName` and arguments | Shows what the agent attempted | Optimizes narration while the tool call stays wrong | | Observation payload | Preserves what the agent knew at the decision point | Blames planning for bad or stale evidence | | Artifact diff | Connects actions to produced work | Rewards fluent answers that changed nothing useful | | Verifier and failure class | Tells the optimizer why the run failed | Chases a scalar score without a causal target | @@ -208,7 +215,7 @@ failureClass notes ``` -The outcome is still necessary. It is the label. It is just not enough by itself. +The outcome is still necessary. It is the label. It is not enough by itself. ## Trace Granularity @@ -247,7 +254,7 @@ enough redaction to preserve privacy and auditability Structured LLM spans record intent. -Raw provider capture records what actually went over the wire. +Raw provider capture records what went over the wire. That distinction matters. A proxy can report a different model name than the model that answered. A streaming parser can drop a field. Token usage can be missing. A retry can produce the final answer while the span only shows the last attempt. A judge can run on stale output. @@ -472,7 +479,7 @@ This matters for GEPA-style prompt optimization, skill optimization, and topolog ## Privacy And Redaction -Traces are powerful because they are detailed. +Traces are useful because they are detailed. That also makes them dangerous. @@ -653,7 +660,7 @@ Source freshness checked on 2026-06-06. - [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629), checked June 6, 2026. - [Reflexion: Language Agents with Verbal Reinforcement Learning](https://arxiv.org/abs/2303.11366), checked June 6, 2026. - [CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing](https://arxiv.org/abs/2305.11738), checked June 6, 2026. -- [Can Large Language Models Really Improve by Self-critiquing Their Own Plans?](https://arxiv.org/abs/2310.08118), checked June 6, 2026. +- [Can Large Language Models Improve by Self-critiquing Their Own Plans?](https://arxiv.org/abs/2310.08118), checked June 6, 2026. - [OpenTelemetry semantic conventions for generative AI systems](https://opentelemetry.io/docs/specs/semconv/gen-ai/), checked June 6, 2026. - [OpenTelemetry semantic conventions for generative client AI spans](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/), checked June 6, 2026. - [OpenTelemetry semantic conventions for GenAI agent and framework spans](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans/), checked June 6, 2026. diff --git a/src/content/blog/subscription-vs-pay-per-request-api-pricing.mdx b/src/content/blog/subscription-vs-pay-per-request-api-pricing.mdx index e85261f..77f4fdc 100644 --- a/src/content/blog/subscription-vs-pay-per-request-api-pricing.mdx +++ b/src/content/blog/subscription-vs-pay-per-request-api-pricing.mdx @@ -16,9 +16,9 @@ tags: - blueprint series: x402 Production Runway seriesOrder: 4 -coverImage: /images/covers/subscription-vs-pay-per-request-api-pricing.png -heroImage: /images/covers/subscription-vs-pay-per-request-api-pricing.png -imageAlt: 'Decision flow comparing subscription and pay-per-request API pricing' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- Choose pay-per-request API pricing when usage is irregular, the buyer is software, and each request has a clear value and cost. @@ -102,7 +102,7 @@ The break-even request count for a buyer is approximately: subscription price / pay-per-request price ``` -If a plan costs `$100` and the same work costs `$0.02` per request, the simple buyer break-even is `5,000` requests per month. +In this sample, if a plan costs `$100` and the same work costs `$0.02` per request, the simple buyer break-even is the reported `5,000` requests per month. That is a hypothetical example, not a Tangle price. The seller's break-even must also include compute, model tokens, storage, network calls, payment fees, retries, and support. diff --git a/src/content/blog/tangle-browser-agent-vs-browserbase-browser-use.mdx b/src/content/blog/tangle-browser-agent-vs-browserbase-browser-use.mdx index c1d123b..703f086 100644 --- a/src/content/blog/tangle-browser-agent-vs-browserbase-browser-use.mdx +++ b/src/content/blog/tangle-browser-agent-vs-browserbase-browser-use.mdx @@ -13,8 +13,9 @@ tags: - comparison series: Agent Intent Infrastructure seriesOrder: 10 -coverImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Comparison of hosted browser infrastructure, browser agent library, and evidence-first browser CLI' +heroImage: /images/covers/editorial/agent-intent-v2.webp +coverImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- Browserbase, Browser Use, and Tangle Browser Agent are easy to compare badly because all three touch "AI browser automation." They are not the same layer. @@ -48,15 +49,9 @@ Primary sources: [Browserbase docs](https://docs.browserbase.com/), [Browser Use Tangle Browser Agent is exposed as the `bad` CLI through `@tangle-network/browser-agent-driver`. -```bash -npm install -g @tangle-network/browser-agent-driver -npx playwright install chromium -bad --help -bad snapshot --url https://tangle.tools --json -curl -fsS https://tangle.tools/.well-known/tangle-browser-agent.json -``` +Start with each product’s public documentation and run the same browser task. Compare where the browser ran, what evidence came back, and how a reviewer can inspect failure. -That manifest names the package, CLI binary, safe discovery commands, SDK exports, and related Tangle surfaces. This matters for agent discovery. A browser automation product should be callable by tools, not only described to humans. +That manifest names the package, CLI binary, safe discovery commands, SDK exports, and related Tangle surfaces. This matters for agent discovery. A browser automation product should be callable by tools, available to tools as well as humans. ## Compare On A Real Browser Task diff --git a/src/content/blog/tangle-sandbox-vs-daytona-modal.mdx b/src/content/blog/tangle-sandbox-vs-daytona-modal.mdx index 8798a18..4c29667 100644 --- a/src/content/blog/tangle-sandbox-vs-daytona-modal.mdx +++ b/src/content/blog/tangle-sandbox-vs-daytona-modal.mdx @@ -13,11 +13,12 @@ tags: - comparison series: Agent Intent Infrastructure seriesOrder: 9 -coverImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Decision matrix comparing developer workspaces, serverless jobs, and autonomous agent workspaces' +heroImage: /images/covers/editorial/agent-intent-v2.webp +coverImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- -Daytona, Modal, and Tangle Sandbox overlap on one phrase: they run code. That phrase is too vague to buy infrastructure from. +A blueprint is a packaged service definition with a typed job interface. x402 is a payment protocol for machine-to-machine requests. Daytona, Modal, and Tangle Sandbox overlap on one phrase: they run code. That phrase is too vague to buy infrastructure from. Daytona is centered on developer workspaces. Modal is centered on serverless jobs and GPU compute. Tangle Sandbox is centered on autonomous agent workspaces: files, commands, browser evidence, credentials policy, snapshots, traces, and handoff into Router, Browser Agent, Blueprint, and x402 services. @@ -64,11 +65,7 @@ If the task feels like a developer opening a workspace, Daytona should look good Tangle Sandbox is useful when the sandbox is not the whole product. It is part of an agent runtime: -```bash -npm install @tangle-network/sandbox -curl -fsS https://sandbox.tangle.tools/health -curl -fsS https://sandbox.tangle.tools/.well-known/tangle-agent.json -``` +Use the public package and manifest documentation to run the shared workload. The decision depends on the artifact that survives the run, not on a copied install transcript. The live manifest matters because agents need stable discovery surfaces. The sandbox should advertise the package, safe calls, auth shape, templates, and related Tangle surfaces without requiring a human to read a marketing page. @@ -115,7 +112,7 @@ I need a serverless or GPU job. I need an autonomous agent workspace with evidence. ``` -Then run the shared workload in the matching platform. The winner is the system that preserves the artifact you actually need. +Then run the shared workload in the matching platform. The winner is the system that preserves the artifact you in practice need. ## FAQ diff --git a/src/content/blog/tangle-sandbox-vs-e2b.mdx b/src/content/blog/tangle-sandbox-vs-e2b.mdx index a54fea7..9c706c9 100644 --- a/src/content/blog/tangle-sandbox-vs-e2b.mdx +++ b/src/content/blog/tangle-sandbox-vs-e2b.mdx @@ -14,11 +14,12 @@ tags: - comparison series: Agent Intent Infrastructure seriesOrder: 8 -coverImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'Agent sandbox comparison showing code execution, workspace state, browser evidence, and paid service rails' +heroImage: /images/covers/editorial/agent-intent-v2.webp +coverImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- -If you are searching for an E2B alternative, the useful question is not "which sandbox is better?" It is: what has to survive after the agent finishes running code? +An agent runtime is the software that starts, controls, and records an agent run. A blueprint is a packaged service definition with a typed job interface. x402 is a payment protocol for machine-to-machine requests. If you are searching for an E2B alternative, the useful question is not "which sandbox is better?" It is: what has to survive after the agent finishes running code? E2B is a strong default for isolated code execution. Its docs, as of June 17, 2026, center on sandboxes, templates, filesystem access, lifecycle controls, persistence, secured access, and SDK-driven command execution. If your product needs to start a Linux sandbox, run generated code, read files, and return stdout, E2B deserves to be in the benchmark. @@ -52,7 +53,7 @@ The steelman for E2B is simple: it gives agents a clean place to execute code. T E2B also has a mature documentation shape. You can find lifecycle controls, persistence, secured access, templates, filesystem operations, command streaming, CLI usage, and SDK references without guessing the product model. If your agent product is a notebook, a code interpreter, a generated-script runner, or a fast validation harness, E2B may be the cleaner first test. -I would not replace that with Tangle just to change vendors. The migration only makes sense if the missing surface is outside "run code in isolation." +I would not replace that with Tangle solely to change vendors. The migration only makes sense if the missing surface is outside "run code in isolation." ## Where Tangle Starts To Matter @@ -63,7 +64,7 @@ An agent installs the wrong dependency. A generated test fails. A browser step p That is the Tangle frame. Tangle Sandbox is a surface inside a larger agent runtime stack: - [AI agent sandbox](/blog/ai-agent-sandbox) for workspace execution, package installs, previews, snapshots, and recovery. -- [Browser automation for AI agents](/blog/browser-automation-for-ai-agents) when the artifact needs browser evidence, not only terminal output. +- [Browser automation for AI agents](/blog/browser-automation-for-ai-agents) when the artifact needs browser evidence, terminal output alongside browser evidence. - [OpenAI-compatible routers for agents](/blog/openai-compatible-routers-for-agents) when the sandboxed task needs model routing without rewriting the client. - [x402 payments for AI agents](/blog/x402-payments-for-ai-agents) and [deploying paid AI agent services](/blog/deploy-paid-ai-agent-service) when the workspace output becomes an agent-callable service. @@ -73,7 +74,7 @@ That stack is the reason to consider Tangle. If you only need an isolated VM, co Do not compare sandbox products with a hello-world command. A hello-world command mostly tests cold start, SDK ergonomics, and whether your API key is configured. Useful, but not enough. -Use a workload that creates the failure modes your product actually has: +Use a workload that creates the failure modes your product in practice has: 1. Start a fresh environment. 2. Install one dependency. @@ -85,38 +86,7 @@ Use a workload that creates the failure modes your product actually has: The test should produce an answer like this: -```json -{ - "workspace_id": "sandbox-or-session-id", - "commands": [ - { "cmd": "npm install", "status": "ok" }, - { "cmd": "npm test", "status": "failed", "reason": "missing env var" }, - { "cmd": "npm test", "status": "ok" } - ], - "artifacts": [ - "patch.diff", - "test-output.txt", - "preview-url.txt", - "browser-evidence.json" - ], - "credential_policy": "scoped to run, not written to artifact", - "replay": "enough state to inspect or resume" -} -``` - -If E2B gives you that answer with less ceremony, use E2B. If Tangle gives you a better evidence trail because the sandbox work can attach to Browser Agent traces, Tangle manifests, Router calls, Blueprint jobs, or x402 payment records, use Tangle. - -## Tangle Smoke Checks - -Start with the public discovery and health surfaces: - -```bash -npm install @tangle-network/sandbox - -curl -fsS https://sandbox.tangle.tools/health -curl -fsS https://sandbox.tangle.tools/.well-known/tangle-agent.json -curl -fsS https://agents.tangle.tools/.well-known/tangle-agent.json -``` +Run the same migration workload in both products and compare the resulting workspace, failure record, recovery state, and artifacts. The comparison is about what survives the run, not about copying setup commands into a post. The live sandbox manifest exposes the service description, homepage, package name, API key environment variable, and agent-facing discovery fields. The agents manifest exposes the publication path: build in a Sandbox workspace, publish a snapshot-backed agent, start an instance, then call the agent endpoint. @@ -141,7 +111,7 @@ Choose E2B when: Choose Tangle Sandbox when: -- The agent needs a persistent workspace, not only a command runner. +- The agent needs a persistent workspace, more than a command runner. - Recovery from failure is part of the product experience. - Browser evidence has to travel with code output. - Credentials need policy around the run and artifact boundary. @@ -162,7 +132,7 @@ Choose E2B when you mainly need a fast, well-documented sandbox for code executi ### How do I test Tangle Sandbox against E2B? -Run the same migration workload in both products. Install a dependency, edit files, force one failure, recover, preserve the final artifact, and collect logs. Then compare not only speed, but also artifact quality, replayability, credential boundaries, browser evidence, and downstream service integration. +Run the same migration workload in both products. Install a dependency, edit files, force one failure, recover, preserve the final artifact, and collect logs. Then compare speed alongside artifact quality, replayability, credential boundaries, browser evidence, and downstream service integration. ### Does Tangle claim to be faster or cheaper than E2B? diff --git a/src/content/blog/tee-attestation-ai-services.mdx b/src/content/blog/tee-attestation-ai-services.mdx index b3dd150..58f91e1 100644 --- a/src/content/blog/tee-attestation-ai-services.mdx +++ b/src/content/blog/tee-attestation-ai-services.mdx @@ -1,5 +1,5 @@ --- -title: 'TEE Attestation for AI Services' +title: 'Trusted Execution Environment (TEE) Attestation for AI Services' slug: tee-attestation-ai-services summary: >- TEE attestation can prove code identity and execution boundary for AI @@ -13,132 +13,159 @@ tags: - verification series: Agent Intent Infrastructure seriesOrder: 12 -coverImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'TEE attestation diagram separating code identity, execution boundary, payment checks, and result verification' +heroImage: /images/covers/editorial/agent-intent-v2.webp +coverImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about hardware-backed evidence for an AI service' --- -TEE attestation is valuable when it is precise. It can tell a caller that expected code ran inside a hardware-backed execution boundary and that a verifier accepted the report. It cannot tell the caller that the model reasoned correctly, the answer is useful, or the paid service deserved the money. +A company wants to send sensitive customer data to an AI service. -That distinction matters for AI services because the phrase "trusted execution" gets overloaded. Trusted where? Trusted to run what? Trusted by which verifier? Bound to which result? In Tangle, TEE attestation is one control inside a wider service model: Blueprint execution, operator health, x402 payment checks, traces, and result verification. +It can pay for an answer, but payment alone does not tell the company which code handled the data. -## Quick Answer +It can read a service's documentation, but documentation alone does not prove that the deployed process matches the documentation. -Use TEE attestation to prove execution properties: code identity, environment identity, measurement, verifier policy, and secret release boundary. +A trusted execution environment is a hardware-backed area designed to keep a running process and its data separate from the ordinary operating system. -Do not use TEE attestation as a proof of AI correctness. A hallucinating model can hallucinate inside a TEE. A bad task can run inside a TEE. A paid job can execute inside a TEE and still return a useless result. +TEE stands for trusted execution environment. -## What Attestation Can Prove +TEE attestation can provide a signed report about the code and hardware boundary that ran a job. -| Claim | Attestation answer | -| --- | --- | -| expected code loaded | yes, if measurement is pinned | -| hardware-backed boundary used | yes, subject to platform guarantees | -| verifier accepted the report | yes, if verifier identity is known | -| secrets released under policy | partly, if key release is bound to measurement | -| output came from this run | only if result binding is implemented | -| model answer is correct | no | -| service should be paid | no, needs payment and result rules | - -The last three rows are where weak TEE posts usually blur the line. Attestation narrows where code ran. It does not grade what the code produced. - -## Artifact Shape - -A useful attestation artifact should be boring and inspectable: - -```json -{ - "service": "blueprint-code-audit", - "blueprintId": "bp_123", - "operator": "0xOperator", - "measurement": "sha256:...", - "teePlatform": "sev-snp", - "verifier": "tangle-verifier-policy-v1", - "inputHash": "sha256:...", - "outputHash": "sha256:...", - "timestamp": "2026-06-17T10:00:00Z", - "traceId": "trace_789" -} -``` - -If the output hash is missing, the attestation may prove only that code booted. If the verifier policy is missing, the caller does not know who accepted the report. If the input hash is missing, the artifact is detached from the task. - -## Where Tangle Fits - -Tangle's role is to keep attestation from becoming a floating PDF attached to a result. The service path should bind the report to the job: - -| Layer | What it contributes | -| --- | --- | -| Blueprint | job definition, runtime requirements, operator policy | -| TEE | measured execution boundary | -| x402 | payment challenge, proof, receipt | -| operator health | whether the service is alive and accountable | -| trace | what happened during the job | -| result verification | whether the output is acceptable | +It cannot prove that the model answered correctly. + +That distinction is the entire subject of this article. + +## The short version + +Use TEE attestation to check execution properties before releasing a secret or accepting a service claim. + +Do not use it as a certificate of AI quality, business fairness, or payment entitlement. + +A model can produce a confident error inside a TEE. + +A broken task can run inside a TEE. + +A paid job can complete inside a TEE and still return an answer your application should reject. -For the local architecture, read [Trusted Execution on Tangle](/blog/trusted-execution-on-tangle), [How Tangle Verifies Work](/blog/how-tangle-verifies-work), and [Blueprint TEE x402 production gating](/blog/blueprint-tee-x402-production-gating). +For the surrounding runtime, see [secure containers for AI agents](/blog/trusted-execution-on-tangle) and [AI agent infrastructure on Tangle](/blog/building-ai-services-on-tangle). -## Review Checklist +## What the terms mean -Before trusting a TEE-backed AI service, ask: +Attestation is the signed report that describes that environment. -| Question | Bad answer | +The report normally includes a measurement, which is a fingerprint of the code or configuration that started inside the TEE. + +A verifier is the service or library that checks the signature, the hardware statement, and the policy for accepting the measurement. + +Those terms describe a chain of evidence. + +They do not describe the quality of the job's output. + +## What a caller can learn + +The useful question is not "is this service trusted?" + +The useful question is "which specific claim does this report support?" + +| Claim a caller wants to make | What attestation can say | | --- | --- | -| what measurement is expected? | "the enclave ran our code" | -| who verifies the report? | "the platform handles it" | -| how are secrets released? | "they are in env vars" | -| how is output bound to attestation? | "the result came back after the report" | -| what checks task quality? | "TEE proves it" | -| what happens if verification fails? | "the user can retry" | +| The expected code loaded | Yes, when the expected measurement is pinned and checked. | +| A hardware-backed boundary was used | Yes, subject to the platform's security guarantees. | +| A known policy accepted the report | Yes, when the verifier identity and policy are visible. | +| A secret was released only to that code | Sometimes, when key release is bound to the measurement. | +| This output came from this input in this run | Only when the service binds the input and output to the report. | +| The model's answer is correct | No. | +| The service deserves payment | No. Payment and result rules are separate decisions. | + +The last two rows are where many explanations become misleading. + +Attestation narrows where code ran. -The service should fail closed. If measurement, verifier policy, payment receipt, or result binding is missing, the caller should not treat the result as trusted. +It does not grade what the code produced. -## Result Verification Is Separate +## A concrete AI service flow -For deterministic jobs, verification might be replay, checksum, signature validation, or on-chain proof. For AI jobs, verification is messier: eval suites, policy checks, human review, downstream tests, or acceptance criteria. That is not a weakness of TEE. It is a category boundary. +Imagine a Tangle Blueprint that summarizes a private document. -```text -TEE attestation answers: did expected code run in the expected boundary? -Result verification answers: did the service produce an acceptable result? -Payment verification answers: did the caller satisfy the price? -``` +A Blueprint is a reusable service description that tells an operator which job it can run and tells a caller what the job returns. -Production systems need all three when money or trust is involved. +Before sending the document, the caller should be able to inspect the expected code measurement and the policy that accepts it. -## External Reference Points +The operator starts the service inside the TEE and obtains an attestation report. -The hardware and cloud categories are documented by platform providers: [Intel SGX](https://www.intel.com/content/www/us/en/products/docs/accelerator-engines/software-guard-extensions.html), [AMD SEV-SNP](https://www.amd.com/en/developer/sev.html), and Google Cloud [Confidential Computing](https://cloud.google.com/confidential-computing/docs). Those sources explain execution boundaries. They do not claim AI task quality. +The caller checks the report before releasing the document or an encryption key. -## What This Does Not Prove +The service runs the summarization job and returns the summary together with evidence that binds the job input, job output, and attestation to one run. -TEE attestation does not make an agent safe. It does not remove the need for sandbox policy, payment checks, operator monitoring, or result review. It reduces one class of uncertainty: what code ran where. +x402 is a payment protocol for machine-to-machine HTTP requests. -The right test is whether the attestation artifact changes a decision. If a buyer cannot use it to accept, reject, replay, or escalate a result, the artifact is decoration. +The caller can use an x402 receipt to show that payment happened, but the receipt does not replace the execution report or the result check. -## Start +If the summary is empty, malformed, or wrong for the application, the caller still needs a rule for rejecting it. -Begin with discovery, then demand the binding points: +## What a useful public artifact contains -```bash -curl -fsS https://agents.tangle.tools/.well-known/tangle-agent.json -curl -fsS https://router.tangle.tools/.well-known/tangle-agent.json -``` +An attestation artifact should be boring enough for another engineer to inspect. -For a TEE-backed Blueprint, ask for the measurement, verifier policy, input hash, output hash, receipt, trace ID, and failure behavior before treating the service as production-grade. +At minimum, ask the service to identify these fields: + +| Field | Why it matters | +| --- | --- | +| Code measurement | Identifies the code that the report covers. | +| Hardware and report version | Tells the reader which platform guarantees apply. | +| Verifier identity and policy | Shows who accepted the report and under which rule. | +| Input hash | Connects the report to the requested job without exposing the input. | +| Output hash | Connects the returned result to the same job. | +| Operator identity | Tells the caller which service provider ran it. | +| Timestamp and expiry | Prevents an old report from being reused forever. | +| Payment receipt | Shows the separate payment event. | +| Failure behavior | Explains what happens when the job or report is rejected. | + +If a service cannot explain these fields, do not assume that the word "attested" answers the missing questions. + +## What attestation does not solve + +TEE attestation does not make the model's training data accurate. + +It does not stop the prompt from asking for the wrong thing. + +It does not decide whether a generated tax form, code patch, or trade recommendation is safe to use. + +It does not prove that the operator priced the job fairly. + +Those concerns need their own checks, such as output validation, an independent comparison, a human approval step, or a domain-specific test. + +The right design keeps these checks separate so a strong execution claim cannot be mistaken for a strong quality claim. + +## The decision + +TEE attestation is worth the added complexity when a caller must protect secrets or distinguish a specific deployed program from an untrusted host. + +It is not the first tool to reach for when the only question is whether an AI answer is useful. + +For a Tangle service, combine the report with the Blueprint job contract, operator health, payment receipt, input and output binding, and a result check that matches the real risk of the task. + +If you cannot state which decision each artifact supports, the service has evidence but not yet a clear trust model. ## FAQ -### What does TEE attestation prove for AI services? +### What does TEE attestation prove for an AI service? -It can prove code identity, hardware-backed execution state, verifier acceptance, and execution boundary when those fields are wired correctly. +It can support claims about code identity, hardware-backed execution, report acceptance, and secret release policy when those checks are implemented and documented. ### Does TEE attestation prove an AI result is correct? -No. It proves execution properties. Correctness still needs result verification, evals, acceptance tests, or human review depending on the workload. +No. + +Correctness still needs result checks, tests, comparison with a known answer, or human review, depending on the workload. ### How should Tangle builders use attestation? -Use it as one control in a Blueprint service path: bind it to payment receipt, job input, job output, operator health, trace ID, and result verification. +Use it as one part of a Blueprint service path. + +Bind it to the job input, job output, payment receipt, operator identity, and the result decision your application makes. ### What makes an attestation artifact useful? -It is useful when it includes measurement, verifier policy, input hash, output hash, operator identity, timestamp, and trace ID so a caller can make a trust decision. +It should name the measurement, platform, verifier policy, input and output hashes, operator, timestamp, payment event, and failure behavior. + +Those details let a caller decide what to trust instead of trusting a label. diff --git a/src/content/blog/the-self-improving-stack.mdx b/src/content/blog/the-self-improving-stack.mdx index f037ced..2636924 100644 --- a/src/content/blog/the-self-improving-stack.mdx +++ b/src/content/blog/the-self-improving-stack.mdx @@ -8,17 +8,21 @@ author: Drew Stone tags: ['agents', 'evals', 'systems', 'self-improvement'] series: 'the-self-improving-stack' seriesOrder: 1 +coverImage: /images/covers/editorial/self-improving-stack-v2.webp +heroImage: /images/covers/editorial/self-improving-stack-v2.webp +imageAlt: 'An editorial still life about how an agent system improves' --- -> **Short answer:** A self-improving agent system is not a model that reflects harder. It is a closed loop around mutable state, trace evidence, evaluation gates, memory, runtime topology, harness code, and governance. The first question is not whether the system improves itself. The first question is which layer changed and what proof allowed that change to persist. +> **Short answer:** A self-improving agent system is software that changes its instructions, procedures, tools, or model and keeps the change only after a measured comparison. -Self-improvement is not a model property. +An **agent** is software that uses a model and tools to complete a task. +A **trace** is the record of that run: the inputs, actions, tool results, artifacts, and outcome. +A **promotion gate** is the rule that decides whether a new version can replace the old one. +An **operator** is the person or service responsible for running and approving that system. -It is a system property. +The model may be part of the change, but most practical systems improve the surrounding prompts, skills, tools, memory, runtime, and release process. -A model can sit inside a self-improving system, but the loop usually lives around it: prompts, skills, tools, traces, memory, evaluators, runtimes, harnesses, and release gates. - -That distinction matters because a lot of AI discourse collapses very different loops into one phrase: +That distinction matters because a lot of AI discourse collapses different loops into one phrase: ```text the system optimizes itself @@ -203,7 +207,7 @@ That is why skill optimization belongs in the stack but does not replace runtime ## Topology Is The Action Space -Agent behavior is not only model output. +Agent behavior includes more than model output. It is workflow shape: @@ -241,7 +245,7 @@ That is still self-improvement, but the loop lives in the harness. Before claiming that a new optimizer improved the agent, beat random or naive sampling at equal compute. -A lot of agent improvements are really compute allocation changes: +A lot of agent improvements are in practice compute allocation changes: ```text more samples @@ -341,7 +345,7 @@ promotion gates memory write paths ``` -This is powerful because it expands the reachable set. +This is useful because it expands the reachable set. It is dangerous because the harness may contain the evaluator. The core rule from the governance layer is: diff --git a/src/content/blog/trusted-execution-on-tangle.mdx b/src/content/blog/trusted-execution-on-tangle.mdx index ace5f20..d0c5930 100644 --- a/src/content/blog/trusted-execution-on-tangle.mdx +++ b/src/content/blog/trusted-execution-on-tangle.mdx @@ -1,5 +1,5 @@ --- -title: 'Trusted Execution on Tangle: What Hardware Isolation Can Prove' +title: 'Secure Container for AI Agents: What Hardware Isolation Can Prove' slug: trusted-execution-on-tangle summary: >- A plain-language explanation of trusted execution environments in the Blueprint SDK, including isolation, attestation, sealed secrets, provider modes, and their limits. @@ -11,12 +11,12 @@ tags: - sdk series: Tangle Re-Introduction seriesOrder: 6 -coverImage: /images/covers/trusted-execution-on-tangle.png -imageAlt: 'A hardware-isolated service producing an attestation report for a Tangle Blueprint' -heroImage: /images/covers/trusted-execution-on-tangle.png +coverImage: /images/covers/editorial/tangle-reintroduction-v2.webp +imageAlt: 'An editorial still life about building a service on Tangle' +heroImage: /images/covers/editorial/tangle-reintroduction-v2.webp --- -Suppose you send private data or model weights to a service run by someone else. +A secure container for AI agents should limit what the process can touch and provide evidence about where it ran. Hardware isolation helps with the second part, but it does not prove the answer is correct. Suppose you send private data or model weights to a service run by someone else. You may be able to verify the result after the job finishes, but that does not answer a different question: could the person running the machine read or change the work while it was running? A **trusted execution environment**, or **TEE**, is a protected area of a computer that uses hardware to isolate a workload from the machine’s ordinary operating system. diff --git a/src/content/blog/web3-developer-tools-agent-workbench.mdx b/src/content/blog/web3-developer-tools-agent-workbench.mdx index a3a1656..5f7606d 100644 --- a/src/content/blog/web3-developer-tools-agent-workbench.mdx +++ b/src/content/blog/web3-developer-tools-agent-workbench.mdx @@ -11,12 +11,12 @@ tags: - developer-tools series: Blueprint Agent seriesOrder: 6 -coverImage: /images/products/blueprint-agent-app.png -heroImage: /images/products/blueprint-agent-app.png -imageAlt: 'Web3 developer workbench with code editor, terminal, docs, wallet testing, and quest verification' +coverImage: /images/covers/editorial/blueprint-agent-v2.webp +heroImage: /images/covers/editorial/blueprint-agent-v2.webp +imageAlt: 'An editorial still life about a runnable service blueprint' --- -Web3 developer tools usually make the first hour harder than it should be. The builder needs docs, RPC endpoints, wallets, test tokens, contracts, SDKs, examples, and a way to know whether the integration is correct. A static docs page cannot carry that whole workflow. +A blueprint is a packaged service definition with a typed job interface. Web3 developer tools usually make the first hour harder than it should be. The builder needs docs, RPC endpoints, wallets, test tokens, contracts, SDKs, examples, and a way to know whether the integration is correct. A static docs page cannot carry that whole workflow. Tangle Blueprint Agent packages the work into an agent workbench: scaffold, docs, isolated environment, code help, quest checks, and deployment evidence. @@ -31,7 +31,7 @@ Tangle Blueprint Agent packages the work into an agent workbench: scaffold, docs | Discord | support | repeatable answers | | agent workbench | build and verify | partner-specific activation | -The workbench is where the builder can actually run the product. +The workbench is where the builder can in practice run the product. ## What To Include @@ -94,7 +94,7 @@ The partner should leave with a clearer onboarding picture: | slow first quest | simplify quickstart | | high completion but low retention | product value or follow-up issue | -The workbench should feed those signals back into the partner assets. If ten sessions fail on the same RPC setting, update the starter project. If builders keep asking the agent the same question, promote that answer into the docs. The agent is not only a helper; it is an instrumentation layer for developer friction. +The workbench should feed those signals back into the partner assets. If ten sessions fail on the same RPC setting, update the starter project. If builders keep asking the agent the same question, promote that answer into the docs. The agent is a helper and an instrumentation layer for developer friction. That feedback loop should be owned. Without an owner, session data becomes another dashboard nobody reads. Assign one partner engineer or devrel lead to review failed quests and ship fixes weekly during a launch. diff --git a/src/content/blog/why-ai-infrastructure-needs-decentralization.mdx b/src/content/blog/why-ai-infrastructure-needs-decentralization.mdx index 58a5e4d..fd4925c 100644 --- a/src/content/blog/why-ai-infrastructure-needs-decentralization.mdx +++ b/src/content/blog/why-ai-infrastructure-needs-decentralization.mdx @@ -1,5 +1,5 @@ --- -title: Why AI Infrastructure Needs Decentralization +title: Why Decentralized AI Infrastructure? slug: why-ai-infrastructure-needs-decentralization summary: >- Centralized AI infrastructure creates single points of failure, censorship @@ -12,12 +12,12 @@ tags: - decentralization series: Tangle Re-Introduction seriesOrder: 1 -coverImage: /images/covers/why-ai-infrastructure-needs-decentralization.png -heroImage: /images/covers/why-ai-infrastructure-needs-decentralization.png -imageAlt: Why AI Infrastructure Needs Decentralization +coverImage: /images/covers/editorial/tangle-reintroduction-v2.webp +heroImage: /images/covers/editorial/tangle-reintroduction-v2.webp +imageAlt: 'An editorial still life about building a service on Tangle' --- -*Day 1 of the Tangle Re-Introduction Series* +The question behind decentralized AI infrastructure is simple: which parts of an agent service should one company control, and which parts should be independently checkable? *Day 1 of the Tangle Re-Introduction Series* --- @@ -25,7 +25,7 @@ Last week, Moltbook went from "[the most incredible sci-fi takeoff-adjacent thin [Business Insider ran the headline](https://x.com/BusinessInsider/status/2018564140273434672): "A viral AI agents platform was hacked in minutes, raising questions about security and vibe-coded apps." -Security breaches are not the only verification problem. After every major model release, developers complain the new version performs worse than the old one. "[Opus must be nerfed because there's no way it's this retarded](https://x.com/thestonechat/status/2017678689454923791)," one developer posted after the model destroyed hours of work. "It ruined so much." [Levelsio](https://x.com/levelsio/status/1989567994872418472), who built multiple products on these models, posted that GPT-5 was "so bad" after it advised him to delete a partition and promised his data would remain intact. It didn't. [Garry Tan, YC's CEO](https://x.com/garrytan/status/2018148196841840907), observed that Claude Code recommended using deprecated APIs that are 200x slower than current alternatives. "We're so early," he wrote. Translation: the tools don't work the way they should. +Security breaches are not the only verification problem. After every major model release, developers complain the new version performs worse than the old one. "[Opus must be nerfed because there's no way it's this retarded](https://x.com/thestonechat/status/2017678689454923791)," one developer posted after the model destroyed hours of work. "It ruined so much." [Levelsio](https://x.com/levelsio/status/1989567994872418472), who built multiple products on these models, posted that GPT-5 was "so bad" after it advised him to delete a partition and promised his data would remain intact. It didn't. [Garry Tan, YC's CEO](https://x.com/garrytan/status/2018148196841840907), reported that Claude Code recommended using deprecated APIs that were 200x slower than current alternatives. "We're so early," he wrote. Translation: the tools don't work the way they should. Users have no way to verify what changed, whether degradation is intentional cost-cutting, or whether they're getting the model they're paying for. The provider says "trust us." The user says "it feels worse." Neither can prove anything. @@ -33,7 +33,7 @@ These failures share a common root: infrastructure without verification, without The question I keep returning to: as AI agents transition from tools to workforce, who should own the infrastructure that hosts them? -## What AI Agents Actually Do Now +## What AI Agents Do Now AI agents in 2026 are not hypothetical. By some estimates, coding agents now generate 30-50% of code at major technology companies. Research agents synthesize literature and design experiments across pharmaceutical and materials science. Trading agents execute strategies across decentralized exchanges, managing portfolios and rebalancing positions without human intervention. Customer service agents handle upwards of 70% of support inquiries at companies that have deployed them. @@ -55,7 +55,7 @@ But structural problems remain. Providers can observe what agents do. They can c Tangle implements the third approach. -## What Verification Actually Requires +## What Verification Requires The critics of decentralized infrastructure raise a legitimate concern: slashing is punishment, not prevention. If an operator leaks your trading strategy, slashing them afterward doesn't un-leak the information. This critique is correct, and any honest discussion of cryptoeconomic security must address it. @@ -115,11 +115,7 @@ Tangle Network is a Substrate-based blockchain designed for coordinating off-cha The public discovery surface should be inspectable before anyone treats the story as a pitch: -```bash -curl -fsS https://tangle.tools/.well-known/ai-plugin.json -curl -fsS https://router.tangle.tools/v1/models -curl -fsS https://sandbox.tangle.tools/health -``` +The public manifests and product documentation are the reproducible starting points for this claim. They let a reader inspect the service surface without treating a marketing sentence as proof. Those calls do not prove every claim in this essay. They prove that the product surface is machine-discoverable and that Tangle's [router](/blog/openai-compatible-routers-for-agents), [sandbox](/blog/ai-agent-sandbox), and [blueprint](/blog/how-blueprints-work) paths are concrete enough for agents to inspect instead of relying on copy. @@ -131,7 +127,7 @@ Tangle does not prevent irrational attackers. Economic security assumes rational Tangle does not guarantee verification for arbitrary computation. Verification mechanisms have tradeoffs. TEEs require trusting hardware manufacturers. Redundant execution is expensive. MPC has honest-majority assumptions. Blueprints must choose verification approaches appropriate to their threat models. -Tangle does not eliminate the cold-start problem. A protocol with no operators and no customers is an equilibrium, just a bad one. Bootstrapping requires incentives that attract initial participants before network effects take over. +Tangle does not eliminate the cold-start problem. A protocol with no operators and no customers is an equilibrium, but a bad one. Bootstrapping requires incentives that attract initial participants before network effects take over. These are real constraints. Building within them requires clear-eyed assessment of what cryptoeconomic infrastructure can and cannot achieve. @@ -150,11 +146,11 @@ Tangle is a general-purpose coordination layer where developers choose and confi Yes. Agents can discover services on-chain, evaluate operator stakes and reputation, submit jobs, verify results cryptographically, and trigger slashing automatically. Combined with payment protocols like x402, the entire flow from discovery to settlement runs at machine speed. ### Does decentralized infrastructure add latency compared to centralized cloud? -Yes. Blockchain coordination adds overhead, making Tangle a poor fit for sub-10ms latency requirements. It's designed for services where trust and accountability matter more than raw speed: custody, signing, AI inference, code execution, and multi-party protocols. +Yes. Blockchain coordination adds overhead, so the stated sub-10ms latency limit makes Tangle a poor fit for that workload. It's designed for services where trust and accountability matter more than raw speed: custody, signing, AI inference, code execution, and multi-party protocols. ## What's Next -This post is the first in a series reintroducing Tangle. Next, I'll dive into how blueprints and services actually work: the lifecycle from request to execution, the economics of operator incentives, and what it actually feels like to build on this infrastructure. +This post is the first in a series reintroducing Tangle. Next, I'll dive into how blueprints and services in practice work: the lifecycle from request to execution, the economics of operator incentives, and what it feels like to build on this infrastructure. The infrastructure question will define the next decade of AI development. Whether that infrastructure concentrates power or distributes it depends on what we build now. I'd welcome thoughts from anyone working on these problems. diff --git a/src/content/blog/x402-blueprint-production-deployment-checklist.mdx b/src/content/blog/x402-blueprint-production-deployment-checklist.mdx index 659125d..209a2a0 100644 --- a/src/content/blog/x402-blueprint-production-deployment-checklist.mdx +++ b/src/content/blog/x402-blueprint-production-deployment-checklist.mdx @@ -8,16 +8,16 @@ author: Drew Stone tags: ["blueprint", "x402", "tangle", "deployment", "production", "tee", "pay-per-call"] series: x402 Production Runway seriesOrder: 13 -coverImage: /images/covers/x402-blueprint-production-deployment-checklist.png -heroImage: /images/covers/x402-blueprint-production-deployment-checklist.png -imageAlt: 'x402 Blueprint production deployment checklist: dev, staging, and mainnet config' +coverImage: /images/covers/editorial/x402-production-runway-v2.webp +heroImage: /images/covers/editorial/x402-production-runway-v2.webp +imageAlt: 'An editorial still life about taking a paid agent service to production' --- -Imagine you've built a small API service. It accepts requests, does computation, returns results. Now you want to charge for each call. The problem is that this isn't a normal web API with a billing dashboard. Payment happens on-chain, in stablecoins, before your compute even runs. The payment configuration you deploy with is the payment configuration that executes. There's no refund process, no dispute resolution, no "oops" button. A misconfigured operator wallet address doesn't generate a startup error; it silently routes every settled payment to the wrong address forever. +A TEE is a hardware-isolated environment that can report which code ran. An operator is the person or service responsible for running a job. Imagine you've built a small API service. It accepts requests, does computation, returns results. Now you want to charge for each call. The problem is that this isn't a normal web API with a billing dashboard. Payment happens on-chain, in stablecoins, before your compute even runs. The payment configuration you deploy with is the payment configuration that executes. There's no refund process, no dispute resolution, no "oops" button. A misconfigured operator wallet address doesn't generate a startup error; it silently routes every settled payment to the wrong address forever. A rollout sequence is the discipline of promoting that configuration through environments in the right order, changing only what needs to change at each stage, so you catch misconfigurations before they touch real money. For most web services, a wrong environment variable causes 500 errors. For an x402-enabled Blueprint, the wrong token address means payments fail at settlement. The wrong chain ID means the facilitator can't clear. The wrong operator address means every successful payment is a donation to a burn wallet. -This article walks through three environments: dev (local, loopback), staging (remote, testnet), and production (mainnet, TEE enforced). At each stage, a small set of fields changes. Knowing which fields those are, and why they change, is the difference between a smooth launch and a very expensive config mistake. +This article walks through three environments: dev (local, loopback), staging (remote, testnet), and production (mainnet, TEE enforced). At each stage, a small set of fields changes. Knowing which fields those are, and why they change, is the difference between a smooth launch and an expensive config mistake. If you need the gateway wiring first, start with [Blueprint SDK x402 payments](/blog/blueprint-sdk-x402-payments-runnable-jobs). If you are enabling confidential execution, pair this checklist with [x402 and TEE production gating](/blog/blueprint-tee-x402-production-gating). @@ -50,9 +50,9 @@ Before flipping to mainnet, verify each of these. The validator catches some of --- -## What does the dev config actually do? +## What does the dev config do? -The example config that ships with the x402 Blueprint is designed to be safe by construction. It cannot receive real payments, cannot be reached from the internet, and won't accidentally forward money anywhere meaningful. Here's the full [`x402.toml`](https://github.com/tangle-network/blueprint/blob/main/examples/x402-blueprint/config/x402.toml): +The example config that ships with the x402 Blueprint is designed to be safe by construction. It cannot receive real payments, cannot be reached from the internet, and won't accidentally forward money anywhere meaningful. The full [`x402.toml`](https://github.com/tangle-network/blueprint/blob/main/examples/x402-blueprint/config/x402.toml): ```toml bind_address = "127.0.0.1:0" @@ -88,7 +88,7 @@ Walk through each field: **`default_invocation_mode = "disabled"`** -- any job not listed in `job_policies` is blocked from x402 access. This is the [struct default](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs#L21) and the right choice in every environment. Explicit allowlisting prevents accidental exposure of jobs you haven't priced. -**`pay_to = "0x0000000000000000000000000000000000000001"`** -- the field that will burn you. Address `0x1` is a placeholder. It's a valid EVM address so it passes validation, but any payment that actually settles against this config goes nowhere recoverable. The validator checks that `pay_to` is a parseable EVM address; it does not check that you own it. +**`pay_to = "0x0000000000000000000000000000000000000001"`** -- the field that will burn you. Address `0x1` is a placeholder. It's a valid EVM address so it passes validation, but any payment that in practice settles against this config goes nowhere recoverable. The validator checks that `pay_to` is a parseable EVM address; it does not check that you own it. **`network = "eip155:8453"` and `asset = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"`** -- Base mainnet chain ID and USDC on Base mainnet, even in the dev config. The validator checks CAIP-2 format and EVM address parseability; it does not check that the contract exists or that you have access to the chain. For dev testing, this is acceptable because no real settlement occurs. @@ -102,7 +102,7 @@ The job pricing lives in a separate file, [`job_pricing.toml`](https://github.co 1 = "10000000000000000" # keccak256: 0.01 ETH ``` -Prices are denominated in wei, where 1 ETH = 10^18 wei. The gateway converts these to stablecoin amounts using your `rate_per_native_unit` and `markup_bps`. The math: `0.001 ETH * 3200 USDC/ETH * 1.02 markup = 3.264 USDC = 3,264,000 smallest units`. This conversion runs in [`convert_wei_to_amount`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs#L179). Wei as the denomination is deliberate: operators set prices once in native units, and the stablecoin conversion is a runtime concern that varies by token and market rate. +Prices are denominated in wei, where the reported conversion is 1 ETH = 10^18 wei. The gateway converts these to stablecoin amounts using your `rate_per_native_unit` and `markup_bps`. The reported math is: `0.001 ETH * 3200 USDC/ETH * 1.02 markup = 3.264 USDC = 3,264,000 smallest units`. This conversion runs in [`convert_wei_to_amount`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs#L179). Wei as the denomination is deliberate: operators set prices once in native units, and the stablecoin conversion is a runtime concern that varies by token and market rate. ## What changes in staging? @@ -210,13 +210,13 @@ The critical production changes: **`invocation_mode = "restricted_paid"`** -- production commonly graduates jobs from `public_paid` to `restricted_paid` to enforce caller access control. `restricted_paid` requires both `tangle_rpc_url` (for `eth_call` permission checks) and `tangle_contract` (the contract implementing `isPermittedCaller`). The validator rejects their absence. Note that `restricted_paid` with `auth_mode = "payment_only"` is also rejected at load time; `payment_only` provides no caller identity to check against. -One production-specific operational consideration: the `AttestationFreshnessPolicy` is currently [only `provision_time_only`](https://github.com/tangle-network/blueprint/blob/main/crates/tee/src/config.rs#L218). Attestation is captured once at provision and the hash stored on-chain. If the enclave reboots, the stored hash becomes stale, and key exchange with `on_chain_verification = true` will fail until you re-provision. Periodic re-attestation is planned but not yet implemented. Factor this into your incident runbook. +One reported production-specific operational consideration: the `AttestationFreshnessPolicy` is currently [only `provision_time_only`](https://github.com/tangle-network/blueprint/blob/main/crates/tee/src/config.rs#L218). Attestation is captured once at provision and the hash stored on-chain. If the enclave reboots, the stored hash becomes stale, and key exchange with `on_chain_verification = true` will fail until you re-provision. Periodic re-attestation is planned but not yet implemented. Factor this into your incident runbook. -## Which config fields will actually cost you money? +## Which config fields cost you money? Three fields deserve extra attention because mistakes in them don't cause startup errors; they cause lost funds or silent settlement failures. -**`pay_to`** is the operator wallet that receives settlements. The validator confirms it's a parseable EVM address. It does not confirm you own it, that it exists on the right chain, or that it isn't the dev placeholder `0x1`. If you forget to replace `pay_to` before production, every settled payment goes to address `0x1`. The service runs fine. No alarm. The payments just go somewhere else permanently. +**`pay_to`** is the operator wallet that receives settlements. The validator confirms it's a parseable EVM address. It does not confirm you own it, that it exists on the right chain, or that it isn't the dev placeholder `0x1`. If you forget to replace `pay_to` before production, every settled payment goes to address `0x1`. The service runs. No alarm. The payments go somewhere else permanently. **`network` and `asset` together** define which chain and token contract the facilitator uses for settlement. The validator checks that `network` is in CAIP-2 format (`eip155:`) with a valid `u64` chain ID, and that `asset` is a parseable EVM address. It does not check that the contract at `asset` exists on `network`. Carrying a Sepolia USDC address into a production config with `network = "eip155:8453"` loads cleanly, then fails at settlement time, not at config load time. @@ -258,7 +258,7 @@ Never mix testnet and mainnet values in the same config. There is no validation After promoting to production, run these checks before declaring the deployment done: -1. **Submit a test request** to the service and confirm you receive a 402 response with a valid quote. The quote TTL is `quote_ttl_secs` (default 300 seconds); complete the verification within that window. +1. **Submit a test request** to the service and confirm you receive a 402 response with a valid quote. The quote TTL is `quote_ttl_secs` (reported default 300 seconds); complete the verification within that window. 2. **Complete a real payment flow**: sign and resubmit with payment proof. Verify the job executes and returns the expected result. 3. **Verify settlement to your operator wallet**: check your production operator wallet on Base mainnet for the incoming transfer. The amount should match `rate_per_native_unit * price_in_eth * (1 + markup_bps / 10000)` minus facilitator fees. 4. **Confirm TEE attestation**: check the on-chain attestation hash matches the hash submitted at provision time. A mismatch here means `on_chain_verification = true` will fail key exchange for all clients. @@ -282,7 +282,7 @@ No. The validator rejects `restricted_paid` without both `tangle_rpc_url` and `t Wei prices are token-agnostic. An operator sets a price once in native units; the gateway converts to whatever stablecoin the client presents at settlement time, using `rate_per_native_unit` and `markup_bps`. Adding a second accepted token (DAI, for example) requires no changes to `job_pricing.toml`, only a new `[[accepted_tokens]]` entry in `x402.toml`. ### What does `markup_bps = 200` mean in practice? -200 basis points is a 2% markup on top of the converted stablecoin price. For a job priced at 0.001 ETH at 3200 USDC/ETH: 3.20 USDC base + 2% = 3.264 USDC. The markup is applied in [`convert_wei_to_amount`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs#L179) before the quote is returned to the client. It covers settlement risk and operator margin; it is not a fee paid to the facilitator. +The reported setting `markup_bps = 200` means 200 basis points, or a 2% markup, on top of the converted stablecoin price. For a reported job priced at 0.001 ETH at 3200 USDC/ETH: 3.20 USDC base + 2% = 3.264 USDC. The markup is applied in [`convert_wei_to_amount`](https://github.com/tangle-network/blueprint/blob/main/crates/x402/src/config.rs#L179) before the quote is returned to the client. It covers settlement risk and operator margin; it is not a fee paid to the facilitator. --- diff --git a/src/content/blog/x402-payments-for-ai-agents.mdx b/src/content/blog/x402-payments-for-ai-agents.mdx index e0b7252..8659bf7 100644 --- a/src/content/blog/x402-payments-for-ai-agents.mdx +++ b/src/content/blog/x402-payments-for-ai-agents.mdx @@ -13,11 +13,12 @@ tags: - payments series: Agent Intent Infrastructure seriesOrder: 5 -coverImage: /images/covers/agent-intent-infrastructure.svg -imageAlt: 'x402 payment sequence showing request, payment requirements, signed retry, settlement, and response' +heroImage: /images/covers/editorial/agent-intent-v2.webp +coverImage: /images/covers/editorial/agent-intent-v2.webp +imageAlt: 'An editorial still life about describing and running an agent task' --- -x402 lets an AI agent pay for one HTTP request without opening an account or selecting a subscription first. +A blueprint is a packaged service definition with a typed job interface. x402 is a payment protocol for machine-to-machine requests. x402 lets an AI agent pay for one HTTP request without opening an account or selecting a subscription first. The server responds with `402 Payment Required`, the agent evaluates the price and terms, the wallet signs a payment payload, and the agent retries with that signature. The server verifies and settles the payment before returning the purchased resource.