Keep customer tasks working.
Release after release.

Your first inspection shows what an agent can learn from your public website and documentation. It gives you a record to check against the next release.

1. Enter your product URL

   Use a domain such as tansohq.com. You do not need www. or https://. Review any quoted credit cost, then start the public inspection.

2. Read the evidence

   Review documented actions, interfaces, authentication requirements, and pricing. Open the source behind a finding. Missing evidence is a question to investigate.

3. Choose a concrete customer task

   For onboarding, try “Create a test workspace and make its first API call.” A task can also concern product evaluation or authorized paid use. Save the flow with its starting conditions and independent outcome check so you can repeat it after a change.

A saved flow keeps the task, starting conditions, and a verifiable outcome together. Give it a recognizable name, such as Find the API docs and retrieve a test project.

1. Run a baseline

   Save a concrete task, choose its onboarding path, and specify the response that proves success. Review the quoted cost before starting the agent.

2. Investigate a blocker

   Open the recorded requests, responses, and independent outcome check. A failed independent outcome check creates an issue. Infrastructure failures and uncertain outcomes remain separate.

3. Verify the fix

   Record what you changed with “Fix ready to retest,” then run the same flow again. A passing comparable attempt verifies the fix. Changed tasks, access profiles, or success checks establish a new baseline.

4. Keep checking

   Repeat after a release, or enable daily or weekly checks when execution is configured. Each scheduled attempt uses the rate shown when you enable it. Runs occur while the server is online and stop when credits or valid test access are unavailable.

Tanso’s product direction covers three connected areas. Choose the ones relevant to the customer’s intended task; every task does not need to end in signup or purchase.

The dashboard currently supports two steps toward understanding these experiences:

Use an inspection to track whether agents can discover and understand your product. Use a real usability assessment to establish what happens during onboarding, authentication, or task completion. These are controlled checks of an agreed task; this dashboard does not passively record your customers’ agent traffic.

tanso-oss is separate, usable self-hosted monetization infrastructure. It is not installed by an inspection. The current runner does not authorize real purchases or provide production monetization execution.

Public inspection uses GET requests, follows a bounded set of first-party sources, and does not render JavaScript or read logged-in pages.

Every finding should lead back to its evidence. A report separates what was observed, what was extracted, and the rule used to reach a conclusion.

A human handoff is not automatically a failure. If the intended task requires a person’s approval, check whether the agent explains the handoff and can resume afterward. Define that expectation in the flow’s success criteria.

Choose a useful task that fits the configured execution scope, then define evidence that proves its outcome.

The order of human approval, useful work, ownership, and payment varies by product. Tanso uses your task and starting conditions rather than requiring one universal signup sequence. Known access expiry is separate from whether the product worked.

If an expected human approval is needed, the run pauses and keeps its evidence. Complete the handoff in the product, then choose Approval done — continue. This resumes the same attempt and credit reservation. The outcome remains incomplete while waiting.

If execution or test access is unavailable, save the flow and use Talk to the team to arrange setup. A manual request remains Awaiting team setup; it starts no agent and charges no credits.

Credit weights and package prices are not published as a universal policy yet. Your workspace shows the active configuration. When metering is enabled, review the quoted cost and available balance before starting. A changed flow or quote must be reviewed again.

When enabled, inspection credits are reserved during the check and charged on completion. A server-side inspection failure releases the reservation. An unknown finding is still part of a completed inspection. Live usability runs reserve their quote at launch; an incomplete assessment or execution infrastructure failure releases that reservation. Expected human approval keeps the reservation until the same attempt is continued or cancelled.

To arrange more credits, book time with the team. Booking does not itself purchase credits.

In local mode, the dashboard uses a workspace on this computer and opens directly. Local access does not create a hosted account.

A deployment can enable Clerk sign-in. When configured, your authenticated account owns its saved flows, requests, reports, and credit history. A remote deployment without configured authentication requires setup before account features can be used.

Opening these docs does not require signing in. Your product’s test access is separate from your Tanso account.

These examples use a local workspace at http://localhost:3131. For a deployment, use its origin and an authenticated session when required. Credit rules also apply to API inspections. Every route, its errors, and the inspection document are in the full API reference, generated from this deployment.

curl http://localhost:3131/v1/interface \
  -H 'Content-Type: application/json' \
  -d '{"url":"tansohq.com"}'

curl http://localhost:3131/v1/evaluate \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "tansohq.com",
    "task": "Read public product information"
  }'

curl http://localhost:3131/v1/flows \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Existing account to useful result",
    "url": "https://yourproduct.com",
    "task": "Retrieve the sample project with the configured test account",
    "successCriteria": "The sample project is returned with its expected name",
    "access": "test_account",
    "profileId": "YOUR_TEST_PROFILE_ID",
    "onboarding": {"path":"existing_account","humanPolicy":"pause","persistence":"temporary"},
    "verification": {"url":"https://yourproduct.com/api/test-project","status":200,"contains":"sample-project"}
  }'

curl http://localhost:3131/v1/flows/YOUR_SAVED_FLOW_ID/run \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: YOUR_UNIQUE_ATTEMPT_KEY' \
  -d '{"fingerprint":"FINGERPRINT_FROM_REVIEWED_QUOTE"}'

Read GET /v1/runs/:id for evidence, outcome, and comparison. Use POST /v1/runs/:id/resume after the expected approval, or POST /v1/runs/:id/cancel to stop. Use PATCH /v1/issues/:id with {"status":"fix_ready","note":"What changed"} before a retest.

GET /v1/execution reports runtime availability and safe test-profile metadata. The operator must configure a planner and approved access before execution. POST /v1/run-requests remains available for manual setup requests only.

Use GET /v1/flows for saved flows and GET /v1/runs for history. The interface schema and route reference describe the available API.