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

Built With

Share this project:

Updates