The write trigger, which was the open question. Three answers were available and two are worse. A second model call after each run, asked to extract durable facts, judges well and costs an entire extra call against a ceiling of 8,000 tokens a minute — on every run, most of which have nothing worth keeping. A heuristic in the loop is cheap and remembers the wrong things: the shape of a run says nothing about whether a fact outlives it, so the table fills with restatements of rows the database already holds. So: a tool. It costs nothing extra, because the model is already mid-run with a catalogue in front of it and remembering is one more call it may make when it has just learned something that will not be in the records next time. It is automatic in the sense that matters — nobody types "remember this" — and it is visible in the trajectory, which an extraction pass would not be. IT IS A CONFIRMED WRITE, and that is the invariant working rather than an obstacle. EffectWrite forces RequiresConfirmation, and this tool stores personal data that will shape later hiring answers — the most consequential thing a model can do here short of assigning somebody to a shift. A reader sees the sentence before it is kept, who it is about, that an agent and not a person decided it, and that it expires in ninety days. A memory about a person also carries a warning that says so and says it can be erased. If a deployment later wants workspace facts kept without asking, the honest change is a SECOND tool scoped to workspace subjects. Loosening this one would quietly make personal memories unconfirmed too, which is the whole thing this gate is for. Author is always "model" and is not a field the model can set: an inference must never be readable later as though a person had written it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7.2 KiB
7.2 KiB