TickStock.ai.

Writing

Connecting Context

Chat history is an operational failure mode for state management. When engineering initiatives span days or release cycles, criteria shift, constraints emerge, and decisions compound. Forcing models to reconstruct context from raw conversational threads guarantees hallucination, lost requirements, and review fatigue.

Decoupling Session State from Repository Reality

Large language models do not need bloated database overhead to maintain continuity. They need a deterministic context layer anchored directly to your repository and work tracking systems.

  1. Structured schemas over unstructured text. Define standardized file artifacts (.json, .yaml, or structured Markdown) to track four fields: decision records, hard constraints, verification criteria, and explicit exclusions.
  2. Version-controlled state. Store these context artifacts alongside the code in Git. When an agent starts a task, it reads the current schema state, not a 50-message chat history.
  3. Reusable query primitives. Pair records with structured inspection prompts so subsequent agents can query: What is currently in scope? What architectural options were evaluated and rejected? What verification gates remain open?

The agent then reads and updates that layer in place. After an interruption of days or weeks, you query the system rather than reconstruct the conversation.

flowchart TB You -->|ask| Model Model -->|answer| You Model -->|write artifacts| Engine[Context engine in git] Engine -->|records, constraints, criteria, exclusions| Engine Engine -->|read before answering| Model You -.->|days later: query the system| Engine classDef storage fill:#1a2433,stroke:#9ec0ee,stroke-width:2px,color:#f4f0ea class Engine storage linkStyle 5 stroke:#d4dae4,stroke-width:2px,stroke-dasharray: 6 4

Figure 1: The session handles computation; the version-controlled context engine maintains institutional memory.

An Architectural Example: Managing a Multi-Week Database Migration

Consider a multi-week initiative: migrating an active data pipeline from PostgreSQL to TimescaleDB.

An engineering team relying on chat threads will repeatedly paste table schemas, re-explain connection pooling constraints, and remind the model which tables were already partitioned. Three weeks in, an agent inevitably suggests an index pattern that was already tested and discarded in week one.

In a governed context layer, the agent never relies on conversational memory:

  • The artifacts. A version-controlled migration-manifest.yaml tracks migrated tables, hypertable chunk_time_interval, deferred foreign keys, and discarded indexing strategies.
  • The interaction. When an implementation agent boots up, it reads the manifest. It executes the next slice of work, runs the verification suite, updates status flags such as migrated, deferred, and discarded, and commits.
  • Zero re-orientation. Two weeks later, a new specialist agent or human reviewer does not rebuild the conversation. They inspect the system: What chunk_time_interval is locked? Which schemas failed the dry run? What remains out of scope?

Read next: Keeping Your Train on the Tracks → How this system runs