-
-
Two staff race for one loaner. A SERIALIZABLE transaction guarantees exactly one wins; the other retries and sees it is already taken.
-
Every ticket is worked as visible tool-calls. look_up_user and recall_memory read the requester and their history from CockroachDB.
-
A database node is killed live (nodes 2/3) and the desk keeps working. The district's memory was never in the app process.
-
Vector search clusters three scattered reports across the district into one incident (INC-1002): a live defect and outage radar.
Inspiration
A language model has no memory; every call wakes up blank. The sponsor put it exactly: what makes an agent useful in production is not the model, it is what it can store, retrieve, and act on. One of us works in K-12 IT support, where that memory is huge and shared: thousands of students and staff, a mixed fleet of Windows laptops, Chromebooks, and iPads, ClassLink accounts, device carts, and buildings. So we built the agent we would actually want at the help-desk counter, and put its entire memory in CockroachDB.
What it does
Throughline is a live IT ticketing desk for a school district of about 5,000 people. It works each ticket as a visible sequence of tool-calls: it looks up the user and their device, recalls what it already knows about them, searches the district runbooks for the platform-correct fix, decides, and acts. Three things make it feel like a technician rather than a chatbot:
- The fix path branches on device type. "I can't log in" is a domain-controller problem on Windows ("no logon servers available"), a wrong-org-unit or enrollment problem on a Chromebook, and a Managed Apple ID problem on an iPad. It identifies the platform first.
- It sees the whole district. When several "not in ClassLink" reports arrive after a roster sync, or several devices from the same cart go dead, it opens an incident and tells every affected user it is a known issue. That is organizational memory: a defect and outage radar built from clustered reports.
- Sensitive actions wait for a human. Resetting a staff credential, unblocking a filtered site, or reimaging a device is proposed but not executed until a supervisor approves it.
How we built it
- CockroachDB holds the district's entire memory: users, devices, a shared loaner pool, runbooks, per-user memories, tickets, an append-only audit log, cross-user issue signals, recognized incidents, and the human-approval queue.
- Distributed vector indexing does triple duty from one embedding per ticket: recall the user's own memories (a per-user prefix index), retrieve the platform-correct runbook, and find semantically similar recent reports across all users to detect a defect.
- Serializable transactions make loaner checkout from the shared pool safe: two staff grabbing the same loaner at once resolve to exactly one assignment; the other retries and sees it is taken. A device is never handed to two students.
- AS OF SYSTEM TIME reconstructs an account exactly as it was at a past instant, so an audit can answer "what did the agent see when it acted at 8:05am."
- The agent reasons with Amazon Bedrock and Claude Sonnet 4.5, live on the deployed demo, with an offline stub brain as an automatic fallback and a hard daily cost cap. Embeddings use Amazon Titan Text Embeddings v2.
- A Flask server serves the operator desk as a ticket queue; a single container deploys to AWS App Runner.
Challenges we ran into
Making CockroachDB genuinely load-bearing rather than decorative. It already ships a first-party LangChain integration for vanilla vector storage, so we built on the things it does not give you: durability under a live node kill, natural concurrency on a scarce shared resource, and time-travel replay. We also kept the defect radar honest: three password resets in a day is a Tuesday, not a defect, so baseline categories never open an incident on volume alone, while genuine shared-root-cause categories (rostering, carts, network) do.
Accomplishments that we're proud of
All four "impossible in a single-node database" moments are real and verified on a live cluster: vector recall, node-kill survival (reads and writes continue with a node down), serializable correctness under contention, and time-travel. The domain is real, not invented: the tickets, runbooks, device-specific root causes, and pain points come from how school IT support actually works.
What we learned
The model is the commodity; the memory is the asset. When you build that way, a distributed SQL database stops being storage and becomes the agent's identity and governance layer.
What's next for Throughline
Wiring the live tools to real systems (Google Admin org-unit moves, ClassLink roster checks, Intune and Jamf profiles), and using the Managed MCP Server as a full natural-language console for querying the district's memory and open incidents in production.
Tools used (per the rules)
- CockroachDB: Distributed Vector Indexing (memory, runbook, and defect recall) and the Cloud Managed MCP Server (natural-language introspection on the deployed build).
- AWS: Amazon Bedrock with Claude Sonnet 4.5 (agent reasoning) and Amazon Titan Text Embeddings v2 (the vectors); deployed as a container on AWS App Runner.
Links
- Live demo: https://support.rowset.co
- Source (MIT): https://github.com/mark124/throughline
Log in or sign up for Devpost to join the conversation.