The Context Files the Agent Could Never Keep Current

I once believed that feeding an agent every available document, calendar, and roster would keep its answers current without anyone lifting a finger. The assumption came from watching early retrieval systems pull Bible text and sermon outlines at scale. I figured if the sources existed, the model would simply notice when something changed.

That assumption broke on a children’s ministry schedule. We had three separate updates running at the same time: a shared spreadsheet the volunteers edited on their phones, an email thread the coordinator used to confirm room changes, and an agent we had just connected to the same sources. When a last-minute leader swap happened, the spreadsheet reflected it, the email did not, and the agent served the older version. Two rooms sat empty for twenty minutes while parents waited in the hallway. The cost was not theoretical. Families left early, and the volunteer who showed up to an empty room stopped responding to texts for two weeks.

The mistake was treating context as a static collection rather than a living set of handoffs that people still had to maintain.

Charlie Munger’s latticework of mental models insists that no single view is sufficient. Reality shows up only when several independent models overlap and contradict one another. In product work this means the agent’s memory file is never the final model. It is one layer that must be checked against the next human handoff. Without that check, the lattice collapses and the system quietly serves yesterday’s facts.

When the volunteer roster lived in three different updates

The roster problem was not a data-cleanliness issue. It was a visibility issue. Each update lived in its own channel because that was the fastest way for the actual people involved to move. The spreadsheet let a volunteer add a substitute in under thirty seconds. The email thread captured the coordinator’s reasoning. The agent had access to both but no rule for which one to trust when they diverged.

We tried solving it by giving the agent higher priority. That only made the contradictions louder. When the coordinator opened the agent output and saw the wrong name, she assumed the system had already corrected the spreadsheet. She stopped checking the original source. The handoff between her and the volunteers became invisible because the agent sat in the middle.

The latticework view would have required us to keep the three updates visible to one another instead of routing everything through the model. The agent could have surfaced the differences rather than picking a winner.

The edit diff that revealed the real schedule change

A week later we added a simple diff view on the context file itself. Every time the agent ingested an update it produced a short list of what had actually changed since the last human review. The coordinator could open that list on her phone and confirm or reject each line in under a minute.

The first real test came on a Wednesday night when two volunteers traded nights. The diff showed the swap plus the fact that the room assignment had not moved with them. That single line caught the error before any parent arrived. The coordinator made the correction in the file and the next agent run carried the right room.

The diff did not replace the human step. It made the human step cheap enough that it actually happened. Munger’s point about multiple models became practical: the file, the coordinator’s judgment, and the agent’s next run all stayed in view at once.

Why context ingestion became the weekly discipline

After that incident we stopped treating ingestion as an automated background task. Every Monday the person responsible for the next handoff opens the context file, runs the diff, and records any manual overrides in plain language. The entry stays attached to the file so the next person sees both the data and the reason it was adjusted.

The discipline takes about twelve minutes when nothing has changed and closer to twenty when something has. It is not glamorous, but it keeps the lattice intact. The agent still rewrites its own memory, yet the rewrite is now traceable to a named person who accepted responsibility for that week’s handoff.

We tried skipping the step twice. Both times the same roster error reappeared within ten days. The cost was always measured in empty rooms and volunteers who quietly stopped showing up.

Your Turn: Apply This Today

• Open the shared context file your team actually uses for the next handoff and add a one-line note on who last edited it and why.
• Turn on edit diffs for that file so the next person sees only the changed lines instead of the full document.
• Schedule a twelve-minute Monday review on your calendar with the person who owns the upcoming handoff and treat it as non-negotiable.
• Write the reason for any manual override directly into the file rather than sending it in a separate message.
• Check the agent output against the diff list before the handoff leaves your team this week and log the result.
• Pick the single upcoming handoff that matters most and make its context file the only source the agent is allowed to read until the review is complete.

The same pattern shows up in the agent schedule problem described in “The PM Who Inherited the Agent Schedule” and the memory layer decisions in “The Data Moat That Actually Matters for Small Ministry Teams.”

I consult with product leaders and ministry teams on persistent context files, visible handoff design, and agent memory layers that survive real schedule changes. Let’s talk.