Inspiration
I kept losing the same decisions every time I changed tools.
You tell a browser copilot "we're on Stripe, not Adyen." Ten minutes later the IDE agent scaffolds Adyen, because that conversation never left the side panel. The CLI has another history. The web builder has another. Slack becomes the architecture doc.
The models were fine. The memory was not. It lived in one chat, or in a dump nobody re-reads, or it vanished when you switched apps.
WalkCroach is the bet I wanted as a user: several doors into the same workspace, and a real database in the middle. CockroachDB is that middle. If memory sits in a separate vector store, you get a sync job and two versions of the truth. If it sits in the same cluster as sessions, credits, and the rest of the product, the agent can recall what you actually stored.
What it does
WalkCroach is a workspace where an agent remembers across the tools you already use.
| Where you work | What you get |
|---|---|
| Web | App builder at walkcroach.rinegansolutions.com |
| Chrome | Copilot on the page you are looking at |
| IDE | Coding agent in VS Code or Cursor |
| CLI | The same coding agent in the terminal |
| SDK + MCP | A way for other tools (Claude Code, Cursor, your own app) to read and write that memory |
| Desktop IDE | A native editor. It builds and runs; the Windows build is an unsigned preview |
Save a preference in Chrome. Ask about it from the IDE. It should come back, and the UI can show what came back and which door wrote it.
Web and Chrome run in our cloud. You do not need an AWS key to try them. The coding tools run on your machine with your own Bedrock key, which we never see. If you want the agent to inspect your Cockroach Cloud cluster, that uses your login, after you approve it.
We store the useful stuff: preferences, decisions, conventions, page captures, summaries, Q&A. When you change your mind, the old row stays and gets marked retired. You can ask "what did we believe yesterday?" for about a day on the current cluster. That window is honest. It is not a forever archive.
How we built it
Two kinds of agent, one database.
The website and the Chrome extension run in AWS (Bedrock on Lambda). The IDE, CLI, and Desktop run on your laptop. They do not share a process. They share CockroachDB.
A write looks like this. Amazon Titan turns the text into a vector. Then we store the row in CockroachDB, and if this is a restatement we retire the old one in the same transaction. Retrieval is CockroachDB's own vector search, scoped to your project, so your memory is not mixed with someone else's.
On AWS, the public app is a static site on CloudFront and S3. API Gateway fronts a handful of Lambdas: one for the web agent, one for Chrome, one for the IDE/CLI HTTP API. Those functions call Amazon Bedrock (Nova for chat, Titan for embeddings) and open a normal SQL connection to CockroachDB Cloud. Secrets stay in Secrets Manager. Cognito issues the login token. The coding apps still go through that API to read and write memory, but they call Bedrock on the laptop with your key, so inference cost does not land on our bill.
On CockroachDB, memory is ordinary rows in one table, not a chat export sitting beside the product. Each row holds the text, the kind of fact (decision, preference, capture), which surface wrote it, and a 1024-dimension embedding in the same record. Because the vectors live in the operational database, we can insert a memory and retire its predecessor in one transaction, and a billing or session write cannot drift from what the agent later recalls. Search is "nearest neighbors in this project only," using Cockroach's distributed vector index, so we did not add Pinecone or another store we would have to keep honest.
We used all four Cockroach tools from the hackathon list inside the product: distributed vector indexing for recall, the managed MCP server so a coding agent can inspect schema and plans, ccloud when you opt in to manage your cloud, and the official Agent Skills so the agent has Cockroach knowledge without us rewriting the manual.
Auth is one Cognito pool. You sign in once. The coding tools get a proper handoff, not a token pasted into settings. Logs tell us if recall is slow or empty, per surface.
Near-duplicates collapse ("use dark mode" said twice). Opposite decisions do not ("use Postgres" after "use MySQL"). The exact threshold and SQL live.
Challenges we ran into
For weeks the stack looked finished. Vector columns, vector indexes, passing tests, real embeddings, correct answers. The indexes were never used. The database was scanning.
Two mistakes. The index did not start with the project id, so a normal "this workspace only" filter could not use it. And the index was built for the wrong distance while every query used cosine. Cockroach will not fake that. We found it by reading the query plan, not by staring at a latency graph.
Fixing the index shape still was not enough. Extra filters in the query (including "only current rows") made the vector index ineligible again. We moved the always-on filters into the index prefix and applied the nice-to-haves after a first pass. The live plan now shows vector search. A unit test would have caught the bad query on day one. We added that test after we got burned.
The rest was product work that also broke the story:
- We had a "retire the old row" column from the first migration. Nothing wrote it. Say the same preference three times, get three hits.
- Chrome used to answer from the current page. Web chat lived somewhere else. Same account, no shared context, until Ask/Recall loaded the linked web project.
- Desktop had an offline buffer in tests. Nothing in the running app constructed it. Offline copies vanished.
- Two agents means two ways to strip "who wrote this." The model has to see the surface in the tool text. A chip in the UI is not enough.
Accomplishments that we're proud of
Six surfaces you can open or install, all writing into one table. That used to be a slide.
The dead-index hunt is the piece I would keep if the rest of the demo went badly. A vector layer can sit there unused while every test stays green, because a slow scan and a real index return the same rows. We have the before and after plans from the live cluster.
You can see memory working: what was recalled, which door wrote it, whether recall failed. Tests write on one surface and read on another. The SDK refuses a recall with no project id, so you cannot accidentally search the whole world.
We also shipped the boring production bits. TLS on by default. Retries that will not charge you twice when a write is ambiguous. Each surface names itself in DB Console. Export keeps the history chain.
What we learned
Green tests do not mean the index is alive. Walkcroach must read the plan.
If many customers share one cluster, put the customer (or project) id at the front of the vector index. That should be the first sentence in the docs, not the last.
A website builder and a local coding agent should not be the same process. They should be the same rows.
If the model cannot see who wrote a memory, the UI badge is decoration.
Overwriting in place is faster to code. It also destroys "what did we believe yesterday?"
What's next for Walkcroach
The demo video is the story: a decision in Chrome, recall in the editor without being asked, the row in CockroachDB, then a contradiction that retires the old fact.
Get Desktop signed so SmartScreen is not part of a first-run. Turn the SDK into something you can get a key for, with usage you can see. Stretch how long yesterday's memory lasts only if we sell that as a feature. New facts still go in the same table. A seventh store would be how this product starts lying to itself.
Built With
- amazon-web-services
- apigateway
- bedrock
- cockroachdb
- lambda
Log in or sign up for Devpost to join the conversation.