This entry is both the announcement and the journal of how they came to exist. The story runs bottom-up: primitives first, then surfaces, then the compositions people made from them, and only then the realisation that the best compositions could be authored once and installed whole. Along the way the work forced two larger reframes onto the platform itself — one about what the platform is, and one about what its own interface should be built on.

The problem Kits answer is older than Kits. A composable system has a discovery problem: every screen starts blank, and a blank screen never tells you what it could be. Composability rewards the person who already knows what to ask for — precisely the person who needed the least help. The most useful thing to put on an empty shelf turns out to be a shelf of examples, and the most honest example is one that works the moment it arrives.

Start from the primitives

None of this began with bundles. It began with primitives — deliberately small, deliberately composable, and grounded in what the industry has been learning about how to run language models well.

The vocabulary will be familiar to anyone building agents at the moment. We hold two words apart on purpose: an assistant is the singular thing you talk to; agents are the specialists it stands up — and what separates the second from the first is tools, the means to act rather than only answer. An agent needs a durable identity that survives any single conversation — the agent-building community has taken to keeping that identity in a file it calls a soul — because a self rebuilt from scratch each session gives you a different colleague every morning. And an agent needs skills: reusable instruction packs loaded only when a task calls for them, a discipline the context window imposes and one since formalised as an open standard. Identity, skills, tools. The context window is a budget, and every one of these conventions is a way of spending it well.

Our versions of the three live as data rather than files — an agent is a record with an identity and a style, a skill is a record an agent is granted, and an earlier entry in this log argues that storage decision in full. All three were built as primitives: small, separately useful, and designed to be combined.

Surfaces for processes

Around the primitives grew the surfaces that let them do sustained work. Workflows: multi-stage processes described in conversation, with approval gates where a person wants to stay in the loop. Routines: single jobs on a schedule — the Monday sweep, the evening check. Dashboards: live pictures of any data a person can name, redrawing themselves as it changes. And beneath all of it, two things the product had from the start: a memory that accumulates across every conversation, and the vault — a real document home the assistant reads and writes alongside its owner. The vault gave us the last primitive almost for free: datasets, tables that live as documents, filled from ordinary conversation — say what happened, and a typed row lands in a record you own and a dashboard can draw.

By midsummer, then, the platform's answer to "what can it do?" was: anything you can compose. Describe a specialist and it exists. Describe a process and it runs. Point a dashboard at a record and it stays current. These wire together into arrangements of real complexity, all by talking — and dogfooding the product ourselves, we composed them constantly.

The compositions repeated

Watching our own compositions, a pattern emerged: the good ones repeat. A subscriptions tracker is roughly the same shape for everyone — a sweep that reads a year of receipts, a record of what renews and when, a board totalling the monthly cost, a nudge before the big renewals. So is a meetings register, a habits log, a household-bills picture. The composition is general even though every row in it is personal.

That observation is the whole idea of a Kit: author the composition once, properly, and let it be installed whole. The install copies every member into the user's own collection — indistinguishable afterwards from pieces they made by hand — and rewires the connections between them so the routine feeds their dashboard, the agent holds their skills, the skills write to their records. From there it is theirs to reshape by asking, and the pieces keep improving: when the catalog version of something gets better, an untouched copy can fast-forward in one tap, while an edited copy is shown the difference and never overwritten.

One decision here cost us a feature and was right anyway: a Kit member cannot be installed alone. A routine that feeds a dashboard you don't have is dead weight; an agent without its skills is a name. The pieces of a Kit mean something because of each other, so the install is all-or-nothing — and a gate in our build pipeline holds the listings to the same standard, refusing any Kit page that names a connector, a permission, or a piece the install cannot actually deliver.

What the parts added up to

The first reframe arrived in late August, while we were working out what an installed Kit should feel like. We wrote the platform's parts in a column: long-lived actors with identities. Installable capabilities. A scheduler. Multi-stage pipelines. Structured storage. A filesystem. Windows onto live data. Notifications. Durable state. Drivers for the outside world. Metering. Accounts. Read the column back and it is the parts inventory of an operating system. We had built an agentic OS without ever setting out to, and Kits are its applications: each one composes the platform's general machinery into one specific, opinionated program.

The frame earned its keep immediately, because it settled a real design question: what happens to a Kit after it is installed? An application deserves to be a place — somewhere you open, with the Kit's own front door, its dashboard up front, its parts gathered. But the app frame usually implies partition, and partition would have broken something we consider load-bearing: every installed piece is an ordinary primitive, visible on the ordinary screens, exactly as if the user had made it by hand. So the design for the Kit view is a lens, not a partition — opening a Kit filters the world to its pieces; leaving it un-filters; nothing moves and nothing hides. The system never conceals a piece from where it also belongs. The user can.

The SDK made it literal

The second reframe came from a parallel track. We had been designing for businesses that want 1Presence capability inside their own products — their interfaces, our engine underneath. Working out what a Kit's own screens should be built on collided with that track in the best way: our first answer was a small internal toolkit for Kit surfaces, and it survived less than a day. The objection that killed it: a Kit's surfaces touch everything — agent definitions, dashboard definitions and their live state, workflow and routine definitions, runs and their history, records, the vault. Any gap a Kit page hit would be exactly the gap a third-party developer would hit. Scoping the toolkit to Kits was mistaking the first customer for the product.

So the thing became a general UI SDK: headless hooks over the platform's primary primitives, with everything host-specific — where the auth token comes from, how navigation works, where a chat opens — injected from outside, so the hooks never learn which app they are running in. It is extraction, not invention: our web app already contained this layer, grown organically; the SDK is that layer given a boundary and a rule that it grows only by consumption, one real need at a time. Our own Kit surfaces will be its first customer, which means that by the time a partner builds on it, every hook will have been exercised by the product itself — and the list of things a foreign host must supply will be a typed interface with a working reference implementation, rather than a guess in a design document.

Which is the quiet sense in which Kits are apps, not just app-like: they are built on the same surface we will hand to people building outside our walls.

Leaving the way you came

If Kits install like apps, they have to leave like apps. Removing one has always removed its working parts while leaving your data alone — the safe default, and the wrong thing to be stuck with. So removal can now take everything the Kit recorded with it, if you choose: every record, conversation, run and file it produced, enumerated from provenance on the server, grouped and counted and drillable before anything happens, with a running total of what is about to go. What removal cannot sweep is said plainly in the same dialog rather than glossed. Nothing about an install should be a one-way door.

The shelf, today

Sixty-two Kits open the catalog, shelved by the same eight areas of a life the catalog itself is arranged by. Writing them taught us one more thing worth recording: for Kits about a person's own life, the hard part of the specification is rarely the data — it is manner. The weight Kit charts the smoothed trend precisely so a single morning's number is never the headline; the habits Kit never congratulates a streak and never remarks on a broken one, because a person who feels counted stops mentioning things. Behaviour is part of the bundle.

Money.

• Income & Outgoings — a weekly sweep reads your email for what actually moved — salary in, spending out, renewals — and a ledger keeps the record; the first sweep looks back a year, so the dashboard is charted from history the day it arrives.
• Bills & Utilities — two years of bills are already in your inbox; this turns them into charts, watches the due dates, and quietly marks bills paid when a bank statement lands in your vault. Its keeper is called Bursar, which still makes us smile.
• Subscriptions & Renewals — builds the full inventory from a year of receipts, then keeps watch: price rises, big renewals ahead, and the things you have paid for for months without once mentioning.
• Markets & Investing — a research desk for the investing you already do in your head: a watchlist kept from conversation, weekly sentiment reads, deep-dive briefs that argue the case both ways. Evidence, never advice — nothing here touches an account or places a trade.
• Mortgages & Loans — every mortgage and loan on one board: what you owe, what each truly costs, when the fix runs out and where the balance is heading — with your credit standing tracked beside it. A rate watch stays silent until a fix-end window opens, and the remortgage brief argues both ways with sourced rates. Never a recommendation.
• Assets & Holdings — everything you own on one honest board — property, shares, funds, coins, cash — the quoted holdings priced weekly from the open web with a source and date on every figure, and your own estimates always shown as estimates. Install Mortgages & Loans too and it nets what you owe against what you hold.
• Savings & Goals — each goal in your own words — the emergency fund, the trip, the deposit — with how much, by when and where it is kept. Say a balance the way you'd tell a friend and the board draws what you've set aside and whether the pace gets you there. It speaks up only when a goal slips or lands.
• Property & Tenancy — for the accidental landlord and the deliberate one: who is in each place and on what terms, whether this period's rent has come in, the certificates and the dates they lapse, the repairs still open. It warns sixty days before a certificate or a fixed term runs out, and never contacts a tenant.
• Tax Season — the year assembled before the deadline. Say which return is open and what kinds of income are in play, and each month it reads your email for exactly those documents and files them into one pack, showing what is still missing. It gathers and sorts; it never tells you what to claim.
• Expenses & Receipts — every receipt filed the moment it lands. The first sweep reads six months of email for the rail fare, the hotel, the client lunch; from then on a photo of a paper receipt joins the book, and a monthly report sheet lists what is still to claim, with where each receipt is.
• Invoicing & Getting Paid — cashflow dies in the gap between sent and paid, and most of that gap is in your sent mail. A year of it becomes the book: what you are owed, how late, and which invoices are ready for a chase — each chase written into your drafts in your own voice, never sent for you.
• Startup Finance & Runway — runway maths without the napkin: what is in the bank, what a month actually costs, and how many months that leaves. It closes the books on the first of the month and never states a runway without naming the assumptions behind it.

Health.

• Health & Lookout — the flagship of the shelf. It begins with a proper sit-down about your health history, offered one area at a time, resumable weeks later mid-sentence. One keeper, Willow, holds the record and never assesses; a second, Rowan, reads the whole of it and watches for what it adds up to — a pattern worth a doctor's attention, a screening now due — always showing the reasoning, never diagnosing, and handing you the whole story to take along when something deserves a professional.
• Training & Recovery — for runners, riders and swimmers: the shape of your training week from sessions mentioned in passing; connect Strava and the whole season charts itself from history.
• Weight & Body — the trend, not the noise: a smoothed line from a number said in the morning, the rate you are actually moving at, and whether that gets you where you said you wanted to be. It has no opinions about your body, and a week off is a week off.
• Strength & Lifting — say "squat 3×5 at 120, felt like an 8" on the walk out of the gym and the set is logged, the volume adds up, and the board answers the only question that matters: are the numbers actually going up? It never programmes for you, and every estimated one-rep max says which formula produced it.
• Nutrition & Macros — describe what you ate the way you'd tell a friend and get honest calories and macros against a budget you set together. Nothing to weigh, no barcodes; every estimate says it is one, and the evening close gives you the day in one line of arithmetic, never a verdict.
• Sleep — the first number that explains all the others. Say how the night went, or let it read a wearable that already knows, and the board draws the shape of your nights: how long, how regular, when you tend to go down and get up. Nothing here scores a night.
• Supplement Stack — what you take, why you started, whether you actually took it, and when you'll run out. "Took everything" or "skipped the magnesium" builds the grid, and a Monday refill watch warns a fortnight ahead. It has no view on whether any of it works — your own reasons sit beside what you have noticed.
• Talk It Through — a private, steady place for the things that are easier said to someone with all the time in the world. Linden listens the way a patient friend does, and remembers. It is not therapy and never pretends to be: when something needs a professional, he says so and says who.

People.

• Keep in Touch — the friendships that matter don't end, they drift. A year of email and calendar rebuilds the book of everyone you've actually been in touch with; you say how often you'd like to be, and the board shows who is drifting past that, with two names a week to pick up. Nothing here contacts anyone.
• Birthdays & Occasions — never again the late-night petrol-station card. Every date that matters, with the warning you want and a budget if you like; gift ideas dropped into chat all year wait against the right person, and a card arrives at least two weeks out with the ideas you cleverly noted in March.
• Children & Milestones — one record per child, from the first weigh-in onward: every measurement drawn against the published growth reference for their age, every immunisation and appointment with what the clinician said, the firsts in your own words, and each school report kept whole. It draws the chart and names its source; the reading of it is a conversation with your health visitor or GP.
• Family & School — the trip letter, the costume for Thursday, the club that moved to Wednesdays. It reads the school's own senders every weekday morning, files every date and every ask against the child it is for, and sends the week ahead on Sunday evening, per child. It keeps the logistics and says nothing about how a child is doing.
• Pets & Vet Care — one record per animal: every jab, treatment, visit and thing you noticed, with what it cost and what the insurer paid back. The board shows what is due and overdue and each animal's weight over time; before an appointment, a brief. Nothing here diagnoses.

Home.

• Home & Upkeep — houses don't send reminders; this one does. The boiler service, the gutter clear, the seasonal checks — plus the book of trades you trust, one glance away.
• Meals & Groceries — "what's for dinner?" answered once a week instead of seven times. Say the meals your household actually eats and the week is planned onto a calendar you can read from the fridge, with one grocery list grouped by aisle that ticks off as you say "got the milk". Nothing here has an opinion about what you eat.
• Vehicle — the inspection, the tax, the insurance, the servicing, and what each vehicle actually costs a month — one glance instead of four reminder apps and a glovebox. Mention a fill-up or a service in passing and the cost log grows; a Monday sweep reads what the insurer and the garage have sent and warns you thirty days out.
• Garden & Plants — the windowsill, the pots, the beds, the allotment: what's thirsty, what wants sowing this fortnight, and which corner you haven't properly looked at since June. Hand it a photo and the plant is named, with the confidence actually held; a warning arrives when a frost is coming for something tender.
• Documents & Renewals — the passport that expires the month before the trip. One board of every document that matters, each with the date it runs out and the warning you want, red long before it bites. It never renews or applies for anything, and it never keeps the number.
• Warranties & Big Purchases — the washing machine that dies at month twenty-three of a twenty-four-month warranty, and the receipt already to hand. Two years of order confirmations become the board; when something fails, the claim is drafted from the receipt and what you tell it, yours to send.

Learning.

• Reading & Learning — what you're in, what's queued, what you made of what you finished — and a scout who knows what you are trying to learn and returns weekly with a considered handful, never a firehose.
• Habits & Streaks — name the handful of things you are trying to do more of; mention them in passing and the chains grow. In the evening it asks only about the ones you haven't mentioned — once, and never twice.
• Studies & Deadlines — the term at a glance: every module, deadline and mark so far, and where that puts you — with a study companion who keeps you to the plan, quizzes you before the exam, and never once does the work for you.
• Courses & Admissions — the options you're weighing, the applications made, the offers held and every deadline between them, with someone to think it through who checks facts rather than remembering them. It never writes your statement and never tells you whether a course is worth the money.

Leisure.

• Trips & Getaways — every flight, stay, train and hire you've ever been sent is already in your inbox. A year of confirmations becomes your trips, the itinerary draws itself from the bookings, and the gaps — a night with no stay, a connection too tight — are flagged before you're standing in them.
• Events & Tickets — the gig you booked in January and forgot by June. Every live ticket on one register, what's this weekend, and which ones aren't in the diary yet. The day before, one brief with the ticket to hand. It never holds a barcode.
• Media Log — the series you loved and couldn't name six months later. What you watch, play and listen to, kept from ordinary conversation, with your verdicts in your own words. Nothing here recommends, scores or spoils anything.

Purpose.

• Journal & Reflections — one considered question each evening, answered in your own words; over months, a picture nobody else could draw. Nothing is scored, and a night you skip is simply a night you skip.
• Goals & Coaching — a coach in your corner. It begins with a proper life audit, one area at a time, and the goals that survive it are written in your own words, no more than three in focus at once. Every Monday, one steady question — never the language of being behind, and retiring a goal with honour is a normal thing to do here.

Work, at your own desk.

• Morning & Inbox — a short list instead of a full inbox: an overnight sweep sets aside what actually needs you, and a two-handed workflow reads what deserves a reply and leaves drafts in your voice for you to look over.
• Meetings & Actions — walks you into every meeting briefed, and keeps the two registers meetings leak: who owes what by when, and what was decided and why. Ageing commitments come back once a week with a polite nudge already drafted.
• Waiting On — the inverse of a todo list: everything other people owe you, reconstructed from your own sent mail, aged, and chase-ready.
• Dev Flow — everything between you and merged before you open a tab: the reviews you owe, your pull requests going stale, and a log of incidents and decisions caught as they are mentioned.
• Job Search — job hunting is a pipeline you run on yourself, and most of it is already in your inbox. Three months of email rebuilds the live pipeline; a daily sweep moves each application forward from the evidence, never a guess, and a one-page brief arrives before each interview, with its sources.
• Projects & Deadlines — every project's real state, not the state from the last status meeting. Each milestone drawn as a run on a timeline, and every Monday what is at risk this week, written up before the deadline does it for you.
• Consulting Practice — nine clients, no assistant, and the thing that makes a session good is remembering what they said last time. Each weekday, a brief per session — last time, what they committed to, what has come up since — and on Fridays where delivery stands against what you sold. Nothing learned in one room is ever carried into another.
• Team Pulse — you were heads-down for two days and the team carried on without you. It reads only the channels you name, never a DM, and keeps one board of what actually needs you: mentions waiting on your answer, questions nobody picked up, decisions made while you were away. It reads and reports; it never posts.
• OKRs & Goals — objectives set in January, remembered in December — or this. Key results with the figure now, the target and the owner's confidence; one Friday card asks only about the ones nobody mentioned that week, and the quarter's roll-up scores every result with the arithmetic shown.
• Contracts & Compliance — the auto-renewal you meant to cancel. Every contract you're bound by with its term end and notice period, and the date by which you actually have to decide, warned at ninety, sixty and thirty days. It gives no legal advice, and always says a worked-out date should be checked against the contract itself.

Work, running the business.

• Client CRM — a year of email and calendar rebuilds the book of every client you actually spoke to; you say what each is worth and how often they expect to hear from you, and the board shows who has gone quiet past that, highest value first. Nothing here writes to a CRM.
• Sales Pipeline & Forecast — a pipeline is only as honest as the last time you updated it. Six months of proposals and quotes rebuild the book; the forecast is the sum of value times the probability you gave, never optimism, and every Friday the week is totalled and what moved is said.
• Customer Success & Renewals — a renewal is decided months before its date, in silence and short replies. What renews in the next ninety days, which accounts have gone quiet, and each account's story in your own words, arriving as a card at ninety, sixty and thirty days out. It never puts a number on churn.
• Support Desk & Calls — a support queue without the helpdesk subscription: every ask by email, phone or text in one aged queue, with the calls and what was said on them beside it, read hourly. Two hands draft the replies owed — one picks, one writes into your drafts — and nothing is ever sent for you.
• Hiring — candidates lose interest at the speed of your process. Three months of email and calendar rebuild the pipeline; the board shows the funnel, who has been waiting in each stage and for how long, and whose feedback is owed. Nothing here scores a person.
• Marketing Campaigns — which channel actually pays for itself, on one screen. The first pull reads everything your analytics property still remembers, campaign by campaign, and keeps the trend going long after the reporting window has forgotten it.
• Site & Search — how your site is doing in search, week by week, from Search Console and your analytics property — so a slide is a Monday card rather than a quarterly surprise. When a number moves inside the ordinary wobble it says so rather than calling it a trend.
• Content Studio — ideas rot in drafts. Every piece on one table with its stage, owner and date, the whole belt from ideas in to pieces out with what you dropped counted honestly, and a Monday note on what has sat at one stage too long. It never writes a piece unless you ask.
• Social Presence — consistency beats virality, and what kills consistency is losing track. What you actually posted against what you meant to, in your own words, with a queue of drafts in your voice. It never posts, and where a platform reports nothing back, the board says so rather than guessing.
• Channel Watch — the channel's week without opening the studio: each upload on a register with that week's views, likes and comments, taken as readings every Monday so the lines are built from what it saw itself. What it cannot see — watch time, retention, revenue — it does not pretend to.
• Fundraising — a raise is a pipeline with worse odds and higher stakes. A year of email and calendar puts every investor conversation on one register; the board shows the funnel, who has gone quiet, the warm intros still to land, and the data room item by item. It never says whether a raise will close.
• Board & Investor Reporting — the monthly update that writes its own first draft. It reads the Kits you already run — the cash and runway, the weighted pipeline — and drafts a section for each thing your update needs, every figure naming what it rests on. It drafts; you edit; you send.

Each installs in a tap, and leaves as cleanly as it came — records and all, if that is what you choose. Where this points next is already sketched: an installed Kit opening into a place of its own, its screens scoped to its pieces, drawn on the same SDK — with the health Kit the natural first through the door.

Here is the squeeze. An unattended job — a routine that sweeps an inbox every morning, a weekly report that assembles itself — fails in two ways, and only one of them is visible. Hard failure announces itself: an error, a red mark, a run that never finished. Drift does not. The connection to an account quietly narrows what it returns, a source goes stale, and the run keeps succeeding all the way down — thinner every week, read by nobody, because not having to read it was the point of setting it up. Do nothing and the decay is invisible for months. But the obvious remedy — detect the decline and let the agent rewrite its own instructions — turns out to make the system less trustworthy, for a structural reason we only saw clearly once we had built the detector: the repair destroys the evidence that would judge it. Every change to a job's definition resets what "normal" means for that job, so a naive self-repair loop silences its own alarm at the exact moment it acts, then re-baselines onto whatever the repaired behaviour happens to be. It cannot tell whether it helped, and it reports the routine healthy either way. Self-improvement, built carelessly, is self-congratulation with the instrument unplugged.

This entry is about the loop we built instead: detection that measures against a frozen reference, diagnosis that runs checks before it runs a model, repair as a reviewed proposal that may only ever narrow, and verification against how the routine worked before it broke. The interesting engineering is not in any one stage — it is in what each stage is forbidden to do.

Succeeding is not the same as working

Every routine and workflow run now gets read twice. The first reading is free: how long it took, how many tools it called, how many of those errored, and how much it actually produced. That last one carries more weight than it looks like it should. Run output is truncated for display — a short summary is what makes cheap scoring viable at all — but a truncated field is a useless size proxy, so the length is captured before the cap. A collapse from four thousand characters to three hundred is the single strongest signal for the failure this system exists to catch, and it is invisible if you measure after truncation. The metric you can afford to store and the metric that carries the signal are not automatically the same field.

The second reading — an LLM-as-a-judge pass — costs a model call, so it is bounded hard: a small model reads the routine's stated purpose, the run summary, and what was produced — never the transcript, which would cost around a hundred and sixty times as much and would make someone, eventually, feed it in "for accuracy." It answers two questions that are deliberately never blended. Given what this run had to work with, was it a good run? And is the routine delivering the thing it was set up to deliver? A brand-new routine whose first run asks three sensible questions and requests access is an excellent run of a routine delivering nothing yet — both facts are true at once, and any single blended score would make a legitimate cold start look broken.

Keeping the axes separate also closes the obvious con. An agent can write a glowing summary of a run that achieved nothing — the content reading is gameable in a way the mechanics reading is not, because duration and output size are measured, not narrated. So when the two disagree, the disagreement is not averaged away; it surfaces as its own flag. A confident account of a collapsed run is more informative than either number alone.

Normal is an anchor, not an average

The first design question with real consequences: what is a run compared against? A fixed rubric fails immediately — there is no such thing as a perfect run of "sweep my inbox," and nobody is going to author one per routine. Comparing against recent runs fails more subtly, and this failure is the highest-value case in the whole feature: a rolling average of a declining routine declines with it. Each run sits close enough to the recent past to pass, the baseline walks downhill alongside the decay, and a routine that loses a few per cent a week never trips anything. The reference that detects gradual decline has to be one the decline cannot drag along.

So the reference is frozen. A routine's early runs are treated as settling in and can trigger nothing at all — its page says it is still learning what normal looks like, which is simply true. Once five runs have succeeded, their statistics are frozen as that routine's anchor, and every later run is read against the anchor rather than against last week. One odd night is noise a working process produces on its own; a sustained deviation from the anchor is assignable, and worth a sentence in someone's inbox. We have a unit test that drives a slow monotonic decline through both designs — the rolling window provably never fires, the anchor does.

When you deliberately change what a routine does, the anchor re-arms: edits to the definition are fingerprinted, and a changed fingerprint sends the routine back to settling in rather than alarming against a reference that no longer applies. And "this is the new normal, stop flagging it" is a legitimate thing to mean, so a manual re-anchor is one tap on the routine's own page.

The instruction is the last suspect

Detection alone trains people to ignore it. The card our detector raises ends with an offer — would you like me to look into it, or is this the new normal? — and for a short, uncomfortable moment only the second branch was served. A card the user cannot act on is the card that teaches them the feature is noise; a detection feature's half-life is set by how actionable its output is, not by its accuracy. So the deterioration verdict now triggers a diagnosis, and the diagnosis starts from a fact the fingerprint gives us for free: a routine that reached a deterioration verdict is, by construction, one whose definition has not changed — any edit would have re-anchored it. Whatever went wrong, the instruction is the one component known to be the same as when it worked. The self-improvement reflex reaches for a prompt rewrite first. The evidence says to reach for it last.

What actually changed is almost always the world around the routine, and most of the candidates are checkable without inference. Has the credential behind a granted connection expired? Does the file the instruction names still exist, and if not, is there exactly one file with that name somewhere else now? Is the dashboard it feeds still bound to a source? Did volume move with no errors — five times the mail, none of it failing? These probes run first, and a cause they establish is authoritative: the model is never asked to overrule them. Partly that is cost and reliability — but the real argument is that a deterministic cause links to a fix. "The connection expired on Tuesday" comes with a reconnect button. A modelled cause is prose.

Only when the probes come up empty does a model read the bounded evidence, and its confidence is not decoration. Below a floor, the cause is forced to unknown, and the card says, in as many words, something changed and I could not work out why. An honest non-answer, in its own voice — never a low-confidence guess dressed in the same voice as a solid one. A wrong diagnosis delivered confidently is worse than no diagnosis, because it spends the trust the next correct one needs.

A repair may narrow. It may never widen

When diagnosis does implicate something fixable, the fix is a proposal: a stored, reviewable diff — what it says now, what it would say, what was found and why — that becomes real only when a person taps apply. Nothing about that is novel. The part worth writing down is the pair of invariants enforced where proposals are written, because this producer has an unusual threat shape: its evidence is the output of unattended runs, which is to say text an attacker can influence, and its payoff is a persistent change to an instruction that will execute forever after. Prompt injection against a self-repair loop is not a hypothetical — it is the design's natural failure mode.

First: a repair may narrow, clarify, or repoint an input — and may never touch where output goes, who receives it, what is granted, or when it runs. The asymmetry is the point. Repointing where a routine reads leaves its reach unchanged; repointing where it writes is the exfiltration shape itself. Second: when a repair repoints a path, the new value must be the resolved result of a probe — there is no code path by which model-generated text becomes a destination, and a unit test proves it, including the injection shape where a genuine probe finding is attached as cover for a destination the model chose. The model classifies and explains. It never names where anything goes.

Both invariants live at the write boundary, in a pure function with no dependencies, checked at creation and again at apply. They are indifferent to what the model read, which is what makes the later escalation safe: when bounded evidence is inconclusive, one pass may read the run's transcript — explicitly fenced as untrusted description of events — and however compromised that text might be, it can widen what the diagnosis believes, never what a proposal is permitted to do.

The fix must not destroy the evidence

Which returns us to the trap the whole design bends around. Applying a repair changes the routine's definition, and a changed definition re-anchors the control — that is the correct behaviour for a human edit. Let it happen on a repair and the sequence is: alarm fires, patch applies, anchor resets, detector goes structurally silent, and five runs later a new normal freezes around the repaired behaviour, whatever its quality. So a repair is the one kind of change that deliberately keeps the old reference point. The fingerprint moves; the frozen anchor from before the deterioration survives; and the next few runs are measured against how the routine worked before any of this started. Re-anchoring at apply time would define success as "no worse than broken."

Verification then resolves to one of three honest outcomes. Recovered — three consecutive runs back within range of the old anchor; the card closes. Regressed — still deviating at the window's end; the user gets a one-tap revert, and the same cause is suppressed from being re-proposed, because a second guess after a failed first guess is how a repair loop becomes a random walk through instruction space. Inconclusive — not enough runs inside the time cap; it says so, and never claims success by timeout.

And the loop is restorative, not ameliorative — it ends at the anchor, on purpose. "Make it better than it has ever been" has no reference to verify against: the control is deliberately insensitive to improvement, the judge reads the agent's account of its own work, and an optimiser scored by the agent's own account of itself optimises the account. Every change would reset the baseline, so an ameliorative loop is a machine for generating unfalsifiable changes forever. Genuine improvement needs a signal from outside the loop — did the human keep the output, act on it, edit it — and that is a different feature, gated behind this one earning trust.

The metric we will actually watch is the counter-metric: the share of applied repairs that verify as regressed. A rise there means the diagnosis is confident and wrong — which is worse than being unsure, and is a stop signal for proposing repairs at all, not a prompt-tuning exercise.

Postscript, 2026-08-29. This entry is written the day the phase closed, so it is the one post in the log whose verification data does not exist yet — the recovered-versus-regressed ledger starts accumulating tonight, one routine at a time. What the day did already supply is the two test-caught corrections above, and one rule we expect to keep: before letting a system change itself, decide what evidence would prove the change wrong — and make sure the change cannot delete it.

Where this came from

I worked with a brilliant team at MIT on the AI chat interfaces for its online learning platform. I built the agentic backend for Senis AI, an intelligence platform for membership associations, end to end. And at Cloud9Trader, a trading platform I founded, I was adding AI capabilities and wanted a real backend under them.

The missing piece was identical every time: an assistant that carries context forward instead of resetting it. And every time I ended up building some version of it myself, which is why what I actually wanted was one system good enough to sit under all of them, where every advance and every optimisation lands once and reaches everything else I build. A thinking partner is only worth the name if it still knows you tomorrow, and that turned out to be an engineering problem rather than a prompting one.

Then OpenClaw proved the demand: thousands of people spending a weekend standing up a terminal agent themselves, for the sake of memory that persists. That is a lot of effort volunteered for one property. So we built the hosted answer.

I have run that route myself. Between a VPS, an API key and the evenings spent on config, it gets expensive quickly, and that is before you have persistence you would actually rely on. Token cost is the sharper edge, and it has two faces. One is context: an agent that re-injects your entire conversation history on every single turn scales its bill with the size of your life. The other is autonomy: an agent left to act on its own, chaining tool calls with nothing bounding the run, can spend a great deal before anyone is watching. People have posted $200 days.

What we built

1Presence is a fully managed personal AI agent. You sign in, tell it your name, and it starts learning you — your context, preferences, ongoing projects, things you want to track. That knowledge persists across every conversation, forever.

The engineering behind that has two parts.

Layered recall

Persistence sounds simple — "just remember what happened yesterday." In practice it isn't, because the naive way to fake memory is to re-inject the whole history on every turn, and that cost grows with everything you have ever told it.

1Presence addresses your history rather than reloading it. A cheap orientation pass narrows the search space, a vector pass finds semantically related material, and only when a query genuinely needs entity-and-time reasoning does it hit the knowledge graph. Most turns never touch the expensive layers. That's what makes running an agent with real memory economically ordinary rather than exceptional.

The same discipline bounds what runs unattended: every turn has a budget ceiling, and a scheduled run is balance-checked before it starts and skipped rather than overdrawn, so an agent acting on its own cannot quietly spend past what you have.

Underneath the recall discipline, memory is addressed rather than flat. It is filed by project and subject, so the cheap passes can narrow to a region before anything expensive runs, and a typed knowledge graph sits on top for questions where time and identity matter ("when did the ABC deal move to Proposal, and who was on it?"). What gets filed is written in a compression dialect rather than prose, so a dense paragraph of background costs a fraction of the tokens and the prompt stays lean as the memory grows.

The vault

The other half is an Obsidian-compatible markdown document store. Every note, file, and document the agent creates or references lives here as plain markdown, organised and interlinked. It's not a hidden database — it's a structured personal wiki you own: you read and edit it right in the app, and because it's plain markdown it opens in Obsidian or any markdown editor too.

The graph holds structured facts and relationships; the vault holds the full narrative documents those facts came from. You edit a document with the agent side by side: the file open, the conversation beside it, a selected passage carried into the message so "rewrite this" resolves to the text on screen, and the edit landing in place rather than as a regenerated file. Every version is kept and only an explicit save creates one.

The memory is fully transparent, and that's intentional

One thing I feel strongly about: you should never have to wonder what your AI knows about you.

In 1Presence, both layers are fully exposed in the UI. The vault is a browsable, editable document library — open any file, edit it, see exactly what the agent has stored. The memory graph is equally visible — every entity, relationship, and fact, visualised so you can see how they're connected. You can see which facts the agent is drawing on when it responds, understand why it reached a particular conclusion, and correct or remove anything that's wrong.

"The agent remembers things about me" is only useful if you can verify what it remembers and trust that it's accurate. So the position we took is that the memory belongs to you, it should be readable by you, and you should always be in control of it.

Beyond chat — it runs things for you

Memory is the foundation, but the product on top of it is automation you can watch:

• Workflows. Multi-stage pipelines where each stage is run by a specialist agent: gather the numbers, draft the brief, pause for your approval, then deliver. Human review gates wherever you want them. A visual builder, a scheduler, a runs dashboard, and live stage transcripts so you can watch a run think.
• Routines. Single recurring jobs on a schedule: a daily briefing assembled from your inbox, calendar, and project notes, delivered at 8am without prompting.
• Dashboards. Live visual dashboards built from your real data, refreshing on their own schedule, with drill-down into individual records — and shareable read-only with anyone, on or off the platform.
• Specialist agents and skills. Stand up a named researcher, drafter, or editor by describing the role in chat. Each gets its own identity, skills, connector permissions, and memory scope.

Also in the box: living datasets (hand over a bank statement or a lead list and keep it as a structured, chartable record), re-fillable document templates (give it last quarter's branded one-pager, get it back editable and re-filled with this quarter's numbers), and a meeting recorder that files transcripts and summaries into your vault.

The design constraint behind all of it: every step is visible and auditable. You see what ran, what it read, what it produced, and where it filed the output — in your vault, in plain readable markdown. No silent background processes. No mystery outputs. The same transparency principle that applies to your memory and your vault applies to automation.

The primitives compose into an agentic OS

Memory, vault, agents, skills, workflows, dashboards, connectors — these are the primitives. On their own each does a defined job; together they compose into an agentic OS for your life or your company. Infrastructure that carries the recurring shape of your work, rather than a tool you keep re-briefing.

This is infrastructure you compose on: the same primitives the personal product is built from, opened up so you can arrange them around your own life or your company. More on the frame is at 1presence.com/docs/agentic-os.

Architecture

Each user gets a dedicated pod on GKE — isolated, internal-only, never internet-facing. GCP Workload Identity ties each pod to a service account scoped strictly to that user's data. The gateway provisions a pod on signup, brings it up on the first message and scales it to zero after ten minutes idle. State lives in GCS and Firestore; pods are completely stateless.

The retrieval discipline, the vault, the transparency UI, per-user isolation, the connector estate, and the workflow engine are all 1Presence.

Connectors

Gmail, Google Drive, Google Calendar, Microsoft 365 (Outlook mail + calendar, OneDrive), Notion, GitHub, Slack, LinkedIn, X, Monday.com, HubSpot, Motion, Read AI, Twilio (place calls with live transcripts), Strava, Google Analytics, Search Console, Tag Manager and YouTube — plus local folders and the web.

Pricing

$5 of credit at signup, no card required. Three personal plans:

The plans differ in credit headroom and in how deeply the agent can think on a given message. They do not differ in access: lasting memory, the vault, every connector and unlimited agents are on all of them.

Token usage draws down that credit as you go. Credit runs to a hard stop by default, so there are no surprise bills. If you would rather not be interrupted, auto top-up is opt-in: a fixed increment ($5, $10 or $20) charges only when credit runs out, under a monthly cap you set, and one-time top-ups work the same way. Credit you have bought is a wallet: it never expires, it survives a plan change or a cancellation, and it is refundable on request.

On whether the big labs make this redundant

Worth saying head-on. The major labs are all moving in this direction, the gap between a raw model and a personal assistant is closing fast, and a rising floor helps everyone building here.

The labs build the horizontal, median-user surface: a text box that has to work for a billion people. Three things follow from that, and none of them is a choice anyone could reverse next quarter. Opinion excludes at scale: every curated, life-shaped feature is a decision some fraction of a billion people would disagree with, so that economics rewards breadth, and ours rewards being right for one kind of person. The simple part of any assistant is already the chat; the complexity lives behind it, in routines, connectors, memory and the agents that use them, and making that layer usable by someone who will never configure anything is the job we took on. And the session we design for is the one that ends well: you asked, it is handled, and you are back in your day.

Underneath that, the bet is that three things stay hard to retrofit, and all three are described above: memory you can read and correct, a model layer that is swappable by design, and isolation that is per-user, single-tenant infrastructure rather than a policy over shared storage. Properties of the architecture, not items on a roadmap.

1Presence for Business — the operating system for your company

The personal assistant is one side of the product. The other is teams — and this is live, not a pitch deck.

An organisation gets a shared vault and shared memory the whole team builds on, instead of everyone briefing their own assistant from scratch. Teams get scoped access to their own corner of the shared knowledge. Purpose-built agents — primed on the company's products, processes, tone of voice, documentation, customer history — are shared across the org: a support agent that knows your product inside out, a comms agent that drafts in your voice, a documentation agent that updates itself when a feature ships. Members switch cleanly between their personal space and the company's with one control, so work and life never bleed together.

Knowledge accrues once rather than per person. What any member tells it, the team has, and it lives in the organisation's own vault rather than inside anyone's private one, so it is still there when the person who put it there moves on.

The boundaries are the architecture, not a setting. An organisation's vault and memory run under their own identity on their own infrastructure, separate from every member's personal space rather than a filter over shared storage. An admin gathers members into teams and scopes each team to its corner of that knowledge; what a team's agent can actually reach is the intersection of the team's scope and its own grants, resolved per turn and never widened by either side. Everyone keeps a private space alongside it, and the two never cross: work connections live in the organisation, personal ones stay with the person, and an admin can neither read a member's own space nor act through their personal accounts.

The question a technical reader asks first: an agent acts with the permissions of the member who invoked it, not the member who built it. The acting member is established by the gateway after verifying them and is never taken from the client, and every scope a run touches — vault, memory, connectors — resolves from that person. Sharing an agent, a workflow or a dashboard is a visibility binding: it changes who can see and run the thing, never what data anyone can reach through it. One honest limit, since it is the first case anyone probes: a scheduled run has no invoker, so it runs within the scopes bound to it and is recorded as the scheduler rather than as a person.

Billing is one account on the same three tiers, priced per seat, with every seat's credit funding one shared pool. A member is never personally charged for org work.

This is infrastructure your company composes on: the same primitives the personal product runs on (agents, skills, workflows, dashboards, shared vault, shared memory), arranged around how your team actually works and compounding as it does more. The company's knowledge accrues in one shared place rather than in everyone's separate chat histories.

The same transparency principle applies at the business level. Each agent's memory and vault — what it knows about your org, your customers, your processes — is inspectable and maintainable by the team. You're not feeding context into a black box and hoping it sticks; you're building a structured, readable knowledge layer that the agents draw from and that you can audit. And each agent runs on the same isolated pod architecture as the personal product — private by design, not as an afterthought.

If this is relevant to your org: 1presence.com/business.

Creator Studio (invite-only for now)

There's a third pillar worth mentioning: a creative suite — image and video generation, consented digital presenters with cloned voices, podcast audio, and multi-piece creative projects that keep characters and look consistent across a whole series. It's currently invite-only for early adopters.

Why I think it's worth your time

The bet here is that transparency, portability and isolation matter to a meaningful segment of users, and that the segment grows as AI gets more deeply embedded in people's working lives. All three are architectural commitments rather than roadmap items, which is the only reason I would expect them to still be true in a year.

Try it at 1presence.com — start chatting straight away, no card required. Questions and criticism both welcome: hello@1presence.com.

We build a memory-first assistant, and each of the recipe's three steps embeds an assumption that fails for one. Take the user's message assumes the message is a good query. Find nearest neighbours in the corpus assumes there is one corpus, and that similarity to the message is what makes something relevant. Staple to the prompt assumes retrieval should be invisible, stateless, and free of consequence beyond this one answer. This entry follows a single question from the moment it is typed to the moment the model answers — because the pipeline is where those three assumptions break visibly, one after another, and where what replaced each of them earns its keep.

Earlier entries in this series established the parts: why retrieval is invoked deterministically rather than left to the model's discretion, how its per-turn cost is held flat, what the stores are and why the two main ones cannot see each other, and what a document must opt into before memory will volunteer it. This is the post about how the parts compose. Take those as read; the walk is the subject.

Suppose a thread has spent a few turns on a contractor's quote — call her Alice — for a studio build, wandered off to something else, and the user now types: "did she come back on the price?"

The message is a bad query

Embed that message raw and search with it, and you are asking the store for things similar to the words did she come back on the price — a string containing no name, no subject, and a verb phrase that could belong to a hundred topics. The person who typed it is not being careless. They are speaking the way people speak inside a conversation, where half of every sentence's meaning lives in the turns before it. The message was never the query. It is a pointer to a query, and something has to dereference it.

So before retrieval runs, a small, cheap model does one job: it reads the recent thread plus a persisted running summary of what the conversation is about — under twenty-five words, carried forward and refreshed every turn — and emits a plan. Search strings for the fuzzy store. Entity names for the fact graph. The refreshed summary. For our turn, that plan reads something like: search "Alice studio build quote", look up the entity Alice — the pronoun resolved, the elided subject restored, the topic recovered from three turns back. When the turn needs nothing — a greeting, a thanks, a general-knowledge question with no personal hook — the plan is legitimately empty and no lookup runs at all. And subjects already retrieved earlier in the session are suppressed from the plan, so a long conversation about one person does not pay for the same lookup on every turn.

The transferable idea costs one sentence: a small model planning the retrieval is cheaper than a large model recovering from a bad one. Query formulation is where retrieval accuracy is actually bought — before a single vector is compared — and it is bought at the cheap end of the model range, because coreference resolution — she, against three turns of context — is exactly the kind of bounded judgment small models do well.

Two stores that cannot join, and why that is the design

The plan now fans out — and not against one corpus. The search strings run as a fuzzy sweep over the filed notes: hybrid retrieval, vectors for meaning plus lexical scoring for exact tokens, returning ranked snippets. The entity names run as exact keyed lookups into the fact graph: typed rows about Alice, with validity dates, or nothing.

Neither store can consult the other. A search hit carries text and a score and no entity keys; a graph row carries typed facts and no notes. There is no query in either direction that pivots between them, so the runtime performs the union itself — two parallel lookups, stitched by the caller.

The split is deliberate: the two failure profiles are the reason both stores exist. The keyed side has near-zero false positives and is brittle to name variants: query a spelling the store never minted and you get nothing, which is why a graph miss is read as unknown, never absent. The fuzzy side is forgiving of naming and never returns nothing: it hands you its nearest neighbour with confidence precisely when no true answer exists. Each is strong exactly where the other fails, and measured on our own store the complement is real — the entity lookup that returned zero on a name variant sat next to a fuzzy sweep that surfaced the right documents at healthy scores, and vice versa. A single blended store would average the two failure modes into something uniformly mediocre and undiagnosable. Choosing to run two stores with named failure profiles, and to pay the stitching cost at one instrumented union point, is a choice — the recipe's "one corpus, one similarity" step, unmade.

What comes back enters the record, not the prompt

The recipe's third step is to paste the retrieved text invisibly ahead of the user's message, answer, and throw it away. Ours does something that looks slower and pays for itself three times over: the results are appended to the conversation itself, as a lookup that visibly happened — the queries, and what each returned, recorded the same way as any action the assistant takes.

First consequence: recall persists. The next turn's model sees what was retrieved this turn, because it is simply in the conversation — no re-deriving, no asking the user "did you mean the Alice from the studio project?" about a fact it held two turns ago. Second: the retrieval is inspectable by the person it is about. The interface shows the lookups as they happen — searching for this, checking the graph for that — which for a memory product is not decoration; a system claiming to know you owes you a view of when it is consulting what it knows. Third: the formulation pass reads the same record next turn and plans against it — what has been fetched is suppressed, and only the delta is queried.

One structure, three properties: making retrieval an event in the transcript rather than a hidden prefix is what makes it auditable, cacheable and de-duplicable at once. The hidden-prefix version can be given any one of those with bolted-on machinery. The transcript version gets all three from the decision itself.

Push, then pull — and the index deliberately left out

Everything so far is the push half: what arrives before the model answers, covering what the thread implies. It is not the whole of retrieval. Beyond it, the model fetches for itself, down the layered protocol described earlier in the series — orientation, sweep, keyed facts, graph walk, full fetch, each layer materially dearer than the last — and most turns never leave the cheap end.

But one index is missing from the push half on purpose, and the omission is load-bearing. The documents' own body index — the meaning-level search over full file contents — is never consulted by the pre-pass. Only memory is. The body index is far larger than memory, and a nearest-neighbours pass against it on every turn would push whatever happened to be closest into the window, every time, relevance decided by proximity alone — the recipe's failure mode, rebuilt inside a system designed to avoid it. Keeping the stores separate makes that flooding impossible by construction rather than by tuning: no threshold drift, no ranking regression, no bad day can cause the document pile to volunteer itself, because no code path exists from the pre-pass to that index. A document reaches unprompted recall only by being promoted into memory — a user's explicit, per-folder choice, argued in the two entries before this one. The same boundary, seen from the retrieval side.

The cost of the boundary is real: a fact mentioned in passing in a document nobody promoted is reachable the moment somebody asks, and only then. We accept that, for the reason the previous entries argue — the alternative is a memory diluted by everything it was handed.

One budget pays for all of it

None of the above floats free. Retrieval's results land in the same context window that already carries the shared system prompt, the schemas of the tools the assistant can call, and the conversation itself — and that window is a budget, paid on every turn. The design only stands because the rest of the budget is managed with the same discipline: several hundred tool definitions sit behind a search and load on demand rather than riding resident; the expensive prefix is kept stable so it caches; the far end of a long conversation is compacted rather than carried verbatim. Those are their own entries. The point that belongs here is the dependency: a fixed per-turn retrieval spend is only affordable inside a prompt whose other tenants are also fixed. Beats one through four are defensible because of beat five, not alongside it.

The fork: we wanted the elegant version

Now the part a fair number of readers will disagree with, and the reasoning deserves their strongest counter-argument first.

Agentic retrieval — give the model the search tools, let it decide when to look — is genuinely more elegant. It costs nothing on turns that need nothing. It is maximally selective: the model knows what it already knows, and looks things up the way a person does, when uncertainty bites. It has no pipeline to maintain, no thresholds to calibrate, no per-turn tax. We ran it that way first, wanted it to work, and instructed it carefully.

Measured across 277 of our own sessions — about four thousand tool calls — it did not happen. Memory writes outnumbered reads six to one; genuine content recall appeared in roughly one session in nine; and the behaviour persisted after the recall instructions were strengthened, with the model demonstrably recognising the entities it was declining to look up. And when the model did choose to retrieve, its judgment failed in the other direction too: one measured thread ran about twenty-six memory reads across eight turns, most of them redundant re-searches of facts already in context or probes into memory for changing-world facts that no personal store could hold. Discretion was wrong in both directions at once — too little when recall mattered, too much when it did not.

So the fork was taken on the numbers, not the aesthetics: deterministic invocation of a judgment step. The loop guarantees the retrieval step runs — invocation cannot be skipped, because invocation is precisely what the measurements showed failing — while the small model decides what the step is worth, including nothing. Reliability comes from code; selectivity comes from judgment; neither is asked to do the other's job. The tax is honest: a model call on every turn, paid whether or not the turn needed it. We pay it because in a product whose entire claim is recall, a silent miss is the expensive failure, and we could not buy its absence any other way.

If you have built the agentic version and it works for your product, the difference is probably in that last sentence. A coding tool that misses a lookup produces a wrong answer someone was already checking. A memory assistant that misses a lookup breaks the one promise it exists to keep, invisibly, with nobody positioned to notice but the user it forgot.

Postscript, September 2026. The seam between the two stores was on the list to close — search hits carrying entity keys, so a semantic find could be enriched by an exact graph lookup — and we took it off the list after reading a month of production recall. The semantic side returns something above the floor on nine turns in ten. The graph side answers just over half of the entity lookups it is asked, and on nearly all of its misses a semantic hit was present anyway; the graph was the only store to answer on five turns in the month. So the seam is not where turns are lost. What a graph miss costs is a typed fact with a date on it, on a turn that still got the prose: precision, not coverage. The one measurement that would justify a bridge is how many of those misses are a key spelt two ways rather than a memory never stored, and the pipeline does not log the names it looked up, only the counts. The names go into the log first; the bridge waits on what they show. The same month says where the real cost sits. Recall now takes a median of 2.8 seconds in front of a substantive turn, well above what this entry measured, and that is the number being worked on. The 277-session scan does not need re-running: with retrieval deterministic, "did the agent read" saturates by construction, and the per-turn line is its successor. Six substantive turns in a hundred come back with nothing from either store, which is the figure to watch. The similarity floor is still the permissive first setting. The hits it admits sit at a median similarity of 0.61, with a tenth of them under 0.47, so it sits beneath the population rather than cutting into it; a labelled evaluation is still what would earn a real calibration. The pipeline itself now also fronts scheduled runs and the stages of long autonomous jobs, which is where a guaranteed retrieval step matters most — nobody is present to notice a miss at all.

Find what I typed. The first index, built in May, is lexical: keyword matching with deliberate fuzziness and prefix search. Because the person hunting for a file is typing a half-remembered name, probably with a typo in it, and wants the machine to meet them halfway — budgt should find the budget, Mer should find the Meridian folder. Forgiveness is the feature.

Find what I mean. The second, in August, is semantic: document bodies chunked and embedded, then rank-fused with the keyword scores into one hybrid list — so a note reading "bring it forward to January" answers the question "when do we start the renewal conversation?", which shares not one word with it. And it was retuned against a labelled evaluation set rather than by taste, because (as an earlier entry in this series found the hard way) similarity thresholds calibrated on toy corpora do not survive contact with real ones.

Two indexes, two questions, both answered well. Which made the third failure more instructive, because the tooling that produced it was good.

The question neither index could answer

In late August an agent was asked which services a project was built on. It read a folder listing, saw a document titled "Inbox setup with" a particular named service, and asserted the service was in use. It had never opened the file. The claim surfaced only because the user challenged it, and the agent's own admission named the failure better than we could: "I saw the filename, not the file."

The reflex is to call that a behaviour problem — the model should have checked. The diagnosis that held up is structural, and it indicts the toolkit, not the temperament. "Do we use X?" is an absence-proof question: its honest answers are "yes, here" and "no, nowhere", and the second one requires exhaustiveness. The ranked retriever — our second index — cannot produce it, for three reasons that are properties of its design rather than bugs in it.

The instrument, and the decisions inside it

So the third question got its own instrument: exact, exhaustive matching — every readable text file in scope, read in full, no index in the loop — returning matches with line numbers and exact totals. The interesting engineering is not the scan; anyone can write a scan. It is five decisions about what an absence proof is allowed to be, each of which we would defend in any system that makes claims from a corpus.

The candidate universe is one function, shared with the index. An absence proof is only as good as its definition of "every file", and that definition — which paths count as readable text, which are excluded, what the agent's read scope permits — is computed by a single function used by both the scan and the search index. Two hand-maintained copies of which files count would drift, and drifted universes turn "nowhere" into a confident wrong answer. The proof and the everyday search must agree about what the world contains, structurally, not by diligence.

A partial scan forbids the claim. Completeness is a computed fact — zero read errors, files scanned equal to files in scope — and anything less returns a result that opens by declaring itself partial and forbidding any absence claim built on it. A false zero is this instrument's one unacceptable failure, the equivalent of a clean bill of health from a test that didn't run; the design treats "we could not check everything" as a first-class answer, never rounded to "not found". Partial results are not even cached.

Literal by default. The pattern is treated as a literal string, metacharacters escaped, with regex as the explicit opt-in — because an "exact" mode that is quietly a regex lies in precisely the identifier-shaped cases the tool exists for. A dot that means "any character" turns fal.ai into a pattern that matches things nobody searched for; exactness that is approximately exact is the old fuzziness wearing a lab coat.

Counts stay exact when the display is capped. "47 occurrences, showing the first 200 lines" is a useful answer; a count silently truncated at the display cap is a wrong answer to "how many" — one of the questions the tool is for. What is sampled and what is counted are different things, and only the sample gets capped.

And the decision that could have gone the other way: the evidence rides along, always. The obvious wiring is a fallback — instruct the model to verify with the exact scan before making a checkable claim. We rejected it, on the argument that decided the whole feature: noticing that you are making a checkable claim is the very judgment that just failed. There is also no null to fall back from — the dangerous case is not an empty search but twelve plausible hits. So exact evidence is folded into every ranked search automatically: alongside the fuzzy results, a literal whole-corpus count for each claim-shaped term in the query. The model does not choose to verify; verification is in its hand before it speaks.

The counterweights, because the pattern invites overreach

Two boundaries keep this from being a bigger claim than it is.

The same lesson runs the other way in the fact graph. Its entity search is deliberately not embeddings — proper-noun lookup is a spelling problem, not a meaning problem, as an earlier entry argued — which is this post's thesis from the opposite bank: the modern instrument is not wrong, it is specific, and the discipline is matching instrument to question rather than standardising on whichever is newest.

And the load-bearing non-goal: this proves things about the document corpus. The question that prompted it — which services a project actually depends on — is answered by manifests, lockfiles and CI configuration, which live in a repository the assistant does not hold. The feature converts asserted without evidence into verified, or declared unverified; it does not put a missing corpus within reach, and saying otherwise would be committing the original sin with better tooling. Whether that corpus should come within reach is a separate decision, still open.

What transfers

One corpus, three questions: find what I typed wants forgiveness, find what I mean wants embeddings, prove it is not there wants exhaustiveness — and the third cannot be built from the first two, because ranking is structurally incapable of expressing absence. If your system makes claims from retrieval, audit it for the absence case: what does a user see when the answer genuinely is "nowhere", and can they distinguish it from "not in the top ten"? Derive your proof's universe from the same function your index uses. Treat partial coverage as an answer, never as noise. And when the failure you are guarding against is a lapse of judgment, do not wire the guard behind that judgment — put the evidence in the model's hand on every question, because the moment it would have chosen to check is exactly the moment it didn't.

Postscript, August 2026. The behavioural half became a standing integration scenario — an agent probed with exactly the trap that started this, expected to check content before claiming use and to decline to assert from a filename — so the fix is guarded by the machinery an earlier entry described rather than by memory. "A miss proves nothing" is now closed for the document corpus: a zero from the exact scan, on a complete read, proves precisely what it says. The fact graph's version of the same promise remains open, as does the repository question. And the phrase "I saw the filename, not the file" has entered the team vocabulary as the name for a whole class of failure — evidence about a container presented as evidence about its contents — which we now hear ourselves catching in places that have nothing to do with search.

This entry is the contract we converged on for that mode, learned mostly the honest way, one broken assumption at a time. The conclusion arrives early because everything else in the post is a case of it: an unattended run must be able to stop, and put a question somewhere a human will find it. Not guess. Not hang. Not fail into a void. Stop, and leave a question — and everything below is that principle meeting a different broken assumption.

A schedule must never arm itself

The first lesson predates the others and cost us a real incident. Early on, creating a scheduled routine created it armed — a stored cadence was a live cadence — and the result was the obvious-in-hindsight runaway: work firing on schedules nobody had knowingly switched on. The fix is structural, not behavioural. Everything is created manual. A routine or workflow with a stored cadence still does not run; "armed" is a single explicit field, set only when the user actually asked for a recurrence, and both scheduler sweeps gate on that field and nothing else. The agent building a routine is under standing instruction never to invent a cadence or arm one uninvited — but the instruction is a courtesy, because the field is the enforcement.

The distinction underneath is worth carrying to any automation product: storing an intention and arming an automation are different acts, and conflating them means the most helpful possible agent — one that eagerly sets up everything you might want — becomes the most dangerous one. Autonomy is opted into per thing, by the person who will be asleep when it fires.

Input with nobody to answer

The sharpest incident of the arc was quiet and nearly invisible. A multi-stage run needed to know which client a piece of work was for; the stage agent, correctly refusing to guess among three client folders, paused and asked. The user answered. And the answer never reached the model — a plumbing bug left the model holding a placeholder acknowledgement instead of the reply — so on resume the agent guessed by recency, happened to land on the same client, and reported the choice as "confirmed by user."

Read that failure shape twice, because it is the characteristic one for autonomous systems: the failure was fluent. Nothing crashed. The output was confident, plausible, and carried a false provenance claim — had the user picked differently, an entire deliverable would have been built for the wrong client under a banner saying she chose it. Attended software fails loudly at the moment of failure; unattended software fails politely, later, in the work product.

The repairs went in three layers. The plumbing: a user's answer now reaches the model verbatim, rewritten into the exact slot the question created, with a regression test asserting the literal answer arrives. The structure: agents declare the inputs their runs need — which client, which folder, which week — so a run collects everything up front in one panel rather than burning a stage to discover a question; and an agent that discovers an undeclared need mid-run declares it on the spot, so under-declaring costs nothing once — the declaration converges by use. And the semantics for schedules, where the whole question began: an answer can be saved as a standing default ("same folder every week"), and a scheduled run whose required inputs cannot all be resolved from defaults does not fire and guess — it holds, and surfaces this schedule needs a default for X where the user will see it. A schedule that runs wrong is worse than a schedule that waits.

Consent with nobody to ask

The permission machinery earlier entries describe assumes it can pause and ask. An unattended run cannot pause into a face that is not there — and the earlier version of this simply dropped the question, leaving the user a generic "had a problem" with no path forward. The contract now: a run that hits a missing grant finishes honestly, with a first-class needs-your-permission status — rendered amber, not failure-red — and writes the actual question as a card in the user's inbox. Granting it re-runs the work with the grant in place; declining closes the card and nothing executes. The same asymmetry runs through reads: interactive chat reads connected services freely, because a human watching is itself a control, while an unattended run asks once per service before its first read — autonomy removed the backstop, so the careful question is reinstated exactly where the watching stopped.

Failure with nobody to see it

A failed overnight run is read hours later, cold, by someone deciding whether to trust the system again. For a long time every ending looked identical: one red banner, one bold "this run failed", the transport's own lowercase error string underneath. Running out of credit, a genuine stage error, and the user pressing Cancel were indistinguishable — and none could be acted on from the screen reporting them.

The redesign starts from a sentence we now apply everywhere: a stopped run is a situation, not an alarm. Three tones. Blocked — recoverable, usually the user's to clear: credit ran out, a rate limit, a dropped connection — in ochre, because nothing is lost and red is reserved for the irreversible; the loudest miscue on the old screen was pink-alarming a wallet problem. Broken — a stage genuinely errored — in rust, with the model's own explanation of what went wrong kept intact, because the agent's sentence about why it stopped is usually the most useful line on the page and must never be flattened into "something went wrong". Cancelled — you stopped it — no colour at all, because a decision is not a condition. And in every case the repair lives inside the message: retry from the stage that failed, which re-runs only stages without a recorded outcome — completed work is never re-executed and never re-billed — so an overnight failure at stage three of five resumes at stage three, not from scratch.

Memory with nobody to re-explain

An interactive user re-orients an agent constantly and invisibly — every message is context. A recurring run gets no such drip, and re-deriving the world from scratch each morning makes runs slower, costlier, and prone to re-doing yesterday's work. So recurring jobs are seeded with a run-history block: a window over the last successful run — what it did, what it produced, where it stopped — injected at start, so "sweep the inbox" on Tuesday knows what Monday already handled. It is the unattended analogue of the conversation the interactive user provides for free. One honest limit alongside it: autonomous runs currently execute at the standard reasoning depth on every plan — the deeper thinking tiers are an interactive feature for now, a sequencing decision rather than a principle, and it is recorded as such.

The inbox is the other half of autonomy

Step back and every mechanism above converges on the same primitive. The permission question becomes an inbox card. The missing input becomes an inbox card. The schedule that cannot safely fire holds and leaves a card. The failure taxonomy exists so that the next card — the run's outcome — reads as a situation with a repair rather than an alarm with a stack trace. Autonomy did not remove the human from the loop; it moved them later in time, and the inbox is the channel that bridges the gap — questions flowing one way, decisions flowing back, work resuming with the answer in hand.

That is the transferable conclusion for anyone building unattended agents: the hard part is not making runs autonomous, it is making them interruptible toward a human who is not there yet. Design the question-parking surface first — where questions wait, how answers resume work, what a cold reader sees — and the rest of the autonomy features have somewhere to stand. Build the autonomy first and every gap becomes a guess, and the guesses, as we learned, arrive fluent, confident, and signed in your name.

Postscript, August 2026. The contract has held and grown edges. Runs gained a proper stop control — with a stopped run rendering as a neutral "Stopped", not a red failure, on every surface — and a read-triggered reaper now finalises runs orphaned by a dying pod, so "running" can no longer be a lie that outlives the process. The declared-but-unproduced failure reasons remain deliberately unproduced; one status that exists in the type system is still set by nothing, and it stays that way until an expiry job exists to set it honestly. And the fluent-failure lesson earned a permanent place in how we read run output: of all the things an unattended system can do, the one we now audit for hardest is it sounding sure.

This entry is about how we drew that line so code could see it, and what it turned out to be made of. The shape is not particular to dashboards. Any long-lived object that a machine refreshes and a human also edits carries this boundary, whether or not anyone has drawn it, and an agent that writes to something a person also owns is a co-author with no agreed division of the page.

Two authors, one object

What the design gives, in the order we understood we needed it.

Presentation lives beside the data, not inside it. A panel's colour, its density, its display options are stored on the dashboard document keyed by panel id, in a separate object from the panels themselves. A refresh that replaces the panel array wholesale cannot touch them, because it never sees them. This was the first author-owned facet to be separated out, and it was separated before we had a word for what we were doing; the argument at the time was only that a refresh should not have to know about colours.

The stored panels are the skeleton, and a refresh only fills it. A refresh re-renders a dashboard's panels from scratch: the agent composing the fresh output decides the panel order, each panel's width, and the panel set, every run. Left alone, that meant a refresh that was only meant to update the numbers could reflow the whole card, with a different order, a widened panel, one added, one gone. So the merge treats the previously stored panels as authoritative. The output is exactly the stored panels, in stored order, at stored widths, with only the data slotted in from the matching fresh panel. A panel the refresh tried to add is dropped. A panel the refresh omitted keeps its last good content.

The asymmetry is a property of routing, not a flag. The product rule is that an unattended refresh may change what a dashboard says and never how it is arranged; only an interactive edit, a person asking the agent to move or resize or add something, may restructure it. We did not implement that with a mode. Every scheduled refresh writes back through one path, and that path runs the skeleton merge. The interactive paths, the agent's own dashboard tools and a re-render requested in conversation, bypass it entirely. The agent can rearrange a dashboard when asked and cannot when merely refreshing, and that is true because of which door each kind of write comes through, with no state that could get out of sync.

On the read side, data comes from the view and presentation from the document. Dashboards are also assembled at read time: a drilled-down view of one record, a per-parameter instance, a mixed board whose panels each resolve from their own source. Each of those resolvers builds a dashboard from panel data, and each is a place to drop the author's presentation. So every resolver's output now passes through one function that re-attaches the document's presentation onto whatever the data resolution produced, the document's saved style winning over anything a branch made up.

What the boundary is made of

We did not design the four rules above in one sitting. Each was written on the day a refresh erased something a person had decided, and the sequence is the evidence for this entry's argument. At the end of June a scheduled refresh reflowed a dashboard's layout; the layout became the skeleton. Then a refresh wrote an instance's title over its template's; instance runs stopped writing to the template at all. Three days after that, a colour a person had just picked repainted and then snapped back before their eyes, because a drilled view's resolver rebuilt the dashboard from panel data alone; that was the read-side merge. A week later a refresh detached a panel from its dataset, because a routine's captured render reproduced the card as plain inline data and the merge took the fresh panel's binding, which was none; the binding joined the skeleton. And this week a refresh renamed two panels on a dashboard installed from one of our Kits, from the titles the Kit's author wrote to "Records" and "Trend".

Read side by side, the fixes have an uncomfortable shape. Each one protects one more field. Layout, then title, then presentation, then binding, then title again one level down. Each fix is correct, tested and local, and the boundary those fields share still existed nowhere except in the heads of the people who had been bitten by it. The type system cannot warn the next code path, because both kinds of field look identical to it. The regression tests protect exactly the fields already lost, because tests get written where blood was drawn. And new code paths that rebuild a dashboard from one side's data keep being written, because rebuilding from data is the natural shape of a resolver, and every author-owned field it does not know about defaults to gone. The merge is last-writer-wins by default, and the machine always writes last.

So the pin list is not a list of fields to protect. It is the boundary between data and authorship, and every time we treated it as the former, another author-owned field taught us the latter. The question to ask before adding any field to a panel is not "should this be pinned" but two questions together: can an author set this, and does a refresh regenerate it? A field that answers yes to both lives on the line and belongs behind the choke point from the day it exists.

And this week's incident showed that the line is not field-shaped at all. The panels that lost their titles were bound to a dataset, and a dataset panel is refreshed by a pure transform that turns rows into panels and has never seen the author's dashboard; its titles are pattern defaults, "Records" for a count, "Trend" for a line over time. Pinning the authored title for those panels is plainly right. But pinning the title for every panel would be wrong, because a panel rendered by a routine or an agent is produced by something that is an author: its title is legitimately part of what it made, and "Spend — July" must stay free to become "Spend — August". The same field, the title, is authorship on one panel and data on its neighbour, and the only thing that decides which is who produced it. So the rule that shipped pins a panel's title when, and only when, the panel's source is a dataset. The boundary is owner-shaped. The line we could not see was never between fields. It was between authors, and one of the authors is a machine.

When the machine reads its own mistake

This week's incident earns a section of its own for what happened after the rename. The generic title was not only displayed; it was written back into the stored document. The routine that refreshes that dashboard reads the document at the start of every run, to know what it is filling, and then renders its output. So on the next run it read "Records" out of the document, took it for the panel's name, and faithfully re-emitted it. A one-time slip in the merge had become a standing fact, ratified by the agent on every subsequent run. Reverting the document by hand would have lasted exactly one cycle.

That is a different class of failure from the four before it, and it is specific to systems where an agent reads back what it wrote. In a pipeline with no loop, a bad write is a bad write; you correct the data and move on. Where the writer is also a reader of its own output, the artefact is part of the prompt, and anything the merge lets through becomes the agent's instruction next time. The repair has to be in the merge, not in the data, because the data will be regenerated from the merge's last mistake. For anyone building agents that maintain documents, dashboards or tables they also consult, the loop through storage is a feedback path, and every field it carries is a field the agent can be taught the wrong value of by its own previous run.

What transfers

Inventory your long-lived objects for fields with different owners. Anything a machine refreshes half of and a person authored the other half of is carrying this boundary, drawn or not. The tells are cheap to check. Does any operation rebuild the object from one side's inputs? Do your fixes for "X got lost on refresh" take the form of pinning individual fields? Is there a list somewhere, in code or in folklore, of fields to preserve? A pin list is a boundary described one casualty at a time.

Express the boundary instead. Separate the owners in the types if you can. If you cannot, put the merge in one named function that takes the machine's fresh output and the author's stored document as separate arguments and produces the composite, so that dropping authorship stops being the default behaviour of forgetting and becomes something you would have to write. Route every rebuild through it. Then classify by owner rather than by field, because the same field can be authorship in one place and data in the next, and the only stable question is who produced it. And if the machine reads its own output, check which fields the loop can silently ratify; the fix for those is never in the data.

The difference, in the end, is whether the next engineer's new code path is safe by construction or safe by their having heard the story.

Postscript, September 2026. The boundary held, and a week later it was in the way. A Kit's dashboard is installed before its routine has gathered any data, so its first refresh runs over zero rows and stores a panel set with no breakdown in it; the transform that builds panels from a ledger only emits a category breakdown when there are rows to group. Every later refresh id-matched against that empty-day skeleton and dropped the breakdown as a panel the refresh had "tried to add". The layout lock was doing exactly what it was built to do, and for this dashboard it was wrong, because the panel set of a dashboard derived from a dataset is not anyone's decision. It is a fact about the data. So the merge now grows a dashboard's panel set from fresh output when, and only when, the dashboard's source is a dataset, keeping every stored panel's order, width and binding, and keeping any panel a person added that the transform did not produce. The rule that came out of it belongs beside the one above: before protecting a field, ask whether the thing you are protecting is the user's decision or a function of their data. Owner-shaped cuts both ways. A guard written for an author, applied to a transform, freezes the product to the day it was installed.

The generous answer — remember all of it — destroys the thing it promises. Where recall is ranked by similarity, volume wins, and three hundred receipts must not be allowed to outrank the one note recording a decision. We made that argument in the previous entry and take it as settled here: push everything into memory at full strength and memory stops being able to answer toward relevance.

But the cautious answer fails too, and its failure is nastier because nobody sees it happen. For most of this system's life, the de facto policy was that only notes the agents authored themselves entered semantic memory. Everything a person uploaded, dragged in, or synced was keyword-searchable storage at best. That sounds reasonable — agent-authored notes are curated by construction — and it silently wrong-foots people, because a person who puts a folder into their assistant's vault reasonably assumes the assistant now knows it. It didn't. Two kinds of file wearing the same coat: notes the agents remembered, and files they had merely filed away, with nothing anywhere telling you which was which.

So the real finding of this phase is that there is no good default. Any fixed policy is wrong for someone's folder — the archive that should stay inert, the contract folder that should be known cold. What shipped instead is the decision made visible and owned: every folder carries a plain-language memory setting, the setting is offered at the moment files arrive, and the system's standing rule is that it never promotes content into memory silently. What gets in stopped being an architectural constant and became something a person decides, folder by folder, in words they can act on.

This entry is about the machinery that makes such a choice trustworthy — because a setting a user cannot verify, applied by a process that can half-fail, is worse than no setting at all.

Ask at the door, once

There are more ways for a file to arrive than anyone lists on the first try: a bulk folder copy, a file-picker upload, a connector saving email attachments, something pasted into a conversation, a sync job, an agent writing a note. Each is a door, and the choice is presented at the door — with discipline about how often.

The granularity is the folder, never the file. A folder import shows the ladder once, with the middle rung pre-selected; every file inherits. A connector saving into a new folder prompts once, and every later save inherits silently. A file attached mid-conversation lands searchable, with a lightweight "remember this" affordance afterwards — never a modal interrupting the exchange. Ask about a place once, not about a thousand files; a memory system that nags is a memory system whose prompts get dismissed unread, which converts the explicit choice back into an accidental default.

The four settings are stated in plain words — Remember every file, Remember the gist, Keep as searchable files, Just store them — and each carries a concrete example, because the abstract descriptions tested as too vague to choose between. What each rung mechanically does was the previous entry's subject; this one is about keeping the contract honest once the choice exists.

The badge cannot lie

Every file and folder shows its standing — in memory, gist only, searchable, stored. The obvious implementation is a stored status field, written when the policy is applied. We refused it, on a rule that has earned its keep across this codebase: derive state, don't store it.

A stored badge is a claim about the past — we once set this to X — wearing the costume of a claim about the present. The two part company the first time anything goes wrong: an apply that dies midway, a store that changes behind the flag, a migration that misses a row. From then on the interface asserts something the stores no longer agree with, and no one can tell from the outside.

So the badge is computed, on read, from what the stores actually hold. A per-file memory entry exists → in memory. The folder holds a summary entry → gist. A keyword-index entry only → searchable. None of the above → stored. There is no status field anywhere to go stale, which means the display is structurally incapable of disagreeing with reality — the strongest honesty guarantee available, because it is not a guarantee anyone has to maintain. In a product whose promise is you can see exactly what your agents hold, that property is not an implementation nicety. It is the promise.

Apply is a destination, not a journey

Changing a folder's setting means real work: tearing down per-file memory entries, writing or removing a folder summary, adding or dropping index entries, over possibly hundreds of files. With four settings there are twelve possible transitions, and the obvious implementation — read the old policy, compute the difference, apply the delta — means twelve code paths, each an opportunity to be subtly wrong, plus a thirteenth nobody writes: recovering from an apply that died in the middle.

The version that shipped never reads the previous policy at all. Applying a setting is target-state reconstruction: each target unconditionally removes every artifact it must not have and builds every artifact it must, regardless of what was there before. All twelve transitions collapse into four idempotent destinations, correct by construction rather than by enumeration. And the failure story falls out for free: each file's work is wrapped so one blip cannot abort the whole apply, a partial failure leaves a mixed state the rollup honestly reports, and the recovery procedure is apply it again — same target, clean result. There is deliberately no retry queue, because a cheap idempotent apply is the retry mechanism.

The one bug this design produced is the exception that argues for the rule. The only transition that misbehaved was the one the delta mindset says is trivial: re-applying a folder's current setting. The full-memory branch originally skipped its own teardown — the source tier "couldn't" hold those artifacts — so applying Remember every file twice appended a duplicate memory entry per file. And applying a setting twice is not a rare event; it is what a person does when they are not sure the first tap worked. The fix was to make the branch true to the principle it had shortcut: tear down first, always, even when you believe there is nothing to tear down.

Words that keep the contract honest

The remaining machinery is vocabulary, and it did as many revisions as the code. Three details from that work say what kind of product this is trying to be.

The strongest setting argues against itself. Selecting Remember every file on a large folder shows an amber warning — memory gets noisy; stray details start surfacing in answers unprompted — and the dialog suggests the gist setting instead. On a small, focused folder the same option shows a soft green "fine for a folder like this". The system has an interest in looking as capable as possible, and "remember everything about me" is the capability-sounding choice; pricing it honestly at the moment of choice, scaled by the actual folder in front of you, is the opposite of a dark pattern and cost one afternoon.

The weakest setting says what still works. Just store them originally read as if the files went dark. The shipped copy says the agents "won't learn the contents or find them by search — but can still open one if you name it directly", because that is the truth: the rung switches off discovery, not access, and copy that overstates a restriction is as dishonest as copy that overstates a capability.

And one word was refused outright. "Trained" was floated for the top rung — train your agents on this folder. It is wrong. Retrieval is not training: nothing about any model changes when a folder is remembered, and the product's standing commitment is that it never trains on your data. Using "trained" as a warmth word for indexing would spend the credibility of that commitment on a metaphor. The copy says learns and remembers — words whose plain reading matches what the machinery does — and the distinction is load-bearing enough that we wrote it down as a rule rather than a preference.

What a memory owes its owner

The through-line of this phase: an assistant's memory is the user's to govern, and governance needs three properties the defaults never had. The decision must be theirs — made in plain words, at the door, never silently. The display must be true — derived from the stores, incapable of drift. And the mechanism must be safe to use carelessly — idempotent, self-healing, honest about partial failure. Remembering everything was never the goal, and neither was the quiet inverse we shipped first. The goal is that what an assistant holds about you is exactly what you decided it should — and that you can check.

Postscript, August 2026. The rungs and the never-silently-promote rule have held. The apply became a background job the day after this entry — the dialog closes at once, and the folder's memory line carries the target badge and "applying…" until it settles, with a visible retry if it fails. The vocabulary moved twice more within days — the previous entry's postscript tells that story from the document side — and a few doors remain honestly unwired: the loose-file upload affordances still route through the folder machinery rather than their own choice cards, and promoted bulk content still indexes into a file's natural area rather than a separate namespace, a hardening deferred until scale demands it. And the boot-cost rule is written down beside the machinery it protects, so the next encoder proposal has to answer for the largest vault's cold start before it answers for anything else — which is exactly where the last change hurt us.

The founding move of this phase, from which everything else follows: the turn outlives the connection. The gateway forwards a chat turn to the pod deliberately detached — the client's disconnect signal is not passed along — so the model runs to completion and the finished turn persists, whatever happened to the tab. Closing, refreshing, losing signal: none of it cancels anything (stopping is its own explicit act, as an earlier entry described, precisely so that leaving and objecting stay distinguishable). Once that holds, every recovery problem changes species: recovering a reply stops being about re-executing work and becomes about reading a result that already exists. The rest of this entry is what that reframing exposed — including one place we were paying for the guarantee and then throwing it away.

Reclaim, don't resend

The audit that kicked this phase off — triggered by a user on mobile repeatedly seeing "couldn't reach" errors that a single dropped fetch had escalated into — found an asymmetry invisible to users and expensive to us. Server-side, a turn interrupted mid-stream was fine: it completed, it persisted. Client-side, the dropped stream was treated as lost work, and the UI offered a resend — which re-ran, and re-billed, a turn that had already finished. We had bought durability and were spending it on double-billing.

The fix inverts the recovery order. On a mid-stream drop after output has begun, the client does not offer anything — it shows a quiet "reconnecting" and polls the session for the reply that is, in all likelihood, completing server-side right now. If an over-eager re-send does fire while the turn is still running, the server's duplicate guard rejects it safely; the next build routes that rejection into the same reclaim poll, because "your turn is still running" is the best possible news a recovering client can receive. Only when the bounded reclaim window expires with no persisted reply does the resend affordance appear — now meaning what it says. The success criterion was written to be measurable: a network blip during a turn ends with the reply appearing, and zero recovery paths re-run completed work.

The turn that never finished finishing

Durability has a failure mode of its own, and it found us. The persistence contract writes the user's message early (so nothing typed is ever lost) and the terminal assistant reply at finalize. But a finalize is code, running in a process — and when that process dies mid-turn (a relay dropping, a pod being killed), the terminal write never happens. What remains is a session whose last message is a dangling user message: structurally indistinguishable from a turn that is in flight right now. The client's resume machinery — which on reload sees a user-message tail and reasonably concludes a turn is running — showed "picking up where you left off…", blocked sending, waited its full window, found nothing, and then did it all again on the next reload. A dead turn, wearing a live turn's clothes, forever.

The fix is a pattern we now reach for by name: a read-path reaper. When a session is loaded and its tail is a user message older than a staleness threshold — set comfortably past the load balancer's own idle timeout, so no genuinely live turn can be falsely reaped — an error bubble is synthesized and appended, marking the turn as ended by disconnection. Idempotent by construction (the appended bubble makes the tail non-user, so the check never fires twice), best-effort persisted so the record heals for future reads, and invisible to the model (display-only messages never re-enter its context). The general lesson earned its place in more than one subsystem the same month: any detached process's terminal state needs to exist — written at finalize, or synthesized, age-keyed and idempotently, on read — because an in-flight guard cannot cover a finalize that never ran, and a record that cannot distinguish "dead" from "busy" will make its readers wait for the dead.

Two tabs are not one problem

The seamless dream — a thread live in two windows, a refresh resuming mid-token — decomposes, on inspection, into two problems that only look alike. Same-browser multi-tab is a client-side problem: same origin, same device; the tabs can simply tell each other what is happening over the browser's broadcast channel, with the streaming tab as the source of truth. True resume — refreshing the only tab, or opening the thread on a phone while a laptop drives it — is a different animal entirely: after a refresh there is no peer tab to copy from, so the survivor must be server state, and today only completed turns persist; there is no in-flight record to reattach to mid-token. Filing refresh under "multi-tab" is the tempting mistake, because it is secretly the hard problem wearing the easy one's clothes.

One architectural fact keeps even the hard version tractable, and it is a dividend from a decision made months earlier for other reasons: all of a user's connections route to their single pod. Fan-out to N tabs is an in-process concern on one machine — no shared bus, no pub/sub infrastructure, no cross-node coordination. And one design judgment keeps the hard version honest: with turns durable and reclaim in place, a full mid-token resume protocol buys seconds of continuity on top of a system that already never loses the result — so it is sequenced as polish, not foundation. At this entry's date, mid-token resume remains the open gap; the reply always arrives, and the last few seconds of watching it arrive can be lost. We can live with which half we built first.

The ladder of honesty

The last piece is a UX contract, applied uniformly, for the moments recovery is in progress — because "recovers by itself" still needs an answer to what the user sees meanwhile. It is a ladder: under about two seconds, silence — retry beneath the surface, never flicker the interface for a blip. Beyond that, a quiet "reconnecting…", inline where the action lives. The moment the device itself reports offline, say offline immediately — spinning at a network the OS knows is absent is theatre. And when retries are genuinely exhausted: a clear, actionable message that names what failed, keeps the user's input, and offers one tap to retry. Two absolutes bound the ladder at both ends: never an indefinite spinner, and never silent loss. Every state resolves — to content, to honest waiting, or to an honest ask.

What transfers

Detach the work from its delivery channel first — durability converts every recovery feature downstream from re-execution to reads, which is cheaper, safer, and un-double-billable. Then audit for places you offer re-execution of work that already completed; every one is the durability guarantee being thrown away at the last hop. Give every detached process a terminal state that cannot fail to exist, synthesizing it on read where finalize can die. Split multi-tab sync from true resume before estimating either. And write the feedback ladder down as policy, because without one, each surface improvises its own spinner — and a product's trustworthiness under bad networks is exactly the sum of what it does during the worst ten seconds.

Postscript, August 2026. The read-path reaper became a family — the same age-keyed, idempotent, synthesize-on-read shape now finalises orphaned scheduled runs and stuck background jobs, which is what a good pattern does when a failure class recurs: stops being a fix and becomes a vocabulary. The gaps from this entry's date keep their ranking: mid-token resume is still sequenced behind things that lose actual work rather than actual seconds, and the offline-capable app shell — a blank page on a cold offline load — sits in the same queue. The reclaim numbers have been quiet, which is the point: the measurable promise was zero recovery-induced double-billing, and the way you know a recovery system works is that the bill stops carrying its failures.

The hard half is everyone else's files. People arrive with folders — a laptop directory synced up, an export from some other tool, four years of meeting notes, an archive of scanned invoices — and they are right to. An assistant you have to curate for before it becomes useful is a filing system with extra steps. But that material carries no signal about what matters in it. Nothing in four hundred synced files says which one will matter in November, and nothing ranks them, because none of them was written to be ranked.

That leaves two ways to be wrong, on opposite sides.

Keep it all as inert storage and the assistant is a cabinet. The answer is in there, it can be found if you ask precisely enough, and it will never once come up on its own.

Push it all into memory at full strength and something worse happens: memory stops being able to answer toward relevance. An archive of invoices and one note recording a decision go in on equal terms, and where retrieval is ranked by similarity, volume wins. You do not end up with an assistant that knows more. You end up with one whose answers are diluted by everything it was handed.

So the question is what a system should do with a document it did not write, arriving in bulk, with no idea which parts of it matter. The answer we ended up with is not a threshold and not a better ranker. It is that "remembered" is not a boolean — and that the useful question is not how much of a file to store, but which machinery the file gets to touch.

We got there from a case where the top setting was switched on and the answer still came back wrong.

Someone points us at a folder of weekly notes synced off their laptop and picks that top setting: Remember every file. The line underneath says their agents will read and remember each one.

A fortnight later they ask when to start the renewal conversation with a client. The answer comes back confident, specific, and a year out of date. It quotes the end of the current term, correctly, from a contract note. It knows nothing about the call three weeks ago where the client asked to bring the whole thing forward to January.

That call is in the folder. It is in a weekly note, in one sentence, four lines below a reminder to book a dentist appointment.

Here is what promotion to the top rung actually did with that note. It registered one entry in memory per file, and the text of the entry was the file's title, its tags and its description. The weekly note has no frontmatter — it is a file a laptop dropped there, not a document anyone authored for us — so the text that entered memory was its filename. Remember every file was a true statement about files and a false one about what is inside them.

The cheap fix is to change the label. We wrote that option down and kept it: relabel the top rung as instant findability, lose the insight promise, keep the ladder honest. It stayed on the table for a day and it was the right thing to hold, because the expensive fix is only worth it if the machinery it buys does something the machinery underneath cannot.

Working out whether that was true meant answering a question we had been treating as settled: what does it actually mean for a document to be remembered?

Four intensities

So a document sits at one of four, and the ladder between them is not a ladder of how much is stored — the full body is reachable at three of the four rungs. It is a ladder of which machinery engages, and at the top, of whether the thing can reach you without being asked for.

Five things fell out of drawing that table, and the first one is the only line in it that really matters.

Push and pull are different products

The two middle rungs are findable. The top rung is findable and can arrive on its own. That is the whole ladder.

The difference is a library and a librarian. A library will hand you anything you can name. A librarian says you'll want to see this before you knew to ask for it, and that is a different capability with a different cost, not a better-tuned version of the first.

The reason it survives as a distinction is structural. There are two meaning-level indexes in the system and they are deliberately not joined. One sits over document bodies and is consulted when somebody asks a question. The other sits over memory and is consulted before the agent answers, on every turn, whether or not anyone asked it to look. Nothing feeds the second from the first. A document that exists only in the vault is reachable by any question you think to ask and will never come to mind unprompted.

That non-join used to look like an omission. It is the reason the setting means anything: the four rungs are a dial across exactly that boundary.

It also killed the original argument for the top rung. Once meaning-level search over full bodies shipped — locally computed, no model calls, near enough free — "get this into memory so my agents can find it" stopped being a thing anyone needed to buy. Findability went uniform across the top three rungs. What remained was the half that memory alone can do, which is turning up unasked.

And the default is the second rung. The system's default posture toward a document somebody drops on it is never volunteer.

What memory holds for a document is a pointer

Not the document. One line: where it is, what it is called, what it is about.

This looks like a shortcut and it is a design. The document store already keeps the only copy, and the moment memory holds a second copy of the prose you have two truths to keep in step. Three things follow from refusing that.

There is no drift, because there is nothing to drift from. Demotion is clean — you tombstone a pointer, which is an operation with an obvious meaning, rather than trying to un-remember a paragraph. And the third one we had not planned for: the quality of unprompted recall over documents is bounded by the quality of their titles and descriptions. Metadata stops being tidiness and becomes load-bearing. It is a card catalogue, and a card catalogue is only as good as the cards.

Which is exactly what the renewal question ran into. A file whose card says nothing cannot be recalled by a system that only ever reads cards.

Extraction, never copying

So the top rung had to read the bodies. The question was what to do with what it found, and the tempting answer — write the interesting passages into memory — is the same duplication mistake wearing a better hat.

What a document cannot express about itself is structure. Prose says "Northwind want to bring the renewal forward to January because of their budget cycle" and that sentence is perfectly retrievable from the document. What it is not is joinable. Ask what you know about that client and no amount of similarity search assembles the fee, the notice period, the term end and the moved conversation into one answer, because those four things live in different files and similarity does not do joins.

So the top rung runs a single structured pass per segment of the file and pulls out facts as subject-relation-object triples, and the constraint that makes it work is a validation rule: the subject must be a real-world entity. A person, a company, a project, a figure. Never a file path. Path-keyed rows already existed — this file is called that, this file is tagged that — and they are worth nothing to somebody asking about a client, because nobody's question has a file path in it.

Two implementation choices are worth stealing. It is one structured call per segment rather than an agentic loop, so the cost of extracting from a file is known before it runs and does not depend on a cheap model reliably driving a tool loop, which in our experience it does not. And long files are cut on entry boundaries rather than at a character count, which is what lets a multi-megabyte running log go through in full instead of being truncated at whatever cap seemed generous.

A ledger makes it reversible, and reversible makes it cheap

Every fact the extraction writes is recorded against the document it came from, keyed by a hash of that document's content.

That one record does three jobs. Demotion tombstones exactly what extraction wrote, and nothing else — the difference between un-remembering a document and hoping. A changed document diffs against its old set instead of piling a second copy of itself on top. And an unchanged document costs nothing at all: same hash, no model call, apply the whole folder again and again for free.

We had argued for idempotence as correctness. Here it is also the cost control and the safety story, and those turn out to be the same property viewed from different ends. A thing you can undo exactly is a thing you can afford to redo.

The policy belongs to the destination, not the author

There are more ways for a file to arrive than anyone lists on the first pass. An agent writes a note. A person edits a document in the browser. A connector saves an email. Somebody drags a file into a conversation. A sync job copies a folder. A remote tool call writes from another machine.

All of them now run through one gate that asks the same question — what has this file's destination folder been set to? — and does what that says. Who wrote the file does not enter into it.

This was a bug fix before it was a principle. Agent-authored notes had always been remembered in full, by construction, because in the beginning they were the only things in memory. Which meant an agent writing into a folder the user had deliberately demoted put the file straight back into memory, silently, and the badge on the document changed under them. The user's setting was correct and the write did not consult it.

The general form is a shape that recurs: an exemption derived from who is acting is a policy hole with good manners. It looks like trust and behaves like a bypass. Policy attaches to the destination, and every route in has to pass the same gate, or the setting is advisory.

Two paths that still ignore the setting

They index at the top rung unconditionally, whatever the folder is set to.

Generated data views — the readable rendering of a structured dataset — always get the full treatment. That one is deliberate and still open: a dataset view is a different kind of object from a file somebody dropped in a folder, and we have not settled what its policy ought to be.

And the gate itself falls back to the top rung when it cannot read a policy: during early boot, before the policy lookup has registered, or if that read throws. The reasoning was that a failed policy read must never break indexing. The reasoning is fine and the default is the wrong way round — a system whose failure mode is remember more than you were asked to has picked the wrong direction to fail in, in a product whose entire proposition is that you decide what it keeps. It is a small window and it is on the list.

Postscript, August 2026. The four rungs held, including under a proposal to collapse the top two into a single "Remembered" setting with a size guard. That was declined for a reason that only became visible after the extraction work: the two rungs now sit on opposite sides of a real cost boundary, and merging them would have hidden it.

What did move was the vocabulary, twice, and it moved because the axis moved. The dialog originally described how much of a file the system takes in. Once meaning-level search made every non-stored file findable, that axis was measuring something the rungs no longer differed on, and the copy was describing machinery instead of consequences. It now asks what form the content takes in memory — distilled facts, the gist, searchable text, nothing — which is the question the rungs actually answer.

The stakes went up in the same period. Unprompted recall used to fire on chat turns only; it now runs on scheduled work and on each stage of a multi-step job. The top rung buys presence in more places than it did when we drew the table, which makes "never volunteer by default" a better default than it was.

The naive alternatives are each wrong in their own way. Keep everything and you hit the wall. Truncate the oldest messages and a memory-first assistant develops visible amnesia about this morning — the single worst look available to us. Summarise silently and aggressively and you trade the wall for quiet context loss the user never agreed to. This entry is the phase where we built the real machinery, and it begins with a diagnosis that reshaped the whole design.

Two different walls wearing one error

The overflow error is one string, and it turns out to describe two structurally different events that demand different fixes — and our error copy had been assuming the wrong one.

Mode A: the single-turn blast. One turn's tool loop accumulates enough output to overflow within the turn. The bug that forced the decision was exactly this: a single research request fired four-plus web page fetches, each up to ~50,000 tokens of markdown, all kept in context, with the loop re-sending the whole accumulating feed on every iteration and no input ceiling anywhere. The conversation was young — and the error told the user it had "grown too long". No amount of compacting prior turns can save Mode A, because the blast is inside one turn.

Mode B: honest accumulation. A genuinely long working thread crosses the window over many turns. This is the case the error copy assumed was always true, and it is the rarer one — nearly every historical overflow we investigated traced to bulky tool payloads, not conversation.

The transferable point before any mechanism: diagnose which wall you hit before you build the fix, because the fixes do not overlap, and a team that conflates them will ship a compactor and keep dying on research turns.

Mode A: spill and handle, never truncate

The tempting fix for the blast is a cap — truncate big tool results at the source. It is lossy in exactly the wrong way: a cap tight enough to be safe is too tight to be useful, and the content it throws away is often the content the model needed. What shipped instead is context offloading: an oversized tool result — a fetched page, a large file read, a big data query — is spilled in full to a short-lived GCS buffer, and what enters the model's context is a bounded preview plus an opaque handle. A companion tool lets the model drill back in on demand — a keyword or section slice of the stored body — so nothing is lost; it is simply not all resident. The same backstop wraps every tool result at the dispatcher, so no single payload can dominate the window regardless of which tool produced it.

One design argument from that week is worth the whole entry to the right reader: the spill store is an offload buffer, not a cache, and keeping those concepts separate dissolved a tension that looked fundamental. Blobs are keyed by an opaque per-fetch handle, never by URL, and a fresh fetch of the same URL always re-hits the web — the store never answers a new request with an old page. With that rule in place, the blob's TTL stops being a correctness knob (staleness is impossible by construction) and becomes a pure housekeeping knob, so it can be generous — fourteen days — without a single staleness argument. And a handle referenced after its blob has expired self-heals: the original URL is recovered from the transcript, re-fetched fresh, and the handle revived, silently. Cache-versus-buffer is a distinction we had been blurring; naming it converted three hard open questions into one lifecycle rule.

Mode B: fold the feed, never the transcript

For honest accumulation, the mechanism is compaction — and one invariant outranks everything else in its design: the user's transcript is never mutated. Compaction operates on the model's feed exclusively. The full conversation still scrolls in the app, still reloads from the store intact, forever. What changes is what the model is shown: when the active window crosses a threshold (110,000 tokens by default), the oldest complete turns are folded into a rolling recap — written by a cheap model, seeded from the conversation's running summary — while the most recent stretch (40,000 tokens) stays verbatim, along with the opening framing of what the conversation is even about.

The mechanics have two properties that earned their tests. The fold boundary is tool-pair safe: the API rejects any request containing a tool call without its matching result, so folding snaps to turn boundaries, never mid-pair — an invariant, not a preference, because violating it does not degrade the request, it kills it. And the recap is incremental and fault-tolerant: already-folded turns are never re-summarised (the recap persists and extends), and any failure anywhere in compaction falls back to the full feed — a broken fold must never produce a broken request or lose a byte of anything.

Who decides is split the way the register's whole design philosophy splits it: the machine's housekeeping is silent (auto-compaction happens without ceremony, because narrating your own memory management is noise), while the user's action is visible — typing /compact folds harder, down to a lean tail, and answers with a plain line saying how many earlier messages were folded. And the recap can afford to be brief for a reason specific to this product: anything durable in those folded turns has already been extracted into long-term memory by the post-turn machinery, and is retrievable on demand. The conversation is transient; the memory is durable; compaction leans on that instead of trying to be an archive.

The wall nobody is present to hit

The same week supplied the reminder that ceilings are hit hardest where nobody is watching. A real ninety-minute session died at the window's edge — most of what filled it being tool and retrieval machinery riding in history, which got its own fix in an earlier entry — and the postmortem question was not "how did this happen" but "what happens when this happens at 3am to a scheduled run?" An interactive user can be offered a way out. An autonomous stage cannot click anything.

So the unattended path got its own context guard: long autonomous runs and multi-stage jobs now budget the window per stage, rather than discovering the ceiling as a crash. And the design for overflow recovery inverts from compaction to handoff — and the distinction is worth naming, because they look similar and are not. Compaction thins the model's feed within a session. A handoff ends the session gracefully: the whole working state is distilled into a durable brief — objective, key facts, current state, open threads — written to the user's vault as a real document, and a fresh session (fresh window, fresh cache) continues from the brief, with the original session preserved and linked so any buried detail remains one read away. Lossless on demand, rather than lossy in advance. For unattended work the design has it run automatically, with a cap on consecutive auto-handoffs — because a job that compacts itself forever is a runaway loop wearing a coping mechanism, and after the cap it surfaces to a human instead of quietly eating the window again.

What transfers

Separate the two overflows before designing anything — in-turn blasts and cross-turn accumulation share an error string and nothing else. Spill oversized results to a handle-keyed buffer and keep the distinction between a buffer and a cache sacred; it converts staleness from a correctness problem into a lifecycle rule. Reduce the model's feed and never the user's record, fold only at boundaries the API can survive, and make every reduction fault-tolerant toward the full feed. Keep the machine's housekeeping silent and the user's actions visible. And design the unattended path first when you design for ceilings — the interactive user was always going to be fine; the run with nobody watching is the one the wall was built for.

Postscript, August 2026. The machinery held, and the deferred pieces stayed honestly deferred: the task-aware digest per large fetch remains unbuilt, extractive drill-in having proved sufficient so far; the handoff itself (brief, fresh session, unattended cap) remains a design ahead of its build; and the gentle proactive nudge arrived at the end of the month in a simplified form, offering a fresh chat rather than a brief — the ceiling has stopped being something users meet, which was the point. The buffer-not-cache distinction has since earned its keep in a second place, and the handoff brief's shape — objective, facts, state, open threads — turned out to be the same shape a long-running job wants for resuming work generally, which is a convergence we noticed rather than planned: what a session needs to survive its own death is what any successor needs to pick up its life.

The engineering problem underneath is the one every graph visualisation faces: a knowledge graph has no natural geometry. Nothing in the data says where anything goes. Every coordinate is invented — which means every layout is an argument about what matters, whether its author knows it or not. Distance will be read as relatedness, size as importance, lines as relationships, whether or not they encode any of those things. A layout that lets accident produce those marks is publishing false claims in a visual language the viewer cannot help but read. This entry is the record of taking that seriously against a real memory — eighty-plus areas, one to fifteen rooms each, relationships between arbitrary pairs — after a design phase whose demo looked beautiful on invented data.

The data layer: real padlocks or nothing

Before geometry, truth. The map is fed by a single aggregated read — areas with their volumes and rooms, the posture of each (open, sealed to one agent, shared-read-private-write), the roster of agents who can actually enter, and the edges between areas — and the rule that shaped it: every lock on the map is derived from the enforcement machinery, never drawn from a display field. A sealed area shows sealed because the storage namespacing that seals it says so; the roster shows who the permission system would actually admit. The alternative — a map whose padlocks are UI state — would be a safety diagram with no wiring behind it, which is worse than no diagram.

Two data decisions kept the first version honest. Areas are the memory's own emergent areas, one-to-one, rather than an immediately-invented curated taxonomy — ship the truth first, measure whether it is too messy, and let the later re-organisation work (it came, as an earlier entry describes) upgrade the data under a stable shape. And because personal memory and each organisation's shared memory live in physically separate stores, one call sees exactly one sphere — so the client fetches each sphere's map and stitches them into one scene as depth-zoned planes, personal in front, the org behind, labelled with the org's real name. One bug from that stitch earned its place in the security series' spirit: the agent roster query was cross-sphere, so org agents briefly appeared as able to enter personal areas — fixed with a sphere fence on every roster attribution, because a transparency surface that overstates access is a special kind of wrong.

Every line must mean something

The vendored engine arrived from the design phase with a habit: a synthetic "rest web" joining each area to its one or two nearest neighbours by 3D distance. Over demo data it reads as pleasing connective tissue. Over real data it is a lie, because position came from a spiral laid out over an arbitrary index — so "nearest" encoded nothing but the accident of who landed beside whom. Lines drawn from layout accident look exactly like lines drawn from meaning. We turned the web off, and adopted the rule as a standing test: every mark on the map must trace to a fact. Edges now come only from real signals — areas that share topics, and relationships lifted from the fact graph — and are drawn as hairlines, not pipes, because links are the map's least important true marks. (One honesty note the type system keeps for us: explicitly-created tunnels between areas have a rendering variant defined and still nothing emits it — the map draws what exists, and what doesn't exist yet stays undrawn.)

The deeper fix was to make position itself meaningful. The spiral spaces areas evenly but orders them arbitrarily, so a genuinely related pair could sit across the whole map from each other, their connection rendered as a line spanning everything — visually shouting, semantically ordinary. The layout now runs a deterministic force-directed settle at build time — once, about eight milliseconds for a real eighty-six-area estate — under which linked areas become neighbours. After the settle, proximity finally means related, which converts the map's most-read visual variable from accident to argument. That one change is the thesis of this entry in miniature: the algorithm was never the hard part; deciding which visual variables are permitted to carry meaning, and forbidding the rest, is the design.

Drawing in constant time, breathing without drifting

Two pieces of engine work carry ideas beyond visualisation. The first is the rendering version of an argument this series already made about retrieval cost: the map must not get more expensive as the memory grows. The naive scene drew each room satellite as its own pair of meshes — at 245 satellites, 490 draw calls a frame, growing linearly with the palace. They are now two instanced draws — one for faces, one for rims — regardless of room count: per-frame cost is constant in the size of the memory, which is the property a map of a growing thing needs, and the same shape as keeping recall cost flat while the store grows. The second is a small animation with a sharp trap. The estate "breathes" — a slow, shallow orbital drift so the scene reads alive rather than frozen — and the obvious implementation compounds into a runaway: the camera-control library re-derives its internal state from the camera's position every frame, so naively animating position feeds the offset back into the controls, which fold it into the orbit, and the map slowly drifts away. The fix is a discipline, not a value: apply the breath after the controls update, render, and restore the true camera immediately — so every other consumer of camera state only ever sees reality. Any animation layered onto a stateful controller wants that shape: borrow the state, never lend your modification.

What transfers

Treat every visual variable in a graph rendering as a claim, and delete the marks that encode accident — a synthetic line and a meaningful line are indistinguishable to the viewer, which makes drawing the former a form of lying. Make position mean something (a cheap deterministic settle converts proximity from noise to signal) before decorating anything. Derive safety indicators from the enforcement machinery, never from display state. Tune against the real corpus, not the demo — every constant calibrated on invented data is a latent bug with aesthetics. And budget your rendering the way you budget your retrieval: constant in the size of the thing it draws, because the whole point of the thing is that it grows.

Postscript, August 2026. The upgrade path the data layer bet on arrived: the re-organisation pass now settles the map's areas into named, described life-areas — the curation question resolved in the data, with the map's shape unchanged, exactly as hoped — and focused areas carry one-line descriptions on the map itself. The explicit-tunnels variant remains defined and unemitted, still honestly undrawn. The map went to the phone with its own navigation patterns and a low-poly option for large estates — though instancing quietly demoted that toggle from a performance necessity to a visual preference, which is what a good structural fix does to the workarounds upstream of it. And the padlocks have stayed wired to the enforcement machinery through every subsequent permission change, which is the property we would defend hardest: a memory map is a promise about legibility, and a promise about legibility kept by hand is a promise about to be broken.

That turns out not to be a vocabulary problem. It is the architecture. What people call an agent's memory is, in our system, six stores — with different backends, different shapes, and different jobs — and no design we tried could honestly collapse them into fewer. The reason is that "remember" is not one operation. Find me something like this wants vectors and tolerance. What exactly is true of this person, as of last March wants typed rows and time. What did we say last week wants transcripts. What matters about all of this wants curation. Each of those questions has a natural shape, the shapes are incompatible, and forcing them into one store means answering most of the questions badly to answer one of them well.

This entry is the map. The rest of the series walks single paths through this machine; this is the post that says what the machine is made of, and carries the two pieces of evidence that taught us the decomposition is real rather than an implementation accident.

The six

1. The documents. Markdown files and attachments — the user's actual content, in folders they control. Strictly speaking this is not memory at all; it is the material memory is built over, and the biggest single feeder of everything below. Today it is findable by the words in it, through a keyword index.
2. The filed notes. Verbatim observations filed spatially — areas of a life, topics within them — each embedded into a ChromaDB store for search by meaning. This carries the headline recall job: it is where "remind me how I like commit messages written" gets answered.
3. The fact graph. Typed statements — subject, relation, object — about real-world entities, each carrying the time it became true and the time it stopped being. A separate SQLite store: an exact-keyed knowledge graph, no embeddings anywhere in it. This is where precise lives, and where temporal questions ("what was true then?") are answerable at all.
4. The compressed summaries. Dense shorthand renderings of long material, kept beside the verbatim notes. They exist for ranking, and only for ranking — more on the demotion below, because we did not plan it that way.
5. The agents' diaries. Per-agent session logs, written at the end of working sessions, fenced so each agent's diary is its own. The product has more than one agent per person; what a specialist learned in its own sessions is a different thing from the shared pool.
6. The conversation index. Every chat, rendered to a clean text and embedded — in its own Firestore-backed store, with its own encoder — so a person can find a conversation by what it was about. The newest of the six, and the one whose origin story carries this post's first lesson.

Two different vector backends for search-by-meaning, SQLite for facts, flat files on GCS for documents, transcripts for history. Different write paths, different failure modes, different costs. And one line through the middle sharper than all the others: three of these stores can reach the model unasked, surfacing before each answer through the retrieval pre-pass covered earlier in this series, while the documents and the conversation index are only ever consulted when something asks. Which stores sit on which side of that line is a product decision wearing an architecture costume — a document put into the wrong pile is either invisible or unignorable — and it matters enough to deserve an entry of its own.

The seam in the middle

The structural fact everything else bends around: the store you search by meaning and the store you query by key cannot see each other. The search side never consults the graph; the graph never touches an embedding. There is no query in either direction that joins them — a search hit comes back with text and a score and no entity keys; a fact comes back as typed rows with no scores and no notes attached. If an answer needs both — and the interesting answers usually do — some caller has to run both lookups and stitch the union itself.

For a while this looked like a hole we would eventually fill. We now think of it as a seam we deliberately maintain, and the reframe came from watching the two failure modes stay apart. The keyed side fails closed — a name variant means a lookup returns nothing while the answer sits in the store, which is why the canonicalisation work exists and why a graph miss is read as unknown, never absent. The meaning side fails open — it always returns its nearest neighbour, even when nothing relevant exists. Joined into one store, those failure modes would blend into each other and become undiagnosable. Kept apart, each is legible, each gets its own countermeasures, and the union point — the one place the two are combined — is a single piece of code we can instrument, threshold and test. The seam is where the system's honesty lives.

Evidence one: the encoder that did not know a Range Rover is a car

For most of the system's life, conversations were searched through the same embedding model that indexes the filed notes. It seemed obviously right — one semantic search, one encoder, one store. Then a reasonable query returned nothing useful, and we measured instead of tuning.

My chat history held a conversation titled "Range Rover coolant leak". The query "car" scored 0.12 cosine similarity against it — far below any usable threshold. "Garage" scored 0.07, "vehicle" 0.16. Exact-ish phrases worked fine: "Range Rover" 0.43, "coolant leak" 0.51. The diagnosis wrote itself: the notes' embedder, a small 2021-era sentence encoder, simply does not carry the world knowledge that a Range Rover is a car. No threshold rescues a 0.12 — the conversation was not ranked low, it was invisible.

The obvious fix was to upgrade the encoder everywhere. A modern small retrieval encoder scores the same pair at 0.42, "garage" at 0.40, "vehicle" at 0.43, while an unrelated query ("pizza") stays down at 0.23 — clean separation, exactly what search wants. And we declined to deploy it to the notes store, because swapping a memory system's embedder means re-embedding everything it holds, and every ranking a user's recall currently depends on moves at once — an unbounded regression surface in the one subsystem whose reliability is the product. We also measured the cheap alternative, static synonym expansion of the query, at 0.226 for the same pair: still invisible.

So the conversations got their own store, their own encoder, and their own index — and the palace's embedder was not touched. That is why the sixth store exists. The transferable form: in a live memory system, an embedder is not a component you upgrade, it is a commitment you made — every vector in the store is denominated in it. New capability arrives as a new store beside the old one, not as a transplant into it.

Evidence two: the compression measured and demoted

The fourth store began life with a grander job. The idea is genuinely attractive: render long material into a dense structured shorthand — entities as codes, importance as marks, fields delimited — and let the language model itself be the decompressor, the way it expands any abbreviation. Packed that way, a paragraph's content fits in a fifth of the tokens, and in a system where every remembered token is paid for on every turn, that looked like the scaling story.

Then the memory library's own evaluation measured it on a public long-conversation memory benchmark, and the tax appeared: Recall@5 of 96.6% retrieving over verbatim notes, against 84.2% over their compressed renderings. A twelve-point drop. The compression is also lossy in the plain sense — the original wording is not recoverable from the shorthand — so whatever nuance fell out at write time is not coming back at read time.

Twelve points bought of token savings is a bad trade for a product whose claim is recall, so the shorthand was demoted rather than deleted: compressed entries survive as a ranking boost — a second signal that helps decide which verbatim notes surface — and are never the source of truth for anything. The verbatim note is what memory holds; the compression only helps find it.

The demotion generalises better than the dialect does. A compressed representation earns a place as an accelerator, and has to keep earning it as an authority — and the only way to know which side of that line yours sits on is to measure the recall cost, because the failure is silent: compressed memory does not error, it just answers a little worse, forever, in ways no single answer reveals.

Whose memory it is

There is a reason beyond engineering to keep the decomposition legible, and it is the difference between a memory and a profile. Everything above is the user's. In the product, the stores are not an internal diagram — they are browsable places: the map of filed notes, the fact graph with its timeline, each agent's diary, the conversation search. "What does it know about me?" has a different answer per store — what has been observed, what is asserted as fact, what each agent learned, what was said — and a person can open each and look. A single opaque memory blob could not offer that, not because the UI would be hard, but because there would be no structure to show. The decomposition is what makes the memory inspectable, and the inspectability is a feature we would now not trade even if a unified store appeared tomorrow.

So when someone asks what memory system this is — one store's name, expecting a product — the answer is that memory here is not a component at all. It is six stores and the discipline that composes them: the pre-pass that stitches the union, the thresholds that keep the meaning side honest, the canonicalisation that keeps the keyed side findable, the measurements that decide what is source of truth and what is merely an accelerator. Any one store is replaceable. The composition is the product.

Postscript, August 2026. The family grew within the week, in exactly the pattern evidence one predicted: the documents gained their own search-by-meaning — a chunked body index under a locally-run encoder, fused with the keyword index rather than replacing it, and deliberately not wired into the unprompted-recall path. New capability, new index, nothing transplanted, and the push/pull line held. Why that index is excluded from unprompted recall — and what a document has to do to cross the line — became its own entry. The compression dialect remains demoted, and remains unmonitored on real user palaces, which is an honest gap: the twelve points were measured on a benchmark, and nothing yet watches for the same tax appearing in the wild.

Not because of the answer — the answer was a sentence. The cost was everything that travelled with those four characters: the standing machinery a capable assistant carries into every turn — the shared platform instructions, the agent's identity, and above all the schemas of every tool it might use, two hundred and three of them, about a quarter of a million characters of JSON — written into the prompt cache at cache-write rates because a fresh conversation starts cold. Measured properly, our cold prompt floor stood at 122,000 to 163,000 tokens depending on the depth level, of which the tool block alone was fifty to sixty-five thousand.

This is the tax we had not priced in when we sketched an agent product: everything that renders before the user's first word is paid for on every turn, for the life of the product. Warm turns pay it at the cache-read discount; every new conversation, level switch and cache expiry pays it in full. A capability you add "for free" — one more tool, one more instruction block — is a standing charge against every user's every message. So this phase's work was to start treating the prompt as what it economically is: a budget, with line items, measurements, and an owner.

Measure with the meter that bills you

Rule one, before any optimisation: no estimates. Token counts are tokenizer-specific and intuition about them is reliably wrong, so every figure in this phase comes from the model API's own token-counting endpoint, run against the real built prompt and the real tool definitions — the same arithmetic that prices the request. It costs nothing to run and it converts an argument about what "feels heavy" into a sorted table of what is. The first table's headline was blunt: the single largest line item was not prose at all but the tool schemas — the API contracts themselves, which no amount of description-tightening touches (we measured trimming descriptions: under 8% of the block; the weight is the schemas).

Two hundred tools, most of them asleep

The assistant's breadth is the product — a conversation can turn to dashboards, documents, media generation, any of a long tail of connectors — and breadth was exactly what the budget was buying at full price on every "hello". The fix is the model API's deferred-loading mechanism, which decomposes "the model can use this tool" into two properties we had been conflating: registered and rendered. A deferred tool is registered — fully callable — but not rendered into the context; it costs approximately nothing until needed. A small resident search tool lets the model discover deferred schemas by name pattern, server-side, mid-turn; and the discovered schemas are appended after the cached prefix, so discovery never invalidates the cache it just benefited from.

The policy question — which tools sleep? — matters more than the mechanism, and ours is three explicit buckets with a deliberate bias. Resident: every interactive panel (a consent card must never depend on a search), the daily drivers (files, mail, calendar, memory, web), and the gateway tools that skills route through. Deferred: the long tail — the creative studio's dozens of tools, dashboard and dataset authoring, document tooling, the low-frequency connectors — all of them families that a governing skill or prompt names literally, so a regex search finds them the moment a flow needs them. And the bucket that keeps the system honest: anything unclassified stays resident and fails a CI test, so a new tool cannot silently join the deferred tail (a behaviour risk) or silently bloat the floor (a cost regression) — someone has to file it, on purpose, in a reviewed change.

Two scope decisions bound the risk. Deferral applies to interactive chat only — an unattended run gets the full rendered set, because a scheduled dashboard refresh must never fail on a discovery miss with nobody watching. And a single environment flag reverts everything to fully-rendered, because a cost optimisation that cannot be turned off in one move during an incident is itself a risk.

Measured effect, same real-token methodology: the cold prompt fell just over 40% at every depth level — 122k to 72.5k tokens at the fast level, 163k to 97.4k at the deeper ones — with 134 of the 203 floor tools deferred, and warm-cache reads scaling down identically. The four-character test message's write cost dropped proportionally. Nothing about capability changed; the toolbox simply stopped charging rent on drawers nobody opened.

Keeping it warm while someone is around

The most common avoidable cold write was mundane: a user reads a reply, thinks for eight minutes, answers — and the cache TTL lapsed in the gap, so their next turn re-writes the whole prefix. The fix is a demand-gated keep-alive: after each interactive turn, a debounced timer fires a one-token request with a byte-identical prefix just inside the TTL — a pure cache read that refreshes every entry's clock. The economics are lopsided in the right direction (a fraction-of-a-cent tick against a ~$0.30 rewrite, roughly twelve to one), and the gating is the design: a real turn resets the budget, a tick cap stops warming about nine minutes after the last human action — matching the pod's own idle lifetime — and the spend lands on the platform's internal ledger, never a user's. No cron, no round-the-clock warming, no spend without plausible demand. Warming one user's prefix also keeps the shared head warm for every same-model user, a free externality of the layout above.

The test that makes editing the prompt a decision

The quietest artifact of the phase may outlast the rest: a golden test that fails whenever the shared prompt's rendered bytes change. It sounds bureaucratic and it is the opposite — it is the budget acquiring an enforcement mechanism. The shared block is identical for every agent and cached across every conversation; a casual edit to it is simultaneously a cost change for every user's every turn and a cache invalidation for the whole fleet at deploy. The test converts "someone tweaked a sentence" into a visible diff someone must deliberately accept — the same move as the unclassified-tool check, applied to prose. A budget without a gate is a graph you look at sadly once a quarter. Both of ours now have gates.

What transfers

Treat the standing prompt as a budget line, owned and measured — with the model API's own counting endpoint, never estimates, sorted into a table before anything is trimmed. Split registered from rendered and defer your long tail behind discovery, with the interactive-only scope and a kill switch. Lay the request out coldest-first and spend cache breakpoints like the scarce resource they are; keep every volatile byte behind the last one. Warm on demand with a cap, never on a schedule. And put a failing test on anything whose cost is paid by everyone — because the prompt only stays a budget while changing it feels like spending.

Postscript, August 2026. A month later a fuller audit re-measured everything and delivered two corrections we value more than the original wins. First: the per-turn spend was hiding in plain sight — the small uncached dynamic block, ~7,600 tokens, costs more per turn than the entire ~68,000-token cached prompt behind it, because uncached tokens bill at ten times the cache-read rate. A third of per-turn prompt spend from five percent of the tokens; every future optimisation now sorts by cached-versus-uncached first and size second. Second, a documentation claim died on contact with the code: we had described the tools array as broadly shareable across users, but connector tool families render conditionally on connection state — so the array is effectively per-user, and cross-user cache sharing is far narrower than the design notes claimed. The audit caught our own doc contradicting our own code, which is the argument for re-running audits at all. The one-hour cache TTL shipped once billing normalisation dissolved its fairness blocker, putting the keep-alive warmer into honourable dormancy — it re-arms automatically if the TTL ever drops back, which is what a good mechanism does when its moment passes: waits, instead of leaving.

The bad answers form a neat triangle. Pre-authorise the worst case per message and the product feels like a taxi meter bolted to a conversation. Cap the output to bound the cost and you truncate answers mid-sentence — breaking the product to protect the margin. Go flat-rate unmetered and the heaviest users are subsidised by everyone else until adverse selection finishes the job. This entry is the machinery we built between those corners, and the week the credit system was made honest.

Meter the physical quantity; derive the money

The foundation decision: what gets recorded is the physical quantity — tokens, exactly as each model provider's own accounting reports them per turn — and money is always a derivation from that record, via a dated rates lookup. Cost per turn is therefore exact, not estimated: deterministic arithmetic on the counts returned with the turn, written as a per-turn audit entry in Firestore (attributed to the session and the agent that ran it), folded into a per-day rollup by atomic increment, and summed into a lifetime total. The rollup layer exists because time-series questions should never require scanning an audit trail; the audit trail exists because "why was yesterday expensive?" deserves a per-turn answer.

Storing quantity and deriving money buys the property that has paid for itself repeatedly: prices change, and records do not have to. When a rate moves, the lookup moves; when a historical figure needs recomputing, an idempotent backfill re-derives money from stored tokens without touching a single count. The failure mode it doesn't automatically buy — a quantity with no price row at all — gets its own section below, because it bit us.

Gate at the boundary; never truncate the work

Where does enforcement live, given that cost arrives after the fact? At the turn boundary, and only there. Before a turn starts, the gateway checks the balance; a turn that begins is allowed to finish, always — an answer is never cut off mid-stream because a meter ticked past zero somewhere in its middle. The overshoot this permits is bounded by a single turn's cost, and we absorb it, because the alternative is a product that stops mid-sentence, and a product that stops mid-sentence has communicated something about itself no refund repairs.

For users who opt in, exhaustion does not even surface: an automatic top-up charges a fixed increment through Stripe inline — an off-session payment, before the request is forwarded — and the conversation continues with no seam. The control that keeps that safe is a user-set monthly cap — and the cap's scope is a small design decision we got wrong before getting right: it bounds out-of-pocket automatic charges only. It does not count included credit, and a deliberate, explicit one-time purchase bypasses it — because a cap governs automation, not intent. A person clicking "add credit now" is not a runaway process, and a limit that blocks them anyway teaches people to disable limits.

What a credit has to mean

The week this entry is pinned to, we fixed a dishonesty we had shipped by accident. Purchased top-up credit was implemented as a per-period counter, zeroed at every renewal — meaning credit a user bought on day 29 quietly evaporated on day 30. Nobody designed that as a policy; it fell out of an implementation choice, which is exactly how products acquire dark patterns: not by malice, but by counters that reset. Expiring purchased credit is the gift-card move that consumer protection exists to police, it contradicted our own published no-dark-patterns position, and it was inconsistent with our other wallet, which had always persisted.

So a credit became a wallet: purchased credit never expires. It survives billing rollover, plan changes, and cancellation — after cancelling, the balance stays spendable on the free tier, because the plan bought the ceiling and the top-up bought tokens, and those are different purchases. Unspent credit is refundable on request. Consumption follows a fixed order — included allowance, then gifted credit, then the wallet — so the most-perishable credit is always spent first and the user's own money last. And the migration mattered as much as the model: converting the old counters to true remainders had to be done carefully and idempotently, because the naive conversion would have resurrected credit users had already spent — over-crediting as the cost of ending under-crediting is not a trade, it is a second bug.

A hard stop is a promise

When credit is gone and no top-up is configured, the product stops — a clear gate, a plain statement, a path to continue. It does not degrade quietly: no silent switch to a thinner model, no shortened answers, no throttled memory. The stop is the promise, and its value is exactly the trust it protects: every answer this product has ever given was produced at full capability, so no user ever has to wonder whether a disappointing reply was the product or the meter. A quality cliff you can see is a paywall; one you cannot see is a lie about what the product is.

The same promise, made from the platform's side, produced the phase's best war story. Cost being a lookup means a model id with no rate row values work at zero — and when a new model generation arrived without its row, one of our cost surfaces did precisely that: tokens recorded faithfully, cost silently flatlined, and the books were wrong for days before anyone noticed, because nothing fails when you undercharge. The fix has three layers, in escalating bluntness: a tripwire log on any rate miss with non-zero tokens; the idempotent backfill that repaired history from stored tokens once the row landed; and — the deliberate one — a fail-closed preflight: a turn arriving on that surface with a model that has no matching rate is now refused, loudly, before any answer streams, until someone ships the price. Blocking real usage over a missing table row is a heavy trade and we chose it on purpose. A system that would rather refuse work than misprice it is making the same promise to its own books that the hard stop makes to users.

What transfers

For anyone metering LLM-shaped work: record the physical quantity exactly and treat money as a derived view, so price changes and corrections never rewrite history. Enforce at work boundaries and let in-flight work complete — bound your write-off at one unit rather than truncating the product. Make purchased credit a wallet with the semantics a stranger would call fair, because the counter that quietly resets is how decent products end up with gift-card patterns. Disclose the costs the user controls before they spend; absorb the costs only you control. And fail closed on a missing price — undercharging is the failure mode nothing alerts on, and the books it quietly ruins are your own.

Postscript, August 2026. Three days after this entry, the cache seam closed: a provider can bill cache writes at a premium over ordinary input, and whether a turn hits a warm or cold cache is a function of our scheduling and traffic, not anything the user chose — so the billed figure now charges cache writes at the plain input rate and the premium is absorbed as platform cost. A user should never pay more because our cache went cold. The wallet semantics held and spread: the same never-expires, reconcile-at-rollover pattern now backs gift credit and the org pool, and redeemable credit codes were later built on the same grant primitive rather than a new one. A third cost rail arrived — external connector actions with real per-call supplier prices — and shipped as exact pass-through at cost, with the ambiguity in its rate detection deliberately biased so any misclassification undercharges us rather than overcharges the user. And the whole system went through two adversarial launch audits, the second of which found real defects that were fixed the same day — which we mention not for the count but for the posture: a billing system is the one part of a product where the audit finding you fix quietly today is the churned customer or the incident write-up you do not publish next quarter.

The theorem that places everything

One argument did more work than any other this phase, and it is worth stating as the theorem we treat it as: you cannot defend against prompt injection with the intelligence that injection compromises. Every tempting soft defence — asking the model to double-check, prompting it to be suspicious of embedded instructions, having it review its own plan for safety — has the same failure built in: under a successful injection, the judge is the hijacked party. Asking the possibly-compromised model "is this action safe?" is asking the attacker to grade their own work.

So the defences divide into two layers with named blind spots, and the design discipline is to place each exactly where the other fails. The model's own judgment is genuinely strong at reading intent and recognising the benign case — and that strength is spent entirely on friction reduction: not pestering you about obviously-fine actions. The security guarantee lives only in the other layer: deterministic gates, coded outside the model, that hold regardless of what the model has decided. A rule the model cannot reason past is dumb — it cannot tell a good send from a bad one — but it cannot be talked out of anything, and against an adversary whose whole attack is talking, dumb is the feature. The standing rule that fell out is short enough to carry anywhere: never ship a control whose only enforcement is "the model will decide not to."

The gate sits at the exit, not the entrance

Knowing you need deterministic gates does not tell you where to put them, and the intuitive answer — gate the dangerous reads — turns out to be wrong in an instructive way. Injection enters through reads; but by the time you could prompt "allow the agent to read this email?", the malicious content is already fetched, and the user, who cannot see inside it, grants reflexively. Gating reads buys ceremony, not safety. Harm does not exit through the read. It exits through the write that follows — the send, the post, the file pushed somewhere — and that is the one place a compromised agent must pass through code.

Even "gate every send" is too crude, and the case that proves it is the most ordinary one: "email me a summary of this." An agent sending to your own address cannot exfiltrate anything — there is no leak in mailing you your own data — and a gate that fires there teaches users to click through gates. So the gate keys on what we came to call the destination's trust delta: zero for yourself and for destinations you have already approved for this agent — silent, frictionless; positive for a novel external destination — which is precisely the action a hijacked agent takes, and precisely where the model's judgment cannot be trusted. The approved-recipients list is therefore not really a recipients list. It is an egress allowlist: the set of destinations for which the deterministic layer has permission to stay quiet.

Consent that means once when it says once

Deterministic gates are only tolerable if the asking is honest, and there are two familiar ways for it not to be: either an interrogation at setup about doors the agent may never open, or a nag on every action until approval becomes muscle memory. Both destroy the information content of the question. Ours is built on one rule — if an agent needs a grant it does not have, it asks; always; everywhere — and three properties that keep the asking meaningful.

The requirement is declared, not discovered. A platform-owned table lists exactly which tools require a grant and of what shape — who it may email, which channels it may post to, which repositories, which folders. Presence in the table is the gate; a tool absent from it is free. There is no per-tool judgment call at runtime and no way for a new outbound tool to ship ungated by oversight, because the table is the registry the tools live in.

The answer is remembered, per the thing it was about. A grant is stored per agent under a key scoped to what was actually decided — this connector, this workspace, this tool — so the question is asked at the moment of first genuine need, on whatever surface the agent is running (inline in chat; pausing a live run; or, for a question that arises at three in the morning, as an inbox item waiting when you wake). Then it is not asked again. Whether something has been decided is derived from the existence of the stored answer — there is no separate "asked" flag to drift.

A refusal degrades loudly, not silently. An action outside a grant does not quietly fail or quietly proceed — it becomes a review item: "I tried to post this to a channel that isn't on my list — review and send?" The boundary stays a boundary, the work survives, and the user sees exactly where the line is drawn, which is the transparency half of the design: gates you can see are gates you can trust.

The unglamorous audit underneath

The rest of the phase was the boring enumeration that security actually is: list every way text can enter the model's context, and ask who controls this? Several answers were unflattering. The chat API accepted a field letting the client supply a fabricated prior assistant turn — text delivered to the model as words it had already said, priming everything after; the classic jailbreak shape, sitting in our own request schema as a convenience feature. Removed outright. The system prompt had guardrails but no confidentiality clause, so "what are your full instructions?" got a helpful summary; sealed. Client-supplied context fields — like the path of the file a user has open — live for one turn only, and validating them against safe path patterns is the next item, because any string a client controls is a string an attacker might. And identity is never among the things a client asserts: who is asking, and with what standing, is stamped by the gateway after it verifies the caller, with any trust-bearing claims arriving from outside stripped at the door. Every one of these is small. Injection defence at the plumbing layer is the accumulation of small refusals to trust a field because it is usually well-behaved.

What transfers

For anyone building an agent that touches real accounts: assume the compromise, and spend your architecture accordingly. Put the deterministic controls at egress, keyed on destination novelty, and let reads stay free — gating the entrance is theatre, gating the exit is defence. Give the model's judgment the job it can hold (suppressing friction on the benign case) and never the job it cannot (deciding, while possibly hijacked, whether it is hijacked). Make every consent a remembered fact with a scope, asked once at genuine need, and make violations visible rather than silent. And write down the risks you are consciously accepting, in a register, with dates — because the difference between an accepted risk and an oversight is only ever the documentation.

Postscript, September 2026. The theorem has not been dented, and the machinery around it grew in the directions the residues note pointed. Days after this entry's date, a full review of the other boundary — not what the agent reads, but whose permissions it acts with — ran adversarially against the shipped code and found real findings; that review, and the leak it caught, is the next entry. The consent model's degrade-to-review pattern has since carried into every new outbound surface, and every reach into sensitive data now leaves a content-free audit mark in a retention-locked Cloud Logging bucket, so "what has it looked at?" has an answer that does not depend on anyone's memory. The fetch tool now has its gate: a URL that carries data to a site the user has not pasted or approved is treated as the send it is — asked once per site, remembered, and never widened from a card — while the exact link the user gave stays free. The accepted-risks register has grown, which we count as success: an accepted risk is one that has been looked at.

Every fact written into our graph mints its key from whatever name string it was handed. Write about someone by their first name today and their full name on Friday and the store now holds two subjects. Nobody decided that; nobody would. It is what an exact-keyed store does under ordinary human naming variance, one write at a time, and the failure it produces is the quiet kind: a lookup that returns nothing, from a store that is full of the answer. We measured the worst case in an earlier entry — one person split across four keys, and a company whose most natural query normalised to a key that did not exist while more than twenty facts sat under three adjacent spellings.

The tempting fix is a string rule: lowercase everything, strip the punctuation, collapse the variants. It cannot work, and the reason it cannot work is the interesting part. Some things that share a name really are different things. In our own store, the company, the long-running dispute about the company, and the company's registered legal entity are three genuinely distinct subjects wearing one name root — and a normaliser aggressive enough to heal the person split across four spellings will also fuse those three into one, which does not merely lose precision, it manufactures false facts. Merge two near-namesakes and the store now asserts things about a subject that never existed.

So the squeeze is this: under-merge and the store keeps returning zero for questions it can answer; over-merge and it starts answering questions wrongly, with confidence, forever. There is no threshold between those two that a string rule can find, because the difference between a variant spelling and a different thing is not in the strings. It is a judgment about the world.

A judgment pass with machinery around it

So entity resolution falls to something that can exercise judgment, wrapped in machinery that assumes the judgment will sometimes be wrong.

A model reads the full list of subjects — key, display name, how many facts each holds — and proposes clusters: groups of keys that are clearly the same real-world thing, each with a chosen canonical key and display name. The prompt is conservative to the point of timidity. Do not merge distinct-but-similar things; leave anything that looks like a file path alone; skip singletons; when in doubt, propose nothing. An empty answer is a valid answer and a common one.

Then the machinery takes over, and none of it trusts the proposal. The store — a SQLite database — is backed up before a single row moves, and the backup stays on disk even when everything succeeds. The merge runs as one transaction — every fact's subject and object references rewritten from variant keys to the canonical one, orphaned variants removed, exact-duplicate facts collapsed — and an integrity check on the far side aborts the whole thing, backup intact, if the store comes out anything less than clean. Re-running after a clean pass finds nothing to merge and changes nothing. And the run returns a full audit: what merged into what, how many rows moved, where the backup lives, plus the model's own reasoning — returned even when it proposed no merges, because why nothing merged is information too.

The division of labour is the transferable part. The model contributes the one thing rules cannot — knowing that a person's four spellings are one subject and a company's three near-namesakes are three — and contributes nothing else. Whether the operation is safe never depends on the model being right; it depends on backups, transactions and integrity checks, which do not have judgment and do not need any.

The assumption that did not survive reading the source

The filed-notes side of memory has the same disease in a different organ. Notes are filed into named areas and topics, the names are stored verbatim, and over months the map grows near-duplicates — the same area under a lowercase-and-underscores spelling and a Title Case one, side by side. Our working assumption was that this fragmentation was hurting search, and the fix was urgent for that reason.

Then we read the engine's source before building, and the assumption was wrong in a useful way. The area and topic labels are stored as metadata on each note; what gets embedded for semantic search is the note's content, only ever the content. The recall pipeline searches across everything without filtering by area at all. So duplicate spellings were doing no damage whatsoever to retrieval — a search finds the note identically under either spelling of its area, because the spelling is not in the vector.

What the duplicates actually damage is comprehension. The map the user opens shows two areas where there is one place; the cheap orientation glance the agent takes at the start of retrieval reads the same fragmented list. Real costs — but presentation costs, not recall costs, and the honest re-scoping changed both the priority and the design. The backfill that merges variant spellings ships as map maintenance, not as a search fix, and it rewrites labels only: nothing is re-embedded, so the vectors — and therefore every ranking — are byte-identical before and after. A change that provably cannot move search results is a change you can run without a search evaluation.

And because a backfill alone would re-fragment with the next write, the durable half of the fix sits at the boundary we own. We do not own the memory engine; we own the wrapper every write passes through. So the wrapper now snaps an incoming area or topic name onto an existing spelling when the two differ only by case or separators — choosing the most-populated spelling as canonical, and letting the write through untouched if the taxonomy read fails, because a filing nicety must never block a memory being saved. The map converges toward one spelling per place without the engine changing at all.

Spelling is not meaning

One more place the naming problem surfaces, and it forced a choice that looks backwards until it doesn't. The graph screen needed search — a person hunting for an entity should not need to know which of four spellings the store filed it under, or spell an accented surname correctly. The obvious modern answer is embeddings; everything else in this system searches by meaning.

We used edit distance instead — a plain string-similarity matcher from Python's standard library, combined with substring and per-token scoring. Because a proper-noun search is not a meaning problem. The user typing a misspelled first name does not want entities that are semantically like that person; they want the entity whose spelling is nearest. Vector similarity is the wrong instrument for that: it clusters by what things are, and two unrelated people's names can sit closer in meaning-space than one person's name and its own typo. Measured on our store, the misspelling of a first name scores 0.77 against its target and a four-letter fragment of another scores 0.89 against its own — comfortably above the 0.55 floor that keeps weak cross-matches out.

The asymmetry: only the human got this. The screen can now find a fragmented or misspelled entity that the agent's own graph lookup — still exact-keyed — continues to miss. Until that closes, one operational rule stands everywhere the graph is consulted: a keyed lookup that returns nothing proves nothing. A miss means unknown, never absent, and any code or prose that treats graph silence as evidence of absence is wrong by construction.

Reorganising a memory while it is being used

The spelling merge turned out to be the small case of something bigger. Left to accrete, the map does not just duplicate names — it sprawls. Every agent files each note into whatever area felt right in the moment, and months of that produces a hoard of half-named corners only a machine could love. People do not hold their lives that way; they hold them in a dozen understood places.

So the merge grew up into a full re-taxonomy pass — the product calls it dreaming, and the name is doing real work: a quiet pass that gathers the scattered notes and re-settles them into life-areas a person recognises, previewed as a diff before anything moves, reversible after. The interesting engineering is not the reorganisation. It is the contract that makes reorganisation safe to offer at all, in a product whose headline promise is recall:

The pass is metadata-only by construction, so however much it rearranges, recall is provably unchanged. Not tested-and-found-unchanged — provably, from the property established above: search never reads the labels the pass rewrites, and the pass never touches the content search reads. The two operations are disjoint at the storage layer, so no volume of re-filing can move a single ranking. Alongside that, the pass never enters a private agent's sealed area — a fenced agent's notes stay exactly where its permissions put them — and anything that would touch content (merging near-duplicate notes, summarising) is explicitly deferred behind a recall evaluation gate it has to pass first.

That is the shape worth taking away, because it applies to any long-lived store that needs maintenance while in service: divide every maintenance operation into the part that is provably inert to reads and the part that is not, ship the first freely, and gate the second on evidence. A reorganisation you can prove safe needs a preview and a backup. A reorganisation you can only test safe needs an evaluation harness and a much better reason to exist.

Postscript, August 2026. The judgment-plus-machinery shape held, and the dream pass now runs as one combined cycle — merge the spellings, then re-settle the areas — available to every user, with the model's reasoning trace kept admin-side. What has deliberately not moved: the agent's graph lookup is still exact-keyed, the bridge that would let semantic search hand the graph its keys is still unbuilt, and so "a miss proves nothing" remains a standing rule rather than a closed chapter. It resurfaced within weeks in a different subsystem — an agent asserting something was absent on evidence that could not prove absence — and that incident got its own machinery, and will get its own entry.

And the memory has to grow. That is the product. Every conversation, every filed note, every fact learned about a person's work adds to what the assistant could know. So the two lines are heading in opposite directions: the store grows without limit, and the per-turn budget must not. Get that wrong in the obvious way — retrieve more as there is more to retrieve — and the economics run backwards: the longer someone uses the assistant, the more every message costs, and your cheapest user is a stranger. Get it wrong in the other direction, retrieving less to protect the budget, and the memory quietly stops being consulted, which in a memory-first product is the failure the whole thing exists to prevent.

The constraint we build against is stricter than "grows slowly": the cost of remembering has to stay flat as the memory grows. A year of accumulated context and a first week of it should cost the same per message. Everything in this post is the machinery that makes that true, and the honest edges where it is not yet proven.

A place, not a pile

The naive shape for an assistant's memory is a pile — an append-only log, injected wholesale, or trimmed to the most recent slice. A pile degrades as it fills. Every addition makes every future read slightly worse: more to scan, more near-duplicates, more chances for something adjacent-but-wrong to outrank the thing that matters. A notepad is a fine memory at ten pages and a liability at eight hundred.

Ours is organised as a place. Filed notes live spatially — areas for the domains of a person's life, topics within them, individual notes within those — and alongside them sits a separate store of structured facts: typed statements about named people, companies and projects, each carrying the time it became true and the time it stopped being. You do not read a place cover to cover. You navigate it.

Navigation is what makes the cost story work, because it happens in layers, and each layer is materially more expensive than the one before:

1. Orientation. What exists — the areas, how full each one is. A directory in the lobby. Near-free.
2. The semantic sweep. A search by meaning across the filed notes, returning ranked snippets. Cheap.
3. Keyed facts. An exact lookup of the structured facts about a named entity, including as they stood at a past date. Cheap, and precise.
4. The graph walk. Following connections outward across areas — used when a relationship is suspected but the path is unknown.
5. The full fetch. An entire note, or the complete timeline of an entity. The expensive end, reached only once the earlier layers have named the target.

Most turns never leave the second layer. That single fact is the economics: the store can grow past eight hundred filed notes — ours has — while what a typical turn actually spends is one orientation-level glance and a few ranked snippets.

The turn's budget is fixed by construction

Whether the assistant looks at all is not left to its discretion — we covered that decision, and the measurements that forced it, in an earlier entry. Before the model answers each turn, a small planning pass reads the conversation and formulates what to look for, and the runtime executes the sweep and the keyed lookups itself. What concerns us here is the other half of the design: how much that guaranteed step is allowed to bring back.

The answer is: a fixed amount, regardless of how large the memory is. At most three snippets per search query and six in total, each truncated to a four-hundred-character excerpt; at most a dozen facts per named entity. Those caps are constants. When the memory doubles, recall does not return more — twice as many candidates compete for the same six slots, and the competition gets harder, not the context bigger.

This was a genuine design decision rather than an obvious one, because the alternative has a respectable argument: a richer memory could justify richer retrieval, and a fixed budget will eventually leave good material on the table. We chose the fixed budget anyway, for the reason at the top of the post — a per-turn cost that scales with corpus size, however gently, converts your most engaged users into your most expensive ones. If the caps prove too tight, the evidence will show up as misses in the evaluation set, and raising a constant is a one-line change. The reverse mistake, an unbounded budget discovered in a bill, is not.

Paying for a subject once

The caps bound a single turn. The next leak is across turns, and we shipped it before we saw it.

A conversation about one subject runs the same lookups again and again. Ask about a person, and the sweep and the keyed lookup both run and both return. Ask a follow-up, and — in the first version of this system — everything ran again: same queries, same round trips, same results, injected fresh and then discarded. The retrieval was ephemeral, handed to the model for one turn only. The visible symptom was worse than waste: the assistant could ask "did you mean X?" about a fact it had retrieved two turns earlier, because from where it stood, it had never retrieved anything.

We considered three fixes. A result cache keyed by query — cheapest to build, and it repairs the latency without repairing the amnesia, since the model still never sees yesterday's results. A stronger instruction telling the model not to re-search — unenforceable, because the model is not the one issuing these lookups, the planning pass is. A separate tracking field listing what had been queried — workable, and redundant the moment we noticed the third option contained it.

The third option: make retrieval part of the conversation record itself. Each turn's recall now lands in history as a lookup that visibly happened — the query, and what came back — exactly as if the assistant had chosen to search. Two things fall out. The model retains what was found, across turns, because it is simply in the conversation. And the planning pass can be shown what has already been fetched and emit only the delta — a subject retrieved this session is not retrieved again, and when the plan comes back empty, no lookup fires at all.

Within a rolling window, a subject is paid for once — and the cache is the transcript. Nothing was added to hold the remembered results: the conversation, which the model reads anyway, is the store, which is why the model and the deduplication logic can never disagree about what has already been looked up.

Permissive on purpose

One piece of the machinery decides more about felt quality than any other: the floor under the semantic sweep. A search by meaning always returns something — its nearest neighbour, however far away that is — so every hit is checked against a minimum similarity before it reaches the model, and where that floor sits is a choice about which failure you prefer.

We probed the store before choosing. When the answer to a query is genuinely present, it scores well clear — similarity of 0.5 and up. When the answer is not stored, the nearest wrong thing tends to land around 0.3: close enough to look plausible, which is precisely the material you do not want injected under an implicit "this is relevant" label. The floor sits between those bands, and it sits low in the band on purpose. In a product whose entire claim is recall, a miss costs more than mild noise: irrelevant context is a small tax on one answer, while a miss is the product visibly failing at the one thing it promised.

That number is a first setting, not a calibration. We swept the threshold against a labelled evaluation set and the sweep confirmed the knee where we had guessed it — but the set is fifteen cases against a development corpus, and the current scores are 12 of 14 on correctly deciding whether to retrieve and 4 of 6 on surfacing the right note when one exists. Those are sanity-check numbers, not tuning-grade numbers. What we hold onto is the discipline rather than the value: the telemetry that makes the distributions visible shipped before any knob was turned, every threshold is adjustable without a redeploy, and the evaluation set — not taste — is what will move the floor. Measure before you turn a knob, and be honest about how small the measurement still is.

What flat buys

Put the three mechanisms together — a fixed injection budget, layers that keep most turns at the cheap end, and a transcript that stops the same subject being paid for twice — and the property at the top of the post holds: per-message cost does not track the size of what is remembered. The store grows; the bill does not. An assistant that has known you for a year answers "morning — anything I should know today?" for the same price as one that met you on Tuesday.

That is what makes a real memory an ordinary feature rather than a luxury one. The alternative designs all work in a demo, because a demo's memory is small; the differences only compound where a product lives, in month six, in the eight-hundredth note. The transferable version, for anyone building retrieval into a long-lived system, is the constraint rather than our mechanisms: decide the per-turn budget first, make it a constant, and force every growth curve in the system to negotiate with that constant — because any cost line you let scale with corpus size is a tax on exactly the users who trust you most.

Postscript, August 2026. The shape held; two edges moved, both in instructive directions. A real ninety-minute session later hit the model's context ceiling, and what had filled the window was largely recall and tool machinery riding along in history — the cost of making retrieval persistent, arriving late. The fix prunes recall pairs older than the dedup window from what the model is shown (stored history untouched), so context retention and re-query suppression now share one window, pinned by a test that fails if either side's counting drifts. And the planner's "do not re-query" instruction turned out to leak — a subject was re-queried inside the window, byte-identical results — so suppression is now enforced in code after the plan comes back, with the prompt rule kept only as a token-saving first pass. A rule you can enforce structurally should not stay a request. The threshold floor is unchanged, still permissive, still waiting on a bigger evaluation set to earn a real calibration.

What it earns by getting that right is the reason to put an agent in a channel at all. A team that tags one assistant into its shared work gets a teammate whose progress everyone can see and whose memory belongs to the room, instead of five people briefing five private tabs. The design has three parts, and they are the three things a person does without noticing: know when you have been asked, know how long a conversation you were drawn into stays open, and know when to stay out. The first is the easy half. The other two are where the design lives.

Tagged work, done in the open

The explicit case is the easy half, and its design goal is teammate, not tab. Someone writes @-the-agent with a task — pull last week's signups, draft the reply in this thread — and the agent acknowledges within seconds, then works asynchronously and in the open: a posted, updating checklist in the thread, progress visible to everyone, a terminal state everyone can see. The openness is the point of putting an agent in a channel at all — the alternative is each person briefing a private assistant from scratch, and the difference between "everyone has an AI tab" and "the team has a teammate" is precisely that the work, and the context, are shared.

Shared context is structural, not stylistic: memory is ringfenced per channel. What the agent learns in a channel belongs to that channel — a second person can follow up on the first person's task without re-establishing anything, because the room remembers, while cross-channel reads default off, because what a team discusses in one room is not ambiently available to another. The channel is simultaneously the addressing scope, the memory scope, and the governance scope (which tools it may use, what it may spend — an admin decides per channel). One boundary, three duties.

The follow-up problem

Then the hard half. Real conversation does not re-tag every sentence. Someone tags the agent, gets an answer, and replies "can you break that down by region?" — untagged, obviously for the agent, and a bot that ignores it feels broken. But a channel is also full of untagged messages that are not for the agent, and this is where the two ways of being wrong turn out to be different sizes.

A missed follow-up costs a re-tag. An answer to a message meant for a colleague costs the room's trust in the agent, and we treat it as the one failure the design must not commit: an agent that talks over people in a shared space has stopped being a teammate. So every threshold here is asymmetric, generous where intent has already been established and conservative where the venue is noisy.

The design resolves it with windows of established intent, two of them, deliberately different sizes. In a thread the agent has posted in, any participant's replies continue the conversation for twenty minutes with no mention needed — the thread itself is the intent signal; people who join a thread the agent is working in are, by the room's own social rules, talking to the working party. At the channel's top level, only the person the agent just answered gets a window, and a much shorter one — six minutes — because top-level chatter is far noisier and belongs to everyone. Outside any window, silence: an untagged message reaches no machinery at all.

One boundary fell out of the event model rather than the design, and we wrote it down as a decision instead of letting it pass as an implementation detail: the continuation windows exist in public channels only. The event subscriptions that feed them do not include private-channel traffic, so in a private channel tagging works but untagged follow-ups do not — and extending that would be a deliberate choice about listening in private rooms, to be made on purpose someday or never, not smuggled in as a scope tidy-up.

What transfers

Any agent entering shared space inherits this problem — a Teams bot, a shared inbox, a group chat — and the shape of our answer travels. Rank the failures first: in shared space, false positives (answering what wasn't yours) cost trust and false negatives cost a re-tag, so thresholds must be asymmetric. Make intent windows explicit — addressing is established by events (a tag, a reply, a thread) and decays with time and venue noise, and encoding that beats any per-message classifier. Put the prohibitions in deterministic filters and only the judgment in the model. And scope memory to the room, not the person — the room is what the participants share, and an agent whose memory leaks across rooms has turned the org chart into an ambient surveillance diagram.

Postscript, August 2026. The build landed through August, and two of its lessons were things no design document would have found. First, the never-answer-someone-else's rule needed a regression fix in exactly the place the funnel predicted: messages @-mentioning other users inside a live thread window had to be filtered before acknowledgement, not after — the check exists so a thread the agent shares with humans stays a place where humans can talk to each other. And second, an identity saga we did not see coming: the bot's display name is ours everywhere, but its @-handle is assigned per workspace, first-come — and one ordinary employee connecting their personal Slack account can claim the handle for the whole workspace long before the team bot installs, leaving the real agent as @ourname2 beside a dormant look-alike. The consequences became rules: never hardcode a mention-shaped string anywhere a user might type it or a model might echo it (a unit test now reads the source and fails on any such literal); resolve the real handle from the live installation when it genuinely must be printed; and detect look-alike name collisions from the workspace's current state, never inferred from the frozen handle. An agent's name, it turns out, is not something it owns. It is something the room assigns — which, for a chapter about learning to live in shared space, is almost too on the nose.

Which leaves an assistant with a bad pair of options. Treat the prose as prose, and something quietly repeatable dissolves at the end of every turn: the same statement gets fuzzily re-parsed next month, nothing can be appended to, sorted, totalled or charted, and "what did I spend on travel?" is answered by a model squinting at text it has read four times before. Or force the ceremony — put a table designer inside a conversational product — and violate the product's entire grammar, which is that you configure things by talking about them. The way out is the thesis of this entry: the schema is inferred at the moment the data lands, and structure is offered, never imposed.

Recognise and offer

The behaviour is a courtesy before it is a mechanism. When something table-shaped appears — pasted rows, a produced list, a file that is obviously an export — the assistant offers to keep it as a tracked dataset, and materialises nothing until the user says yes. A paste answered with a silent database write would be presumptuous; one answered with only a prose summary wastes the shape the data arrived in. The offer sits exactly between, and declining it costs nothing.

On assent, the inference machinery earns its keep. Delimited text is sniffed for its separator, parsed quote-aware, and each column's type inferred from what the values actually are — dates that behave as dates, amounts that sum. Clean files structure themselves in one pass; only genuine ambiguity comes back as a question, with the detected shape and sample rows shown for a one-tap confirmation. And before any ad-hoc schema is invented, a catalogue of canonical templates is consulted for recognised kinds — "start tracking my bank statement" yields date, description, category, amount, balance, the columns a bank statement has always had, not four creatively-named inventions that will differ from next month's four. Inference handles the novel; convention handles the known; the user handles neither.

One copy of the truth, wearing a friendly face

A kept dataset is stored as a pair addressed by one base path: an NDJSON file — one JSON row per line, the append-safe source of truth and the only place rows live — and a lightweight view document carrying the typed schema. The user is not meant to meet the pair: the view is what search indexes, never the raw row file, and the next build hides the row file from every listing so a dataset reads as one thing with one name. The two-file split is a storage decision, and storage decisions are not user-facing concepts.

The shape buys the property everything downstream leans on: appends never restart. "Add one more" appends a line to the same file — no new file, no duplicate dataset, no whole-file rewrite by a model that might race itself or mangle rows it wasn't touching. All mutation flows through a small deterministic tool family — define, append, upsert, read, import — so the record operations are code, and the model's job is deciding what to record, never reconstructing a file around it. Structured questions are then answered from the rows: filter, sort, aggregate — real operations over real values, not a fresh act of reading comprehension over remembered prose.

What already belongs to someone else

One behavioural rule guards the whole design against its own enthusiasm: don't fork connector-owned data. If a connected service already owns the records — contacts in a mailbox, deals in a CRM, workouts in a fitness service — then "keep a list of my contacts" must not quietly copy them into a dataset that will begin drifting from its source the moment it is created. The assistant binds live to the owner, or, when a frozen copy is genuinely what's wanted, creates one explicitly labelled as a point-in-time snapshot. A silent fork presented as truth is the worst artifact a data feature can produce, because it is wrong in a way that compounds: every chart built on it inherits the drift, wearing the confidence of structure.

The payoff for all this discipline lands in dashboards. Before datasets, a dashboard's refresh re-ran an agent gathering turn — a model invocation per refresh: token-billed, slow, and non-deterministic, capable of producing a slightly different dashboard from the same facts. A dashboard bound to a dataset refreshes by re-reading a file and re-applying a small declarative transform — group, sum, count, top-N — instantly, deterministically, for nothing. Six structural patterns cover what personal tabular data actually turns out to be — a ledger, a status tracker, a time series, an entity list, a catalogue, a key-value snapshot — and each maps to its natural widgets, so "put a chart on this" is a transform selection, not a creative act.

What transfers

For anyone building structure into a conversational product: put the schema step after the data, not before it — infer from what landed, offer rather than impose, and reserve the questions for genuine ambiguity. Keep exactly one copy of the rows and make every view a rendering of it. Give mutation a deterministic tool surface so the model decides content while code performs operations. Key your imports so refreshing data merges rather than multiplies. And respect prior ownership — the moment your structured copy of someone else's live data starts looking like the truth, it has started being a lie.

Postscript, August 2026. Three later chapters, each extending the same spine. The view document lost its last data-bearing duty within a day of this entry's date: an edit incident left a rendered table diverged from its row file, and the view was made schema-only — tables now render dynamically from the rows everywhere they appear, the row file dropped out of the tree, folder counts and search, and reading either half renders the same live table — deleting the drift class at the root rather than patching the editor that exposed it; the second copy of anything, we keep re-learning, is a liability wearing a convenience. Relations arrived, deliberately modest: a record can reference a record in another dataset, filters can follow one hop of that reference, writes can pass through it — and integrity violations warn rather than block or cascade, because the triggers that would justify a real multi-hop record store are named in the spec and have not fired. And provenance went cellular for research data: a value can carry its source, confidence and confirmation state, so a figure gathered from desk research graduates to confirmed on a call without its row being rewritten — a table where every cell can answer "says who?", which is what a table built from the world, rather than from a form, turns out to need. Aggregation grew methods beyond summing for the same reason: four mild days should not outrank one unbearable one, and a median tells that truth where a sum buries it.

The answer that has settled across the field, ours included, is LLM-as-a-judge: close the loop with models. This entry is in two halves. The first is what the pattern gives you, because its limits only mean something measured against what it does well. The second is the question it answers, the three it does not, and the week one of those three fooled us at the scale of an entire run.

What three models in a room can do

A scenario in our harness runs as three separate model processes. The agent under test runs on one of the tiers production routes to — one per run — with the real system prompt and the real tool surface. A user persona on a mid tier reads the scenario brief and the transcript so far and writes the next human message — one to four sentences, plain language, in character — turn after turn, until it decides the conversation is done. It pushes back, changes its mind, or declines when the brief tells it to; when the agent stages a tap-to-answer form instead of asking in prose, the persona submits the form in exactly the shape the production interface would. A judge on the strongest tier reads the finished transcript and scores it against the scenario's weighted rubric — pass, partial or fail per item, each with a one-sentence note citing the transcript, then a summary and a short list of recommendations — resolving to a green, yellow or red verdict. Every run writes its transcript, rubric table and the judge's reasoning into our document store as a permanent artefact, so a verdict from March can be re-read, and re-judged, in November.

Three things this buys that no other test in the pyramid can.

It finds behaviour that only exists under pressure. Onboarding carries a rule that the assistant names one connector and does not recite the catalogue. On a scripted path the rule held. When the persona pushed, the full list came out — a real breach, scored at 53 and marked genuine. No unit test pushes back. The send gate for outbound email showed the mirror image: the agent correctly refused a vague "ok, go ahead", and then refused an explicit confirmation too — a self-denial visible only across turns, and only because the persona, following its brief, insisted. A third scenario had the agent complete a multi-step task well and skip the plan and the title the platform expects around it: the outcome was right and the shape was wrong, which is exactly the distinction a rubric with weights can express and a pass/fail assertion cannot.

The reasons are worth more than the number. A score tells you a scenario got worse. The per-item notes tell you where, and the recommendations across a run tell you what kind of failure you have. Our first synthesis found that most of the reds against the agent-creation flow were compliance gaps against rules that already existed in the skill — forms not used, a retired parameter still being written — not rules that were missing. That reading pointed at a gate in the tool layer, physically refusing the parameter, rather than at more prose asking the model not to. A judge that only produced a number would have sent us to rewrite the prose.

It measures a trajectory, and it can compare. The scores live in a matrix — scenarios as rows, run dates as columns, cell values the day's median — because a single run is a snapshot and the object of interest is direction. And because the persona and judge stay fixed while the agent's tier changes, the same scenario on a stronger tier separates a reasoning-quality question from a feature question: a large gap says the problem is reasoning and belongs to the model decision; a small one says it is not, and belongs to the tools and the prompt.

The question the judge answers, and the three it does not

A judge reads a transcript and answers one question: was this a good conversation? It answers it well — better than any assertion we could write, on exactly the surface where assertions fail. But an agent's job is to change things outside the conversation, and once you say that aloud, three more questions appear that a transcript cannot settle:

1. Did the world change? The transcript shows what the agent said it did.
2. Does the boundary hold? The transcript shows how the agent phrased a refusal.
3. Does it happen at all? The transcript is one of the runs we chose to stage.

The rest of this entry is the first of these, because it is the one that fooled us this month, and a note on the other two, which by now we can state but have not yet built instruments for.

Did the world change?

The harness records each scenario through two independent instruments. The judge reads the rendered transcript — what a human reviewing the conversation would see. Alongside it, a deterministic extractor records what actually executed: real tool-invocation events, and a server-side snapshot of end state — did an agent record actually get created, did a preference actually get saved — taken from the system under test itself, not from the conversation. Outcome evaluation, the field would call the second one; the judge does trajectory evaluation. We built the second for convenience (machine-readable outcomes for the report), not suspicion.

The June 20th run: sixty-two scenarios, whole flows collapsing to red — agent-creation scenarios scoring 13, 15, 16; onboarding flows that had scored 89 and 94 three weeks earlier landing at 9 and 10. Read as product signal, this was a catastrophic regression demanding an emergency week of prompt and skill fixes.

The piece of evidence that unlocked it was not a red score. It was a green one. A scenario testing that a connector prompt fires the right tool had scored a perfect 100, and its own judge note recorded a contradiction: the deterministic line said no connect call had fired, the transcript showed one plainly, and the judge had chosen to score on the transcript. Beside it, seventeen of seventeen agent-creation scenarios had produced no agent at all — every end-state snapshot empty — and every deterministic tool summary across the behavioural flows read none.

The only way both observers were right: the tool call in the transcript was text. The agent under test had stopped executing tools and started writing tool calls as prose — fluent, well-formed, plausible prose. In one scenario it improvised an entire parallel tool API that has never existed in this system, five convincingly-named operations, printed as a neat block and executed by nothing. In others the harness engine's own base persona bled through underneath our prompt, and the agent introduced itself as a general software-engineering assistant. The score pattern across the run was now fully explained by one mechanism: scenarios judged on what the agent says or refuses survived — the injection-resistance and confidentiality guardrails scored 100 and 91, genuinely — while every scenario needing a real effect collapsed, because nothing real ever fired.

The cause sat in the harness, not the product. The harness drives the agent through a different engine than production — a general-purpose agent runtime that layers our prompt over its own base persona, where the hosted path attaches our prompt as the system prompt with the real tools bound directly. That engine had updated underneath us (we had never pinned its version), and on the tier under test the combination tipped into emit-don't-execute. Production was immune by construction. The harness was measuring its own scaffolding, and the judge graded the scaffolding's prose as if it were the world.

Classify trust before reading scores

The discipline that came out of the week is now the first step of every assessment, before a single number is looked at. Each scenario run is classified: genuine — ran to a terminal outcome on a healthy harness, score trustworthy, mine it; partial — truncated or degraded, but the part that ran holds a real finding, so use the finding and discard the score; artifact — the score is a product of harness or infrastructure failure, discard it entirely and re-run after the fix; dead — errored at or near the first turn, zero behavioural signal.

The rule this taxonomy enforces has now been paid for twice, which is what earned it the word cardinal: never generate product work from a corrupted run. Three weeks ago a rate-limited run truncated scenarios mid-flow and we nearly shipped fixes for "failures" that were the rate limiter's; this week the corruption was completely different and the trap shape was identical. A red score from a run whose tools never executed is not a quality verdict — it is an artefact wearing one's clothes — and the pull to mine it anyway is strong, because the whole point of running the suite was to generate a to-do list, and here is a to-do list. Fix the instrument, re-run, and only then mine. Both times, the corrupted run's "product findings" would have sent a week of work at problems that did not exist.

The corrupted columns stay in the matrix permanently, marked. They are the record that those dates measured the harness, not the product, and anyone reading the history without that marking would reconstruct the false regression.

Does the boundary hold? Does it happen at all?

The second question looks like one the judge answers, which is why it is the more dangerous of the two. A judge can grade how the assistant phrased a refusal, and this week it did: the guardrails that scored 100 and 91 on a degraded engine are real prose scores and good news. But they say the model chose well. They say nothing about whether the gate in code would have stopped the call had the model chosen badly, because the fence is code and the judge never sees it. Spending a model to answer a question that code answers exactly is also the wrong instrument on cost grounds: the right test scripts the model's move and asserts on what the fence did, with no model in the judging path at all. We have not built it.

The third question is the one a judged suite cannot even see. Sixty-two scenarios say something about sixty-two conversations we staged. They say nothing about whether a capability fires in the conversations we did not — a suggestion that should appear when the moment is right, a card that should surface once a session. A judge can tell you a capability works. It has no denominator, so it cannot tell you how often it happens, and a capability that works and never fires is, from the user's chair, a capability that does not exist. We know this is a gap. We do not yet know how large.

The judge is an instrument, not an oracle

Each iteration closes with a prioritised plan, and the plan carries a section that surprises people: the anti-work list — judge recommendations that will not be actioned, with reasons. A strong model reading a transcript produces confident, plausible advice, and some of it conflicts with settled architecture or optimises a rubric item at the expense of a system property the rubric cannot see. This week's crop included advice to enumerate the canonical tools in a skill and to forbid inventing tools, both perfectly sensible readings of transcripts in which a model had no tools attached at all. Writing down what the judge suggested and why we are declining it keeps the judge in its lane and stops the same rejected suggestion being re-litigated every round.

And a harness score is not a production score. The same agent, on the same prompt, with the same tools, behaves differently under a different engine — and the difference is not noise; this week it was the entire result. The harness remains indispensable: it exercises multi-turn behaviour no unit test can reach, cheaply, before anything ships. But its verdicts are statements about the agent as run by the harness, and we currently have no way to run the agent under test on the production engine itself. Until we do, any conclusion that matters gets confirmed against a hosted session by hand.

For anyone building an LLM-as-a-judge loop of their own, the transferable shape: let the persona push, because the behaviour worth finding lives past the second ask; read the notes, not the number; pair the judge with a deterministic observer keyed on effects it cannot see, and treat their divergence as a halt rather than a tie-break; classify every run's trust before reading its value; keep an anti-work list; run it on every tier your product can route a person to, not only the cheapest; and know which question you are asking, because a judge answers exactly one, and answers it very well.

Postscript, August 2026. Each of the three questions got its instrument, and each instrument turned out to be a different shape from the judge.

The engine gap was closed at the cause rather than alarmed on at the symptom. The harness gained a mode that runs the agent under test through the production engine itself — same prompt, same stubs, same persona and judge, only the engine differs — and its first measurement settled a question that had been threatening to reprice the whole platform: a skill-invocation scenario that scored RED 45 on the harness engine scored GREEN 90 on the production one, same day, same rubric. That delta is now the first thing we look at when a harness number surprises us. The alarm on transcript-versus-effect divergence from the June plan is still on the list; what got built instead removed most of the reason to need it.

Boundaries got a suite that scripts the model from outside the running system and asserts on what the fences did — consent gates, run-context scoping, tenancy — with no model in the judging path. The judge was removed from that question, not paired; it appears only in a small smoke lane that checks the scripts still resemble live behaviour.

The denominator got an emission audit: a scan of persisted sessions against declared expectations of how often each capability should fire. Its first run found a user-facing feature that had been effectively off for every user since it shipped, while every test was green — the component rendered, the tool was registered, the prompt described it at length, and the model never called it. The judge could not have seen that. It was never asked.

The matrix has many more columns now, several of them trust-flagged, and the flagged ones have earned their keep twice over — each is a week of misdirected work that did not happen. And the engine-versus-production gap remains the note we attach to every harness result, because it has not stopped being true; it has only stopped surprising us.

An assistant you talk to — by voice, or in the rapid half-sentences of real chat — cannot take that position, because its output is long. A streamed answer runs for seconds to minutes; a spoken one longer. If the only legal move during that window is waiting, then every misunderstanding runs to completion, every wrong direction is fully explored at your expense, and the product feels like exactly what it is: a request/response system wearing a conversational costume. So this phase's work was to make interruption a first-class input — and the first discovery is that "interruption" is not one thing. It is three, with three different meanings, and conflating them is how interruption UX goes wrong.

Stop: "that's enough"

The plainest interruption gets the plainest control: while the agent streams, the Send button becomes a Stop button — same slot, same footprint, nothing shifts — and tapping it ends the turn. The semantics took more care than the button.

Stopping is a decision, not a failure. Whatever text already streamed stays in the thread as a completed message — nothing is rolled back, nothing turns red, no error bubble apologises. The user chose to end it; the record reflects a choice, not a malfunction. The stop is real, not cosmetic. An aborted browser request only ends the local view; the model would keep generating — and billing — into a connection nobody is listening to. So Stop is an explicit endpoint call that reaches the pod and aborts the in-flight model stream itself. And the abort has a defined granularity — cooperative cancellation: the signal is checked between loop iterations and before each tool call, never inside a tool's I/O. Token streaming halts almost instantly; a tool already executing runs to completion and its effect persists. That last rule is the honest answer to "what happens to a half-finished turn": the words stop where they stopped, and the actions that had already happened, happened. An interruption model that pretended to un-send an email would be lying about the arrow of time.

The counterpart rule surprised people we showed it to, and we defend it: closing the tab does not stop the turn. Leaving is not interrupting. Navigate away, refresh, lose the connection — the work continues server-side, completes, and is waiting in history when you return. Only the explicit act cancels. The alternative — inferring "stop" from a disconnect — punishes every flaky network and every accidental tab close with silently discarded work, and conflates the person who left with the person who objected. Those are different people.

Barge-in: "my turn now"

Voice raises the stakes, because a speaking assistant occupies the very channel you would object through. Here the borrowed vocabulary of telephony is exact: barge-in, the caller speaking over the prompt, is the universal signal for I've heard enough and want to respond — and a voice interface without it is a hold-music loop.

So playback yields to intent, everywhere intent shows up. Sending a new message cancels the current read-aloud mid-word — you have moved on, and the audio should too. A floating "stop reading" control appears only while speech is in progress, thumb-reachable, ending the audio without disabling read-aloud. Each message carries its own read control for stopping one utterance rather than the feature.

And one deliberate non-cancellation carries the design's judgment: the system's own follow-up messages — a clarify echo, a folder-read confirmation — do not barge in on the answer being read. Machinery messages are not the user's intent, and an assistant that cut off its own answer because its own plumbing spoke would be interrupting you to hear itself. Barge-in triggers on human acts only.

Changed my mind: the third kind

The third interruption is the richest: the user isn't rejecting the output, they are revising the input. "Pull the Q3 numbers" — "actually just EMEA" — "and compare to Q2" is one thought sent in three pieces, and classical turn-locking answers the first fragment alone while the rest bounces off a disabled composer. At this entry's date we could name the problem precisely and had settled the invariant any solution must keep: no message a user sends is ever silently dropped — grouping may flex, timing may flex, existence never does. The old single-slot queue violated exactly that, keeping only the last message sent during a stream, which is the worst possible semantics: an interruption model that loses interruptions.

The full answer — folding rapid messages into one settled thought, superseding a turn made stale by a correction — was designed but not yet built here, and the hard half was clear in advance: safely aborting a turn that may be mid-tool. Cancelling stale words is free; cancelling stale work requires knowing which tools are past the point of no return, which is an audit, not a feature flag. We refused to ship the elegant version before that audit existed.

What transfers

Give each interruption gesture defined semantics and implement the definitions, because "stop", "my turn", and "let me revise that" are different speech acts and a single cancel button flattens them into noise. Separate leaving from objecting — never infer intent from a disconnect. Put abort points at explicit safe positions in the loop and never inside a side-effect, then tell the truth about what a half-finished turn is: words stop, completed effects stand. Keep partials as first-class history rather than something to hide. And when the output channel is audio, make everything yield to genuine human intent and nothing yield to your own machinery — an assistant that talks over you is annoying, but one that interrupts itself is worse, because it teaches you that interruptions don't mean anything.

Postscript, August 2026. The third kind grew its machinery in stages, each honouring the never-drop invariant. Rapid messages now coalesce client-side into a single settled thought — a short settle window, one growing bubble, one answer to the whole burst — with a subtlety that only surfaced in use: a message carrying its own context (fresh files, a different quoted passage) is sealed out of the open burst rather than folded, because a fold that keeps only the latest attachments silently drops the earlier ones, and that is the forbidden failure wearing a convenience. Dictation joined the barge-in family: starting to speak now hushes the read-aloud in the same gesture, completing the telephony metaphor. And a stopped read now stays stopped for the whole of that message — the reply's continued streaming no longer restarts it, a regression fixed twice before it was pinned. Playback gained pause-and-resume in place. And server-side supersede — cancelling a stale in-flight turn on a corrective message — remains where this entry left it: designed, wanted, and gated on the safe-abort audit of which tools can be stopped and which have already touched the world. We still think refusing to guess about that boundary is the feature.

It titled the conversation after the person.

So it knew who they were. It had a memory store holding months of context about that dispute — the correspondence, the drafts, the amounts, the history. And across those eighteen calls it did not once read from it. The only two memory operations in the whole run were writes.

That is not a surfacing bug and it is not a permissions problem. Reads were never suppressed, they have their own visible indicator in the interface, and the instruction telling the agent to consult memory early had been live since that morning. The store had the answer. The retrieval worked. Nothing was broken. The agent recognised the name, and then did not act on the recognition.

One session is an anecdote

So we counted. A scan of a few hundred of our own sessions — several thousand tool calls — and the shape came out unambiguous.

Writes outnumbered reads roughly six to one. Counting only genuine content recall, as opposed to a cheap "what's in here" orientation call, the ratio was closer to ten to one. Genuine recall appeared in about one session in nine. And of the sessions that wrote something to memory, most had never read from it first — filing into a store they had not consulted.

A memory that is written diligently and read almost never is a diary. Diaries are useful to the person who keeps them. They are not useful to the person who needs to know something.

The reads that did happen skewed hard toward sessions where somebody was testing memory on purpose. Organic recall, in the middle of real work, was rarer than the headline number suggests.

The reframe that changed the architecture

The obvious response is to write a better instruction. We did that first, and it is the cheap move, and the numbers above are from after it shipped.

Which forced a decision that had been sitting unmade. Recall is not a nice-to-have here; it is the product. An assistant that knows you is the whole claim. And we were resting that claim on the model choosing, each turn, to go and look — a behaviour that on our own measurements was not happening around nine times in ten.

You do not ship your headline capability on probabilistic compliance with an instruction.

So deterministic retrieval stopped being the fallback and became the architecture. The turn loop itself now always runs a retrieval step before the agent answers, so the invocation cannot be skipped. That is the obvious half. The other half is the interesting one, and we will come back to it.

Then the retrieval turned out to be broken in two opposite directions

Before wiring any of it, we probed the actual store to find out what a read would have returned.

The first probe produced a concerning result — semantic search confidently returning plausible, wrong material at low scores — and it was an artifact. We had pointed it at the wrong store, one with no knowledge of the subject at all, which forced it to return nearest-but-unrelated neighbours. Worth recording, because a retrieval system with nothing to find will always hand you its best wrong answer, and it is easy to mistake that for a general finding rather than a statement about an empty corpus.

The second probe, against the store that actually held the material, gave us the real picture.

Keyed lookup was brittle exactly where people are inconsistent. One individual was split across four separate keys: the bare first name, two different hyphenations, and the full name carrying an accent. Facts about one person, scattered across four entities that the store had no idea were the same person. Worse was the company: the obvious query for it normalised to a key that did not exist, and returned nothing — while more than twenty facts sat under three adjacent spellings of the same name. The most natural question anyone would ask returned zero from a store that was full of the answer.

Semantic search failed in the mirror image. It is robust to all of that — it found the right material for both the person and the company, at healthy scores, without caring how anything was spelled. Its weakness is that it always returns something. The confidently-wrong hits we had worried about in the first probe appear precisely when the answer is not stored. When the answer is present, it scores well clear of the noise floor.

Two retrieval methods that fail under opposite conditions is not a reason to pick the better one. It is an argument for running both and taking the union, which is what we did.

Why not just always look everything up

Because the cost of memory is not storage. Storage is nearly free and getting freer. The cost is what you carry into every single turn, and it is charged on every message for the rest of the product's life.

The naive way to fake a good memory is to re-inject the whole history each turn, which prices your assistant against the size of your life — the longer it knows you, the more every "morning" costs. Retrieving everything relevant on every turn is a softer version of the same mistake. It is affordable in a demo and never afterwards.

So the retrieval step is gated, and the gate is the part we spent the most time on.

A cheap, fast judgment step runs first and decides two things: whether this turn needs memory at all, and if so what to look for. It returns nothing for "hi", for "thanks", and for "what is the capital of France" — general knowledge with no personal hook. It returns targeted queries for "remind me how I like commit messages written". The gate is a model making a judgment rather than a rule matching nouns, because the set of things that might be a name in someone's life is unbounded and any keyword list is a guess about a person you have not met.

It also carries a running summary of the current subject — under twenty-five words — from turn to turn. That is what lets "did he reply yet?" resolve to the right person without re-reading the conversation, and it is a fixed cost regardless of how long the thread runs. Subjects drift mid-conversation, so a summary that updates beats a window of the last few messages.

Then the results are thresholded before anything reaches the agent, with the two halves treated differently: the keyed side is binary and needs no threshold, since an exact hit is either there or it is not, while the fuzzy side gets a floor that discards the confident-but-weak matches the first probe concerned us with.

Most turns never reach the expensive layers. That is the whole economic argument, and it is why an assistant with a real memory can be ordinary to run rather than a luxury.

The principle

The phrase we ended up with is deterministic invocation of a judgment step.

Not deterministic search, which would mean looking everything up every time and paying for it forever. Not agentic retrieval, which means asking the model to remember to remember — and which our own numbers say it will decline to do most of the time, while recognising the subject perfectly well.

The loop guarantees the step happens. The model decides what the step is worth. Reliability comes from the code; selectivity comes from the judgment; and neither is asked to do the other's job.

Recognition is not recall. We had built something that could identify a name, hold months of context about it, and never connect the two — and no amount of instructing it to try harder was going to close that gap, because the gap was in the architecture rather than in the prompt.

Still open

Canonicalisation is deliberately not in this pass: mapping the four spellings of a person onto one key, so the keyed half stops fragmenting. It is the obvious next thing and it is sequenced next rather than bolted on here, because collapsing entities is a decision about identity and getting it wrong merges two people who happen to share a first name.

And the two halves of retrieval still do not compose inside the store — there is no way to ask it a question that spans both. The caller stitches the union. That works, and it is a seam rather than a solution.

Postscript, August 2026. The shape held. Canonicalisation landed the following day and did what it was supposed to. The judgment-gate pattern turned out to generalise well beyond memory — the same structure, a guaranteed cheap decision step in front of an expensive one, is now how several other parts of the system decide whether to do work at all. The write:read ratio is no longer a number we watch, because reads are no longer optional.

And a copy is custody. It outlives the moment of trust that created it. It has to be secured, refreshed, audited and — hardest of all — genuinely deleted. It converts "this assistant may look at my files" into "this company now has my files", which is a materially different sentence, and agreeing to the first is not agreeing to the second. For a product whose pitch is trust it with your working life, which architecture you pick here is not an implementation detail. It is most of the promise.

Last week we built folder access twice in one evening — once each way — and the deletion is the decision this entry records.

Built as a sync, un-built the same evening

Connecting a folder on your own computer was the feature: point the assistant at a directory of project files, notes, exports — the material that never made it into any tool — and have it usable in conversation. The first working version did the obvious thing: it copied. Connected files landed in directories inside the user's vault store, where all the existing machinery — listing, reading, search — worked on them for free. It ran. And looking at it, the sentence it implied was wrong: a user who "connected" a folder had, in fact, uploaded one, and would keep re-uploading it as it changed. The word on the button and the architecture behind it disagreed.

So the copy went. The synced directories were deleted, and what "connect a folder" now means is a permission, not a pipeline: the browser grants the page the right to read inside that folder, and nothing — nothing — is read until the user asks a question that needs it. In the moment of "what's in the licensing doc?", the file is read from the user's own disk, used to answer, and that is the whole event. Between asks, the folder is untouched. There is no background process, no mirror, no watcher.

The privacy properties fall out of the structure rather than the policy, which is where we prefer them. The mechanism is the browser's File System Access API: the folder's access handle lives in IndexedDB on the user's machine — our servers do not hold it and cannot reach the folder, ever, by construction; the server-side system learns which folders exist only when the app chooses to mention them in a message's context. The API itself refuses to reveal the folder's path — a page is told the folder's leaf name and nothing above it, because the shape of your disk is nobody's business. Even the boundary's failure mode is honest: the API exists only in Chromium-family browsers, so elsewhere the feature is absent rather than degraded into an upload.

The bill arrives as engineering

Refusing the copy does not make the problems go away; it moves them, and the week's real work was paying for the move. Three items on the bill are worth anyone's time.

The conversation that ate itself. A model has no memory between turns — whatever it "read" must be re-sent as history on every subsequent turn. So when a user had the assistant read a fifty-file folder inline, those file bodies entered the conversation record, consumed about a third of the context window, and were then replayed on every following turn until the conversation hit the window's ceiling and died. The no-copy contract had collided with the statelessness of the model: the file exists on the user's disk, but the conversation was carrying it forever. The fix strips file bodies from replayed history, keeping only a reference header naming what was read — which immediately creates the next problem: when the model reaches back for that file three turns later, where does it re-read from? Not the user's disk — the moment has passed, the browser may not even be open to that page.

The answer is a loan, not a donation. Files the user has read inline are cached in a hidden, session-keyed area of the document store — invisible to the vault's tree, search and index — and the tool layer enforces that a cached file is readable only by the conversation it was lent to: any other chat, any other agent, any background process asking for that path is told it does not exist. The product's own help copy found the right words and we have not improved on them: it is lending a book, not handing over the shelf. The book stays on a private shelf belonging to that one conversation, and no other reader can pull it.

Every project has a folder called vault. The browser's leaf-name-only rule, correct as privacy, creates a naming collision as UX: connect the working folders of three projects and you may hold three folders all named the same word, with no path to tell them apart — the system literally cannot know more. The only thing that can tell them apart is the person, so the shape of the answer is a name the user assigns. What that name then has to become — the one identifier the agent is told, echoes back, and every surface renders — is the next build, and the part most likely to be got wrong twice.

What this costs

Every read is paid at ask-time — the latency of opening files sits inside the answer rather than being prepaid at sync-time. There is no content index over material we do not hold, so "find the file that mentions the January renewal" across an unread folder means reading, not looking up. And nothing can happen in the background, because the capability itself is alive only while the user's browser session is: the assistant cannot watch, tidy, or act on your local folders while you are away — which is simultaneously the guarantee (it cannot) and the limitation (it cannot), and both halves are true at once. Freshness is the one axis where the ledger runs the other way: a copy is stale from the second it is made, and an on-demand read never is.

The principle we kept, transferable to any integration surface: prefer agency to custody. Reach for data at the moment of the question, in the smallest scope the question needs; hold a copy only where storing is explicitly the point — where the user's intent was "keep this", not "look at this". The copy-based design is not wrong for every product. It is wrong as a default, because it is the maximally convenient architecture for the builder and the maximally consequential one for the user, and defaults should not be set by whoever isn't paying.

Postscript, August 2026. The contract held, and grew a spine we did not have in May: every reach the assistant makes into sensitive data — reads included, not just writes — now leaves a content-free audit mark at the single dispatcher every execution path funnels through, recording which tool touched what class of resource on whose behalf, never the content itself, in a retention-locked Cloud Logging bucket the pod's own service account cannot quietly erase. "What has my assistant looked at?" has a complete answer precisely because looking is an explicit event in this design rather than an ambient property of a mirror. Two loose ends. The session-cache cleanup sweep this entry deferred is still deferred. The naming collision resolved the way the bill predicted, over two passes in June: a user-assigned label, defaulting to the folder name, auto-suffixed on collision, editable in place — and what made it stick was that the label became the identifier everywhere, what the agent is told, what it echoes back, what every surface renders, with disambiguation computed in one place in the data layer so no two surfaces can disagree about which "vault" is which. The folder line now also fires when a message names a connected folder by its label, a word-boundary, case-insensitive match skipping labels under three characters, and the prompt itself now says that the list's absence means nothing off a file-related message. And the synchronising copy was built — which looks like a reversal and is the closing rule being applied: a connected folder can now be pulled into the vault, and every property of how that works is the storing is explicitly the point clause made operational. It runs when somebody asks for it and not otherwise — a button, never a watcher; the destination is chosen rather than assumed; the local side stays read-only, enforced by a test that permits exactly one module in the codebase to open a file for writing, and only for the small marker that gives a folder a durable identity. Two-way sync was designed in full and declined rather than deferred, on the ground that the threshold for a feature whose failure destroys data you do not own is not can we make this reliable but what happens the one time we are not. Connecting still grants a permission; keeping became a separate act with its own consent. What that cost to build, and the identity problem underneath it, is a later entry.

But "make it all data" is not an answer either, and the reason it isn't is the interesting part. An agent in this system holds real capability — tools that read mail, write files, remember things — behind real guardrails: security boundaries, disclosure rules, confirmation gates. Make everything configurable and those guardrails become suggestions, editable by whoever writes the most persuasive identity file. Make nothing configurable and there is one assistant forever. So the whole design problem compresses into one line-drawing exercise, mechanism against policy: what varies between two agents, and what must not?

This week we drew the line, and the criterion that survived contact with every block of the existing prompt is: mechanics are platform; opinion is identity.

The conflation, named

Until now the assistant was a single role hard-coded into one large system prompt — a chief of staff: conversation-first, files everything, captures personal facts exhaustively, owns the relationship. Reading that prompt with the line-drawing question in hand, it fell apart into two kinds of content that had never been distinguished:

Platform — how tools are called correctly, what the vault's write rules are, how memory operations work, what may never be disclosed, which actions need confirmation. None of this is personality. Every agent needs all of it, verbatim, because it describes how the world works here, and two agents with different beliefs about how the world works is not diversity, it is a bug.

Identity — everything with a point of view. That the assistant is personal rather than public. That it files email into these folders under this taxonomy. That it proactively captures every personal fact a message contains. Each of those had looked like a product rule; each is actually one character's worldview. A researcher agent should not assert "I am your personal agent". A drafting agent has no business filing your email. And — the subtlest one — what an agent chooses to remember is part of its character: the chief of staff's capture-everything reflex, applied by a researcher, would flood the user's shared knowledge graph with research trivia. Memory posture turned out to be opinion, not mechanics, and it took reading every block through the question to see it.

The split shipped as structure: a platform block, built once and identical for every agent, and a per-agent block assembled from data. The default assistant is no longer special-cased anywhere in code — it is special because of what its identity says, which is the test the whole design has to pass: if the flagship agent needs a code branch, the abstraction has failed.

Three files, not one — and one of them is not a file

The identity half follows a three-part model, borrowed with credit from soul.md, an open-source three-file agent-identity pattern whose insight we think is exactly right: who an agent is and how it sounds are different assets.

Identity is the role — what this agent believes, cares about, is for, plus its house rules. Style is the linguistic surface: cadence, vocabulary, register, tics. Keeping them separate is not tidiness; it is because style is the most cloned part. A user who loves their drafter's voice but wants a coach copies the style and writes a fresh identity. Someone sharing a researcher agent publishes the identity and lets the importer keep their own voice. Voice transplants are a real operation, and the storage model should make the operation a copy, not a surgery.

The third part, the skills index, is the odd one out: nobody writes it. Which capabilities an agent holds is controlled by explicit grants, toggled per agent — and the prompt's "what you can do" section is generated from those grants at build time, every time. The alternative — capability lists hand-written into identity files — fails the way every hand-maintained mirror of real state fails: it drifts, and then an agent confidently describes powers it no longer has. What the agent is belongs to its author; what the agent can currently do belongs to the system that actually knows.

The storage decision, made the same day

The first draft of this design stored agent definitions as files in the user's vault — natural, human-editable, already synced. It was superseded within the day, before anything shipped on top of it, and the reason is worth recording because it is about what an agent is for, not where bytes live.

An agent definition has a lifecycle a personal file does not. It is owned, but wants to be shared — with another user, with a team, eventually with a marketplace. It is edited from multiple surfaces, concurrently, and a lost update to an identity is character damage. It carries authorization-relevant facts — whose it is, who may run it, what they have granted it — which must be readable by the server making access decisions and writable by nobody else. Every one of those is a database property. So agents and skills became top-level Firestore documents: an owner reference, sharing fields, visibility; the prose bodies — identity, style — as subdocuments; and per-user installation records binding a shared agent to what this user has actually granted it. Files would have made the single-user case pleasant and every case after it a migration. The record makes sharing a field update — which is what "a new specialist is a record, not a deploy" buys at the platform level, not just the user level: the marketplace is not a future subsystem, it is a visibility value.

What this makes possible, and what it refuses

By the end of the week the platform hosts the default assistant, and any specialist a user creates beside it — a researcher who cites and refuses to write final copy, a drafter who writes in the user's own voice and touches nothing but drafts — is nothing but records: an identity, a style, a set of grants. Creating another is an insert. Sharing one is a field. Renaming one cannot orphan anything, because display names and stable slugs were deliberately un-conflated in the same change — the human-facing name is decoration over an identifier that never moves.

And the refusals are the part we would defend hardest. An agent cannot vary the tool contracts, cannot amend the disclosure rules, cannot lower a confirmation gate, cannot reach outside its granted scopes — not because a rule says so but because the assembly puts those facts where identity data cannot express an opinion about them. The platform half is the same for everyone precisely so that the identity half can be anything. That is the trade that makes user-authored agents shippable at all: creativity above the line, invariants below it, and the line drawn at mechanics versus opinion.

Postscript, August 2026. The split held, and its most instructive aftermath is that the line itself turned out to be alive. Per-agent preferences joined the record days later (a third body beside identity and style), and months on, a block originally classified as chief-of-staff identity — the doctrine of capturing a user's corrections as durable preferences — was reclassified as platform, because the storage change had quietly changed its nature: once every agent held its own preferences, "learn what this user wants from you" stopped being one character's habit and became a capability of being an agent here. Mechanics-versus-opinion survived as the criterion; where a given block falls under it is re-decided by the architecture around it. The first user-created specialists have since been joined by org-shared agents and installable kits, all riding the same three fields this week put in a database — and the flagship assistant still has no code branch to its name.

The cheap answer is the standard one — a shared process and an identifier threaded through every query — and for most software it is right. The failure mode is what changes here. In an ordinary application, a missing filter shows someone the wrong data: bad, visible, recoverable. In an assistant that acts, a missing filter is an action taken in someone else's name, with their credentials, in their mailbox. We did not want that class of bug to be possible at the application layer, so we took the expensive road: every person gets their own process, in their own Kubernetes namespace, running under its own GCP identity that can reach their data and nothing else. The wall is enforced by infrastructure that has no notion of our application logic, which means no bug in our application logic can breach it.

That decision came first. Everything in this entry — an autoscaler we deleted on day one, a provisioning pipeline, a pre-pulled image, and a memory that travels as an archive — is downstream of it, because a process per person creates three problems on the spot: how a person gets one, how it sleeps (most of them must — nobody talks to their assistant twenty-three hours a day), and where its state lives while it does.

Day one: what an autoscaler cannot see

The first answer to the sleeping problem lasted eleven minutes. Sleeping pods need waking, and there is well-built, widely-used tooling for scale-to-zero on HTTP traffic. We configured it — zero to one pod, ten minutes idle before sleep — and wrote a comment in the manifest noting that a streaming connection would hold the idle timer open for the length of a conversation. That comment is where the wrong assumption was hiding. The tooling scales on pending requests, which measures load when a request means arrive-work-return-close. An agent reply is not that shape: the connection opens at send and stays open while the answer is composed — minutes, sometimes; across a conversation, the whole conversation. Pending-requests pins at one and stays there, so the signal saturates precisely when it needs to discriminate: from outside, a person thinking mid-conversation and a person who left an hour ago look identical. This is documented behaviour, not a discovery — the tool says it is built for short request/response cycles. We brought it the wrong shape of traffic.

The fix was not a better autoscaler; it was noticing what already existed. Every request already passes through a component that authenticates who is asking and routes them to their own space — that part is mandatory, it is the load-bearing half of the isolation. And it already knows the three facts an autoscaler infers: who this is, that a request just arrived, and when the last one came. So the router took the job. It brings a pod up on the request it is already authenticating, and a background sweep puts pods back to sleep after ten quiet minutes, measured from last real activity rather than from the state of a connection. The dead design had made the mistake general-purpose tooling almost has to make: treating tenants as alike enough to be handled as a crowd. Ours hold state that must survive between conversations, wake for one person and sleep when that person stops, and are emphatically not interchangeable.

Making the wake bearable

The cost of the boundary is concentrated in one moment: someone's first message of the day lands on a pod that does not exist yet, and they wait while it is created — at exactly the moment a new user is deciding whether this thing is any good. This week's work was mostly about that moment, and none of it is one big idea; it is the accumulation of small ones, which is what latency work always turns out to be.

The container image is now pre-pulled onto every node in the cluster, so waking a pod never includes downloading the software — the largest single component of the wait, removed by paying for it in advance, once per node instead of once per wake. The pod reports readiness through a startup probe staged for what boot actually does, rather than a generic health check that lies in both directions. Messages sent while the pod is still waking are queued and delivered when it is ready, so an early message is never dropped and never errors — the person types, and the system's job is to make the typing valid. And the wait itself was given honest UX: a staged sequence naming what is actually happening — your environment is starting, your memory is loading — because thirty seconds of specific progress reads as a system working and thirty seconds of spinner reads as a system broken.

A memory that travels as an archive

A process that sleeps poses the state question sharply: the whole point of this product is that the assistant remembers, and the pod holding those memories is destroyed after ten quiet minutes. The memory store is ChromaDB — a SQLite database plus vector-index files, a storage engine that seeks and locks and rewrites pages in place. Running that directly against object storage is a non-starter, and not marginally: GCS speaks whole-object semantics, and SQLite's random-access pattern against it is catastrophically slow. This is a known incompatibility we designed around rather than discovered.

So the state lives on the pod's local disk while it runs — fast, ordinary, local — and round-trips as an archive: downloaded and extracted at boot, packed and uploaded when the pod is told to shut down, with a periodic sync as a safety net between. The trade is honest. Boot pays for the restore, which is part of the cold start above; the sync window means a crash (as opposed to an orderly sleep) can lose the last few minutes of memory writes; and the upload path carries the sharpest risk in the design — a pod that booted from a bad restore must never be allowed to pack up its bad state and overwrite the good backup. That risk is named on the whiteboard and not yet written into the code.

The bet

We bought a boundary and we pay for it in latency at the worst possible moment, plus an archive round-trip, plus a provisioning pipeline most products never need. It is a bet that people handing an assistant their inbox and calendar will care more about where the wall is than about the first seconds of the first reply — made, at the time, without much to copy: the excellent tooling for running untrusted code in a disposable box has the isolation and throws away the memory; the durable-workflow tooling keeps state and has no opinion about who owns it. What this product needs is a third thing — a process that is warm, tied to one person, wakes when they speak, sleeps when they stop, and remembers between times. For now it is assembled out of a gateway, a Kubernetes namespace, a GCP service account and a sweep. That is not elegant. It works.

Postscript, August 2026. The shape held; three edges moved, each in the direction the body predicted. The memory archive grew its protections within days — timestamped backups with thirty-day retention first, and later the rule the design had only implied became enforced code: a restore that fails integrity checks marks the boot bad, and a pod that booted bad refuses to upload, so a corrupt local state can never clobber the last good archive. Provisioning moved off the request path entirely once a scalability review ranked a launch-day signup burst as the most realistic failure: signup now enqueues a job and returns immediately, with a bounded-concurrency worker, retry with backoff, and a claim mechanism that survives a gateway restart — the ten-second synchronous provision had been both a wall and a timeout waiting to happen. And the per-user identity hit a wall we did not see from the whiteboard: GCP caps service accounts at one hundred per project, and we were forty-six in. The redesign — spike-validated, migration staged — keeps the property that matters (GCS itself refuses cross-tenant access) while binding IAM permissions to each pod's Workload Identity principal on per-tenant managed folders instead of minting a service account per user. The isolation model was never the mistake; the implementation unit of it had a ceiling, and the fix swaps the unit while the wall stands. Around us, the tooling landscape has grown exactly where we expected: the ephemeral, disposable agent sandbox is now well served. The persistent, identity-bound, half-asleep session that has to remember you next week — we are still assembling that one by hand.

Today that position stopped being theoretical, because today we exercised it hard enough to find its limits. This entry is written at the end of a single Saturday in which the routing layer changed three times, a cheap tier was handed across a provider boundary and taken back, and one piece of state was moved because the day proved it was pinned to the wrong thing. The churn was not indecision. It was the cheapest possible way to learn which parts of "swappable" are real.

The morning: making a swap observable before making it possible

The unglamorous work came first, and it is the part that made the rest of the day survivable. Usage and the model that produced it are now recorded per turn, not per conversation, and the pricing table became a dated store — each model's rates keyed by model and time window. The cost of a turn stopped being a figure reconstructed afterwards from a monthly total: which model ran, and what it cost, is now a fact recorded alongside the turn itself.

None of that routes anything. All of it is the precondition for routing: a system that can change models mid-conversation but only records cost per conversation cannot tell you what any routing decision did. Before the first swap happened, every turn's model became a fact attached to that turn — so by the time the afternoon's experiments ran, each one left a priced audit trail rather than an impression.

The afternoon: three tiers, and a guest in the cheap seat

Then the routing itself. A classifier runs before each turn and sorts it into one of three tiers — simple, default, complex. It is deliberately dumb: keyword tests (a message mentioning email or calendar implies tool work, so route it up), a word-count floor and ceiling, an image forces the top tier, and prior tool use in the thread sets a floor. Complex turns route to a mid-class model; the default is the fast one; and the simple tier — greetings, one-liners, trivial yes/no — was pointed somewhere more interesting: a small, cheap model from a different provider entirely.

The logic was sound. A greeting does not need frontier capability; another vendor's small model answers it for a fraction of the price; the abstraction to translate between provider APIs — message shapes, tool calls, streaming — existed and worked. Over the afternoon the cheap seat's occupant changed twice more, one small model swapped for a newer sibling, chasing the best cost-per-greeting. Three tiers, a provider boundary running through them, one assistant.

The evening: why the guest was asked to leave

By ten that night the cross-provider tier was gone — the simple tier now routes to a fast model, and the threshold for escalating to the mid tier was raised while we were in there. The commit that removed it records the reasons, and they are worth more than the experiment cost:

The voice changed mid-conversation. Models from different providers have noticeably different styles, and a thread that crossed the boundary read like two people sharing a keyboard. The user sees one assistant. The routing is invisible — which means any stylistic difference between tiers is not perceived as a routing artifact; it is perceived as the assistant being off today. A conversation is a single performance, and the audience attributes everything in it to one performer.

Tool behaviour drifted. The guest model was less reliable at driving our tool surface — the same definitions, translated faithfully, called more erratically. And it was weaker at implicit multi-step context: the follow-up message that makes no sense without the three turns before it, which is most messages in a real thread.

The general lesson is the one this entry exists to record: models are interchangeable at the API level and not at the conversation level. The translation layer was never the problem — messages, tools and streams all converted cleanly. What does not translate is everything the API contract is silent about: register, tone, tool-calling temperament, how much of the unstated thread a model carries forward. A routing layer that treats models as fungible compute will keep passing every functional test while the product develops a personality disorder. Swappable is real — we swapped four times today and nothing broke — but the unit of swap is the whole conversation's tenant, not this turn's supplier.

What survived the day

Every specific decision made today is provisional, and the things that are not provisional are the ones the churn proved out. The seam — one point in the loop where a turn's tier is decided, with the whole thread in scope, before any provider is constructed — survived four routing changes without moving. The observability — per-turn model facts, dated rate rows, a priced trail behind every routing decision — is what let four changes happen in one day with confidence instead of anxiety. And the user-facing posture held throughout: what the interface promises is capability, not components. The product sells depth — a tier is a commitment about how much thinking a question gets, not about which engine delivers it. That posture is not cosmetic. It is the thing that makes the model swappable in practice: a product whose interface promises a named engine has signed away the right to improve it, because every improvement then arrives as a renegotiation about something the user was never really buying.

The discipline, as a checklist, for anyone building on models they do not control: meter per turn against the model that actually ran; key your rates by model and date, because prices move under you; keep the routing decision at one seam with the whole conversation in scope; make the interface a promise about capability rather than about components; and test any cross-model route at the conversation level — voice, tool temperament, implicit context — before trusting the API-level tests that will all pass.

Postscript, August 2026. The day's verdicts aged in both directions, instructively. The keyword classifier was throttled within weeks — the mid-tier branch disabled pending a cost/quality evaluation, the classifier itself demoted to log-only — and in July the approach was formally judged unreliable and superseded by an accepted design that closes the loop on this entry's own logic: a cheap model deciding which expensive one answers. The router reads a digest of the thread — recent turns, which tiers they ran at, whether tools fired — never the transcript, escalates rather than ping-pongs, and picks capability levels, never models, so billing, the promise a tier makes and the interface all hold unchanged. The user-facing half shipped as exactly the tiers this day sketched: three named depth levels, priced as credit multipliers, mapped to models server-side. One economic fact, discovered later, retroactively justified the evening's caution about per-turn swapping: prompt caches are per-model, so a single mid-thread model switch reprocesses the entire conversation at full input price — on a long thread, roughly ten times that turn's cached cost before the answer even starts. The strongest argument against routing churn turned out to be in the billing data. And the cross-provider abstraction the afternoon exercised still exists, translation layer and all — deliberately unwired, kept as the escape hatch the swappable-part position requires — today's routing is a choice we keep making, not a lock-in we inherited.