Lattice

• 

• 

• 

Inspiration

Agent systems are getting good at finding relevant information, but “relevant” is not the same as “safe.”

We kept coming back to one uncomfortable incident-response question: if an AI proposes an action because of a bad memory, can an operator prove exactly where that recommendation came from—and safely undo its influence before anything happens?

Most memory systems treat retrieval as the finish line. Lattice treats it as the start of an investigation. We wanted a control room that makes an agent’s memory visible: what it read, why it trusted it, what was rejected, and how the final plan changed when unsafe evidence was removed.

What it does

Lattice is a forensic control plane for AI agent memory.

For a checkout-degradation incident, it retrieves operational memories from CockroachDB using vector search and produces a recovery plan. Every retrieved memory is evaluated for provenance, signature status, trust score, policy violations, and semantic consistency with trusted memories.

In the demo, one memory suggests disabling JWT signature verification during key drift. It is relevant to the incident, but dangerous. Lattice flags it because it is unsigned, low-trust, semantically anomalous, and recommends an authentication bypass.

An operator can then quarantine that memory. Lattice reconstructs the exact CockroachDB state from when the first decision was made, replays the incident without the unsafe memory, and shows a Git-style before/after plan diff. The safer plan still requires human approval before it can proceed.

How we built it

We built Lattice as a Next.js control room backed by an AWS Lambda agent service and CockroachDB Cloud.

CockroachDB is the core of the product, not just storage:

• Native VECTOR(1024) indexing retrieves incident memories by cosine similarity.
• The same retrieval layer compares a memory against its verified cohort to identify semantic outliers.
• Each agent run records CockroachDB’s logical timestamp.
• On quarantine, Lattice uses AS OF SYSTEM TIME to reconstruct the exact memory snapshot behind the original decision.
• The intervention, blocked dependent read, replay branch, event record, and journal result are written in a retry-safe serializable transaction.
• Lineage records connect the run, recalled memories, guardrail decision, intervention, replay plan, and human approval.

We also used CockroachDB Agent Skills for transaction, privilege, and cluster-health guardrails, and the ccloud CLI to provision and assess the Cloud cluster.

Amazon Bedrock creates the incident and replay plans, while S3 stores a hashed, versioned evidence receipt. The deployed UI is designed around one clear operator workflow: inspect → quarantine → replay → compare → approve.

Challenges we ran into

The difficult part was making the demo honest.

A polished interface can easily fake a “before and after” story, so we made the UI read its timeline, trust scores, timestamps, and lineage directly from the backend. The replay is also not a copy of an application-level version table: it is a real historical query against CockroachDB MVCC state.

We also had to make semantic retrieval meaningful. Early embedding results did not separate safe incident evidence from the poisoned workaround clearly enough. We adjusted the retrieval path so trusted telemetry and verified recovery memories surface first, while the unsafe memory remains detectable through multiple independent guardrails.

Finally, we had to make the system feel operational rather than academic. A blocked recommendation is useful, but the real value is showing an operator what changed, why it changed, and what is now safe to approve.

Accomplishments that we're proud of

• Turned agent memory provenance into a visible, inspectable product experience.
• Made CockroachDB vector search, MVCC time travel, and serializable transactions load-bearing parts of the workflow.
• Built a replay that changes the actual plan after unsafe memory is removed.
• Kept a complete causal trail instead of relying on opaque model logs.
• Added a human approval gate so a safer plan still does not execute by itself.
• Deployed the full experience publicly for judges to test.

What we learned

We learned that trust in agent systems cannot be represented by one confidence score.

A memory can be highly relevant and still be unsafe. Trust needs evidence: who created the memory, whether it was signed, how old it is, whether it agrees with verified knowledge, which plan it influenced, and whether an operator approved the resulting action.

We also learned that temporal database features become much more powerful when they are part of the product story. AS OF SYSTEM TIME is not just a recovery feature here—it is how we answer, “What did the agent know at the moment it made this decision?”

What's next for Lattice

Next, we want to connect Lattice to real agent frameworks and production runbooks, so memory citations and approval gates can follow an agent across tools instead of living in a single demo workflow.

We also plan to add signed memory ingestion, policy packs for different teams, multi-operator approval, richer branch visualisation, and retention-aware evidence export for audits.

The larger goal is simple: agents should be able to use memory quickly, but they should never be able to hide behind it.

Built With

• agent-memory
• ai-agents
• amazon-bedrock
• amazon-nova
• amazon-titan
• amazon-web-services
• aws-lambda
• cloudflare-workers
• cockroachdb
• cockroachdb-cloud
• guardrails
• human-in-the-loop
• incident-response
• mvcc
• next.js
• node.js
• provenance
• react
• retrieval-augmented-generation
• serializable-transactions
• time-travel-queries
• typescript
• vector-search