A new web3 (blockchain-based application) developer opens the documentation, copies a software development kit (SDK) example, visits a faucet that dispenses test assets, changes the remote procedure call (RPC) address, approves a wallet request, and loses the error that explains what failed. The product may document its SDK, supported networks, and common provider errors. The missing runtime mounts starter files, launches the browser, captures wallet events, and stores the source difference beside a trace, the ordered record of actions and results.
Web3 developer tools include software development kits (SDKs), application programming interfaces (APIs), smart contracts (programs that run on a blockchain), networks, wallets (software that holds keys and approves transactions), RPC endpoints (network addresses for sending requests to a blockchain node), indexers (services that make chain data searchable), explorers, and testing workflows. Each tool answers one question; none retains the project’s complete failure context. The first integration reads a network, requests wallet access, and verifies the resulting user-interface state.
A Uniform Resource Locator (URL) is the address a browser or client uses to reach a web resource.
An agent workbench is a development workspace where a person and an AI agent can read the project, edit files, run commands, inspect browser and wallet state, and keep the resulting evidence together. It mounts a starter project, runs the browser and wallet flow, and keeps the source difference and that trace beside the result.
Blueprint Agent is Tangle’s in-browser coding product. Its public documentation describes a real development environment in which an agent writes and runs code while a developer reviews and iterates. Tangle’s Sandbox runtime is the isolated workspace that supplies the files, processes, and policy boundary for the session. The workbench idea matters because the agent needs the same project, network settings, and failure output as the developer it is helping.
Run code, wallet actions, and browser checks in one workspace
The missing joins are starter files, network configuration, wallet state, and browser assertions.
| Tool | Good at | Question it leaves open |
|---|---|---|
| Documentation | Explaining APIs and concepts | Which example works in this project? |
| SDK | Providing typed access to a protocol | Which network and account should run it? |
| Faucet | Providing test assets | Did the application use them correctly? |
| Wallet | Authorizing a user action | What state did the app reach afterward? |
| RPC endpoint | Reading or submitting chain data | How does the user interface handle delay or failure? |
| Explorer | Showing chain state | Does the application interpret the state correctly? |
| Chat assistant | Explaining a next step | Can it run the next step and inspect the result? |
| Agent workbench | Joining code, tools, and checks | Which evidence should the partner retain? |
The workbench should not hide the underlying tools. It should make their boundaries visible so a developer can tell whether a failure came from code, wallet approval, network state, contract behavior, or the test itself.
Carry a wallet flow across the boundary
Use a small user behavior as the continuing example. Suppose a partner wants a developer to display the current network, connect a wallet, read a balance, and explain a rejected request. That is a bounded first quest because each step produces inspectable state and a defined failure.
The workbench path can be explicit.
read the partner brief and SDK docs
-> open a versioned starter project
-> configure the declared test network
-> run a read-only provider check
-> ask for wallet connection with user consent
-> render the returned state
-> exercise rejection and wrong-network cases
-> save the diff, browser result, and traceThe browser wallet boundary has a public standard.
Ethereum Improvement Proposal 1193 (EIP-1193) defines a JavaScript provider interface with a request method and provider events.
The following illustrative TypeScript fragment uses that public interface.
It does not assume a particular wallet brand.
type Eip1193Provider = {
request(args: { method: string; params?: unknown[] }): Promise<unknown>
}
export async function readNetwork(provider: Eip1193Provider) {
const chainId = await provider.request({ method: 'eth_chainId' })
return { chainId: String(chainId) }
}
export async function requestAccount(provider: Eip1193Provider) {
const accounts = await provider.request({ method: 'eth_requestAccounts' })
return { account: String((accounts as string[])[0] ?? '') }
}The first function is read-only. The second asks the user to authorize account access. A verifier is the check or service that observes a stated behavior and records whether it passed, failed, or was skipped. The verifier should check that the application distinguishes those actions and handles a rejected request without displaying an account that was never granted. An evaluation is a repeatable check against an expected result.
Retain docs, files, runs, wallet state, browser state, and exports
| Surface | Required behavior | Evidence to keep |
|---|---|---|
| Docs | Searchable, versioned, and linked to examples | Source URL and document version |
| Files | Real project state with a visible diff | Changed files and lockfile |
| Terminal | Commands with exit code and output | Logs and environment versions |
| Wallet | Account, network, and approval state are visible | Provider result and user action |
| Browser | The user flow can run against the preview | Assertions, screenshots, and failure state |
| Export | The builder can take the result to its own repository or target | Artifact, preview, or patch |
The workbench can add a seventh surface for the objective verifier described above. It should be independent of the assistant’s claim that it completed the task.
Web3 browser checks can use Playwright, whose public documentation covers browser isolation, assertions, test reports, and continuous integration (CI) execution. Repository checks can run through GitHub Actions, which provides repeatable jobs inside a repository workflow. Those tools are components. The workbench’s job is to connect their inputs and outputs to one developer path.
Owners for documentation, workspace, wallet, network, browser, and export
The workbench crosses several systems, so each boundary needs a person who can repair it. The documentation owner keeps examples aligned with the current API and network. The workspace owner maintains the starter project, runtime image, and permissions. The partner engineer owns the SDK, contract fixtures, and test accounts. The verifier owner maintains browser and backend checks. The program owner decides which evidence a partner or reviewer may retain.
| Boundary | Failure signal | Owner’s first repair |
|---|---|---|
| Documentation | Repeated question or invented method name | Add a versioned example and error explanation |
| Workspace | Install or process failure before product code runs | Fix the image, dependency pin, or resource limit |
| Wallet | Rejection or wrong account state | Improve consent, network messaging, or reset flow |
| Network | Timeout, stale state, or rate limit | Add a fallback, wait policy, or fixture |
| Browser | Flaky selector or missing user state | Stabilize the assertion and preserve the failure |
| Export | Preview or patch cannot be inspected | Bind the artifact to a version and expiry |
Inspect a failed run, patch one repeated boundary, and rerun the same behavior from a clean workspace. Limit the first launch to a flow whose fixtures, checks, and traces have named owners. Start with one wallet flow, one read-only network check, one user-approved action, and one expected failure so each boundary has an owner. Expand after the owners can explain every failure category and keep the evidence useful to a developer who was not present for the original run.
Give the agent a bounded runtime
An AI agent needs project files, a shell, package management, browser access, network rules, and a way to keep the first failure while it tries a second approach.
An agent profile is the saved configuration for a run, including the model, instructions, tools, permissions, and budget. A runtime is the software and machine that start the agent, mount the workspace, run processes, and enforce resource and network limits.
The profile should express what the agent is allowed to use. The runtime should enforce it outside the model’s text. For a wallet quest, the agent may need a browser and a public RPC endpoint while the wallet account remains under explicit user control. For a contract deployment quest, the workspace should use a disposable test account with limited funds and a documented reset path.
The Tangle AI documentation describes profiles for model, tool, and budget choices and isolated sandboxes with explicit policies and resource limits. The AI agent sandbox guide explains why the workspace must survive a failed command long enough for an agent or developer to inspect it. The AI Coding Assistant With Deployment Evidence follows the same build path when the partner needs a reviewable deployment result. For browser-specific evidence, read Browser Automation AI Needs An Evidence Loop.
The workbench should show permission decisions as part of the result. “The agent could not access the wallet” and “the user rejected the request” are different failures. Combining them into “wallet step failed” teaches the wrong lesson.
Define Tangle’s product and protocol boundaries
Tangle uses Blueprint for a protocol service definition. A Blueprint describes the jobs, inputs, outputs, artifacts, triggers, and optional payment or verification rules for a service that operators can run. A Service is a live configured instance of that Blueprint. A Job is one callable unit of work inside the Service. An operator is the person or team that provides infrastructure and runs the Service. The public Blueprint documentation describes those objects and roles.
Blueprint Agent is the workbench where a developer builds with an AI coding assistant. The workbench can help a developer create a client for a Blueprint job or package a service that later becomes a Blueprint. Keeping the names separate prevents a developer from assuming that an in-browser project is already a registered network service.
In the protocol runtime, a job router maps a job identifier to the handler that executes it. If a workbench quest calls a Blueprint job, the final check should use the same job route and input schema a user will use. Testing a helper function alone leaves routing, encoding, authorization, and result submission untested.
For paid services, x402 is an open Hypertext Transfer Protocol (HTTP) payment standard.
The server can return 402 Payment Required with payment requirements, and the client can retry with the protocol’s payment payload after authorization.
The x402 client and server guide describes the buyer and seller flow.
The workbench should show payment status separately from the service result.
For sensitive execution, an attestation is a signed statement about the code or environment observed by trusted hardware or its verifier. It exposes the attestation, measured code identity, verifier, and policy decision for that execution boundary. It does not prove that a smart contract call was economically safe or that an AI-generated result was correct. The Tangle execution confidentiality guide documents the protocol’s confidentiality policies and their limits.
Make traces useful to builders and partners
A trace is the ordered record of the build and run. It may include the brief, profile, tool calls, file diff, terminal output, browser events, wallet errors, evaluation results, and exported artifact.
The trace should answer concrete questions.
| Question | Evidence |
|---|---|
| Which network did the app use? | Chain identifier and RPC configuration |
| Which account authorized the action? | Redacted account address and user approval event |
| What did the agent change? | Source diff and lockfile |
| Why did the first request fail? | Request shape and provider or RPC error |
| Did the user interface reach the intended state? | Browser assertion and screenshot |
| Which result can a partner inspect? | Preview URL, artifact, transaction, or job identifier |
The evaluation is the repeatable check that produces a pass, failure, or skip. The trace provides context around the evaluation. It should never turn a missing assertion into a success because the assistant described the expected screen.
Redact wallet secrets, API keys, private repository content, and personal data. Keep the minimum information needed to reproduce the check. If a trace is shared with a partner or used for judging, state its retention period and the people who can view it.
A workbench should teach failure, not erase it
Web3 development includes failure states that a happy-path tutorial hides.
Wrong network. The app reads a chain identifier that does not match the partner’s test network. The user interface should name the expected network and avoid showing a successful result.
Rejected approval. The user denies a wallet request. The app should preserve the current state, explain the action, and offer a deliberate retry.
Insufficient funds. The test account cannot pay gas or a job fee. The error should tell the builder which account, asset, or faucet rule applies without asking for a private key.
Delayed state. A transaction is submitted while an indexer or RPC endpoint has not reflected it. The app should show pending state and a clear timeout rather than claiming success from submission alone.
Contract revert. The request reaches the chain and fails. The evidence should retain the request parameters and decoded error so the developer can distinguish a code bug from an invalid fixture.
Stale preview. A judge or partner opens a URL from a previous artifact. The deployment record should name the version and the preview’s expiry.
A workbench that hides these cases teaches developers that integration means a screenshot of the happy path. A workbench that records them teaches developers how the product behaves.
What an agent workbench cannot solve
A workbench can mount the starter project, run the browser flow, and export the source difference and trace. It cannot make a bad protocol design good. It cannot protect a wallet if the developer grants an unsafe application permission. It cannot guarantee that an RPC provider is available. It cannot replace an audit of contract code or a review of key management. It cannot prove product-market fit because a developer reached the first quest.
The workbench also has a maintenance cost. If its owners stop reviewing failed traces and refreshing fixtures, starter projects, browser versions, contract addresses, and verifiers fall out of date.
Test the first expected failure
Use an agent workbench when a product’s first integration crosses code, wallets, networks, browser state, and a reviewable result. Keep documentation as the reference source and keep the underlying SDK, wallet, RPC, and testing tools visible. Use Blueprint Agent for the build path when developers need an in-browser project and an AI assistant. Use a bounded runtime, product-specific evaluations, and traces when the partner needs to know where builders succeed or stall.
The first workbench experiment should be one real behavior with one expected failure. Expand the onboarding path only after fresh developers can pass both the expected behavior and expected failure, inspect the evidence, and export the result without losing network or wallet context.
What are web3 developer tools?
They are the SDKs, APIs, smart contracts, networks, wallets, RPC endpoints, indexers, explorers, and testing workflows used to build crypto applications.
What is an agent workbench?
It is a development workspace where a person and an AI agent can read files, edit code, run tools, inspect browser or wallet state, and retain the resulting evidence.
How is an agent workbench different from a chatbot?
A chatbot can explain a next step. A workbench gives the agent a bounded project and the tools needed to run the step and inspect its result.
Does a workbench replace web3 documentation?
No. Documentation remains the reference for APIs, versions, networks, and security rules. The workbench connects that reference to a real project and a checkable behavior.
What should the first quest test?
Test the smallest real integration, such as reading the network, requesting wallet access with consent, calling one product API or job, and handling one expected failure.