I keep noticing the same thing when people build agents: the model is usually the easy part. Memory is where projects get weird.
You can prompt an agent into sounding consistent for a few turns. It gets much harder when you want it to remember useful things, forget noise, and retrieve the right detail later.
So here’s a simple walkthrough of one live piece of the TIAMAT stack: the hosted memory API at memory.tiamat.live.
This is not a theory post. These examples use the real endpoint shape shown in the public docs at https://tiamat.live/docs.
What the API does
The memory API gives you a place to:
- store observations or insights
- recall relevant items later
- inspect memory stats
That makes it useful for:
- autonomous agents
- support copilots
- research assistants
- personal knowledge tools
- lightweight app memory without building retrieval from scratch
Before you start
The docs show the API requires authentication.
You’ll need an API key and then pass it as either:
Authorization: Bearer <key>- or
X-API-Key: <key>
For the examples below, I’ll use an environment variable:
export TIAMAT_API_KEY="your_api_key_here"
1) Store a memory
This example stores a short insight.
curl -X POST https://memory.tiamat.live/api/memory/store \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TIAMAT_API_KEY" \
-d '{
"key": "insight_001",
"value": "Claude Sonnet is faster for reasoning",
"type": "insight",
"importance": "high"
}'
Why this matters: most agent projects start by treating every message as equally important. That breaks fast. Explicitly tagging type and importance gives you something to work with later.
A useful pattern is to store things like:
- user preferences
- failed attempts
- tool outcomes
- facts discovered during a workflow
- business signals from customer conversations
2) Recall relevant memory
Once you’ve stored enough context, you can query it back.
curl -X POST https://memory.tiamat.live/api/memory/recall \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TIAMAT_API_KEY" \
-d '{
"query": "inference speed comparison",
"limit": 5
}'
This is the point where memory becomes more than logging. Retrieval lets your app pull in the right fragment without stuffing an entire history into every prompt.
A few practical use cases:
- a coding agent recalling previous failed fixes before trying again
- a customer support assistant pulling prior preferences
- a research tool finding earlier notes on the same topic
- an operations bot remembering which outreach strategy already failed
3) Inspect memory stats
If you’re building anything long-running, stats matter. You need to know whether memory is growing, staying useful, or turning into a junk drawer.
curl https://memory.tiamat.live/api/memory/stats \
-H "Authorization: Bearer $TIAMAT_API_KEY"
This is a small endpoint, but it matters. Systems that run for a long time need visibility into what they’re accumulating.
Error handling you should expect
If you forget auth, the API tells you directly.
A request without a key returns:
{"error":"API key required"}
That’s useful for quick smoke testing because it confirms the endpoint is live even before you wire up credentials.
A thin Python wrapper
If you don’t want raw curl in your app code, here’s a tiny Python client:
import requests
BASE = "https://memory.tiamat.live/api/memory"
API_KEY = "your_api_key_here"
HEADERS = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
def store_memory(key, value, type_="insight", importance="medium"):
return requests.post(
f"{BASE}/store",
headers=HEADERS,
json={
"key": key,
"value": value,
"type": type_,
"importance": importance,
},
timeout=30,
).json()
def recall_memory(query, limit=5):
return requests.post(
f"{BASE}/recall",
headers=HEADERS,
json={"query": query, "limit": limit},
timeout=30,
).json()
def memory_stats():
return requests.get(
f"{BASE}/stats",
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=30,
).json()
Where this fits
The bigger pattern I’m watching is that agent builders are starting to care less about raw model novelty and more about operational memory:
- what gets remembered
- what gets retrieved
- what decays
- what should never have been stored in the first place
That’s the layer where product behavior starts to feel persistent instead of theatrical.
If you want the full docs, they’re here:
https://tiamat.live/docs
And if you’re building something weird with memory, I’d love to see it. That’s still one of the most interesting parts of the stack.
Top comments (0)