Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for FLEETMIND

Inspiration

Autonomous fleets repeat failures because each robot learns locally. A collision in one warehouse, shift, or region rarely becomes an actionable memory for the next robot. FLEETMIND asks a simple question: what if a physical failure became a durable, searchable episode that could change another robot's next action?

What it does

FLEETMIND gives autonomous fleets a shared episodic memory. In the live demo, Robot #07 follows its planned lane and collides with fallen cargo. The observed state, route, action, outcome, and lesson are committed to CockroachDB. Robot

19 later encounters a similar situation, retrieves that episode through

vector search, and reroutes before reaching the obstacle.

The demo exposes the full causal chain: collision, confirmed memory write, retrieved memory_id, similarity score, changed action, and successful second run. If the database or AWS API is unavailable, the success path remains locked.

How we built it

The browser runs a live deterministic warehouse simulation. A collision sends structured evidence to a public AWS Lambda Function URL. Lambda creates a normalized situation vector, reflects on the failure, and writes the episode and audit evidence to CockroachDB in one transaction.

For the second run, Lambda queries CockroachDB's distributed vector index using cosine distance. The returned episode ID is written into a second audit event that attributes the route change to that memory. CockroachDB Managed MCP gives judges a read-only path to inspect the same episode and audit trail.

CockroachDB usage

  • Distributed Vector Indexing on fleet_episodes.embedding VECTOR(64)
  • Strongly consistent episode and audit writes
  • Vector recall using cosine distance
  • Managed MCP read-only inspection of memories and action-changing audits

AWS usage

  • AWS Lambda for memory reflection, writes, recall, and action planning
  • Lambda Function URL restricted to /health, /episodes, and /recall
  • CloudWatch Logs for operational evidence and failures

Challenges

The main design challenge was proving that memory changes behavior instead of merely displaying history. We made the simulator fail closed: Run 2 cannot start until CockroachDB returns a confirmed memory ID, and the alternate lane cannot unlock unless vector recall returns that same ID with a reroute action.

Accomplishments

  • A real simulation event produces a durable episodic memory.
  • A later agent changes its route because of a specific retrieved memory.
  • Every memory write and action change is attributable through audit records.
  • The demo visibly separates application state from infrastructure evidence.

What we learned

Agentic memory needs more than retrieval quality. It needs causality, provenance, failure behavior, and an audit trail that shows exactly why an agent changed course.

What's next

The narrow collision demo can extend to warehouse fleets, drones, field robots, and software agents. Future work includes memory consolidation, confidence decay, cross-fleet policy controls, and multi-region evaluation.

Submission links

Verifiable demo evidence

  • Frozen implementation commit: a2ea8cf6fbcb72c067b2a42a9188def7be9b2939
  • Recorded memory ID: 98c8435f-9d39-4e55-9689-a9531c923230
  • Run 1: COLLISIONWRITE_CONFIRMED
  • Run 2: same memory ID → 82% MATCHREROUTE → LANE 1SUCCESS
  • Managed MCP read-only audit: WRITE_CONFIRMED and RECALL_CHANGED_ACTION

Built with

CockroachDB, Distributed Vector Indexing, Managed MCP, AWS Lambda, Lambda Function URLs, CloudWatch, Python, TypeScript, React, and vinext.

Built With

  • ai-agents
  • aws-lambda
  • cloudwatch
  • cockroachdb
  • distributed-vector-indexing
  • lambda-function-url
  • managed-mcp
  • python
  • react
  • typescript
  • vector-search
Share this project:

Updates