Skip to main content
The Customer Health agent combines product activity, reliability signals, and approved production aggregates into a weekly report. Use it when you need current-versus-prior cohort comparisons, one durable report, and a Slack thread for questions and follow-ups. The agent’s instructions restrict it to analysis and dispatch: it must not change product code, customer data, provider state, or production. The repository deployment adds a read-only checkout and a tenant-specific production query policy.

​
Configure the managed template

This example adapts the repository deployment’s weekly settings and pins its managed role to @auto/agents@1.11.0/customer-health.yaml. Set followupAgent to an installed agent and slackChannel to your reporting channel. Choose cohort and activity definitions that your sources can actually measure.
.auto/agents/customer-health.yaml
All eleven variables are required by this template; the values above are example settings, not omitted-field defaults. See managed templates for import resolution and connections for making provider connections available to a project.
Importing the role does not grant production database access. Without a tenant-approved aggregate source, the report must mark production aggregates not configured rather than inventing results.

​
Schedule and coverage

The example runs at 08:30 every Monday in America/Los_Angeles, with a seven-local-calendar-day reporting window. The template anchors its window on heartbeat.scheduledAt, records explicit local and UTC boundaries, and uses half-open intervals for the current and adjacent prior window. Local-calendar arithmetic preserves the reporting clock across daylight-saving changes; a week is not always 168 hours. The report must record each source independently as complete, partial, unavailable, or not configured, with an as-of time and a content-free reason. Missing data is never zero. A healthy source with no matching activity is complete, zero activity, and still produces a report. If either the activity denominator or reliability numerator is incomplete, the overall verdict is coverage incomplete, not healthy. With the example settings, a cohort needs at least five accounts to be published. Smaller cohorts are rolled into other/suppressed. A high-error cohort needs at least five error events and an error rate of at least 10 percent of meaningful activity; a newly regressed Sentry issue may be flagged separately below that floor.

​
Durable reports and delivery

The template instructs the agent to derive a report key from the time zone and exact UTC window bounds, then reconcile existing Notion reports and customer-health sessions before querying. A completed key with confirmed Slack delivery is a silent no-op; an incomplete report resumes only the missing source work. The detailed report includes scope, coverage, product activity, reliability, approved production aggregates, current/prior comparisons, findings, source gaps, delivery state, dispatch history, and predecessor status. It remains the final auto session response, with Notion as the preferred additional artifact when available. For each report key, send one top-level Slack summary linking that artifact, not the full report. The artifact URL is the only permitted link in the summary. Both destinations exclude names, emails, customer or organization identifiers, raw events, message content, stack traces, and provider evidence links. An explicit pre-send Slack failure permits one bounded retry. A timeout or ambiguous outcome is delivery unknown and requires human reconciliation; it must not trigger an automatic resend. Delivery is confirmed only after Slack returns the canonical thread identifier.

​
Follow up in the report thread

Replies return to the reporting agent through its chat.thread binding. The agent can answer aggregate questions or re-query a requested slice within the same privacy and window rules. Dispatch requires an explicit human request. The agent uses auto.sessions.spawn for the configured followupAgent, with an idempotency key derived from the Slack thread and task. Its brief contains the artifact URL, report key, content-free finding identifiers, acceptance criteria, and authority limits, not raw customer evidence. If the target agent is missing or dispatch is refused, it reports the blocker rather than selecting a more privileged agent. The report records dispatched sessions and their originating threads. Completion or failure produces one evidence-backed reply in the original thread; a completed child session does not establish that a change is ready or merged.

​
Repository production policy

The fractal-works/auto deployment layers its repository runtime and a read-only main checkout onto the managed role. Its prompt permits production queries only through scripts/debug/auto-prod psql from /workspace/repo, requires read-only statements beginning with SELECT, and directs access diagnostics through scripts/debug/doctor-prod-debug. Access denial makes the source unavailable; it is not permission to bypass the wrapper or inspect credentials. Final query results are restricted to counts, rates, date buckets, bounded spend totals, and approved lifecycle labels. The approved metrics include external signups, activity after Day 0, self-initiated sessions, operator commands, lifecycle activity buckets, model-spend cohorts with no attended activity, and agent-opened pull requests. Organization and lifecycle buckets below the configured minimum are suppressed, organizations are never named, and schema drift makes the affected metric unavailable rather than permitting row-level discovery. These are repository-specific instructions, not permissions inherited by another tenant that copies the minimal example.

​
Keep the predecessor until replacement is proven

The repository’s Retention Digest remains authoritative. Customer Health’s parity instruction is to inspect the predecessor’s completed Monday 08:00 run, reuse its exact current and prior UTC boundaries, and compare only the two aggregate counts of external users with self-initiated activity. The predecessor’s per-user list must not be copied. Missing or ambiguous boundaries make parity unavailable; the 08:30 schedule is not evidence that the windows match. Replacement proof requires a real, non-test scheduled report with complete PostHog, Sentry, and approved-production coverage, the predecessor’s exact headline metric and boundaries, a durable detailed artifact, confirmed single-thread Slack delivery, no privacy exception, and an explicit parity explanation. Off-cycle runs, test data, missing sources, or uncertain delivery do not qualify. Even after proof passes, retirement is a separate human-reviewed change. The reporting agent must not pause, edit, or delete the predecessor automation.