Oracle

Choose who to trust: turn the people you already curate (follows, Lists, bookmarks, subscriptions, likes) into your Oracles — the sources the KB deep-ingests and roots trust on. Runs entirely in chat.

NOT the setup tool. onboard readies the machine (keys, consent, the first curation pull); this decides WHO is in. Reach for this when the user asks who to trust, wants to see or change their people, or asks whether their sources are current.

FLOW: call action='screen' → read the ranked candidates to the user (the PRE-TICKED ones are people you've corroborated with ≥2 distinct signals — your default-yes set; the rest are shown unchecked; non-persons are demoted to the end, never hidden) → ask which to keep → call action='confirm' with the kept canonical_ids → then, before action='ingest', ask the user how far back to pull and pass their answer as x_lookback.

Why that question is not optional: the default is only ~6 months, so a user who wanted their Oracle's whole visible history gets a fraction of it and is never told. (It is no longer a COST question — X reads are free since the cutover — it is a completeness one, which is the same reason to ask and a different reason to give.) action='screen' returns the exact presets and defaults under lookback_options — offer those, don't invent your own. The web archive is FREE and already pulls in full, so ask about it (web_lookback) only if the user wants it NARROWED.

To add someone NOT in the list, pass their X @handle or Substack URL in add_handles — they're resolved and added on the spot.

action: • "screen" (default) — the ranked candidate payload. Each candidate carries its reflected signal ("you follow · subscribe · bookmarked 12×"), pre_ticked / shown_by_default / is_person flags, distinct_signals, and its canonical_id (pass these to confirm). classify.ran=False means the kind classifier degraded open (LLM unavailable) — everyone stays person-eligible. • "confirm" — commit Oracle picks. canonical_ids = the ones the user kept (verbatim from screen); add_handles = raw X handles / Substack URLs to add (resolved-at- confirm). Idempotent. Returns {confirmed, unresolved, unknown, total_oracles} — surface unresolved (handles a lookup couldn't find) to the user. • "ingest" — deep-ingest confirmed Oracles into the atom-KB. For each (all confirmed, or just the canonical_ids you pass) run discovery — which mines their trusted blog/Substack for their OTHER profiles — then ingest each trusted personal profile as atoms attributed to the Oracle; an org link becomes an affiliation; an ambiguous one is left for review. Returns a per-source outcome report, with the windows actually pulled under lookback — read those back. • "candidates" — the OTHER half of the promotion decision. screen ranks people by how hard the USER vouched for them (distinct curation signals); this ranks the same people by what they actually write. Pass query to ask a topic question ("who writes about agent memory"); omit it to list who is there. Evidence comes from TWO stores and every row names which, in basis: · "probed" — a light sample of their own timeline (~25 posts). UNVETTED: nobody vouched for this text, only for the person being worth a look. Never cite it as knowledge-base content or quote it as fact. · "saved" — a post the USER saved, so it IS a knowledge-base atom and is citable (open it first). Usually exactly ONE post, and it is a positive example rather than a sample of their output: it matched partly BECAUSE the user kept it. Good evidence for "worth reading more of", weak evidence for "this is what they mostly write about". Scores are comparable only WITHIN a basis; the two are interleaved by rank, never added. Read back no_local_material — a candidate absent because nothing of theirs is stored looks exactly like one whose writing did not match, and those need opposite actions.

Is my stuff still current? You do not ask — screen answers it unasked, under oracle_freshness: per-Oracle, per-source last_pulled_at / hours_overdue / never_refreshed / breaker_open, worst first. If needs_attention is true, read its note out — that flag means either nothing has ever opted in to refreshing, or the cycle has stretched past twice its target. Both are silent failures otherwise.

A model_routing key, when present, lists models that are dead (no OpenRouter provider survives the deny-list — the stage using them cannot run) or fragile (one surviving provider — one withdrawal from dead). Read it out: it is absent whenever everything is routable, so its presence IS the news.