When we first built SLEDS (back when it was still called CONNCT), context was stored as flat key-value pairs. A "memory" was a statement: "The auth system uses JWT tokens." "The design system uses Tailwind." It worked, but it was brittle. There was no provenance, no history, no sense of how knowledge evolved.
Six months ago, we ripped it all out and replaced it with threads.
The Problem with Flat Memory
Flat memories are great for simple facts that don't change. But real project knowledge is messier than that. Decisions get made, revisited, and reversed. Context has layers — who said it, when, in response to what question, and whether it was a firm decision or an exploratory thought.
A flat memory that says "We use Stripe for payments" doesn't capture the three-week evaluation of Stripe vs. Square, the concerns about pricing that almost changed the decision, or the specific integration pattern the team chose. Threads capture all of that.
Threads as Living Context
A thread in SLEDS is a topic with an observation history. Each observation is a snapshot from a conversation — a decision made, a question raised, progress reported, or context shared. Observations are timestamped and attributed to the tool and person who contributed them.
This means a thread about "Payment Integration" might have observations from three different conversations in three different tools, contributed by four different people, over two weeks. The thread's summary is automatically generated from this history, so it stays current as new observations arrive.
Why It Matters for Teams
The shift to threads changed how teams interact with shared context. Instead of a static knowledge base that someone has to maintain, you get a living history that builds itself from your team's actual work. When Frost generates a Pulse briefing, it can reference specific observations: "Marcus raised a concern about PCI compliance in his Cursor session on Tuesday" with full provenance.
Technical Details
Each thread has a status (active, paused, completed, archived), tags for categorization, and a tool attribution showing where observations originated. The observation history uses append-only storage — nothing is deleted, so you always have the full evolution of a topic.
Threads support polymorphic linking: thread-to-thread ("this architecture decision depends on this infrastructure choice"), thread-to-asset ("this discussion produced this spec"), and asset-to-asset relationships. The link graph builds organically as SNOW detects semantic connections.
Replacing flat memories with threads was the single most impactful architectural change we've made. It turned SLEDS from a context store into a knowledge system.