Google Cloud Rapid Agent Hackathon — Elastic Partner Track

One env var. Cloud to self-hosted.

Same agent, same code, same interface. MEMORY_BACKEND=elastic or MEMORY_BACKEND=engram. Elastic Cloud (ELSER semantic search, ES|QL, Kibana) ↔ Engram-rs (local SQLite+FTS5). Zero code changes.

Backends

2 engines

Elastic Cloud with ELSER semantic search + Engram-rs with local FTS5. One abstract MemoryBackend.

Swap Cost

1 env var

Change MEMORY_BACKEND between elastic and engram. Zero code changes. Same tests pass on both.

Elastic Features

3 APIs

ELSER semantic search, ES|QL reflect queries, Kibana dashboard. Partner tech surfaced end-to-end.

The Dual-Backend Architecture

Both backends implement the same abstract MemoryBackend interface. The agent doesn't know which one is running — and it shouldn't have to. This is the genuinely good idea the judges should see.

Cloud Backend

Elastic + ELSER

Semantic search via ELSER NLP model. Finds paraphrased memories that keyword search misses. ES|QL for structured reflect queries. Kibana dashboard for memory analytics.

Local Backend

Engram-rs

Self-hosted SQLite + FTS5. Sub-millisecond keyword recall. Zero cloud dependencies. Same agent code, same MemoryEntry format, same 15 tests passing.

Hybrid Search Demo: Why Semantic Matters

Engram (Keyword)

Query: "how to build fast"
Memory: "we use Rust for speed"

Result: ✗ MISS

"build fast" ≠ "Rust for speed". Keyword matching fails on paraphrased knowledge.

Elastic ELSER (Semantic)

Query: "how to build fast"
Memory: "we use Rust for speed"

Result: ✓ MATCH (0.84)

ELSER understands that Rust is a fast language — semantic search finds what keywords miss.

Quickstart

deploy

# Elastic Cloud (partner track)
export MEMORY_BACKEND=elastic
export ELASTIC_CLOUD_ID=...
python -m agent.main

# Engram-rs (self-hosted fallback)
export MEMORY_BACKEND=engram
python -m agent.main

# Same agent. Same code. One env var.

Rapid Agent on GitHub →