Our go-to-market runs out of KnowDrive

We run our own go-to-market on KnowDrive. The system that plans our week keeps its state in a KnowDrive store, and when that store is unavailable the work stops. This post describes how the loop is put together and what it has cost us.

The loop

The runner is a simple loop. It reads its state from a KnowDrive store, does one unit of work, and writes the result back as a new document in the same store. The next session begins by reading what the last one wrote. State lives in the corpus itself, so there is no second database to keep in step and no prompt that grows longer each week.

• Session handoffs are documents. Each records what was decided, what is still open, and what comes next.
• Memory sync mirrors durable facts into the same corpus, so a fact learned in one session is retrievable in every later one.
• The corpus is read on demand rather than carried in the context window, so the tenth session costs the same to start as the first.

The memory outlives whichever model we happened to be using that month.

What this actually buys

Two things follow from it. Nobody re-pastes context between sessions. And when we change models, nothing migrates: the corpus was cut once and sized for the smallest reader we might ever point at it, so switching readers is a configuration change instead of a re-embedding project.

That is the VORAS argument stated as an operating fact. Running the company this way is how we test it.

Where it is still rough

Retrieval quality is only as good as what was written down, and a poor handoff degrades the next several sessions. We now write each handoff for a reader who was not there, since in effect that is who reads it. Holding that discipline is an ongoing cost of the approach.