Fifteen agents behind Mira & Atlas.

01The mental model

Read these five sentences and you have the whole system. Everything after is detail.

The fifteen run across three theaters plus one on-demand job:

• Theater I — the live turn. One user message fans out into five parallel lanes. MIRA is the only voice the user hears. ATLAS thinks and acts silently with 35 tools. At end-of-turn three planner lanes compose in parallel, each emitting one structured object: MASON the brief, IRIS the "About You" identity file, and PULSE a high/low verdict on the client's hiring intent (a casual client is routed to plain search instead of the concierge). (ATLAS authors none of them — his edit_identity tool is gone.)
• Theater II — background research. ATLAS fires SAGE and forgets it. SAGE investigates the client, then a silent chain runs: IRIS dedups the findings into the dossier, LENS (vision) places harvested images — the client's homepage screenshot is now pinned straight into the brief's About-the-client section — and STYLO re-skins the workspace. Separately, when the client won't name a budget/timeline, ATLAS fires GAUGE — a background estimator that prices the work off the live Fiverr talent market and open-web rates, and proposes a figure for MIRA to relay.
• Theater III — the concierge, between turns. After the client settles on a shortlist, SCOUT hunts a deep pool of talent and ranks the strongest, STERLING negotiates with each one, JUNO rules pass or fail on every proposal against the brief, PORTIA writes each finalist's human "why they fit" pitch at the reveal, and HERALD narrates the live dashboard — all behind a client-approval gate and an anonymity wall.
• On demand — HUE picks the export template (editorial/modern/classic) when the client clicks "Export PDF."

02System map

Where the agents live relative to the runtime. The browser only ever does short REST; the web tier authenticates and enqueues; all agent work happens in the worker; results return to the browser as Pusher events and durable state lands in Postgres.

03How agents talk to each other

The most important thing to understand about this system is its communication. No agent makes a network call to another agent. Instead there are exactly these channels — each with different timing and durability. When you read an agent card below, the "Invoked by", "Produces", and "Triggers" rows always map onto one of these.

04Agent index

All fifteen at a glance. "Tools" counts function-tools the agent itself may call; agents with a forced/structured output (MASON, IRIS, STYLO, JUNO, PULSE, PORTIA) emit one schema'd object instead — though IRIS may first take one optional web_search round before composing (MASON's round was removed 2026-07-02 for latency). Each card links to that agent's full system prompt in the repo.

Deterministic, non-LLM glue (not agents, but load-bearing — see §09): the intent classifier intent.py, the checklist/gate renderer brief_checklist.py, the dual-lane orchestrator + tagged-notes handoff dual_lane.py, the shared conversation projector conversation.py, the SSRF-guarded image harvester site_image.py, the concierge pure-function tools, and the thin LiveSellerAdapter. The lineage's voice-filler and partner-note compressor are gone; ATLAS's edit_identity tool is gone too (identity belongs to the IRIS lane); STYLO is not a per-turn lane (it runs in the research chain).

05Theater I — the live turn, lane by lane

One user message enters run_agent_dual, which spawns five asyncio lanes that share a single event queue, merged into one ordered stream. The fast lane (MIRA) is unlocked so she replies instantly; the slow lane (ATLAS) holds a per-project lock; the three planner lanes — MASON (brief), IRIS (identity), and PULSE (buyer intent) — run un-gated in parallel with ATLAS's tools and each emits one structured object at end-of-turn (MASON a BriefPlan, IRIS an IdentityPlan, PULSE a high/low IntentVerdict). Nothing downstream waits on the three; a post-complete drain keeps the stream open long enough for their writes to land. ATLAS spawns SAGE within his turn; the notes ATLAS, MASON, and IRIS leave become MIRA's tagged reading next turn. Each lane runs in its own agent <name> OTel span, so a turn's trace breaks out per agent.

06Theater II — the background research chain

When ATLAS calls deep_buyer_research — which it may do only once the client's own website URL is confirmed on file (the tool refuses otherwise; added 2026-07-03) — it spawns a detached task and returns instantly. That task — _run_deep_research_background — runs a strict, ordered chain inside the worker. It emits no Pusher events; results land in Postgres and surface on the user's next workspace read. The order matters: IRIS must persist blocks before LENS so the vision pass has real block-ids to attach to.

07Theater III — the concierge, between turns

After the client settles on what they want, the concierge takes over between turns and talks to talents on their behalf. It is event-driven, not polled: every reactive step is a job enqueued from the web layer (a talent reply, a client answer, an approval). Two invariants dominate — a client-approval gate before anything reaches a talent, and an anonymity wall that keeps the client's view anonymized until the reveal. Two newer wires: a run auto-finalizes the moment its last thread resolves with ≥1 offer (finalize_if_complete — no manual reveal click), and every answered client clarification is also folded back into the brief + About You by MASON + IRIS (concierge_answer_ingest) — the concierge feeds Theater I's planners.

08On demand — HUE, the PDF template picker

HUE is not part of any turn. It runs when the client clicks "Export PDF." The button only records a turn and enqueues a job (doctrine: no slow work on the web cycle); the worker then runs HUE — one cheap art-direction call — and stores the chosen base template for the export. The export renders template-only and light-mode; there is no bespoke CSS.

09The deterministic glue (not agents, but load-bearing)

Several non-LLM components do the unglamorous work that lets the agents stay focused. They have no prompt and make no model call — but the system breaks without them.

10Rules every agent obeys

Beyond each agent's own prompt, the platform doctrine binds all of them. These are why the design looks the way it does.

• A rule the model must never follow is enforced where the DATA moves, not asked for in a prompt. Since 2026-09-24. The 6 Sep paragraph telling STERLING to refuse a client boundary on a protected class was live in prod when the same capture happened again on 8 Sep. One detector, recruiter/protected_class.py (a protected term next to a word naming who is being selected: “no Asian companies” goes, “no German to English translation” stays), now runs at four seams: the capture fold (and STERLING’s “noted” is REPLACED by the refusal), every write, the admin editor, and the read SCOUT filters with, which is what neutralises rows already stored. Metered per seam (recruiter.protected_class.rules_refused); the read count should decay to zero.
• The client’s OWN conversation with a talent is a lane of its own, and no agent answers in it. Since 2026-09-24. Messages the product sends AS the buyer (the rail’s brief push, the concierge’s deal push) open a buyer↔talent Fiverr conversation separate from the bot’s, and until now nobody ever saw a reply. recruiter/inbox_mirror sends, receives and reads it, with files both ways (antivirus-gated links) and Fiverr’s own message kinds labelled (CUSTOM OFFER above the line, never instead of it). It has its own table (buyer_seller_messages) so a direct reply moves none of STERLING’s turns, the silence timer or first_reply_at: a talent answering the client must not look responsive to a bot still waiting on them. A reply with no handoff row is dropped and counted, never given one.
• A model is swapped by EXPERIMENT, one per lane, never by editing the default. Since 2026-09-24. gpt-6-luna sits behind two config experiments, both at 0%: model.terra_to_luna6 over agent_model_default and model.luna56_to_luna6 over regional_agent_model. Two, because the lanes have different incumbents and one denominator would hide which moved; disjoint for free, because a project’s lane is frozen at creation. Unit is the project, and voice follows the arm. The scenario judge is pinned to the declared default so a cheap arm never marks its own homework.
• An id the caller already holds is not optional decoration — JUNO judged the price knowing nothing about who is paying, and filed her verdict into a CHECK that dropped it. Since 2026-09-22. The frozen client dossier (the 2026-09-17 rule below, migration 0229) is fetched BY project id, and score_offer_terms_with_brief took none: only the rare text-extraction fallback passed one, while STERLING’s register_offer — the path almost every real offer takes — called the scorer bare. So the wiring that shipped with the tagger buyer-context change reached almost no live offer, and the same $1,800 read identically for a repeat buyer with a $2k average order and for a first-timer. The second cost was invisible rather than merely silent: her offer_tagger report was filed with no project at all, and tag_findings CHECKs that exactly one of project/corpus is set, so the write raised CheckViolationError and the finding was DROPPED, not mislabelled — 96 of them in 14 days on dev, against 2 for every other tagger combined. The scorer now takes project_id/subject_ref and forwards both to _score_offer_llm; the handler passes the run’s project and the offer’s own key, exactly as the extraction path already did. The comments calling those ids “for the tagging report only, the verdict is identical without them” were true when written and stopped being true the day buyer context landed. This changes JUNO’s model input on every offer, so a verdict can shift; the live scenario suite cannot see it (no scenario drives the handler, and every JUNO scenario calls the scorer with no project), so it was skipped deliberately rather than spent for show.
• A window the client PICKED is a promise about when the shortlist is THERE, so the close is spent inside it, not after it. Since 2026-09-22 (Monday 3226572685). The buyer chooses 2h / 4h / 12h at the start-choice picker. Closing a run is real work — rank_offers plus one PORTIA card per finalist, an LLM call each — so collecting for the full duration started that work AT the promised moment and painted the results screen a beat after it. buyer_deadline_seconds takes REVEAL_HEADROOM_S (60s) off what arm_buyer_collection_window arms, and the reveal spends that minute. The headroom comes off the DEADLINE only: collection_window_hours keeps the buyer’s raw choice, so the waiting copy, the client’s view and repo/shortlist_timeframe still read the hours they actually picked.
• A figure is a TOTAL to whoever reads it, so a price registered as a rate is quoted with its unit at every surface. Since 2026-09-22 (Monday 3231047488). The 2026-09-17 rate fix made STERLING register the talent’s RATE on a brief the client priced per unit, and every renderer of an offer price still printed the figure alone: on prod (16 Sep, run 94d7b7de) the closing note the client sent the talent they hired read “at $40, within 14 days” for a $40/hour quote, which reads as the price of the whole job. RateBar.suffix is what a price in that unit reads as after the figure ("/hour", "/article", plus " per person"); format_offer_price(offer, rate=) and offer_proposal_phrase append it, a quoted RANGE taking it once at the end since both ends are per hour. deal_push_template takes the run’s brief_snapshot and the ghostwriter’s AGREED OFFER block takes the brief, so the fallback note and the composed Price line both say “$40/hour”. A plain slash, never a long dash (doctrine 1.13) — this string reaches a client and a talent. The finalist CARD is deliberately unchanged: it keys its unit on a HIRING run, so a one-off priced per unit still shows a bare figure.
• A thread leaves queued exactly ONCE, and a send loop that trusts its own batch is a race the client loses. Since 2026-09-17 (Monday 3226489277). On prod run 1674f407 the client approved outreach and pressed “Stop the headhunting” 12 seconds later. wrap_up closed the eight talents still queued and completed the run — and the send loop, which had read its batch once, kept going: every later dispatch sent its opener and wrote awaiting_seller OVER the closed the stop had just written. Eight talents were messaged after the stop, one banked a proposal nobody could reveal, seven were never told anything. Every writer now leaves queued through one compare-and-set (store.claim_queued_thread, UPDATE ... WHERE state = 'queued'): the dispatch asks the STORE, not its batch, twice — on entry and again after composing, because composing is the slow step — and withholds the opener if the run is over. A lost claim never revives the row, and the losing side is honest either way: if a stop won while the opener was on the wire, the DELIVERED opener is recorded and the talent gets the close-out the stop was too late to send. wrap_up, stop_talent and the reveal’s decline all close through the same claim, and the reveal no longer writes a no_reply row for a talent it never contacted. Both outcomes are METERED (recruiter.seller.dispatch_skipped{reason}, recruiter.seller.dispatch_raced{outcome}), because a race that loses silently is exactly the kind of thing a log cannot tell you the rate of.
• Ending the SEARCH is not ending the client’s access to who it found. Since 2026-09-17 (Monday 3230391034). The red Stop still has MIRA tell every talent the client did not take over that the search is done; it no longer locks the client out of them. The client stays on the field (the stage settles the moment the stop is ACCEPTED, and the completed snapshot only goes out once MIRA has written to everyone), every talent she reached keeps “Send message”, and a project reopened later offers the same actions. stop_talent(takeover=True) lets a CLOSED thread through when it carries a conversation handle and no takeover note yet (_closed_but_takeable), so the talent hears the plain takeover note after the close-out; a replay, an already-taken-over talent and a thread MIRA never reached stay untouched. And the Stop no longer contradicts a takeover landing while it runs: wrap_up skips a talent the client took over, read afresh before each note and again after STERLING’s compose, so nobody hears “the client is coming to you” and then “not this time”. A PROPOSER taken over after the Stop is still a pick (the 2026-09-15 rule below): the pre-loop uses the same gate, and the gate keeps them reachable until the client’s deal note is actually out (deal_pending), so a transient failure retries instead of silently dropping the note.
• Every judging model gets the CLIENT as evidence, frozen once per project, in the user half and never in the prompt. Since 2026-09-17. The gateway returns ~80 fields about a buyer; MIRA’s prompts rendered 12 and the TAGGERS rendered none, so a tag could be asked what a client SAID and never about who they ARE. The dossier is a 24h Valkey entry written at sign-in and a tagger asks its question WEEKS later, so a lookup would answer with today’s profile attached to a past event; migration 0229 freezes it once per project (first write wins) and every run reads that copy. Three properties make it load-bearing. It is EVIDENCE, not prompt: the live prompts are committed byte for byte under tagging/schema/ and pinned by a byte-equality test, so buyer context in a prompt would fork the product’s wording and leave the offline run measuring itself — in the user half, the live call and the offline run get the SAME block from the same function. It goes FIRST, because clamp_transcript drops the head, so a long conversation loses old turns rather than losing who it is with. And its header says whose data it is and that nobody SAID any of it, because a judging model is reading two or three parties at once and a tagger asking “did the client say X” must never find its answer here. personal_data is stripped BEFORE the write rather than filtered after; the table carries no bi_reader grant and the scrub map empties it on deletion; facts are bounded by construction (categoricals plus money BANDS, never a raw figure). One resolve per run (store.attach_buyer_snapshots) and one render in the base (with_buyer_context), so no tagger formats buyer data for itself and none can be left out.
• A fact the ACCOUNT already holds is a column, not a tag — and a menu the definition does not define is a measurement of its own envelope. Since 2026-09-17. The platform could not answer “was this an SMB” for most conversations, so every SMB cut was drawn by hand. finalize_brief_buyer_type, created in the BI console on 2026-09-09, carried a five-value menu with its definition written as a YES/NO question, so the offline envelope asked the model to answer yes or no from [smb, solo_professional, individual_consumer, enterprise, unclear] or not_applicable. It escaped: over 1000 subjects, 252 produced no answer at all and smb fired once. Rewriting the definition to define every value on the menu (the SMB bar kept verbatim) moved that to 10 no-answers on the same scope, measured, not assumed. The deeper half is WHICH source decides: a 1120-buyer SMB cohort (2026-09-17) was 69% identifiable from buyer_identities.company_size alone, 24% from the warehouse’s self-declared size, 7% from Clearbit, while an offline model read of 1000 conversations found FIVE. Clients do not state their headcount; their account often does. So from_company_size decides it and the model fills only the gap, exactly as tagging/ARCHITECTURE.md already required. conv_tagger asks it every turn, the turn latches projects.metadata_json.buyer_type with buyer_type_source recording which decided it — not a ratchet: a later better-informed read replaces an earlier one and unclear never overwrites a decided value — and the admin explorer gets a server-side buyer_types filter, which was the point of the exercise. between_2_and_10 is deliberately NOT smb: the bucket straddles the bar.
• Retention is a CONTRACT: nothing goes on a clock before its history twin exists, and deletion keeps the facts while erasing the content. Since 2026-09-17 (root doctrine 1.17). Postgres holds current state and the warehouse raw tier MIRRORS it, so a partition drop, an age-based DELETE, a reaper or a BigQuery expiry deletes from BI in the same breath — putting a table on a clock is therefore a contract change with three obligations. History first: mira_history.<table> exists and has loaded, or the migration header declares -- retention: <N>d, no-bi-effect: <reason>. Bank before you drop: any admin number that sums across the horizon reads a LEDGER folded forward behind a lagged watermark under an advisory lock, plus the tail newer than that watermark — and a ledger that borrows another’s watermark loses whatever an older worker advances past, which is why agent_trace_project_ledger keeps its own. Say how erasure reaches history: a history table keeps a row Postgres deleted only if every column it holds is a FACT under the account_scrub split, otherwise the history action has a parity step inside the 48-hour budget. Both gates run in ordinary CI, and an admin label claiming “all time” without a computed horizon fails its own test.
• An agent handed its own output as a list of NAMES cannot reason about it, and will go and ask the client for what it already knows. Since 2026-09-15. render_context_block's LAST SEARCH RUN section rendered the revealed shortlist as name (id8) and nothing else, so after her own hunt MIRA had no craft, price, delivery, rating or fit line for any of the people she had just put in front of the client — and live over the MCP surface she did the only thing that context allowed and asked the client to send her the portfolios of her top two matches. Each revealed card now gets ONE line (craft, price, delivery, rating + review count, PORTIA's take or the fit summary) for the first five, with the rest of what is revealed NAMED after them up to twelve, so a fully revealed eighteen-card run costs a few hundred tokens rather than a page. The older rule is untouched and is the reason the block is windowed at all: it renders only what the client has actually been SHOWN (revealed_count), so no agent can name a talent the client cannot see. The general form: a context block is the agent's only memory of its own work, and an identifier is not the work.
• Taking over a talent who has already PROPOSED is a pick, not an introduction. Since 2026-09-15. The waiting field's “Send message” ran one path for every talent: MIRA's takeover note followed by the search-lane job-description push (“I found your profile on Fiverr…”) — sent, in the proposer's case, to somebody MIRA had just finished negotiating a proposal with. stop_talent(takeover=True) on a talent holding an offer now follows MIRA's note with the CLIENT'S own deal-close note (the proposal recap with the brief PDF attached, the same note a carousel pick sends) and writes the buyer↔seller handoff as a concierge pick, sharing notify_pick's helper so the row is written once. The test is the BANKED OFFER ROW, never the thread's lane: a proposer can be parked on the client or back in conversation, so the frontend keys its half on FlowChip.hasProposal (an offer in offers_in_progress) and skips the search-lane push for them. Talents who never proposed are unchanged.
• An experience that never reveals itself has to announce what the reveal used to announce. Since 2026-09-15. Group B of the waiting experiment shows every proposal on the living field the moment it lands and never fires a reveal, and the concierge's only “proposals are in” inbox ping lived inside runner.finalize — so a group B client who closed the tab heard nothing while proposals piled up, while group A's client got the reveal ping. runner.announce_proposal claims the run's proposals ROUND with an atomic conditional UPDATE (the questions-round shape, one column pair over, migration 0227) and sends a count-free message with a Review-proposals CTA; a proposal landing while the round is open joins it silently, and the round closes when the CLIENT LOOKS (POST /api/concierge/{run}/proposals/seen, sent only while the tab is visible, idempotent, and deliberately NOT a buyer action for the abandonment backstop). The next proposal after a look announces again. One channel, no push/SMS twins; group A is untouched; an ended run announces nothing.
• A talent's OWN words to the client are the talent's, not the agent's: never normalized, and no longer withheld. Since 2026-09-15. STERLING asks every talent for a short personal note to the client and the finalist card has carried it since migration 0067, but the pre-reveal offer summary withheld it because free text can self-identify. That reason expired on 2026-08-18, when a proposal started carrying the talent's real name and face the moment it lands. AnonymizedOfferSummary now projects card_json.personal_note VERBATIM — no cap and, pointedly, no long-dash normalization, because §1.13 normalizes what an AGENT wrote and never what a person typed (the wall-guard test is flipped on purpose and now pins that an em dash inside a talent's note survives). The field renders it FIRST under the head as a person's message with their face beside it, not as MIRA's prose, and the Matches row previews one line of it.
• A ranked list and the badge that names its top item sort on ONE key, and a binary judge means the TIEBREAK is the ranking. Since 2026-09-14. The client's finalist cards and the recommended_offer_id that draws “Mira's Choice” are two separate projections of the same proposals, and they had drifted apart: rank_offers was moved months earlier to put SCOUT's shortlist position ahead of raw seller standing (the German-designer fix), and _project_finalists kept standing first. Because JUNO's verdict is a validity GATE rather than a grade (PASS → 100, FAIL → 0), the band ties on nearly every run, so the tiebreak is what actually orders the deck. Preprod run f1d0f795 showed the result plainly: five proposals all at fit=100, the deck led by the talent with the most completed orders, and the badge rendered on card two. Under group A's cap of three the two lists stop agreeing about MEMBERSHIP, not just order. The key is now identical in both places — (pinned, PASSED, scout_rank, standing, received_at), banding replaced by a straight pass/fail on 2026-09-17 so a graded legacy or mock fit_score can no longer reorder passing proposals — because SCOUT already weighed craft fit, the client's stated musts and quality (standing included), so the search's verdict outranks the raw ladder, while standing still breaks an equal or absent SCOUT rank and keeps the zero-standing determinism guard intact. Keep the two keys identical. 2026-09-17, three more benders of that order, and the one case where the badge must name nobody (Monday 3223906785). The order held in the ranking and was bent on the way to the screen: the results deck RE-SEATED the best match into the middle of the opening three on desktop (seatBestFirst / seatedBestIndex, both gone), the concierge lane re-sorted the served list by score in the browser as the search lane had already stopped doing, and a talent approached from SCOUT’s reserve had NO rank at all because shortlist_rank_map read only the first wave (shortlist_seller_ids), so profile standing and arrival time ordered them. The map now reads the run’s whole ranked pool (candidate_pool_json) first and standing orders only talents SCOUT never ranked. And on a group B deck a reveal keeps every scored proposal, JUNO’s failures included, so when none passed rank_offers recommends nobody — while the deck still crowned card one, presenting a partial fit as Mira’s pick. The mapper now carries fit_flag onto the card and the stage names no Mira’s Choice when the first card is flagged (every pass is served ahead of every fail, so a flagged FIRST card means nothing passed). The anchor is that flag, never is_recommended, which a pick overwrites.
• A commitment is judged ONCE, at the tail of the turn, on what the turn SETTLED — never on a half-written figure. Since 2026-09-14. set_search_preference commits a rate or a range across SEVERAL writes inside one turn, and since the handoff tier became a LEVEL (2026-09-14, 00:06) every reading below the tier released the client's booked call on its own — so the unit arriving before the amount, or a rate with no workload attached yet, cancelled a call the client had already booked. The tool's hook now records INTENT only; the worker judges the settled preferences once at the turn's tail (attention.is_below_handoff_tier), also after a turn that ends without complete, and an unreadable figure is UNKNOWN rather than a drop. lapse_handoff_tier hands the notice back for the worker to stream after complete, the disclaimer's pattern. The mirror half holds too: a later commitment back ABOVE the tier re-offers the card, a reschedule cancels every earlier confirmed booking at the vendor rather than orphaning it, and a burst guard keeps a re-offer from racing a booking.
• A prompt is a set of NAMED SECTIONS, every section can be dialled or given a second version, and every agent answers to the name the RUNTIME uses. Since 2026-09-03. Fifty four prompts are now assembled from declared sections rather than concatenated constants, each rendering byte for byte what it replaced, so one section can be served to a share of people or replaced outright by a second version (agentkit/declare.py, agentkit/live.py, admin → System Admin → Prompt sections). Three properties are load-bearing, and all three were bugs first. A section that is computed fresh every turn (MIRA’s workspace picture, STERLING’s thirteen runtime blocks, SCOUT’s four capped prompts) is a DYNAMIC slot, a stable identity over a computed body, because otherwise the largest per-turn half of what a person is told has no name at all. A live prompt is slotted at the SEND SITE, around the exact string handed to the model, rather than by the name of the constant that is supposed to hold it, because name binding once attached three call sites to the wrong text by 43,000 characters with everything still rendering fine. And the registry keys on the LABEL the runtime stamps, not the module a prompt lives in: those had drifted on ten of fourteen entries, so the console’s MIRA tab showed ATLAS and the 65,814-character prompt that writes every reply a client reads was not registered at all, which is why the first voice experiment allocated people faithfully onto a prompt nobody was served. Every failure path in this package returns the whole prompt: a bug here may change what is MEASURED and must never change what a client is answered with. 2026-09-05 fixed the unit and the record. Assignment moved from the PERSON to the PROJECT, because the readout measures a project’s outcome and one client with five projects was contributing five correlated observations counted as five independent ones, which understates the spread and makes a null result look significant; no project now means NO ARM rather than a fallback to the person, since a fallback would put a conversation’s first turns on one voice and its later ones on another. The record was wrong in the same direction: the slow lane filed under mira while serving atlas.* sections, so the table that explodes a turn into one row per section and looks the version up BY SECTION KEY produced 21 rows all reading default and the arm never became a row at all. The slow lane records as atlas, the fast lane records its OWN 35 sections and its own arm from the same call that performs the swap, and the arm is reported on the CONTROL too, because “nobody was on the experiment” and “the experiment never ran” are different facts. The same day the console started listing the 25 slots declared at a SEND SITE, which a walk of the registry can never find because their text is built per call; they are listed as a synthetic part per agent and marked NOT dialable on purpose, since a dial needs the builder and these are chosen at the call site, and a slider reporting a number over a prompt it cannot change is the exact failure the console exists to make visible. 2026-09-06 added INJECTIONS, and the shape is the whole idea: an injection is a section whose DEFAULT approach is the empty string, with two competing approaches carrying the text (always, appended every turn; on_event, appended only on a turn where its trigger fired) under ONE roll, so a project is in exactly one of three comparable groups and the question “is detecting the moment worth paying for, or should we just always say it?” becomes askable. Everything else comes free because it is a section, and it needs no new model call: on_event waits on a verdict the worker already computes and already awaits (attention.classify_attention_llm), so the text lands on the turn the moment is about, and whether the reply WAITS for that trigger is declared on the card rather than inferred. It is injected into the LAST static block, not the first, because appending to the first pushed MIRA’s 22,730-character widget prompt past the cache divergence point (agentkit/injections.py).
• A query on the request cycle is bounded by the PAGE, never by the TABLE — and a LIMIT bounds neither. Since 2026-09-08. /api/admin/users was paged in August and went on returning 504s for another two weeks, because paging bounds the rows RETURNED and not the rows SCANNED. Two shapes cause almost all of it and a LIMIT hides both: an ORDER BY no index can serve (a correlated subquery, a GREATEST, a jsonb extraction) must be computed for every candidate row before it can pick the top 200; and a per-row subquery in the SELECT list is projected at the scan, so it runs once per scanned row whatever the LIMIT says. Measured on a prod-shaped fixture (158k users, 77k projects, 1.6M messages) the first page took 71 seconds; the two-phase rewrite — an inner query that picks the page using only an indexed ordering key, an outer that computes the derived columns for the ~200 rows that survived — made it 220ms with a byte-identical payload. So: the default sort of a paged list is a real indexed column, a per-row probe becomes one grouped pass per source table, and a whole-population aggregate is legitimate work that belongs in the WORKER against the read-only analytics pool, with the request reading the materialized snapshot. Raising the request timeout, indexing to make a full scan tolerable, or capping the rows so it “usually fits” are the same mistake in three costumes. Now doctrine §1.16, with local halves in the repo and web CLAUDE.md files, because paging LOOKED like the fix in August and was not.
• A widget message is FROZEN the instant it is appended, so anything that can change under it needs a VERSION. Since 2026-09-07. A widget is written into the conversation under an id derived from the project and inserted with ON CONFLICT DO NOTHING, which is exactly what makes a replayed job safe — and exactly what makes the card unchangeable afterwards. The call-booking card exposed the cost: a guest is redirected into sign-in mid-booking, as designed, returns to the same conversation, and the card in front of them still opens the vendor’s pop-up, because signing in has no way to rewrite a message already written. The widget and message ids now take an optional VERSION (v1 is byte-identical to before, so nothing already on screen moves); a sign-in mints v2, a second mints v3, the queue-level idempotency key carries the version so a genuine refresh is never deduped away by the first card’s own key, and the project is recoverable from an id at ANY version so every older card still recognises a click. The live-push turn id is versioned with it, since a v1 turn is claimed and completed forever and a refresh that reused it would find nothing to claim. The refresh is unconditional on whether the client’s capability actually improved — a no-op refresh just reproduces the same card, which is cheaper than precomputing “did anything change”.
• Knowing WHO somebody is, is not knowing HOW TO REACH them, and a number is neither a name nor an address. Since 2026-09-07. A signed-in Fiverr buyer is a numeric subject to us; their display name is MINTED from that number, and the attested sign-in address had deliberately never been stored, on an identity-hygiene policy written long before anything needed to email a client. The consequences surfaced together on one feature. The booking card asks “do we have somewhere to deliver this” before it offers to book, and that answered NO for nearly every real signed-in buyer, not only for guests, so nearly everyone got a vendor pop-up instead of booking in the conversation. The calendar invitation, meanwhile, was handed the minted name verbatim, so the meeting read as seven digits and the host. Both are fixed by naming the sources rather than by trusting the identifier: the address now resolves from the identifier where that IS an address, then the attested capture at sign-in (a table of its own, one row per person, deliberately NOT a column on the identity table, because that table carries a blanket warehouse read grant this must never ride), then the gateway dossier; and where NO source has one, the card ASKS in the conversation and keeps the answer only if the booking succeeds. The invitee name resolves the way talent-facing copy already did, every candidate gated against the minted default, with the real address as the honest last fallback. A guest, who by construction can never have an address, is sent to sign in rather than to the vendor, so no booking claim is recorded for a booking that could not have happened.
• Which MODEL an agent runs on is decided by where the client is, once, and frozen there. Since 2026-09-03. Browsers reporting one of nine countries (IN, PK, BD, NG, BR, LK, EG, MA, KE) put the project on gpt-5.6-luna for every agent; PULSE rules those clients low by rule with no model call so the concierge is never offered; and both the project and the person carry the tier as a stored tag the admin Explorer filters, columns and chips. The country comes from the SPA’s own IANA timezone (with the backward aliases Chrome still reports) through a generated zone-to-country table, then the locale’s region, then the edge network’s guess; it is frozen at project creation the way the created-device tag is, and written once per user. Routing is a property over a per-job context variable the dispatcher sets, so every existing settings.agent_model read follows the lane with no call site changed (migration 0195).
• A classifier’s prompt lives in a committed FILE, and the file IS the prompt. Since 2026-09-02. A tagger’s questions used to live in three places at once: the prompt the product actually sends, a transcription of it kept beside the reporting code, and editable rows in the database. Nothing could tell you when the three stopped agreeing, so editing the real prompt silently made the other two lie and the report kept printing numbers under the old wording. Each prompt is now ONE JSON file under recruiter/tagging/schema/ whose entries carry the EXACT paragraphs, and build_prompt(load_schema(…)) reassembles what the model is sent byte for byte. Nine live call sites read from those files now, ATTENTION (conv_tagger), PULSE (finalize_brief_tagger), JUNO (offer_tagger), the attachment relevance read, the guest funnel’s relevance and experience scorers, the fast lane’s batch grader and the two clarification reads; attention._CLASSIFY_SYSTEM survives only as _CLASSIFY_SYSTEM_FROZEN, a test fixture. All ten blocks were GENERATED from their constants rather than retyped and verified character for character against a checkout of the pre-change code, and tests/test_tagger_schema.py pins it in BOTH directions: a prompt a tagger reports from that no block carries fails the build, so a call whose questions still live only in its own code cannot hide. Editing a question is therefore a visible prompt change, reviewed like any other, instead of a second opinion sitting beside the real one.
• The reader reports; what a fired event DOES is somebody else’s job. Since 2026-09-02 the tagger is an agent in its own right (agentkit/tagger_agent.py, TAGGER_SYSTEM) with three properties worth stating as doctrine. (1) It runs after the turn and the turn never waits for it — dispatch() is deliberately not a coroutine, the answer is already with the user, and an agent with no declared events costs nothing at all: no task, no model call, no row. (2) The description is the whole recognition rule, so an event can be added or reworded without a deploy touching the agent it watches, and an event the model names that nobody declared is DROPPED rather than stored, because the vocabulary is the declaration and not the model’s memory. (3) An event it cannot decide is not a “no”. A wrong no reads downstream as evidence the thing never happens, which is worse than an honest gap: a gap is visible, a false zero is indistinguishable from a clean result. Events are asked eight at a time because one prompt carrying forty questions gets forty careless answers, and a batch that fails loses only its own answers. Separating reporting from acting is what lets a behaviour be measured first and given an action later. 2026-09-06 — the agentkit half of this was deleted, and the doctrine survives on the other one. The event / tagger / dispatcher / store machine described above (agentkit/tagger_agent.py, events.py, actions.py, catalog.py, TAGGER_SYSTEM) had shipped and never once run: no agent ever declared an event, two of its pieces had no implementation outside a test, and it duplicated recruiter/tagging — a second agent, a second prompt and a second vocabulary for “did X happen in this turn”. The three properties above remain doctrine and are held by the tagging package, which is the one that actually runs; what the machine was BUILT for, acting on a fired event, is now an injection (see the sections rule above), which reuses the verdict the worker already awaits instead of asking a second reader the same question. The eighth tagger, and the mode that could block a turn. sterling_turn_tagger (2026-09-06) is the first reader whose subject is a whole talent THREAD rather than one turn, and the only one whose prompt is not transcribed from a live call, because nothing in the product judges a STERLING thread today — a question nobody has asked yet has no live answer by definition, and the run is what answers it. Its subject kind is load-bearing: whether a talent was brought work they do not take is answerable only from the brief plus what they said back, and the decline carrying the answer is the LAST thing in the conversation. It pays for itself on a number nobody had read: 43% of production’s 6,123 declines are out_of_scope and 31% are budget_too_low, roughly 4,500 threads in which the person best placed to judge the match already said it was wrong, in their own words, in decline_detail. Deleted with it: TagMode.BLOCKING, gate(), gate_timeout_seconds and fail_open, which had zero callers in a year and encoded the pattern this system exists to prevent — a tagger may be sampled, may time out and may be switched off, so nothing the product depends on may ever wait on one.
• A boundary a talent states is keyed on their USERNAME, and a capture that cannot be keyed FAILS rather than confirming. Since 2026-09-01. Every standing-preference read and write used to key on seller_threads.fiverr_seller_id, and migration 0091 says outright that the column is NULLABLE and that NULL is a NORMAL state: rows predating it have none, and the hand-picked shortlist flow never routes through the gateway that supplies the number. Dev logs that day showed five captures lost across two threads, every one answered “Only projects over $1,000, noted.” Same code, same messages, different thread provenance. The number was never the right key for this table — it was added for a BI join (migration 0111, because the Fiverr warehouse keys on a numeric user id and a username joins to nothing there) and enforcement inherited an analytics requirement — while BOTH ends of enforcement already carry the username and always have: seller_threads.seller_id is TEXT NOT NULL (migration 0018) and CandidateSeller.username is str, with SCOUT’s pool literally keyed by it. A Fiverr username cannot change, so the one argument for the number does not apply. Migration 0181 re-keys both tables and DELETES rather than backfilling them, since the feature had been live one day on dev and was off in production throughout, so no real talent had a boundary worth carrying. Three enforcement seams moved with it: the outreach floor gate, whose own comment admitted a thread with no number “is UNGATABLE here and is deliberately let through”; the finalist card’s availability slot, which silently degraded to “to be confirmed” for the same class of thread; and discovery’s key normaliser, which now lower-cases every map the way the repo does, because the thread’s stored id and the gateway’s username are free text from different systems and a lookup that silently misses is the whole failure being ended here. The half that generalises past preferences is the OTHER one: the unkeyable path used to return "", so no row was written, no block was appended, and a warm confirmation shipped regardless. It RAISES now, the turn fails, no reply is sent, and recruiter.seller_pref.unkeyable moves. Doctrine §1.5 asks for graceful degradation in UX: silence degrades, and the talent writes again while an operator sees the failure. A false promise does not degrade at all — it is indistinguishable from success to the only person who cares.
• The same agents answer inside Claude and inside ChatGPT, on the same turn pipeline. Since 2026-08-31, extended through 2026-09-02. Mira ships as a remote app on the MCP standard rather than as a second product with the same name: the chat tool claims and enqueues the ORDINARY turn, with the same idempotent claim, the same spend budget and the same turn-slot gates the web route has, waits on it by bounded poll, and assembles the reply and the widget from the persisted events, so nothing about how a turn runs is duplicated. It is its own Cloud Run service off the shared image behind one new role. 2026-09-01 moved the wait onto Mira’s FAST lane: it had been awaiting the entire dual-lane turn, ATLAS and the brief rewrite included, while the SPA shows her reply the moment the fast lane streams, so it returns on the first persisted reply, widget or error and the slow lanes drain into the card afterwards. A state of working with a reply already present is the normal shape there, not an error. Two lessons the surface taught that generalise. (1) Omitting a project id is not starting fresh. The worker’s fallback attaches a turn with no id to the user’s NEWEST project, which is right for a dropped thread and wrong for a new role, so every new hiring need overwrote the previous brief; the tool now takes an explicit new-project flag that creates the row BEFORE the claim, SPA-style, with the id derived from the same content key the claim already dedupes on so a host retry re-creates the SAME row and converges. (2) A destructive tool is a ritual, not a sentence in a prompt. Deleting a project does nothing without a separate confirm parameter and reports what the project holds first, and erasing an account acts only on the literal word DELETE, because a model reading a conversation is one misreading of “clear that out” away from destroying a brief. (3) Tool DESCRIPTIONS are the contract; instructions are a bonus. 2026-09-02 dumped the real tools/list and found the entry point had almost no pull: every description was written for somebody already inside Mira, so none of the words a person opens with (hire, find someone, freelancer, I need a logo, who can build this) appeared anywhere on the surface. Worse, the guardrail the whole relay design rests on — do not improvise hiring advice, budgets or talent suggestions yourself — existed ONLY in the server instructions, which the spec treats as an optional hint a host may simply never show the model. It now leads mira_chat’s description with a test holding it there. The same pass made project plumbing a SILENT rule (hosts had started offering to create projects and asking which to use, mid hiring conversation), carried the talent questions still waiting on the client into every chat turn because a surface with no push has no other way to interrupt, and returned the WHOLE ranked list instead of three at a time, since the reveal is what PORTIA’s per-match pitch is written off. 2026-09-15 split the surface in two and lost the thing that told callers apart. One service now serves TWO connectors rather than one with two doors: /mcp (serverInfo “mira-fiverr”) keeps OAuth with the Fiverr account as its ONLY lane and is the only one where the concierge can message real talent, and /open/mcp (“mira”) has no authentication at all. The Google lane is gone from both, and the Fiverr mount now RAISES AT BOOT rather than serve an authorization server nobody can sign in to. Two mounts, not two Cloud Run services, because they share the pool, the queue client, the card bundle and the kill switch, and what a connector user sees is already two servers. The SDK moved to 2.x, so both serve the 2026-07-28 protocol revision alongside every handshake-era one — and that revision DELETED sessions, which is exactly how the open connector had been telling one conversation from another. The caller became a workspace_key the tools themselves carry: a first call with no key mints one, every result hands it back, and a call naming earlier work WITHOUT the key is refused with an instruction rather than answered out of a fresh workspace. Two consequences worth generalising. (4) Only a ToolError's text reaches the model — 2.x redacts every other exception to “Error executing tool”, so an identity refusal that is meant to INSTRUCT the model must be raised as one. (5) A long tool should hand a HANDLE to a host that can hold one. mira_chat, start_search and download_brief_pdf answer a task-capable host with a task handle the moment the work is enqueued (MCP tasks, SEP-2663, as an SDK Extension); nothing runs in-process, a task is a Valkey record naming durable state so any instance answers any poll, and a host that does not declare the extension gets the tools exactly as before. Then all seventeen tools were driven by hand, and the six defects that fell out are one shape: a well-formed key nobody was ever issued opened a fresh workspace, a still-running search reported that it had found nothing, a reply claimed a Google sign-in on the connector that has none, a count said eighteen while eight cards were returned, approve and search both ran on a one-turn brief, and a DELETED project stayed readable and chattable by id while a garbled one surfaced as an opaque failure — every one of them an agent-facing surface answering confidently about something it never checked. (6) A card is hung in SOMEBODY ELSE'S room. The card painted Mira's own absolute dark (#0f1619 on #06090b), which is DARKER than Claude's warm charcoal, so on a transparent iframe over the host's chat every widget read as a black slab; dark surfaces are now a translucent lift (white at a few percent), lighter than any dark canvas by construction, with every token as var(--host-variable, mira-fallback). And because neither side can tell PER CALL whether a card actually rendered (host capabilities arrive only at initialize, which a stateless server does not keep), the fact that the client can already SEE the reply is stated where the model reads it: a “what the user sees” paragraph in every card-bearing tool description, held there by a test. 2026-09-24: no tool argument is nullable any more. A host that speaks strict function-calling marks every property required, so a str | None argument had to be sent as an explicit null and a first mira_chat was rejected by the host before it reached us. Optional strings now publish as a plain {"type":"string","default":""}; omitted, blank and null all mean “not supplied”.
• Every behaviour change is an ARM somebody can see, move and stop from one board, it DECLARES the behaviour it ships, and resolving it is what records it. Since 2026-09-10, completing the platform the prompt-sections work started. Six kinds of change now answer to one vocabulary and one console: a prompt section dialled below full, an injection, a slot approach, a product cohort, a branch in the code (arm()), and a Settings value over a closed allowlist (declare_config). The console answers “what IS this” for all six through GET /api/admin/experimentation/{key}/detail, in facts / one body / arms, so per-kind knowledge lives on the server rather than in six branches of a component. Four properties are load-bearing and every one of them was a bug first. (1) Recording is structural, not opt-in. The always-on A/A control had recorded NOTHING for its entire life — zero rows in every ledger and zero arms across 139,883 agent_trace rows — because writing an exposure was opt-in with FOUR hand-wired ways to opt in, and the experiment whose whole job is to prove the measurement pipeline is honest was the one nobody had wired. experimentation/record.py is now the only thing that writes an exposure, every resolver reaches it, and the bespoke call sites were DELETED rather than documented: a call you can forget had to stop existing. The A/A is the pipeline's canary as a result. (2) A dial the console can draw but not move is worse than no dial. A slot exists because a module-level declaration ran, which makes the registry a function of what each PROCESS imported: the worker imports the extraction and concierge code because it RUNS it, the admin API does not because it only reads about it, so seven declared slots drew cards and sliders that 404'd, twenty-eight times in one morning of dev logs with nothing else saying a word. (3) The default is DECLARED, never inferred (2026-09-11, extended to every kind whose default is a decision on 2026-09-13). An inferred default reproduced the exact lie the platform exists to remove: scout.on_site_lock ships ON, so its baseline arm IS the locked path and its other arm is the pre-lock one, yet the register read an absent row as “every arm at zero” and printed “off (0%)” — which is why an operator moved it to 5% believing that harmless and took the lock off 95% of on-site briefs. default_allocation is mandatory with no fallback now, POST /restore-defaults puts a whole environment back in ONE transaction with a dry run first, a full allocation resolves without the hash (hashing SPLITS a population and at 100 there is nothing to split, so an arm at 100 was quietly serving the baseline to any caller with no bound subject), and the canary rule measures DEVIATION from the declared default rather than the raw headline, because {lock: 10} read as a headline looks like a cautious 10% trial while handing 90% of the work to the untested path. (4) An empty row and a row of zeroes are different STATEMENTS (2026-09-13). An absent row means that kind's no-row fallback, which is the definition of the default, so it reads as AT the default and not as drift; a KILL writes explicit zeros, from the guardrail as well as from an operator, so a stopped experiment is never indistinguishable from an untouched one; and the restore sweep reports ORPHAN rows for experiments no declaration names, because “nothing to restore” and “the table is clean” are different claims. Deciding an arm is pinned as a PURE function — the assignment modules may not import the database, the cache, the settings, the clock or a random source — so the same (key, subject, allocation) answers identically in the web tier, the worker, a future service and a notebook reproducing last Tuesday. And the console deliberately does NOT name the measure: it answers what is running, to whom, and whether it is hurting anything, because a closed dropdown beside a dial can only ever be a subset of what BI already does properly, and two places to name a measure is two places to disagree about it.
• No slow work on the web request. Every agent runs in the worker; the web tier authenticates, enqueues, and returns in milliseconds.
• No streaming HTTP, no polling. Server→client is Pusher channels only; the agent package itself just yields events, transport-agnostic, and the worker republishes them.
• Async is durable and idempotent. Jobs carry stable ids; externally-visible effects are keyed (uuid5 + ON CONFLICT DO NOTHING) so a retry can't double-send or double-write.
• Degrade, don't crash. Every background stage swallows its own errors; LLM failures fall back to deterministic skeletons, palettes, or templates rather than an empty result.
• The work shape is one vocabulary, spoken end to end. Since 2026-08-16 a project is either a one-off delivery, an ongoing engagement, or both, and that single fact travels the whole chain rather than being re-guessed per agent: triage reads it each turn, PULSE settles it, ATLAS commits the rate-in-unit structure around it, GAUGE prices in that unit, MASON renders a start date instead of a delivery date, SCOUT ranks on ongoing evidence, STERLING tells the talent, JUNO compares like units, and PORTIA pitches availability. The fee and the money that merely passes through a talent are separate fields and are NEVER summed.
• Committed money has ONE reading, and it is conservative. Since 2026-08-22 recruiter/budget_view.py is the single place that turns the committed fields into a comparable figure, and the big-client alert, the auto-handoff tier, the admin money columns and the funnel’s money-weighted bars all ask it rather than reading columns themselves. The figure is a committed TOTAL, or ONE MONTH of a committed rate (month as-is, week ×4, year ÷12, hour/day/deliverable only against a STATED cadence). Nothing annualizes; headcount never multiplies (the figure is per person); pass-through external_costs_cents never counts, mirroring PULSE’s $500 floor; non-USD yields no value at all rather than an untrustworthy one; and a rate whose workload nobody stated has no value, because a gate must not invent hours. The operator label carries the unit (“$1,500/month”, never a bare “$1,500”). budget_mid_usd in repo/admin_insights.py is the SQL twin of the same arithmetic and tests/test_budget_view.py pins both to one case matrix. SPLIT 2026-08-25, deliberately and into exactly TWO readings: effective_usd_cents keeps every word above and every consumer it had (the admin money columns, the sort, the funnel’s money-weighted bars stay MONTHLY), while a new commitment_usd_cents beside it carries the whole sum the client signed up for and is what the two OPS tiers judge — because “$100/hour for 100 hours a year” is a $10,000 client and reading it as $833 a month is how a real one stayed invisible. A total exists only where the client BOUNDED the work (a fixed price, a stated annual quantity or rate, or a fixed number of months); where they did not, an open-ended retainer has NO total and is judged on the month against the same bar, which is the point rather than a gap, since annualizing it would make a $500/month arrangement a $6,000 client on the strength of a year having twelve months. The alert bar moves $1,000 → $3,000 in the same change (the handoff bar stays $6,000), because a total is a bigger number than a month for exactly these clients and widening what counts while leaving the bar alone would sweep in a band nobody asked for. year also joined the cadence vocabulary in that change — it had been week or month only, so “100 hours a year” was understood, written into the brief, and then stored nowhere. Nothing may grow a THIRD reading.
• Committing the money is the trigger, not pressing a button. Since 2026-08-24 the big-client alert and the specialist handoff both fire from set_search_preference, on the same read of the same BudgetView at two thresholds, rather than from a search start, a concierge start or an admin approve. All three of those are a PRESS, and most of an intake conversation happens before any press — a client who committed $8,000/month and kept talking to Mira reached none of them, so the desk that exists to meet them never appeared and the booking calendar never opened. The presses stay live and cost nothing beside it, because the takeover stamp one-shots every effect. SCOPED 2026-08-25: the trigger and the two tiers are unchanged, but every CLIENT-FACING limb of the handoff is gone — the booking popup and its embedded desk calendar, the human.takeover Pusher event, the desk ROUTING that chose which calendar to show, and POST /api/workspace/handoff-meeting. A high-value client then saw exactly what everyone else sees and the desk reached them OUT OF BAND, so “the booking calendar never opened” above describes the bug that prompted the change rather than a surface that still existed. RE-SCOPED AGAIN 2026-09-13: a client-facing limb is back, and deliberately a different one. What returned is not the vendor pop-up over the chat but a native card IN the conversation carrying the team's own open times, raised by the desk once and by ATLAS on every later client ask (offer_schedule_call, §ATLAS), with the booking recording the instant and the verification tier and a persistent pill under the topbar keeping a booked call in view. The trigger and the two tiers are unchanged; what changed is that a client who asks a second time can be answered. The two things the feature exists to feed are untouched and are now the whole mechanism: the big_client attention flag with its #mira-prod-big-fish alert, and the BigClientHandoffExportJob row CS works from in the shared BigQuery table. The admin Big-clients desk and its Stop / Pause / Release controls behave as before, and its Desk and Meeting columns are deliberately kept so history stays readable; they simply stop gaining rows. The hook is a callback on ToolContext (the worker injects a closure; a runner with no live publisher injects nothing and still commits the budget), and takeover.py moved from web/ to recruiter/ so the worker may reach it without importing web. 2026-09-14: the tier is a LEVEL, not a latch. A commitment BELOW the tier releases a booked call (cancelled at the vendor, the client told, the metadata cleared, the lapse stamped last) and a later commitment above it re-offers the card, with a mint stamp guarding the burst and a reschedule cancelling every earlier confirmed booking. The lapse is judged ONCE per turn on the SETTLED preferences rather than on each write (§10, “judged once, at the tail of the turn”), because the budget tool commits across several writes and every half-written reading below the tier was cancelling the call on its own.
• A talent’s standing preferences are THEIRS, a human approves them before they filter anybody, and the hours they work never remove them from anything. 2026-08-31: the feature is back ON — SELLER_PREFERENCES_ENABLED (concierge/seller_prefs.py) is True again, which is the state the seller-complaint card asks for. It spent five days off (2026-08-26), and the way it was switched off is why it could come back in one line: reverted rather than deleted, every line left in place, and the 12 behavioural scenarios skipped with a reason naming the constant rather than removed. The tests now pin BOTH states explicitly — seller_preferences_on was the only fixture, because “off” was simply what the constant said, so a sibling seller_preferences_off pins the dark surface and a future flip in either direction cannot quietly delete a state nobody is asserting. When it is off, STERLING behaves as though the feature never shipped (no tools, no policy block, no CURRENT PREFERENCES heading, no pending/refused NOTEs, no per-turn preference reads) and SCOUT filters nothing. Both halves are still gated by the ONE constant on purpose: with STERLING mute and enforcement live, a talent whose preference is already active is dropped from every client search with no way to see it, change it or lift it, and no way to raise the subject, because he no longer knows it exists — invisible filtering with no recourse is worse than either end alone. Since 2026-08-25 a talent can say what they will and will not be brought — a project floor, an hourly floor, a per-leaf price keyed on the numeric Fiverr sub-category, free-text rules and an availability date — instead of the one all-or-nothing opt-out they had. 2026-08-31 added the last facet, and it is the one that is NOT a screen: the hours they work. Migration 0179 had built the columns and argued the design, and then nothing ever read or wrote them, so a talent who said “I work 10 to 6” got “noted” and nothing stored, or landed the sentence in rule_text, where the grader reads it as a statement about the KIND of work under a prompt ending “if you are unsure, treat it as a conflict” and can take them off every brief there is. The capture REFUSES rather than repairs a bad window (a wrapping “10pm to 6am”, an hour off the clock, an end at or before the start), because this value ends up in a message the talent APPROVES and a window we quietly fixed is one they agreed to without being shown it; and it REPLACES rather than accumulates, because a person has one working day and a second window is a correction of the first. seller_working_hours() is the fourth hot-path read and the only one that drops nobody: hours are a fact about THIS MINUTE, so filtering on them would delete the Americas from every afternoon search and Asia from every morning one, for the same client and the same brief, with the shortlist depending on when the client happened to press the button. They are re-stamped onto in_working_hours right before the sort key reads it, worth 5 points (raised from 2 the same day, the same as being online, because presence is a flag the gateway supplies only sometimes while a clock is always available), and they can never cross a fit tier: craft outranks availability, always. The default window opens at 07:00 rather than 09:00, since these are the hours a message may land without waking somebody and freelancers start before an office does. The three price facets are deliberately NOT convertible: an hourly brief has no project total, a project brief has no rate, and comparing across them drops people by three orders of magnitude, so a brief carrying no comparable number enforces nothing and says so. Approval by the talent SUBMITS rather than activates (proposed → awaiting_review → active): a human clears every one in Talent Management > Preferences, each row deep-linked to the STERLING conversation it came from, because the capture is model-authored off one turn, the blast radius is every future search, and a wrong one is invisible from every side — the talent sees fewer briefs and cannot tell why, the client never learns somebody was filtered, and no error is raised anywhere. The stored rule line is the ONE string crossing from one user’s conversation into another user’s search, so it is held by a one-line validator at capture (120 chars, no newlines, no markup — refused, never truncated, and metered), a data-not-instructions fence in the grader prompt, and a post-grade clamp that lets a conflict only ever REMOVE the talent who stated it. Enforced at two seams, because discovery is not on the path for every send: the search drops below-floor talents before grading, and _dispatch_thread re-checks the floor for a hand-picked shortlist (and every other send), short-circuiting before the opening composer so a suppressed outreach costs no LLM call. Both loaders fail OPEN, and the metric carries kind, seam and severity so a rising SOFT rate reads as a prompt problem rather than a market one. 2026-09-16: the stored row now says what the talent said, not only what we computed. An erasure is declared (cleared_facets) rather than inferred from nulls, so an all-null row is either a named clear or refused outright; a rule is removed one line at a time; a non-dollar figure keeps its named amount and currency beside the converted cents; and the operator queue that gates all of it is keyset-paged with a server-side count, after a hard LIMIT 100 had left every later row unreachable while the page read as the whole backlog.
• WHEN somebody can start is a DATE, never a sentence of rule text. Since 2026-08-26 “not before September” is captured as seller_preferences.available_from (migration 0177) and screened by discovery.unavailable_in_time against the CLIENT’s own delivery horizon — the same question hard_filters.drop_out_of_office already asks of Fiverr’s vacation window, of a different source. A talent free BEFORE the deadline is kept; that asymmetry is the rule, and a brief with no deadline has no horizon to be late for, so it is metered no_deadline rather than passed over. It is deliberately NOT a rule_line: rule text reaches the SCOUT grader as evidence about the KIND of work somebody will not take, under a prompt ending “if you are unsure, treat it as a conflict”, so a timing sentence there does not degrade to inert — it plausibly grades the talent OFF every brief there is, the client never learns anyone was filtered, and the drop is indistinguishable from a capability mismatch. A date has nowhere to do that. Capture refuses what it cannot trust: a past date screens nobody, a vague answer is a reason to ASK which date, and a date beyond two years is a mis-resolved relative date far more often than a plan.
• The live rail is ONE continuous search, and every round re-ranks the whole list. Since 2026-08-25 the strip beside the conversation is the real SCOUT at max_rounds=1 — one round per refresh, replaying its own thread, so a conversation accumulates one search instead of a series of unrelated ones. Which lane runs is a CONSTANT in matching/lane.py, not a setting: the previous shape was an env field no environment ever set, so the fast lane shipped and the experiment arm spent a day being measured on the engine it exists to replace, green everywhere and wrong everywhere. It shipped strictly append-only, on the reasoning that the rail is read while it is built and “the third one” has to still be the third one, at the stated cost of a list ordered by when we found people rather than by fit. That cost turned out to be a bug (2026-08-31): the rail is capped at 18, so once the cap was full from earlier rounds the merge returned before it ever looked at the new one and every later round was discarded whole, which is how a client who asked for Spanish speakers mid-conversation got a list where 14 of 18 spoke no Spanish while a pool of 18 who all declare Spanish was thrown away at this seam. So the merge now RE-RANKS every round: this round’s ranked picks grouped by the fit tier it gave them, seen talents keeping their previous relative order within a tier with the round’s new finds behind them, and anyone seen but unranked this round retained below that so a thin round cannot collapse an 18-card list into a 3-card one. Stability became a property of the ranking rather than a freeze: sorting on (this round’s tier, previous position) makes an unchanged round byte-identical and moves a talent only when their tier actually changed, and it absorbs the grader’s between-round wobble for free. append_only_merge is kept whole and still tested, because the switch in lane.py is only a switch if the other side still works, and drops are now metered (recruiter.shortlist.dropped) rather than only logged, after the full-from-history case spent months returning ABOVE its own log line. The hand-over button folds through the same merge_cards, so the rail and the button cannot disagree, and run_concierge_search resumes the rail’s thread rather than opening cold and contacting a different set of people. What may start a refresh is ATLAS’s own judgment since 2026-08-31 (the refresh_talent_preview tool, over a floor that requires the project to carry a definition of its OWN), not the side effect of any state-writing tool call. Waste is cut at both ends: triggers inside an 8s window collapse to one, and discovery.discover takes a still_ours predicate checked immediately before the grade fan-out (~99% of a round’s cost) so a run that has lost the row stops instead of grading 673 packages nobody wants — recorded as superseded and deliberately NOT as an error, so a dead run cannot flip the healthy newer one to degraded.
• Never invent. Across ATLAS, MASON, SAGE, IRIS, and SCOUT the same line recurs: every fact, number, source, and talent must trace to real evidence.
• Mind the ~10KB Pusher cap. A full workspace is never pushed; oversized payloads set resync:true and the client re-reads GET /api/workspace.
• Every call is visible. Each LLM call logs tokens, latency, and dollar cost; each lane runs in its own agent <name> OTel span (gen_ai.agent.name, named via agent_identity) nested under the worker's job span — a turn's distributed trace breaks out per agent.