config.md

deep-dive-<account>-<HHMM>

/tmp

$ARGUMENTS

1.72M polls/day / 2,880 per instance = ~600 instances

$identify

$create_alias

$set

config.md

<SET THIS>

none

none

config.md

references/agent-briefs.md

references/data-rules.md

references/queries-account.md

references/queries-products.md

references/queries-money.md

references/site-scan.md

references/levers.md

docs-prewarm

references/voice.md

references/mode-email.md

references/mode-call-prep.md

data-rules.md

• scripts/phq.py

  sends any HogQL query over the HTTP API on four targets (

  us

  project 2,

  eu

  EU project 1,

  ch-us

  /

  ch-eu

  the direct ClickHouse connection).

  --batch <file.jsonl>

  fires many at once, one JSON object per line with the keys

  name

  ,

  target

  ,

  sql

  and optional

  connection

  ; any other key set is a

  KeyError

  before the first query runs. The MCP stays primary; this is the fallback when the gateway is down and the only path for EU.

• scripts/site-scan.sh <domain>

  runs the common shape of the Round 0 scan.

python3 << 'PYEOF'

curl --data @file

$1

$group_0

$

urllib

CERTIFICATE_VERIFY_FAILED

phq.py --batch

data-rules.md

• Budget in tool calls, never seconds. Cap each gatherer at 12 to 15, and split the brief BEFORE launching if the list runs past 15. Nobody can estimate an agent's seconds; everyone can count reads in a brief.
• The budget caps shape, never scope. Never drop, defer or narrow a read to fit it. The move when a brief is too big is to split it, and a read that still will not fit runs over budget and is named in the closing note.
• Split by call count; never merge briefs by topic. Concurrent agents are near-free in wall clock; calls inside one agent serialize into one chain. Merging trades a cheap resource for an expensive one, so the instinct to reduce agent count is backwards.
• 8 to 10 concurrent agents, each batching 4 wide. Past that ClickHouse returns 202 and the HTTP path returns 429, and the forced serial retries are slower than not splitting. The cap is machine-wide, so expect an occasional refusal and retry rather than shipping without the refused brief.
• Splitting stops paying below about 12 calls, because every agent carries a fixed startup cost whatever you give it. Split down to 12 to 15, then stop.
• A full call-prep set exceeds the concurrency cap, so it runs in waves. Wave one:

  change-point

  ,

  money-quotas

  ,

  clay

  . The first two frame every other finding (what moved, and what a limit actually cut off); the third is slowest.

  docs-prewarm

  goes last and never takes a required gatherer's slot.

site-scan

resolve-teams

sibling-sweep

get_account_conversations

agent-briefs.md

accounts[0]

get_user_details

vitally.accounts.traits

account-state

account-spine

onboarding-state

other-account-tables

conversation-bodies

change-timeline

billing-limit-updates

account-context

touchpoint-timeline

billing-limit-updates

docs-prewarm

internal-context

agent-briefs.md

agent-briefs.md

agent-briefs.md

JSONExtractKeys(assumeNotNull(properties))

per-product-usage

billable_feature_flag_requests_count_in_period = 0 in billing_usage_by_org_date over the window

1. Write

   unmeasurable, no source

   for every product the probe has no column for. Experiment volume and web analytics volume have no source anywhere; heatmap volume lives only on the usage report's

   teams

   map;

   ff_count

   lives on the org usage report.
2. Check

   realm

   on

   org-snapshot

   before trusting a flat zero: the table is Cloud only, so a self-hosted org reads zero everywhere while emitting usage daily, and it carries no row for a day with no usage.
3. Each brief says "verify against the product's own source and report what you found", never "confirm and move on".

• A site-scan absence against the customer's own event stream. The scan is authoritative for what it found, never for what it did not. If their team receives events carrying that host in

  $current_url

  , the tool is installed there whatever the scan said. One query, before any absence claim reaches the output.
• The header's money figures against the invoice.
• Two gatherers against each other, wherever they touched the same object. Reachability claims are the ones that collide: one role probes a table, gets

  Unknown table

  and reports unmeasurable, while another reads a near-identical name successfully and publishes a finding from it. Both digests are then true and the output carries a contradiction. Before writing, list every object more than one role touched and confirm they agree on whether it exists and what it holds.

• Claims whose own citation URL you fetched, against total claims. Count it from a list you append to as each verification happens, never from memory at the end of the run: a number reconstructed at the end is a number you will inflate, and an inflated count is worse than none, because the ratio is the only thing standing between a real Round 4 and a warm cache. Count fetched citations rather than searches run, because a search that returned a confident, adjacent page is exactly the failure this is watching for and it looks identical to a search that answered the question.
• Roles launched against roles required, and Round 1 slugs returned against Round 1 slugs required. Print both halves. A dropped role is the loud half and gets noticed anyway; a Round 1 slug that quietly never ran is the silent half, and it is the one that reaches the output as an absence nobody questioned.
• Hedges found, closed, and carried, as three numbers from the Round 3 list.

onboardingMinimumEligibility

3. Onboarding Completed

6c. Sales Handoff

7. Paid Call Purchased

vitally.custom.onboardingPipeline

1. New Account

2. Onboarding Initiated

3. Onboarding Completed

6c. Sales Handoff

7. Paid Call Purchased

New Account

3. Customer Engaged

3a.

3b. Engaged

6a.

6b. Onboarded

6d. Churned

1. New Account

vitally.custom.onboardingUsageOutreachSentDate

vitally.custom.initialOutreach

vitally.messages.from

source: "google"

Accepted:

Angenommen:

lastInboundMessageTimestamp

lastOutboundMessageTimestamp

crm_segments

segments

Onboarding Lead

Onboarding referral

CSM Managed

TAM

Top 20

Annual Plan

New Account

Sales Handoff

1. Terminal stage, or a live thread on the same topic held by a teammate OR by the sender: the flag leads, the research is still full, and the recommendation is a note or a loop-in rather than cold outreach. This sets the framing and never the mode, so carry on down the list; a run that stops here has a flag and no output. The sender's own recent thread is a collision exactly like a teammate's: not a reason to withhold a draft, but the thing the draft must not repeat.
2. inbound true and the latest inbound is a real customer question: email, reply state
3. else meeting present: call prep
4. else stage is

   1. New Account

   , or absent with

   onboardingMinimumEligibility

   true and no AE or CSM, outreach null, threads 0: email, first-touch state. An absent stage beside an assigned AE or CSM falls through to 4
5. else email, follow-up state

1. New Account

2. Onboarding Initiated

Flag: <only when one applies: a teammate's live thread on this topic, a stage mismatch, a sibling org. Never a roster name.>

quota-limits

Header field rules, since several traits collide:

| Field | Rule |
|---|---|
| Renewal | On an annual plan `nextRenewalDate` is the monthly billing-cycle end, not the contract renewal: use `contractRenewalDate` (or `numberOfDaysUntilEndOfContract`). On a monthly account they are the same |
| MRR | `usage_mrr` is actual, `forecasted_mrr` is forecast, both net of any credit discount (`forecasted_usage_mrr` is the gross figure, do not mix them). Delta is `forecasted_mrr - usage_mrr`; a negative delta on an annual account is usually the annual-vs-usage artifact, not churn. `diff_dollars` is a different comparison |
| Health | `healthScore` from `get_user_details`. Two warehouse columns share the name and neither belongs here: `vitally.accounts.health_score` is a stale copy, `account_health_scores.health_score` is PostHog's own engagement model |
| Users total | `usersCount` from `get_user_details`; per-query counts can differ |
| Org link | `https://us.posthog.com/project/2/groups/0/<ORG_ID>` (organization is group type 0) |

Before handing the output over, confirm all eight and send anything unchecked back to the round that owns it: every claim traces to this run's queries or live searches; every skip is named per subagent with its reason; every trap hit is reported, and a run reporting none was interrogated; every source disagreement shows both figures unresolved; the header is a real table with the People row present; **no section shipped as settled while an agent owning its subject was still running**; the Round 3 roll call ran and any shortfall is named; the closing note states both figures.

**The write gate is the one traded away under time pressure, so it is explicit: a still-running agent owns its subject until it returns.** Wait for it, or write the section and mark it provisional in the output. Marked provisional satisfies the checklist; shipped as settled does not. A confident section a pending agent then contradicts costs the user a correction on work they have already read, and may have already acted on.