Fed by the whole team. Read by every agent.
becos pools what each engineer works out with their agent into one shared record — then holds every teammate's agent answers to it. Below: where the record comes from, and the five things it does to an answer.
Every engineer's session writes it. Every engineer's agent reads it.
Each agent session — whichever tool, whoever is driving — leaves the decisions, dead ends and conventions it produced in the same team record. Nobody files it; nobody gets interrupted to explain it later.
write path: every session • read path: every agent, scoped to your team
Add a retry with exponential backoff — 3 attempts, then dead-letter. Re-run the charge each attempt.
generic; no idea the team already solved thisMatch the existing pattern: key ledger inserts on (invoice_id, attempt) so a replay is a no-op. @rhea's original loop double-charged in April (INC-204); @dan replaced it with idempotent writes. You're picking up a convention two people already landed on — don't reinvent it.
@sam wasn't on the team in April. The record was.
Grounds every claim
Each line of an answer has to be supported by something in the record. What isn't supported is dropped — and the agent tells you the record is silent, rather than filling the gap with a guess that reads just as confidently.
Most likely Elasticsearch — it's the common choice for a search service of this shape.
pattern-matched, not looked upOpenSearch 2.x. The service moved off Elasticsearch in 2025 on licensing and cost. If the record held nothing on the search service, becos would say so — not guess.
Sure — swaps the SQS client for a Redis list-backed queue and updates the workers.
walks into a known failureFlagging this: the team moved off Redis queues in 2025 after messages were lost on a failover. SQS is the standard now — decision #infra-queue. Want to override it anyway?
Catches contradictions
When a draft answer runs against a recorded decision, becos surfaces the decision that overrides it — with its date and rationale — before the answer reaches you. You can still override; you just do it knowingly.
Stays on your team
Only your tenant's record is ever in scope. The match set is filtered to a host-maintained allow-list and the tenant prefix is dropped before any result reaches the model — a cross-tenant hit is discarded and logged with no content.
scope team:vonic allow-list [ vonic/agent, vonic/web, vonic/infra ] tenant prefix dropped before the model sees a result cross-tenant match → discarded, logged content-free
30 seconds — per the comment in api/config.py.
8 seconds, since the June 2026 latency work. The 30s in the api/config.py comment is stale — the record marks it superseded on 2026‑06‑19.
Knows what's current
Facts carry a lifecycle. A value that was replaced is returned as replaced, with the date and the thing that replaced it; a fact still being written, or one whose write failed, is never handed back as settled truth.
Every fact resolves
A citation isn't a footnote you take on faith. Ask becos to resolve it and it returns the stored commit or message verbatim — no summarisation, no model call in the path. You check the source, you don't trust the summary.
The recalled fact says retry handling was made idempotent. Pull the exact source it was built from.
commit 91d77af billing: idempotent ledger retries "invoice webhook can fire twice. keying ledger inserts on (invoice_id, attempt) so a replay is a no-op." changed: services/billing/ledger.py (+37 -6) author: @dan date: 2026-05-06T14:22:09Z
More of the same, on ordinary questions
None of these need a special prompt. They're the questions that come up mid-task, where a confident wrong answer costs the most.
Probably in an auth middleware — try middleware/auth.py or a decorator on the route handlers.
gateway/session.py — verification was pulled out of the app into the gateway during the SSO work so every service shares one path. Owned by @rhea.
Yes — new_checkout looks unused in the code, safe to remove along with its branches.
Hold off. new_checkout is still at 40% in production per the 2026‑08‑22 rollout note; full cut-over is gated on the fraud-review sign-off, which is open.
Migrations usually run in numeric order, so 040 runs before 041.
generic, not checked039 — it adds the invoices.status column that 041's backfill reads. 040 is unrelated (a web-repo index) and was renumbered out of order in the PR.
Whoever owns that service — check the CODEOWNERS file or recent commit authors.
points you back at the question@rhea wrote the ledger and @dan did the idempotency work — between them they authored 80% of services/billing in the last year. Both are on the billing-ledger feature.
See it on your codebase
Connect one repo and ask your agent a question you'd normally have to interrupt someone for.
Get started