Suppose a developer-relations dashboard says that 2,000 people opened the quickstart. The partner team asks how many of them made a working request. The dashboard has no answer because it counted attention rather than an integration.
A developer onboarding platform helps a developer learn a product, start a project, complete technical tasks, and show that the result works. An SDK, or software development kit, is the packaged code and documentation a product provides for integrating with it. An API, or application programming interface, is the documented boundary through which one program requests data or actions from another. The important outcome is a first working integration, such as a successful SDK call, a browser flow, a transaction on a test network, or a deployed preview.
This is where code-verified quests earn their place. A quest is a small task with a stated outcome. A code-verified quest marks that task complete because a build, test, runtime check, browser run, or deployment check passed. A verifier is the check or service that observes the stated behavior and records whether it passed, failed, or was skipped.
Blueprint Agent is Tangle’s in-browser coding workspace. Its public documentation describes a developer who gives an agent a brief, reviews code in a live environment, runs the project, and takes the result to a repository or deployment. Tangle’s Sandbox runtime is the isolated workspace in which those files, processes, and policies are applied. That surface can carry an onboarding path when the partner supplies the project, docs, checks, and support route around it.
Measure the first working integration
Onboarding has several legitimate milestones, and they answer different questions. A page view says the developer noticed the product. An API key says the developer was willing to configure access. An SDK import says the environment reached the dependency step. A passing product-specific check says the developer crossed the integration boundary.
Keep those signals separate rather than collapsing them into one activation number.
| Milestone | Evidence | Decision it supports |
|---|---|---|
| Awareness | Documentation request or page view | Is the topic discoverable? |
| Intent | Registration or API key creation | Did the developer choose to continue? |
| Environment | Clean install and starter project build | Can the quickstart start? |
| First call | Request reaches the partner API or contract | Does the example connect? |
| Product behavior | Expected response, state change, or browser outcome | Can the developer use the product? |
| Reviewable result | Preview, deployment on a test network, or exported artifact | Can a human inspect the work? |
The denominator must travel with the number. “Activation improved” hides the important questions. An illustrative report might say, “18 of 40 workspaces passed the first-call check, and 9 of those produced the preview.” That lets a partner see where the path breaks without presenting a sample as a measured result.
The platform should preserve failed attempts as carefully as successful ones. In the same illustrative funnel, if 12 of the 40 workspaces failed before the first command, the starter environment needs attention. If 10 reached the API and failed on the same response shape, the SDK example or documentation needs attention. If the preview works but retention remains low, the integration may be healthy while the product value is weak.
Build a quest around behavior
“Read the docs” is a useful instruction and a poor technical quest. There is no clear artifact and no objective completion condition.
Use a small behavior instead. Suppose a partner provides a quote API for a paid service. The first technical quest could ask the developer to install the client, submit a valid request, render the returned amount and expiry, and show an actionable error for an expired quote.
That quest has a natural sequence.
clean workspace
-> install the partner SDK
-> call the quote endpoint with a fixture
-> assert amount and expiry in the response
-> exercise the expired-quote error
-> produce a preview or test reportThe task is small enough for a new developer and specific enough for a verifier. It also tells the documentation team which questions matter.
A verifier should state the exact behavior it checks. The following shape is illustrative TypeScript for a partner-owned test, not a claim about a private Blueprint Agent API.
type Quote = {
amount: string
expiresAt: string
}
function assertQuote(value: Quote) {
if (!value.amount || !Number.isFinite(Date.parse(value.expiresAt))) {
throw new Error('quote must include amount and a valid expiry')
}
}
async function verifyQuote(client: { getQuote(): Promise<Quote> }) {
const quote = await client.getQuote()
assertQuote(quote)
return { status: 'passed', fields: ['amount', 'expiresAt'] }
}The real check should run against the partner’s current public API or a documented fixture. It should reject a missing field and report the response, request identifier, and environment without exposing credentials.
Give the agent a workspace with a known boundary
An agent can explain an SDK call from a documentation page. It can do more when it can install the package, read the starter project, run the check, and inspect the failure.
An agent profile is the saved set of run choices, including the model, instructions, tools, permissions, and budget. A runtime is the software and machine that carry out the run and enforce its resource and access limits. The profile describes what the agent is meant to receive. The runtime determines which capabilities the session can use.
Use a profile that matches the task. If the quest needs a browser, the profile and runtime must expose a browser tool. If the quest needs a test account on a test network, provide a disposable account with restricted funds and a documented reset path. If the task needs a package registry or RPC endpoint, allow those destinations explicitly and record network failures. An RPC endpoint is a network address that accepts remote procedure calls, such as requests to a blockchain node.
The public Tangle AI documentation describes agent profiles as controls for models, tools, and budgets, and describes isolated sandboxes with explicit policies and resource limits. The AI agent sandbox guide explains why a persistent workspace matters when an agent must recover from a failed command. The related AI Coding Assistant With Deployment Evidence follows the evidence packet from a partner brief to a running result. For event-based programs, Crypto Hackathon Platform For Code-Verified Builds applies the same boundary to judging.
The workspace should start from a clean, versioned starter project. A developer can still import their own code, but the first measurement needs a known input. Without that boundary, a passing quest might reflect a developer’s local dependencies rather than the onboarding path.
Keep a trace beside every result
A trace is the ordered record of the run, including actions, tool calls, outputs, failures, retries, and artifacts. It answers how a developer or agent reached the result.
The trace is useful to several teams.
| Reader | Trace question |
|---|---|
| Developer | Which command failed, and what changed after the retry? |
| Documentation author | Which error or question repeats across sessions? |
| Support engineer | Can the failure be reproduced from the same inputs? |
| Partner lead | Which builders reached a real integration? |
| Reviewer | Does the evidence match the claimed quest? |
An evaluation is the named check that produces a result. The trace should record which evaluation ran, its version, its status, and the relevant output. Do not let the agent’s final explanation overwrite a failed evaluation.
An evaluation can be deterministic, such as a unit test that compares a result. It can be stateful, such as checking that a transaction emitted the expected event on a test network. It can be visual, such as a browser test that reaches a confirmation screen. Each type needs a failure message that tells the developer what to try next.
The trace should also state what it does not contain. Redact API keys, wallet secrets, personal information, and private source before a partner exports a session. Store a source or artifact identifier so a reviewer knows which version the evaluation saw.
Use the right Tangle surface for the job
Tangle uses Blueprint in its protocol vocabulary. A protocol Blueprint is a reusable definition of a service, including its jobs, inputs, outputs, executable artifact, and optional payment or verification rules. A Service is one live configured instance of a Blueprint, and a Job is one callable unit of work inside that Service. An operator is the person or team that supplies the infrastructure needed to run the Service. The public Blueprint documentation separates that template from a live Service and from an individual Job.
For onboarding, a partner can use a starter project and a build brief without turning the developer into a protocol operator. If the finished example becomes a protocol service, a job router maps each job identifier to the function that handles the job. The quest should exercise the routed behavior when that path is part of the integration.
Some partner APIs are paid.
x402 is an open standard that uses Hypertext Transfer Protocol (HTTP) 402 Payment Required to communicate payment requirements before a server returns a resource.
It can make a useful paid-service quest because the evaluator can check the unpaid response, the client payment step, and the returned result separately.
Payment acceptance remains one fact.
The quality of the returned result remains another.
The x402 HTTP 402 guide documents the payment requirement and response flow.
Some onboarding work may run in confidential hardware. An attestation is a signed statement about the code or environment observed by trusted hardware or its verifier. It can support an environment claim. It does not prove that an SDK integration is correct or that an AI response is useful. The Tangle execution confidentiality guide documents the policy boundary.
Design the partner launch around failure data
Before inviting a large audience, run the quest with a small set of clean workspaces. The goal is to find ambiguous instructions, missing fixtures, incorrect network settings, and weak assertions.
The launch packet should contain the following.
| Item | Minimum quality bar |
|---|---|
| Starter project | Builds from a clean workspace with documented versions |
| Documentation | Quickstart, API reference, examples, and common error answers |
| Quest specification | Input, expected behavior, failure cases, timeout, and evidence |
| Runtime profile | Tools, network destinations, budget, and secret rules |
| Support route | A human owner for failed or high-value sessions |
| Export format | Diff, evaluation results, artifact, trace, and redactions |
GitHub Actions can run repeatable repository checks, and GitHub Codespaces can provide a cloud development environment configured from repository files. Those tools are useful comparison points for the build environment. The onboarding platform’s distinctive job is to connect the environment to a product-specific quest and the resulting activation record.
The first launch can stay narrow. One partner, one starter project, and three quests expose more useful friction than a broad catalog with no owner. Review failed sessions at a regular interval and turn repeated failures into a changed example, a better error, or a smaller task.
Separate activation from instruction quality
A funnel can show where a developer stopped, but the stop does not explain itself. The first command can fail because the starter project is wrong, because the runtime lacks a tool, or because the developer chose an unsupported version. The platform should attach a reason category to the failure before it turns the event into a partner metric.
Use a fixed set of stages for each launch.
| Stage | Denominator | Useful measure |
|---|---|---|
| Workspace ready | Developers invited to a clean workspace | Readiness rate |
| First command | Ready workspaces | Setup success rate |
| First product call | Workspaces with a passing setup | Interface success rate |
| Product behavior | Workspaces that reached the interface | Technical activation rate |
| Reviewable result | Workspaces with a passing behavior | Export or deployment rate |
The denominator changes at each stage, so the rates cannot be compared as if they measured the same population. An onboarding team can improve the first-command rate by removing the product check entirely, which would make the dashboard look healthier while reducing its usefulness. Keep the stage definitions and check versions beside the numbers.
The same record can support several decisions without being reused as several kinds of proof. Developer relations teams can use repeated questions to repair documentation. Product engineering can use failed API calls to fix the SDK. Partner success can use completed technical quests to choose a follow-up conversation. No one should infer long-term retention from a single passing check.
Avoid turning proof into surveillance
Code-verified onboarding creates power for the partner, so it needs boundaries.
Do not collect full model prompts when a check identifier will answer the partner’s question. Do not retain wallet material that a test account can avoid exposing. Do not rank developers on tool-call count or model latency when the goal is a working integration. Do not require a particular agent path when a developer can produce the same artifact through an accessible workflow.
The platform also needs a human path for false negatives. A network outage can fail a valid implementation. A browser test can become flaky after a provider change. A hidden fixture can reject a correct edge-case choice. Record the failure reason and allow a reviewer to rerun or override the result with an explanation.
What code proof can and cannot tell you
Code proof can tell a partner that a named behavior passed under named conditions. It can reveal where the setup path fails. It can create a more useful follow-up list than a count of community joins.
It cannot tell a partner that the developer will retain the product. It cannot establish that the integration handles production authentication, authorization, malformed input, load, and operational failures. It cannot prove that the developer understands every line an assistant wrote. It cannot replace a product review, security review, or commercial conversation.
Use the proof to choose the next action. Fix the starter project when setup failures dominate. Fix the API or documentation when the first call fails repeatedly. Add a browser or deployment check when the integration works in a test but never reaches a user-visible result. Call a human when the work is promising and the automatic signal is ambiguous.
Carry one activation measure into the next launch
Choose a developer onboarding platform with code-verified quests when your partner needs evidence that builders can use the product. Keep a documentation site and a form for awareness and low-friction questions. Use an agent workspace when developers need help editing and running a real project. Use evaluations, traces, and reviewer access when the result affects grants, rewards, or partner follow-up.
The measure worth carrying into the next planning meeting is the count of developers who passed the first product-specific behavior out of the developers who received a clean chance to run it. Every other number should explain where that path stopped.
What is a developer onboarding platform?
It is a system that helps developers learn a product, start a project, complete technical tasks, and show evidence that the integration works.
What is a code-verified quest?
It is a small developer task completed by a named build, test, runtime, browser, or deployment check rather than a screenshot or self-report.
Why use an AI coding assistant during onboarding?
An assistant can explain partner documentation, edit a starter project, run checks, and help recover from setup errors inside a bounded workspace.
Does a passing quest prove production readiness?
No. A passing quest proves the defined behavior under the defined conditions. Security, load, product, and operational review remain separate decisions.
When should a partner use x402 in an onboarding quest?
Use it when the real integration includes a paid HTTP request and the partner can provide a safe test payment path. Keep payment verification separate from verification of the returned work.