Teaching the Agent Where History Belongs

Introduction

#

The first AI move around history is not asking the agent to build a history table. It is asking the agent to argue against needing one. Stored history is stateful, expensive to recover, and easy to misuse, so the assisted workflow has to begin with restraint rather than generation.

This chapter belongs in the book because history capture is one of the clearest tests of the whole method. An agent can produce a snapshot, a current-row view, a point-in-time filter, and a monitoring query very quickly. That speed is useful only after the design decision is right. If the decision is wrong, the agent does not save you from complexity. It helps you create more of it, faster.

Start with the Refusal

#

When I use an agent on a temporal problem, I want its first answer to be a refusal checklist, not an implementation. The question is not, “How do I capture every version of this source?” The better question is whether the source deserves stored history at all. That subtle change matters because it points the agent at judgment support before it points it at code.

I want the agent to challenge the premise. Does the source overwrite rows in place? Is there a real point-in-time question, or only a current-state report with dramatic language around it? Can the past be reconstructed from events, frozen reference data, cycle keys, or another system that already keeps the history? Is the source grain stable enough that a versioned table will mean the same thing next month that it means today? Can the run cadence actually catch every change that matters?

That is a useful agent task because it turns a vague desire into a concrete decision record. The agent can read the source definition, the downstream query, the issue description, and the surrounding models, then produce the case against stored history. I still own the answer, but I get a sharper review surface. If the case against history is strong, I stop there. The most valuable AI output in that moment is not a table. It is a reason not to add one.

Ask the Agent to Prove the Need

#

Once the refusal checklist exists, I ask for proof. The agent can search for the downstream consumers that require a past state, identify the exact date or period they ask about, and show whether those questions can be answered from data that already exists. It can compare alternatives side by side, such as append-only events, deterministic recomputation, natural temporal keys, or a small stateful history table at the edge.

I like to make that explicit in the prompt.

Before proposing a stored history table, show the cheaper alternatives.
For each alternative, explain which point-in-time question it can answer,
which one it cannot answer, and what operational burden it avoids.
Only recommend stored history if the alternatives fail.

This is not prompt theater. It changes the kind of work. Without the instruction, an agent sees a familiar pattern and reaches for the familiar artifact. With the instruction, the agent has to reason about the requirement before drafting the implementation. That is the theme of the book in miniature. The tool moves fast, but the lane is set by the question you ask it to answer.

The proof also protects me from pretending that “history” is one requirement. It rarely is. Sometimes the business needs the state at the end of a cycle. Sometimes it needs the exact value that existed when a decision was made. Sometimes it needs an audit trail of changes, including who changed what. Those are different questions with different designs. The agent can help separate them, and that separation is often where the complexity disappears.

Keep the Stateful Edge Small

#

If stored history really is needed, the next AI-assisted decision is where to put it. A history table is not like a normal model. A normal model is a pure function of its inputs, so I can drop it and rebuild it. A stateful history table depends on prior runs and prior source states that may no longer exist. Once it is wrong, a full refresh does not repair it. A careless full refresh may destroy the very evidence it was built to preserve.

That is why I want a small stateful edge and a deterministic core. The edge captures the irreducible history. Everything downstream should be as rebuildable as possible. I do not want one history table feeding another history table, because layered validity intervals are a trap. The outer table reflects the state of the inner table at the moment the outer run executed, not necessarily the state of the inner table at the historical time a reader asks about later.

An agent is helpful here because it can inspect a proposed design for stateful spread. It can find downstream models that would inherit validity intervals, flag places where current-row logic is being copied into too many consumers, and suggest a narrow interface around the history table. The human decision remains the same. Keep the stateful thing small enough that you can afford to back it up, monitor it, recover it, and explain it.

Let the Agent Build the Guardrails

#

Once the decision is made, the agent becomes very useful. It can scaffold the boring pieces that make a history table safe to consume. Current-row filters, point-in-time filters, deduplication checks, row-count monitors, recovery notes, and model documentation are exactly the repetitive work that should not depend on my patience on a tired afternoon.

The key is that the generated work should encode the design decision rather than hide it. If the current-row predicate is valid_to = '9999-12-31', the agent should place that predicate consistently. If point-in-time reads use an inclusive start and exclusive end, the agent should write that pattern everywhere and add a test around the boundary. If a source backfill can temporarily drop keys, the agent should propose an alert that catches mass row closure before it becomes a silent production story.

This is where AI assistance earns its place. The agent does not decide that history belongs here. It makes the chosen design cheaper to implement well. It turns the checklist into code, the code into tests, and the tests into documentation that the next person can follow. That division of labor keeps the dangerous part human and gives the tedious part to the tool.

Putting It Into Practice

#

1. Ask the agent to argue against stored history before asking it to build anything.
2. Require proof that the source overwrites rows, the point-in-time need is real, and cheaper alternatives fail.
3. Separate temporal requirements, because audit trails, cycle-end state, and exact past values are different designs.
4. Keep stateful history at the smallest possible edge and preserve a deterministic downstream core.
5. Never let the agent stack history tables unless you can explain the validity behavior yourself.
6. Use the agent to generate current-row filters, point-in-time filters, deduplication checks, monitors, recovery notes, and documentation.
7. Own the temporal design decision yourself, then let the agent make that decision cheap to implement consistently.