Keeping it true over time

A useful brain has to handle what happens after it learns something. A contract gets sent, a meeting moves, or a decision makes an earlier promise difficult to keep.

By the end of this part, your prototype will handle one of these changes and expose what it cannot settle.

Start with a real failure

Choose a case from your work:

• A promise that was fulfilled but still appears open.
• Two sources that disagree about the current plan.
• A changed decision that affects a commitment made earlier.

Write what a helpful answer should say, which sources support it, and what remains uncertain. “The contract was sent” should be traceable to evidence of sending. A thank-you may refer to something else, so review it in context.

Make the change visible

Choose how your existing setup will represent the outcome. An MD-based memory can maintain an open-items section with evidence links and a history. A database can store states and supporting references. Both can be tested for the same behavior.

Decide what is sufficient to call an item done, what counts as an explicit reopening, and when the user must decide. Preserve the distinction between confirmed completion, cancellation and an item that has simply gone quiet.

For disagreements, an agent should be able to name both claims and their sources. Asking the person is useful when the uncertainty affects the task; repeatedly asking an irrelevant question is noise.

Test consequences, not just the changed sentence

Suppose SSO moves to Q1 after a customer was promised it in December. Ask your agent to draft the customer follow-up. Does it see the conflict, explain why it matters and leave the response decision to the user?

Implement the smallest change needed to pass that example in your own system. How you discover affected information depends on its structure and volume. Test another item mentioning SSO that is unrelated to the promise: a shared word alone should not make it affected.

Try replaying older material afterward. Check whether the corrected state survives, whether the history remains understandable and whether a failed check is reported rather than presented as success.

Measure

Add new questions about completion and consequences. Reserve genuinely unseen cases for held-out testing; a case you used to design the change belongs in practice.

python3 score.py questions.jsonl part4.jsonl part5.jsonl --out part5-scores.json

The comparison uses only questions both runs answered. Score part5.jsonl on its own to include newly added questions too. Review correctness, omissions and whether the answer provides enough context to act.

Next, part 6: the read path.

---

Build and measure your own setup with the companion skill. See the series. For a maintained company install, talk to Team0.