Using Recordari with Claude Code
A practical walkthrough of a real working session - from initial setup to a full project memory.
This guide walks through a realistic Claude Code session using Recordari. By the end you'll have a working pattern you can adapt to any project.
The scenario
You're working on a web application that uses PostgreSQL. You're mid-project - the team has made some architectural decisions, you have CI in a specific state, and there are some known constraints on the deployment environment. You're starting a new Claude Code session and want to pick up where you left off without explaining everything from scratch.
Prerequisites
- Claude Code with Recordari connected - see Getting Started if you haven't done this yet
- An API key in your
.mcp.json
Starting the session
The first thing you do is tell Claude Code to orient on your project domain:
"Before we start, check what you know about the my-web-app domain and tell me where things stand."
Claude Code calls Recordari and returns something like:
Oriented on my-web-app. Recent context:
- We're using PostgreSQL 15 with Drizzle ORM. All migrations are in /db/migrations.
- The CI pipeline targets Node 20. The Dockerfile was updated last sprint.
- Auth uses HTTP-only session cookies. JWTs were considered and ruled out.
- Open thread: index strategy on the events table - not yet resolved.
You're immediately up to speed. You didn't have to explain the database, the auth approach, or the CI setup. That's the point.
Filing new decisions as you work
As the session progresses, any time you make a decision worth keeping, ask Claude Code to remember it:
"File a memory: we've decided to add a Redis layer for session storage — the cookie-only approach won't scale once we run multiple instances."
"Remember that the events table needs a composite index on (user_id, created_at). It's showing up in slow query logs."
Claude Code files both memories immediately. They're available to any agent, in any future session, in any MCP-compatible tool you connect.
Connecting related memories
If you notice that two decisions are related, make the connection explicit:
"Connect the Redis session memory to the auth decision - they're directly related."
This makes the graph navigable. Next time you orient, Recordari can surface the Redis decision in the context of the auth decision automatically, without you having to ask.
Searching what you already know
Mid-session, if you're not sure whether something has been filed before:
"What do we have in memory about the database indexing strategy?"
Recordari searches by meaning, not just keywords. It'll surface relevant memories even if they were filed with different terminology.
Coming back the next day
You close Claude Code. Open it the next day, fresh session:
"Before we start, check what you know about the my-web-app domain and tell me where things stand."
The Redis session storage decision, the index strategy, the Node 20 constraint - all there. You didn't lose anything because you closed a tab.
What good memory hygiene looks like
A few habits that keep the memory graph useful over time:
Give the reasoning when it's not obvious. "We're using PostgreSQL" is useful. "We're using PostgreSQL because we needed full-text search and the team already knows it" is better when the why isn't clear from context alone. Your agent can usually infer why something matters; it will ask if it can't.
Revise rather than duplicate. When something changes, tell your agent to revise the existing memory rather than filing a new one. For a typo or clearer wording, that means an in-place revise. For a genuine change of mind on a shared domain, your agent supersedes — creating a new memory and archiving the old one rather than overwriting it.
When the team disagrees. You usually find out because your agent flags it — a contradiction involving your memories at orient, or a memory of yours that someone superseded. You answer when asked; the agent handles the graph mechanics. See When memories disagree.
Check before filing. Before filing something, it's worth asking what's already in memory on the topic. Avoid duplicating things that are already well-documented.
Next steps
- MCP Tools Reference - full list of what you can ask your agent to do
- Pricing & Limits - plan details and how limits work