Skip to main content

​
Connect

Mint an MCP token under Settings, API Keys in the dashboard. Tokens are secret; treat them like passwords. Org-wide tokens read every project; project-scoped tokens read one.

​
The loop

1

Pick a spec

Ask the agent to list task specs, or attach observerbee://task-specs/{id} as context. Specs are composed from findings by a person in the dashboard or in a chat host and marked ready when reviewed.
2

Implement with the guarded prompt

Use the fix_friction prompt. It tells the agent to confirm the defect in the source before changing anything, to open a draft pull request only, to cite the evidence links, and to treat each acceptance criterion as a checklist item.
3

Verify in production

After the change is deployed and has collected traffic, ask the agent to run verify_fix with the task spec id. It compares outbound transitions from the affected screen, drop-off at the affected journey step, journey health and loop traffic with the baseline captured when the spec was composed, and reports a conservative verdict per check.
Verdicts are measurements, not gates: “unchanged” often means the fix has not collected enough sessions yet. Run it again later.

​
Tools your agent will use

list_task_specs, get_task_spec, get_insight, get_journey, get_state_context, get_session_evidence and verify_fix. All are read-only. Decisions (marking a spec ready, approving a request) stay with people in the dashboard or a chat host.