GitIntent

Inspiration

We kept watching AI coding agents make the same mistakes twice.

An agent would try a fix, hit a wall, revert it, and move on. An hour later a different agent would open the same file, have the same reasonable idea, and walk straight into the same wall. Git was no help, because Git only records what survived. The failed attempt, the reverted approach, the reason a tempting fix was a trap, all of it is gone the moment it does not get committed.

Our idea began with one question:

"Git was built for how humans write code. What does version control look like when it is built for how AI agents write code?"

Humans remember why something did not work. Agents do not. So we set out to give a repository a memory of its own intent, not just its surviving code.

What it does

GitIntent is a repository-specific memory layer that remembers what was tried, what failed, and why. It has four parts:

• Capture CLI — a gi command that turns each meaningful code change into a content-addressed snapshot. Memory is captured at the diff level, the actual hunk, not the whole file and not the whole session.
• Content addressing — every hunk and every snapshot gets an id derived from a hash of its content and the intent behind it. This is the same trick Git uses to address blobs and commits, pointed at change and intent instead of files. It also gives us automatic deduplication.
• Embedding + Redis memory — each change is embedded with voyage-code-3 and indexed in Redis Stack as searchable memory.
• Hybrid retrieval — when an agent asks a question, Redis runs semantic vector search and keyword search at the same time and fuses the rankings, returning the most relevant past attempts and decisions.

A typical interaction looks like this: Code change → CLI captures it → embed → store in Redis. Then later, Agent question → embed query → Redis hybrid search → relevant past attempts and failures returned before new work begins.

How we built it

• Backend: FastAPI, two endpoints, store and search, with bearer auth and a consistent error contract.
• Memory engine: Redis Stack. Each memory is indexed with both a vector field (HNSW, 1024 dimensions, cosine) and a text field (BM25), so a single store does semantic and lexical search together and fuses them with Reciprocal Rank Fusion.
• Embeddings: voyage-code-3, with input typed as document on store and query on search, and a deterministic fallback so the system runs offline.
• Addressing: a shared canonical hashing scheme so the CLI and the server compute byte-identical ids, which makes dedup and idempotency reliable.
• Architecture: a two-store model. A turn store holds the raw firehose of every agent step, and an invoke store holds curated, high-signal checkpoints. Search reads the right store for the right signal level.

Workflow: Capture change → hash and dedupe like a Git object → embed → index in Redis → on search, embed the query → vector plus keyword retrieval in Redis → fuse and return.

Challenges we ran into

Turning fast, messy AI coding sessions into reliable intent snapshots was difficult because the plugin, CLI, backend, hashing, and search contract all had to stay perfectly aligned without interrupting the developer’s flow.

Accomplishments that we're proud of

We built Gitintent as an end-to-end semantic memory layer that captures code changes, prompts, summaries, and diffs through an OpenCode plugin and gi CLI, then makes that history searchable for future humans and agents.

What we learned

The biggest thing we learned is how much value is hidden in past mistakes. A failed attempt is not wasted work, it is information, and the reason something did not work is often more useful than the thing that finally did. Git throws that away, and so do AI agents, which is exactly why they keep repeating the same dead-ends.

We also learned that the hard part of memory is not the AI model, it is deciding what is worth remembering and how to find it again. Keeping track of what was tried, and why it failed, turned out to be the whole point.

What's next for GitIntent

Deeper integration with agent runtimes, so checking memory before acting becomes automatic rather than a manual step. Ranking that weighs recency and reverts more heavily, so the most relevant lesson surfaces first. And scaling the two-store model across many repositories, so the longer an agent works in a codebase, the more its learning compounds.

Git stores code. GitIntent stores learning.

Built With

• fastapi
• opencode
• python
• redis
• redis-stack
• redisearch
• voyageai