The Graph We Added After Token Costs Stopped Us Shipping

I refreshed the billing dashboard and the line item for the scheduling agent had already doubled from last week. Same questions, same names, same carpool details getting re-explained every time a volunteer dropped out.

We had promised the team this thing would save them hours. Instead it was burning through tokens just to stay in the same place, and every new swap made the next one more expensive. Shipping got pushed again while we stared at the numbers.

That’s when we stopped trying to make the model remember and started giving it something it could actually look at.

The exact token spike that forced the graph decision

The spike showed up first in the prompt logs. Each new conversation restarted with a full dump of the current volunteer roster, every recurring conflict, and the last three schedule versions. When a family called to change their availability, the agent needed another full pass to rebuild the picture. One Tuesday the daily spend jumped past the monthly curriculum line because three separate last-minute changes triggered overlapping prompt refreshes.

We measured the waste directly against the children’s ministry numbers we already tracked. The curriculum itself cost a fixed amount per quarter. The agent had crossed that line in a single month. The team had optimized the model calls for accuracy in isolation, but the real constraint was the repeated transmission of the same local facts.

Once we saw the pattern in the logs, the decision to move context out of the prompt became straightforward. We needed a structure that could answer a narrow set of questions without re-sending the entire history every time.

How the graph preserved the one piece of context the model always dropped

The model reliably forgot which families shared transportation. A parent might confirm they could drive for the 9 a.m. slot, yet the agent would later assign their child to a different campus without checking the shared ride. The graph stored that relationship as a simple edge between two volunteer records and a recurring location constraint. Queries could then test the edge before proposing any change.

We kept the graph small on purpose. Only three node types existed: person, shift, and constraint. Edges carried only the facts that changed weekly. The model still handled natural language, but it called the graph first for any fact that had appeared in more than one prior conversation. Token counts dropped because the prompt now referenced a single lookup instead of re-listing the full roster.

The same structure surfaced the next time a volunteer coordinator joined the team. She could query the graph directly for open shifts that respected existing carpool edges without waiting for the agent to re-learn the pattern through failed suggestions.

The discovery loop that kept the graph from becoming another abandoned project

Torres’s loop requires regular interviews with the people who actually use the system. We scheduled fifteen-minute calls every other week with whoever had made the most recent schedule changes. The question was always the same: what fact did you have to tell the agent twice this week? The answers pointed to new edges that belonged in the graph rather than new prompt text.

Each interview produced one or two concrete updates. We added an edge type for recurring medical appointments after three families mentioned the same constraint. We added a simple weight on certain shifts after the coordinator noted that some volunteers only accepted weekday roles. None of these changes required retraining the model; they only required extending the graph schema.

The loop also caught when an edge had grown stale. One carpool relationship ended when a family moved, and the interview caught it before the agent proposed the old arrangement again. Continuous discovery turned the graph into living documentation instead of another static database that drifted from reality.

Your Turn: Apply This Today

• Review the last ten agent runs that required user correction and list every fact the model asked the user to repeat.
• Group those facts into the three most common categories that appear across runs.
• Build a minimal graph with one node type and one edge type for each category using whatever lightweight store already exists in your stack.
• Instrument the agent to query the graph before generating the next prompt and measure the token reduction on the next twenty runs.
• Schedule a ten-minute call with the person who makes the most schedule changes and ask what single fact the agent still misses.
• Add the new fact as an edge and re-test the same twenty runs to confirm the spend drop holds.

The PM Who Inherited the Agent Schedule showed how inherited context breaks when teams treat agents as black boxes. The Knowledge Layer Ministry Teams Forgot to Budget traced the same pattern across several small teams that later added graphs.

I consult with product leaders building agentic tools for ministry teams on continuous discovery loops and lightweight knowledge graphs for context retention. Let’s talk.