A partner gives your developer program a short brief: install the software development kit (SDK), add one application programming interface (API) call, show the result, and deploy a preview. An AI coding assistant can produce an impressive diff in minutes. The partner then asks, “How do we know the integration works?”
An AI coding assistant is software that helps a developer write, edit, run, and understand code. The useful version for onboarding has to leave the chat window and reach a running project. It needs a place to work, a defined task, checks that can fail, and evidence another person can inspect.
Blueprint Agent is Tangle’s browser-based coding workspace. Its public documentation describes an agent that edits and runs code in a real development environment, with each session running on Tangle’s Sandbox runtime. A runtime is the software and machine that start a task and provide its files, processes, ports, permissions, and resource limits. Tangle Sandbox is the isolated workspace runtime that gives an agent a bounded place for those files and processes.
That distinction gives a partner program a practical standard. An assistant has done useful onboarding work when it can connect a brief to a code change, a check, a running result, and a record of what happened.
The output is an evidence packet
A transcript can show what the developer asked for. A diff can show what changed. Neither one proves that the project builds or that the integration behaves as promised.
Treat the result as a small evidence packet with a clear boundary.
The packet below uses a fictional add-quote-endpoint task so the shape stays public and portable.
| Evidence | Example observation | What it proves | What it leaves open |
|---|---|---|---|
| Source diff | The SDK import and handler are present | Which files changed | Whether the code is safe or maintainable |
| Install log | Dependencies resolved from the lockfile | The workspace reached the dependency step | Whether the selected versions are appropriate |
| Build and test output | The project compiled and checks passed | Defined checks succeeded in that environment | Whether the checks cover the important behavior |
| Runtime result | A preview returned the expected response | The path worked for the supplied input | Whether other inputs or load levels work |
| Deployment record | Target, version, timestamp, and health result | A named artifact ran at a named target | Whether the service will remain available |
| Session trace | Tool calls, failures, retries, and outputs | How the work unfolded | Whether every private fact should be retained |
An evaluation is a repeatable check against a stated expectation. For code onboarding, it might be a unit test, a request with an expected response, a browser assertion, or a deployment health check. An evaluation result describes the check that ran; it does not turn an incomplete check into proof of production readiness.
The denominator matters.
“The assistant passed” is weak language.
An example review note could read: “The add-quote-endpoint task passed four named checks in the test workspace, while the browser check was skipped.”
A profile and a runtime set the assistant’s real limits
The model is only one part of an AI coding assistant. An agent profile is the saved configuration for a run, such as the chosen model, instructions, tools, permissions, and budget. Tangle’s public AI documentation describes profiles as controls for models, tools, and budgets.
The profile states the capabilities the agent is meant to receive. The runtime enforces which of those capabilities the session can use. If the profile asks for a browser, a package manager, a private API connection, and a long-running process, the workspace must expose those capabilities through actual tools and policy.
An RPC endpoint is a network address that lets a client make remote procedure calls to a service such as a blockchain node.
For a partner task, write the boundary before the agent starts.
| Profile choice | Runtime question | Evidence to capture |
|---|---|---|
| Model and instructions | Which model and task brief were used? | Profile version and run metadata |
| Files | Which project snapshot was mounted? | Input revision or archive identifier |
| Tools | Could the agent run the package manager, tests, and browser? | Tool permissions and command results |
| Network | Which SDK registry, RPC endpoint, or preview host was reachable? | Allowed destinations and failures |
| Budget | What capped the run? | Time, token, or action limit |
| Secrets | Which credentials were available, and where were they redacted? | Secret names and redaction policy |
This is where AI Agent Sandbox: Build a Controlled Agent Workspace fits the wider system. The Blueprint Protocol and Operator Services article covers the protocol-side deployment boundary when the example becomes a Tangle service. The sandbox holds files and processes long enough for the assistant to inspect a failure and try again. The coding product helps the developer steer the work. The partner’s checks decide whether the result is acceptable.
Carry one build brief from request to result
Imagine a wallet infrastructure partner wants a small example that calls its public SDK, displays a response, and works on a test network. The onboarding task should be written as a behavior rather than a lesson title.
“Learn our SDK” is too vague to verify.
“Call getQuote with a valid test input, render the returned asset and expiry, and show a clear error for an expired quote” names an artifact and two observable outcomes.
The assistant can then work through a bounded sequence.
brief names the behavior
-> agent profile selects model, tools, and budget
-> runtime mounts the starter project
-> assistant edits and runs the project
-> evaluations check valid and invalid inputs
-> preview or deployment exposes the result
-> trace and artifacts form the review packetThe sequence is useful because each arrow has a different failure mode. The model may misunderstand the API. The runtime may lack a browser or the correct network access. The code may compile while the request is malformed. The preview may be healthy while the task behavior is wrong. The trace may contain sensitive input that should not be shared with a sponsor.
A small illustrative result shape makes those distinctions explicit. This is a teaching example, not a claim about a private Blueprint Agent API.
type CheckResult = {
name: string
status: 'passed' | 'failed' | 'skipped'
detail: string
}
type EvidencePacket = {
task: string
profile: string
runtime: string
checks: CheckResult[]
deployment?: {
target: string
version: string
health: 'healthy' | 'unhealthy' | 'unknown'
}
traceId: string
}
function canCallComplete(packet: EvidencePacket) {
const required = ['build', 'valid-request', 'invalid-request']
return required.every(
(name) => packet.checks.find((check) => check.name === name)?.status === 'passed',
)
}The function does not judge code quality. It only makes the partner’s minimum rule visible and prevents a skipped check from being reported as a pass. Production systems should also bind the packet to the exact source and artifact that generated it.
A trace explains the path without replacing the checks
A trace is the ordered record of a run. It can include the prompt, tool calls, file changes, command output, model usage, errors, retries, and final artifacts. The trace answers “how did we get here?” while an evaluation answers “did this named condition hold?”
Those records solve different problems. When several developers fail at the same import, a partner can inspect the traces and fix the starter project or documentation. When a task reports green but the response body is empty, the evaluator and its fixture need inspection. When a model retries a network call repeatedly, the runtime record can expose a flaky dependency rather than blaming the developer.
Keep the record reviewable. Redact access tokens, wallet keys, personal data, and proprietary source before exporting a trace to a sponsor. Preserve enough context to reproduce the check, including the environment, dependency lock state, and failure output.
The public Tangle AI documentation describes a loop in which work runs in isolated sandboxes and task and agent evaluations feed back into workflows. That feedback is valuable only when the system keeps task outcomes separate from opinions about the assistant’s prose.
Where the Tangle terms fit
Tangle uses Blueprint in two related contexts, and a newcomer should keep them separate. A protocol Blueprint is a reusable definition of an off-chain service, including its jobs, inputs, outputs, artifacts, and optional protocol rules. A Service is a live instance of that Blueprint, and a Job is one callable unit of work inside the Service. The public Blueprint introduction distinguishes a Blueprint from a live Service and from an individual Job. Blueprint Agent is the product where a developer works with an AI coding assistant.
If the partner’s example eventually becomes a protocol service, its job definition needs a handler. A job router is the component that maps a job identifier to the function that handles it. The Blueprint Runner guide documents the job router alongside event producers, result consumers, and background services. For deployment evidence, the check should exercise the routed job rather than merely importing the handler.
If the example is a paid Hypertext Transfer Protocol (HTTP) service, x402 is an open payment standard built around HTTP 402 Payment Required responses.
The server can state the payment requirements, the client can return a signed payment payload, and the server can verify and settle before serving the resource.
x402 proves a payment flow was accepted under its rules.
It does not prove that the paid response is correct.
Use a separate evaluation for the result.
The x402 client and server guide describes those roles.
A trusted execution environment (TEE) is a protected execution area designed to keep code and data isolated from the surrounding host. If a partner needs confidential execution, an attestation is a signed statement from trusted hardware or an attestation service about the code and environment it observed. Attestation can support a claim that a particular workload ran inside a particular protected environment. It does not establish that the workload produced a useful answer, and it does not replace application-level checks. The Tangle execution confidentiality guide explains this boundary in more detail.
Deployment evidence has a return path
The word “deployed” hides several different states. A local preview may be enough for a tutorial. A deployment on a test network may be enough to exercise a contract or service lifecycle. A production release needs an owner, a health signal, an artifact identity, and a rollback path.
For each target, record the smallest useful facts.
| Target | Minimum record | Failure to rehearse |
|---|---|---|
| Local preview | command, port, response, and changed files | process exits or port is unavailable |
| Test network | network name, account, transaction or job result, and logs | wrong network or missing funds |
| Hosted preview | Uniform Resource Locator (URL), artifact version, health check, and expiry | stale or unreachable preview |
| Production | approved artifact, owner, monitoring, and previous version | release is unhealthy and must be reversed |
A successful build log cannot substitute for a health check. A health check cannot substitute for the user-facing behavior. A green user-facing behavior cannot substitute for a security review.
The assistant can help gather these records, but a human should decide which target is safe for the task. Production approval belongs behind explicit review, especially when the workspace has access to keys, customer data, or funds.
Give every evidence item an owner
Evidence is easier to trust when someone owns the question it answers. The developer owns the intent and the source change. The evaluation owner owns the check definition and its fixtures. The runtime owner owns the environment, permissions, and command record. The deployment owner owns the target, health signal, expiry, and rollback. The partner reviewer owns the decision about whether the result satisfies the program.
| Evidence | Owner | Review question |
|---|---|---|
| Brief and diff | Developer | Does the change address the requested behavior? |
| Evaluation definition | Partner engineer | Does the check exercise the real integration? |
| Evaluation result | Runtime or continuous integration (CI) owner | Did the check run in the declared environment? |
| Preview or deployment | Deployment owner | Which artifact is live, and how long will it remain available? |
| Trace export | Program or privacy owner | Which events can the reviewer see, and what was redacted? |
| Approval | Partner reviewer | Is the result ready for the next environment? |
This ownership map prevents a common handoff failure. The agent finishes a build, the runtime reports green checks, and nobody is responsible for deciding whether the checks were sufficient. The result then gets described as “verified” even though the evidence only covers a happy path.
Keep the packet small enough to review. Link to detailed logs when a reviewer needs them, while putting the task, artifact, check status, target, and known failures on the first page. The point of a trace is to shorten investigation, not to make the reviewer search through every model message.
Failure cases worth designing first
The first failure is often more informative than the first pass.
The check is too weak. A test that asserts only that a page loads can pass while the SDK call never runs. Add an assertion on the real response and a failure case that exercises the integration boundary.
The environment is different. A local machine may have a cached package, a wallet extension, or an environment variable that the partner’s workspace lacks. Start from a clean runtime and record the dependency state.
The agent has too much access. A coding assistant that can read every credential can produce a good demo while creating a serious security incident. Grant the smallest file, network, and secret scope needed for the task.
The trace is treated as a verdict. A polished trace is still a record of actions, not proof that the actions were appropriate. Let named evaluations and reviewer inspection carry the decision.
A preview survives after its evidence expires. Record an expiry or cleanup rule so a reviewer does not mistake an old URL for a current deployment.
A task passes only because the agent completed it. For education or partner qualification, include a short human review or a follow-up change that tests whether the developer can extend the integration.
Choose the environment from the evidence
Use an AI coding assistant for partner onboarding when the program can define a small behavior, provide a bounded runtime, and retain evidence that another person can inspect. Blueprint Agent is a good fit for the build portion when a developer needs an in-browser workspace with files, tools, a live preview, and a session record. Pair it with product-specific evaluations and an explicit deployment decision.
If the assistant only answers questions and returns a diff, call it documentation support. If it edits code but cannot run the relevant checks, call it a drafting tool. The onboarding platform begins when the result crosses into observable software. For the next layer, where a developer turns that observable result into a verified onboarding task, see developer onboarding with code-verified quests.
What is an AI coding assistant?
An AI coding assistant helps a developer write, edit, run, and understand software inside a development workflow.
What counts as deployment evidence?
Deployment evidence identifies the target and artifact, records a health result, and connects that result to the source, checks, and timestamp that produced it.
Does a trace prove that the code is correct?
No. A trace records what the agent and runtime did. Correctness still requires task-specific tests, runtime checks, review, and security controls.
Does x402 prove a paid AI service worked?
No. x402 describes how a client and server handle payment over HTTP. The service still needs an evaluation that checks the returned work.
When does attestation help?
Attestation helps when the trust question includes where code or data ran. It does not prove the code’s output or the quality of an AI response.