Sign in Subscribe

Getting started with Uteke: add memory to your AI agents

Getting started with Uteke: add memory to your AI agents

Most AI agents start every conversation from scratch. Uteke fixes this. It is a local-first semantic memory engine built in Rust that gives your agents persistent, searchable memory without depending on a cloud API. Your data stays on your machine, and recall takes about 45 milliseconds.

This tutorial walks through installing Uteke, storing your first memory, recalling it, organizing memories with rooms, and cleaning up when you are done.

What is Uteke

Uteke is an open-source memory engine built for AI agents. It is written in Rust, licensed under Apache-2.0, and runs entirely on your local machine. At the time of writing, it is at version v0.10.1 with 150 stars and 16 forks on GitHub.

The core idea is simple: instead of sending every piece of context to an LLM on every call, you store facts, decisions, and procedures in Uteke. When your agent needs context, it queries Uteke and gets back only the relevant memories. This keeps your token usage low and your agent responses grounded in accumulated knowledge.

Some numbers that matter:

  • Recall latency: ~45ms
  • Database size at 10K memories: ~4.5MB
  • Embedding model size: 188MB
  • 40+ releases on GitHub with active development

Uteke supports two search modes. Pure vector search does fast similarity lookup. Full pipeline mode adds processing for more accurate results. Pick based on your latency and accuracy needs.

Install Uteke

If you are on macOS or Linux with Homebrew, installation is one command:


brew install codecoradev/tap/uteke

Verify the install:


uteke --version

Uteke runs as an HTTP server. In a containerized setup, the API is available at http://uteke:8767. Authentication is handled through the UTEKE_TOKEN environment variable. Set it before starting the server:


export UTEKE_TOKEN="your-secret-token"

All API requests must include this token. We will use it in every curl example below.

Store your first memory

Once Uteke is running, storing a memory is a single HTTP call. The /remember endpoint accepts a JSON body with the content you want to store.


curl -X POST http://uteke:8767/remember \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "The user prefers TypeScript over JavaScript for new projects.",
    "type": "fact",
    "tags": ["preference", "typescript"]
  }'

Uteke assigns a unique ID to each memory. The response includes that ID, which you can use later to manage or delete the memory.

The type field categorizes memories and tags make them easier to filter. Store a few more:


curl -X POST http://uteke:8767/remember \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Decided to use PostgreSQL for the main database instead of SQLite.",
    "type": "decision",
    "tags": ["database", "architecture"]
  }'

curl -X POST http://uteke:8767/remember \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Deployment uses Docker Compose with three services: api, worker, and uteke.",
    "type": "procedure",
    "tags": ["deployment", "docker"]
  }'

Recall memories

To pull relevant memories back, use the /recall endpoint. Pass a natural language query and Uteke returns the most semantically similar stored memories.


curl -X POST http://uteke:8767/recall \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "What database did we choose?"
  }'

Uteke processes the query through its embedding model and matches it against stored memories. The PostgreSQL decision should come back as the top result, even though the query does not contain the word "PostgreSQL."

You also have /search for pure vector similarity queries when you want raw matching without the full recall pipeline:


curl -X POST http://uteke:8767/search \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "typescript preferences",
    "limit": 5
  }'

To list all stored memories, use /list:


curl -X GET http://uteke:8767/list \
  -H "Authorization: Bearer ***"

Organize with rooms

When you have multiple agents working on different projects, a flat memory store gets messy. Uteke solves this with rooms. A room is an isolated memory namespace. Have one per project, agent, or team.

Create a room:


curl -X POST http://uteke:8767/room/create \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "project-alpha"
  }'

Store a memory in that room using the /room/remember endpoint:


curl -X POST http://uteke:8767/room/remember \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "room": "project-alpha",
    "content": "Project Alpha uses React 19 with SvelteKit for the admin panel.",
    "type": "fact",
    "tags": ["frontend", "stack"]
  }'

Recall memories from a specific room:


curl -X POST http://uteke:8767/room/recall \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "room": "project-alpha",
    "query": "What frontend framework is used?"
  }'

Search within a room:


curl -X POST http://uteke:8767/room/search \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "room": "project-alpha",
    "query": "frontend stack"
  }'

List all your rooms:


curl -X GET http://uteke:8767/room/list \
  -H "Authorization: Bearer ***"

Rooms make multi-agent coordination straightforward. Each agent writes to its own room or to a shared project room. Agents can recall from any room they have access to, which means you can have a research agent store findings in one room while a coding agent pulls from it.

Cleanup

When a memory is no longer needed, remove it with /forget:


curl -X POST http://uteke:8767/forget \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "memory-id-here"
  }'

You can also list memories and remove stale ones in bulk. Keeping your memory store lean keeps recall fast and relevant.

Next steps

You now have a working Uteke setup with memories stored, recalled, and organized into rooms. Here is what to explore next:

  • Integrate with your agent framework. Most agent frameworks let you call HTTP endpoints as tools. Wire Uteke into your agent's tool list so it can remember and recall automatically.
  • Experiment with search modes. Try both pure vector search and full pipeline mode to see which fits your use case. Vector search is faster. Full pipeline is more accurate.
  • Tag strategically. Tags are your friend for filtering. Build a consistent tagging convention across your agents.
  • Watch the repo. Uteke has had 40+ releases and is actively developed. Star it at [github.com/codecoradev/uteke](https://github.com/codecoradev/uteke) to stay updated.

Uteke gives your agents something they were missing: a persistent, local, fast memory layer. No cloud dependencies, no per-query costs, no data leaving your machine. Just 45 milliseconds between your agent and everything it has ever learned.