← Platform

Work-Product Gateway

Status
in-flight
Tier
Tier 2 — Platform
Owner
Ryan Colston
Started
2026-05-31

Linear: RYR-234 — identity resolution; RYR-241 — per-step evidence map (2026-07-23 vault→Linear audit)

One-line description. A read-only verification layer. Every SOP completion (starting with offer processing) is logged to BigQuery with its evidence and a verification state, so an agent can confirm their admin's work in one place instead of hunting across Gmail, Drive, FUB, and vendor portals.

Why

The biggest pain point when an agent hires their first admin is trust: the agent can't cheaply confirm the work got done right, so they either micromanage, re-do it, or hope. That turns a $4–$5/hr admin into anxiety instead of leverage. The Work-Product Gateway makes verification cheap and trustworthy — the admin logs every completed SOP through a form, the system collects those completions in one place, auto-confirms the ones a third party can vouch for, and routes the agent straight to the evidence for the rest. Cheap verification is the thing that lets an agent actually delegate.

It started as a broader "gateway for everything coming into the business" idea and was deliberately narrowed: not a system of record, not an everything-bucket, not a notification firehose. It is a bulletin board / read model over work products, with one job it uniquely owns — the cross-source link tying events to the same deal/person. First instantiation is offer processing for Marissa Tah's Jr Operations Coordinator (admin); designed to generalize to all SOPs and eventually all agents.

Current state

Design canonized 2026-05-31 after a long brainstorming session. First concrete artifact shipped: a TRAINING copy of the live Offer Processing Tally form so admins can practice on real offers without polluting live data.

Session 2026-06-02 — practice reps made visible + chat-routed (plain-language)

The trigger was a simple question: an admin (Princess) submitted a test offer and we couldn't easily find it. It turned out practice submissions lived only inside Tally (the form tool) and were deliberately invisible everywhere else, so nobody but Ry could see them. We fixed that end to end:

  1. Gave practice reps a permanent home — they now save into BigQuery (sop_events) with an is_training stamp that keeps them off the live board.
  2. Made them readable — two Google Sheet "posters" lay out the whole submission in contract order (so you can check it line-by-line against the contract), led by the Tally submission id + record key for traceability. One on the Agent Board (your/Marissa's lens), one a separate Jr Ops sheet for the admins to self-review.
  3. Made it automatic — the 15-min Cloud Run robot now ingests practice reps and rewrites both sheets on its own (was hand-filled at first).
  4. Per-team chat pings — every new submission posts a summary into the right team's Google Chat (routed by which agent the submitter belongs to), ending with a clickable Review link to the right sheet.
  5. Caught + fixed a CI bug — the build job only watched ingest_offer_form.py, so changes to refresh_sheet.py/notify_chat.py were silently not rebuilding the image; widened to *.py.

Shipped via MRs !294–!300. Detail in the Shipped list below.

Session 2026-06-04 — setters added, boards isolated per pod, linked in the handbook (plain-language)

Started from a question — "the setters have been submitting work, where are the results?" — and walked it all the way to clean, isolated, linked surfaces:

  1. Setters were submitting into a black hole. They log practice call recordings to a separate Tally form ("Setter Practice Recording", Pdky4P) that the gateway never knew about, so nothing reached BigQuery or any sheet — unlike the admin offer reps. Wired it in: setter reps now land in sop_events (sop='setter_practice', is_training=true, the voca.ro/Drive recording link as the bucket-A artifact), routed setter→agent. Chat pings are off for setter reps (high volume — the sheet is the surface, not a firehose). Surfaced as a standalone Setter Practice Recordings sheet + a "Setter Practice" tab on the board, one row per recording, sorted oldest→newest so a setter's progress reads top-to-bottom.
  2. Audit before sharing found cross-pod exposure. The combined board was already shared with both agents and showed both pods' data plus real past-deal client financials. Ry's calls: keep full detail, isolate per pod, keep the combined board as Ry's all-pods master.
  3. Per-agent isolated boards (replicable by design). Because Google Sheets shares per file, isolation = one board per agent. A new work_product.agent_boards registry maps each agent → their board sheet; the refresh renders one board per row, every tab filtered to that agent. Adding an agent is one registry row (provision_agent_board.py) — no code change, no redeploy. Marissa + Brandon each got their own board; both removed from the combined master.
  4. Linked in the handbook. Each agent's _agent.yaml carries a board_url, surfaced as a "Your Board" chip on their dashboard + every level page. Per-agent, no cross-leak. Verified live (authenticated Playwright pass on Marissa's gated dashboard).

Shipped via MRs !331–!345. Detail in the Shipped list below.

Next 3 actions

  1. ✅ Done 2026-06-04 — per-agent isolated boards (Marissa + Brandon), agents removed from the combined master; each board linked in the handbook ("Your Board" chip). Supersedes the earlier shared-board approach.
  2. ✅ Done — Brandon Plummer is a handbook agent (dashboard + setters Samuel Padilla / Rafferty Ojeba).
  3. Pillars 3 + 4 (FUB pipeline, pre-home-sale checklist) once Marissa returns SOP-Questionnaire Q3/Q4. (Setter-side now also has a coaching surface via Setter Practice.)

Deferred (not needed for MVP, Ry 2026-05-31): offer-submission confirmation. There is no Orchard "watcher" / signal to auto-consume — that was a wrong premise. The real model when we build it: the admin screenshots the Orchard confirmation page (bucket A artifact) and the agent confirms by checking their Cash Offer Marketplace dashboard (manual). For now offers just log (claimed); MVP = offer processing + offer prep flowing end-to-end.

Shipped

Decisions log

Decisions captured inline in the design doc (this project follows the "decisions in the design doc" pattern, like the admin-program-design):

Open issues

References

2026-06-25 — Board: in-progress row + regeneration repoint. The web console (board.rycolston.com/board) now renders a "Requested · generating…" row from PENDING/PROCESSING cma_requests so a just-submitted CMA shows immediately (MR !845), and ingest_cma_requests re-points an UNREVIEWED board item to the fresh doc URL when a report is regenerated (events_to_repoint, MR !844; reviewed rows never overwritten).