For Builders connecting coding agents, scripts, or CI to an existing growth workspace

Prepare growth work from an external agent

A coding agent or script can use the same project context and evidence as the TractionScout workspace. This workflow discovers what the project can do, prepares one evidence-backed growth move, and leaves durable work that you can inspect in the action queue.

The server retains provider credentials, project permissions, approval policy, audit records, memory, and quota tracking. External agents use a dedicated TractionScout user token with access to the intended project.

Before you start

Have a running TractionScout deployment and an accessible project with useful evidence. Review connecting your data sources if the project is new.
Obtain a dedicated user access token and the project ID. Store the token in your local environment or automation's secret configuration.
Use the CLI package or repository checkout provided for your deployment. Public package distribution may not yet be available during pre-release.
Review the project's AI configuration and budget before starting an agent run. Runs consume the project's configured AI resources.

Follow Agent CLI and MCP setup for authentication and installation. With a repository checkout, install from its root:

npm install -g ./agent-cli
tscout --help

The commands below assume TRACTIONSCOUT_API_URL, TRACTIONSCOUT_API_TOKEN, and TRACTIONSCOUT_PROJECT_ID are configured as described in that guide. Keep the token out of prompts and checked-in files.

Discover the project before preparing work

tscout auth:status
tscout integrations:list "$TRACTIONSCOUT_PROJECT_ID"
tscout capabilities:execution "$TRACTIONSCOUT_PROJECT_ID"
tscout analytics:suite "$TRACTIONSCOUT_PROJECT_ID" \
  --page-context overview \
  --run-rollup

Inspect connection freshness, available evidence, and execution capabilities. If a prerequisite is missing, make resolving it the next step. A successful authentication check does not establish that every integration or publishing capability is ready.

When the evidence and budget are suitable, explicitly start a preparation run:

tscout agents:orchestrate "$TRACTIONSCOUT_PROJECT_ID" \
  --prompt "Use the connected evidence to prepare one growth move. Include source references, evidence gaps, the proposed change, a primary metric, guardrails, and an observation window. Stage it for review without publishing or activating it."

The orchestration response provides a durable run_id. Set RUN_ID to that returned value, then inspect the run and queued work:

tscout agents:status "$TRACTIONSCOUT_PROJECT_ID" "$RUN_ID"
tscout actions:list "$TRACTIONSCOUT_PROJECT_ID" --status queued

Worked example: prepare a setup-page improvement

Consider an illustrative scenario, not a customer result: your project has a Search Console observation suggesting that people search for installation help, while the target page primarily explains product benefits. An external agent can request the relevant evidence and prepare a setup section for review.

A useful proposed action includes the source page and query evidence, the specific missing instruction, the proposed content, and a success observation such as completed setup after entering through that page. It also records missing first-party conversion measurement instead of inventing a number.

Review the durable run for source references and limitations, then inspect the staged artifact. The prompt's request to stage work is an expression of intent; the server's validation and approval policy still govern execution. Confirm the applicable approval and publishing path before shipping any change.

Use MCP or repeat the workflow deliberately

For a compatible agent client, use the MCP descriptor returned by execution capability discovery. The default mode blocks user-authored staging; review_staging additionally permits supported internal review artifacts. All MCP modes block external execution. Check annotations before calling tools: some reads can incur provider charges or persist evidence.

Before scheduling repeated CLI runs, establish a successful manual run and choose a cadence that matches new evidence. Inspect existing runs and queued work to avoid duplicates. Record the returned run ID, enforce an appropriate budget, and route failed or incomplete runs to an owner.

What a useful first result contains

You should have a durable run, source-aware output, and a reviewable next step, or a specific explanation of the missing evidence preventing one. Measure whether reviewed work reaches completion and its declared outcome; the number of generated actions alone does not show that the workflow is helping.

Explore the synthetic product walkthroughs for a tour of the growth workspace. The read-only analytics demo shows real, privacy-preserving aggregate traffic from TractionScout.com. For a more specific starting question, use the weekly readout or content experiment.