# 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](/docs/integrations.html) 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](/docs/agent-cli.html) for authentication and installation. With a repository checkout, install from its root: ```bash 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 ```bash 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: ```bash 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: ```bash 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](/#product) for a tour of the growth workspace. The [read-only analytics demo](/tractionscout/demo) shows real, privacy-preserving aggregate traffic from TractionScout.com. For a more specific starting question, use the [weekly readout](/workflows/posthog-stripe-readout.html) or [content experiment](/workflows/search-console-content-experiment.html). ## Setup guides - [Agent CLI and MCP setup](https://tractionscout.com/docs/agent-cli.html) - [Connect the evidence your agent needs](https://tractionscout.com/docs/integrations.html) ## Start with this question How can my agent prepare useful work with the right project context? [Prepare my agent workflow](https://tractionscout.com/signup/tractionscout?workflow=agent-cli-automation) Your workflow is carried into setup. Review the project, sources, and request before starting a run. ## Related workflows - [Understand activation and revenue together](https://tractionscout.com/workflows/posthog-stripe-readout.md): Compare PostHog activation with Stripe payment and subscription evidence to choose a useful next growth move. - [Turn search demand into a content experiment](https://tractionscout.com/workflows/search-console-content-experiment.md): Use Search Console queries and landing pages to prepare a content hypothesis, a reviewable change, and a measurement plan.