Workspaces and Agents

Connect source-controlled Ansight workspaces and terminal-capable coding agents to the same resident host used by the local player.

The local player and coding agents share a host, not an embedded chat surface. The player provides visual session and test review. Agents use versioned ansight commands and repository-owned workspace definitions.

Connect a workspace

Initialize or validate an Ansight workspace from the repository root:

ansight workspace init .
ansight workspace validate . --json

Workspace files define tests, tasks, triggers, quality rules, sanitizers, and schemas in source control. The host discovers them from the connected repository; the player then exposes applicable Tests and Trends views.

Give an agent focused context

Start with the smallest stable identifiers:

ansight host status --json
ansight session list --connected --json
ansight session show <session-id> --json

Pass the selected session ID, app ID, or test ID into later commands. An agent can inspect screenshots, logs, telemetry, visual trees, artifacts, annotations, and guarded app tools without scraping the browser UI.

Keep evidence explicit

  • Session evidence remains local unless a person or command explicitly exports or shares it.
  • Repository tasks receive only their declared inputs and host defaults.
  • App tools remain subject to the SDK’s runtime guard and policy.
  • Host-local paths are never implied by selecting a file or session in the player.

Practical workflow

  1. Select the live or recorded session in the player.
  2. Copy its stable session ID or discover it with ansight session list.
  3. Ask the agent to investigate that ID with the relevant Ansight skill.
  4. Review the evidence or linked test trace in the player while the agent works.
  5. Keep reusable behavior in workspace tests, tasks, triggers, or trends.