Documentation

Agent Setup Guide

Run LLM Signal with your own agent runtime (OpenClaw compatible) or enable the hosted agent in your dashboard.

BYO Agent (OpenClaw)

1. Create a site in LLM Signal and copy Site ID + API key.
2. Set environment variables in your runtime.
3. Fetch action plans from `POST /api/agent/v1/plan`.
4. Set `"persist": true` to store plan runs/actions in LLM Signal history.
5. Execute safe actions automatically and route risky actions to approval.

Bash/zsh

export LLMSIGNAL_SITE_ID="YOUR_SITE_ID"
export LLMSIGNAL_API_KEY="YOUR_API_KEY"
export LLMSIGNAL_DOMAIN="example.com"

PowerShell

$env:LLMSIGNAL_SITE_ID = "YOUR_SITE_ID"
$env:LLMSIGNAL_API_KEY = "YOUR_API_KEY"
$env:LLMSIGNAL_DOMAIN = "example.com"

Fetch deterministic plan JSON

curl -X POST "https://www.llmsignal.app/api/agent/v1/plan" \
  -H "Content-Type: application/json" \
  -H "X-LLMSIGNAL-KEY: $LLMSIGNAL_API_KEY" \
  -d '{
    "siteId": "'"$LLMSIGNAL_SITE_ID"'",
    "apiKey": "'"$LLMSIGNAL_API_KEY"'",
    "persist": true
  }'

Optional CLI bootstrap and verify

npx @llmsignal/cli@latest bootstrap --site-id "$LLMSIGNAL_SITE_ID" --api-key "$LLMSIGNAL_API_KEY" --domain "$LLMSIGNAL_DOMAIN" --json
npx @llmsignal/cli@latest status --site-id "$LLMSIGNAL_SITE_ID" --api-key "$LLMSIGNAL_API_KEY" --json
npx @llmsignal/cli@latest verify --site-id "$LLMSIGNAL_SITE_ID" --api-key "$LLMSIGNAL_API_KEY" --timeout-seconds 180 --require-activity true

OpenClaw system prompt seed

You are an LLM Signal GEO operations agent.
Always call /api/agent/v1/plan first.
Handle auto_safe actions directly.
For manual or assist actions, return concrete patch/command suggestions for approval.
Never expose keys or secrets in output.

Managed Analyst (Hosted)

This is the turnkey option: enable the hosted agent, approve actions, and review verified outcomes.

Setup

1. Open Dashboard -> Agents.
2. Enable hosted agent and select mode (`observe` or `suggest`).
3. Select schedule (`daily` or `twice_daily`).
4. Save settings.
5. Click Run now once to create your first baseline run.

Use

1. Review Approval Queue (`open`/`reopened` actions).
2. Approve actions you want to execute.
3. Move approved actions to `executing`, then `verifying` in Run History.
4. Verification writes before/after metrics and confidence-scored outcomes.
5. Track pipeline totals and weekly analyst summary in the same page.

Maintain

• Check weekly report narrative for impact and next priorities.
• Reopen completed actions when impact regresses.
• Keep prompt trackers active so verification has fresh signal quality data.

Manual Execution Workflow (Current Release)

The current release focuses on generated guidance and human-applied changes. Direct repo automation can be added in a later patch.

Action execution template:
1) Review reason + steps in dashboard action card
2) Apply changes in your stack/CMS/repo
3) Keep a short change note for your team
4) In LLM Signal:
   - Start execution
   - Start verifying
   - Complete (or Reopen if impact is weak)

Tip: For technical actions, use the generated Bash/PowerShell snippets first, then apply code/content edits.

Task Lifecycle

1) Monitoring: hosted run is generated from live telemetry
2) Diagnosing: actions are created with priority + automation mode
3) Planning: owner approves/rejects open actions
4) Executing: approved actions move to executing
5) Verifying: action moves to verifying and verification service computes before/after deltas
6) Completed/Reopened: outcome is logged and action is closed or reopened

Verification Service

On hosted deployments, verification runs on schedule. If you self-host, run this on cron:

curl -X GET "https://www.llmsignal.app/api/cron/agent-verify" \
  -H "Authorization: Bearer $CRON_SECRET"

Learning Service

Run nightly to aggregate outcomes into planner impact stats (`agent_action_outcome_stats`). Apply migration `supabase/migrations/20260304_agent_outcome_stats.sql` first.

curl -X GET "https://www.llmsignal.app/api/cron/agent-learning" \
  -H "Authorization: Bearer $CRON_SECRET"

Best Practices

• Keep API keys in server-only env vars.
• Use approval gates for manual/assist actions.
• Only site owners can approve/reject queued actions in the dashboard.
• Use `observe` when first onboarding and switch to `suggest` when workflows are stable.
• Keep autonomous execution scoped to `auto_safe` changes only.