DraftThis concept page is in progress and represents a forward-looking integration of Consumer Chat, Cases, the daily cycle, and the agent execution pipeline. Individual pieces are shipped; the seamless thread is the build.

The Customer Cycle, Designed

From a customer’s message in support chat to a production fix they verified themselves. In one afternoon.

Most product work doesn’t originate inside the team. It comes from the customer. A bug, a small UX request, a thing that doesn’t behave the way they expected. The traditional path: ticket sits in a queue for 48 hours, support triages, dev gets it next sprint, ships in two weeks, customer notified by email a month after they reported it.

The cycle below is the same loop as the agent-native daily cycle, but the originator is the customer and the verifier is the customer. The compression is not from doing more in less time. It is from removing the queues that today eat 80% of the elapsed time.

Honest scope: this works for small, well-bounded fixes. Bugs, tweaks, small UX requests. Not new modules. The story below uses a real-feeling small bug as the scenario.

The Scenario

On Monday morning a CS rep at one of your customers reports that their daily case-digest email is showing 12 new cases when the dashboard shows 8. Small bug, real friction. They open your in-product support chat (powered by Consumer Chat) instead of filing a ticket and waiting two days for a response. What follows is the entire cycle from that first message to a verified production fix, inside one working afternoon.

01Stage · CaptureMon · 9:14 AM

Customer opens support chat. AI triages in real time.

Acme Insurance · Support Chat

Sarah · CS Lead at Acme Insurance

My daily case digest email this morning showed 12 new cases for our team but our dashboard only has 8. The numbers don’t match.

Support · ProductIntel

Got it. Quick clarifying questions so I can look at the right thing: which timezone is your account set to, and is the dashboard you’re looking at the team-level view (“Cases this week”) or your personal queue?

Sarah · CS Lead at Acme Insurance

Eastern. And it’s the team-level view, "Cases this week".

Support · ProductIntel

Thanks. One more: the digest email landed in your inbox at what time? I want to check whether the count includes overnight cases that would have been dashboard-counted under yesterday.

Sarah · CS Lead at Acme Insurance

7:02 AM Eastern.

AI triage state · Mon 9:17 AM

Surface identified

Daily case digest email cron · /api/cron/case-digest

Hypothesis

Digest cron uses UTC midnight cutoff, dashboard uses tenant timezone. 4-case discrepancy = ~4 cases between UTC midnight and 5:00 AM Eastern

Confidence

0.86 — high enough to refine into a work unit

What humans do

The customer types their issue in plain English. The PM is not yet involved. Support team is not yet paged.

What AI does

Recognizes the customer, the product surface they're describing, and the artifact (case digest email) involved. Asks contextual follow-up questions to disambiguate before guessing.

02Stage · RefineMon · 9:18 AM

AI converts the case into a work unit. The case stays open.

ProductIntel · Cases · CASE-2241 · Auto-refined

Parent case

CASE-2241 · Daily case digest count mismatch

Acme Insurance · Sarah (CS Lead) · Mon 9:14 AM

Status · Investigating
Spawned work unit↓ knowledge graph edge

Work unit

WU-CASE-2241-A · Fix timezone cutoff in daily case digest cron

Type

Bug fix · backend cron · single file change + test

Acceptance criteria

  • ·Digest cron uses tenant timezone (not UTC) for the day-bucket cutoff
  • ·Existing test for digest count is updated to assert tenant-timezone behavior
  • ·Verified against tenant with timezone offset that crosses the UTC boundary

Anchored to · From Context Engine

  • ·Cron · /app/api/cron/case-digest/route.ts
  • ·Service · /lib/services/case-digest.ts (line 47, dayStart calculation)
  • ·Tenant timezone · pb_tenants.timezone column (already exists, unused here)
  • ·Existing test · /tests/api/case-digest.test.ts (does not cover timezone edge case)

Customer voice · preserved

“My daily case digest email this morning showed 12 new cases for our team but our dashboard only has 8.” — Sarah, Acme Insurance

Confidence handoff

AI confidence at handoff: 0.86. Above the 0.75 threshold for auto-refinement. PM is notified that a customer-originated work unit has been refined and is queued for execution. PM can pause for review or let it run.

What humans do

The customer keeps watching the case. The PM gets a notification that an AI-refined work unit has spawned from a customer case (visible in /work alongside other items).

What AI does

Converts the conversation into a structured work unit. Anchors to specific files, tables, and the existing capability. Marks the case as the parent so customer voice stays attached.

03Stage · BuildMon · 9:22 AM → 11:30 AM

Agents execute. Customer is told a fix is being worked on.

ProductIntel · Idea · Execute · Activity Log

WU-CASE-2241-A · Live activity

⬤ RUNNING · ~$0.18 spent

9:22orchestratorSpawned worktree at agent-jobs/case-2241 · branch agent/case-digest-tz-fix
9:24agentRead /lib/services/case-digest.ts · identified UTC dayStart on line 47
9:28agentReplaced UTC dayStart with toZonedTime(now, tenant.timezone) · 11 LOC change
9:36agentUpdated test fixture: tenant timezone Eastern, cases at 23:30 UTC and 04:30 UTC
9:42agentnpm run test:api · case-digest.test.ts now covers timezone-edge case · all passing
9:51agentSelf-review · acceptance criteria met (3 of 3) · no other consumers of the cron path
11:12gitPushed to origin · agent/case-digest-tz-fix
11:14ghPR #251 opened · "Fix tenant-timezone day-bucket in case-digest cron" · awaiting review
11:30casePosted update to CASE-2241: "Fix is built and pushed. Preparing a preview environment for you to test."

2 commits · +14 / −3 across 2 files · PR ready for review

Customer kept in the loop via case

What humans do

The customer gets a single short message in chat: 'I'm investigating, will reach back when I have something to test.' No SLA dance, no escalation paperwork.

What AI does

Spawns isolated worktree. Codes the timezone fix in the case digest cron. Updates the test that should have caught this. Pushes the branch. Opens PR. Posts a status update to the case.

04Stage · PreviewMon · 11:45 AM

The fix deploys to a preview environment. Preview URL pushed back into the chat.

ProductIntel · Vercel · Preview Deploy

Branch

agent/case-digest-tz-fix

Tenant data shape

Acme Insurance · seeded copy

Preview URL

case-2241-preview.productintel.io

Why preview-shaped, not prod-shaped

The preview environment is seeded with the customer’s tenant shape (timezone, sample cases at the boundary times) but anonymized. Real auth flow, real cron logic, no real PII. The customer sees their own scenario reproduced and verifiable.

Acme Insurance · Support Chat (continued)

Support · ProductIntel

I built and tested a fix for the timezone cutoff in the digest cron. Can you try this preview link and let me know if your case count now matches the dashboard? It’s seeded with cases at the boundary times so you can verify directly.

Mon 11:45 AM

Support · ProductIntel

→ case-2241-preview.productintel.io

Click to verify · expires in 24 hours

What humans do

The customer gets a chat message with a preview link and a specific verification ask. They are asked to do exactly one thing: confirm the count matches.

What AI does

Triggers branch deploy with the customer's tenant data shape (seeded from anonymized prod). Generates the verification link. Sends the verification message to the chat.

05Stage · VerifyMon · 1:30 PM

The customer confirms the fix in chat. Case is marked verified.

Acme Insurance · Support Chat (continued)

Sarah · CS Lead at Acme Insurance

Just checked the preview. The count now shows 8, matches the dashboard. Looks fixed!

Mon 1:30 PM

Support · ProductIntel

Thank you for confirming. I’ve marked your case as verified and routed it for production review. You’ll get one more message when this lands in your live environment, which should be today.

Mon 1:31 PM

CASE-2241 · State change · Mon 1:31 PM

Status

Investigating → Customer-Verified

Verification source

Customer reply in chat

Next gate

PM review for production promotion

What humans do

The customer returns to chat after testing the preview link. They confirm or report a remaining issue. Their voice is the verification, not an internal QA pass.

What AI does

Logs the verification on the case and the work unit. Notifies the PM that customer verification passed and the fix is ready for production review.

06Stage · DeliverMon · 2:15 PM

PM reviews scope and risk. Promotes to production. Case closes.

ProductIntel · PR #251 · PM Production Gate

Verifications

  • Build · passing
  • Tests · passing (existing + new TZ-edge case)
  • Type check · passing
  • Customer · verified in chat at 1:30 PM

Risk assessment

  • · Single file change · isolated to digest cron
  • · No other consumers of the affected day-bucket function
  • · Backwards-compatible · UTC tenants unaffected
  • · Cross-tenant scope · all tenants benefit, none regressed

Deploy summary · AI generated

Fixes a tenant-timezone bug in the daily case-digest cron. The cron previously bucketed cases by UTC midnight; now buckets by the tenant’s configured timezone. Originated from CASE-2241 (Acme Insurance), customer-verified in preview at 1:30 PM. Two-file change (cron + test). No data migration. Zero downtime.

Closing message to customer · AI drafted

“Sarah — the timezone fix you tested is now live. Your tomorrow morning’s digest will use Eastern timezone for the day cutoff. Thanks for the quick verification, it kept this on a same-day cycle. Closing CASE-2241.”

What humans do

The PM is the only human gate before production. They review the diff summary, the test report, the customer's verification message, and the risk assessment. One approve, one merge.

What AI does

Drafts the deploy summary, distinguishes customer-verified work from agent-self-tested work, surfaces any cross-tenant risk, drafts the closing message to the customer.

Customer to Production · Same Day

Reported 9:14 AM. Verified by the customer 1:30 PM. Live in production 2:30 PM.

The cycle ran end to end in one afternoon. Three humans were involved: the customer who reported it, the customer who verified it, and the PM who promoted it. None of them waited in a queue. The customer never had to repeat themselves to a second-tier rep, never had to wait for a sprint to start, never had to find out about the fix from a release notes email two weeks later.

The compression is not magic. It is the absence of queues. The work itself was a few hours. The wait, in a traditional cycle, would have been weeks.

One Afternoon · Six Marks

9:14Customer reports
9:18AI refines
11:14PR open
11:45Preview to customer
1:30Customer verifies
2:30Live in prod