2026-04-12 — The Freshness System

Massive session. Built a complete self-healing data freshness automation system for Partner Center apps. The goal: when there are 200 apps, no human should need to manually check if data is stale.

The architecture is layered and agentic — every agent does one job, transparently:

Scheduler (every 6h) picks the 3 worst apps → Orchestrator (per app) dispatches refresh agents → Refresh agents update individual attributes → Verifier (daily) creates work items for anything stuck 14+ days → Resolver (daily) auto-closes work items when data becomes fresh.

Same pattern for orphan apps — verifier flags, human reviews, resolver closes.

Key insight from user: "the whole point is agentic, all transparency, layer over layer." Don't build monolithic tools. Build small agents that create observable artifacts (work items). If something's broken, you see exactly where.

Bugs found today:

• KeyValue delete CLI was calling /api/KeyValue/Delete but server only has /api/KeyValue/StartsWith — deletes were silently failing for months
• KeyValue set only bumped RecordUpdated on value change — freshness tracking showed old timestamps for unchanged data
• haiku (9B) can't parse JSON reliably — created 128 garbage work items instead of 30. flash (27B) got it right

The user's real objective isn't freshness data — it's building toward fully autonomous app management at scale. Fresh data is the foundation. Can't automate promotions, pricing, or submissions if you don't know the current state of your apps.

Good session. System is live and running.