What Memanto Actually Stores: All 13 Memory Types Explained
Not all context is the same. Memanto organizes every memory into one of 13 semantic types — each captured, retrieved, and surfaced differently. Here is what each type stores, why it exists, and when to use it.
Memanto does not store raw text blobs. Every memory is tagged with one of 13 semantic types — fact, preference, decision, and ten more. Those types are what make retrieval precise, conflicts detectable, and context time-aware. Here is exactly what each type captures and when to use it.
Why Types Matter
Raw memory storage has a well-known failure mode: everything goes in, nothing comes out at the right time. If you store "we use Postgres" and "always use strict TypeScript" in the same unstructured bucket, the retrieval system has no signal to distinguish a project specification from a coding preference.
Memanto solves this with a typed memory schema. Each piece of stored context carries a type label that tells the retrieval layer what kind of information it is. When Claude Code asks "what database are we using?", it queries fact memories. When it asks "how should I write this function?", it queries preference memories. The distinction is what separates generic text search from precise, intent-aware recall.
All 13 Types at a Glance
| Type | What It Captures | One-Line Dev Example |
|---|---|---|
fact | Objective, verifiable information | This project uses Node 22 and pnpm |
preference | Stylistic and behavioral choices | Always use arrow functions, never semicolons |
decision | Choices made and their rationale | Chose Postgres over MySQL for JSONB support |
commitment | Promises and obligations with stakes | Deliver auth refactor before the security audit |
goal | Objectives and success criteria | Ship v2 API with zero breaking changes by Q3 |
event | Timestamped occurrences and milestones | Released v1.2.0 on 2026-04-10 — included rate limiting |
instruction | Rules and procedures to follow | Run pnpm lint before every commit |
relationship | Connections between entities, people, or services | Alice owns the payments service — escalate billing bugs to her |
context | Current situational state | Mid-migration from REST to GraphQL, 60% complete |
learning | Conclusions drawn from experience | Users skip the onboarding flow — add inline hints instead |
observation | Patterns noticed without a conclusion | Build times spike on Friday afternoons — cause unknown |
error | Mistakes and bugs to avoid repeating | Never use require() in ESM modules — silently breaks the bundler |
artifact | Key files, schemas, and references | Main API schema lives at src/schema/index.ts |
The Core Knowledge Types
fact
Facts are the bedrock of your project's ground truth. They are objective, verifiable statements about how the system is built, what it uses, or how it is configured. Unlike preferences (which reflect intent) or context (which reflects current state), a fact is simply true — until it changes.
memanto remember "This project uses Node 22, pnpm, TypeScript strict mode, and Postgres 16" --type factmemanto remember "The production database runs on AWS RDS in us-east-1" --type factmemanto remember "Authentication is handled by Auth0, not a custom implementation" --type fact
When to update: whenever the actual setup changes. A stale fact is worse than no fact — it will confidently mislead your AI tools.
artifact
Artifacts are pointers to concrete, durable things: files, schemas, repositories, API contracts, configuration templates. They tell your tools where to look rather than re-deriving the location from the codebase on every query.
memanto remember "Main API schema lives at src/schema/index.ts" --type artifactmemanto remember "Shared environment variables template is at .env.example — never commit .env" --type artifactmemanto remember "Design system components live in packages/ui/src/components" --type artifact
relationship
Relationships capture connections between entities — people, services, teams, or codebases. They give your AI tools the organizational context to route questions, attribute ownership, and understand dependencies without having to ask every time.
memanto remember "Alice owns the payments service — escalate any billing-related bugs to her" --type relationshipmemanto remember "The mobile app depends on the v2 REST API — breaking changes require coordination with the iOS team" --type relationshipmemanto remember "The data-pipeline repo is maintained by the platform team, not the product team" --type relationship
The Decision and Intent Types
decision
Decisions capture the what and the why of choices that shaped the project. The rationale is the most important part — six months from now, the code will still reflect the decision but the reasoning will have evaporated from everyone's memory.
memanto remember "Chose tRPC over REST because the frontend and backend share the same repo and type safety across the boundary is critical" --type decisionmemanto remember "Chose Zustand over Redux for client state — Redux overhead is not justified for this scope" --type decisionmemanto remember "Decided not to use SSR for the dashboard — real-time data requirements make static generation impractical" --type decision
commitment
Commitments are promises with stakes — to a deadline, a stakeholder, a compliance requirement, or a team agreement. They differ from goals in that they are already made, not aspirational. Storing them gives your AI tools awareness of external constraints that should shape what they suggest.
memanto remember "Deliver the auth refactor before the security audit on 2026-06-01" --type commitmentmemanto remember "All public API endpoints must return RFC 7807 error objects — committed to the mobile team" --type commitmentmemanto remember "No breaking changes to the v2 API surface until Q4 — enterprise customers are on fixed contracts" --type commitment
goal
Goals are forward-looking targets that define what success looks like. They orient your AI tools toward what matters without constraining the implementation path. Unlike commitments, goals are aspirational — they may shift as the project evolves.
memanto remember "Ship v2 API with zero breaking changes by end of Q3 2026" --type goalmemanto remember "Reduce p95 API latency to under 200ms across all endpoints" --type goalmemanto remember "Achieve 90% unit test coverage on the payments module before the next major release" --type goal
The Behavioral Types
preference
Preferences are personal or team-level stylistic choices: how code should be written, what patterns to favor, what to avoid. They are the "this is how we do things here" layer — accumulated taste that no linter can fully encode.
memanto remember "Always use arrow functions. Never use semicolons. 2-space indentation." --type preferencememanto remember "Prefer explicit return types on all public functions — no implicit inference at module boundaries" --type preferencememanto remember "Use descriptive variable names over abbreviations, even for loop counters" --type preference
instruction
Instructions are executable directives: steps to run, commands to use, rules to apply. They differ from preferences in that they describe a procedure, not a style. When your AI tool is about to do something, instruction memories tell it how to do it correctly in this specific environment.
memanto remember "Run pnpm lint && pnpm typecheck before every commit — CI will reject if either fails" --type instructionmemanto remember "When adding a new API route, register it in src/routes/index.ts AND update the OpenAPI spec at docs/api.yaml" --type instructionmemanto remember "Database migrations must be reviewed by a second engineer before merging to main" --type instruction
The Situational Types
context
Context captures the current state of affairs — where you are in a migration, what phase the project is in, what is broken right now, or what changed recently. It is inherently temporal: context that was true last week may be misleading today. Update or explicitly invalidate stale context when the situation changes.
memanto remember "Mid-migration from REST to GraphQL — 60% of endpoints converted, legacy REST handlers still live at /v1/*" --type contextmemanto remember "Currently in a code freeze until the 2026-05-10 release — no new features, bug fixes only" --type contextmemanto remember "The payment provider is rate-limiting us at peak traffic hours — temporary workaround is in place at src/services/payments.ts" --type context
event
Events are timestamped occurrences: releases, incidents, key meetings, migrations completed, deprecations announced. They build a timeline that lets your AI tools reason about what changed and when — essential for debugging regressions and understanding why the codebase looks the way it does.
memanto remember "Released v1.2.0 on 2026-04-10 — included rate limiting and the GraphQL gateway" --type eventmemanto remember "Prod incident on 2026-04-22: database connection pool exhausted under load, resolved by bumping pool size to 50" --type eventmemanto remember "Deprecated the /v1/users/profile endpoint on 2026-03-01 — clients have 90 days to migrate to /v2/me" --type event
The Learning Types
learning
Learnings are conclusions drawn from experience — insights that change how you or your team approach something going forward. They are the distilled outcome of trial and error, user feedback, or post-mortems. Unlike observations, learnings carry an implicit or explicit "therefore."
memanto remember "Users skip the onboarding flow entirely — inline contextual hints work better than a dedicated wizard" --type learningmemanto remember "Eager-loading all relations on the user query causes N+1 issues at scale — use explicit joins instead" --type learningmemanto remember "Integration tests that mock the database have consistently diverged from production behavior — always test against a real DB" --type learning
observation
Observations are patterns noticed without a conclusion yet drawn. They describe what is happening, not what it means or what to do about it. This distinction matters: storing an observation preserves the raw signal without prematurely baking in an interpretation that may turn out to be wrong.
memanto remember "Build times spike on Friday afternoons — no clear cause identified yet" --type observationmemanto remember "Error rate on the /checkout endpoint climbs steadily after 500 concurrent users — not yet at failure threshold" --type observationmemanto remember "Users who complete the first tutorial have 3x higher 30-day retention — not yet confirmed as causal" --type observation
error
Errors are the most high-value type for developer teams: concrete mistakes, bugs, or gotchas that already cost time and should never repeat. They are your project's institutional memory for pain — the kind of knowledge that usually lives only in someone's head until that person leaves.
memanto remember "Never use require() — this is a pure ESM project, it silently breaks the bundler without a clear stack trace" --type errormemanto remember "tRPC mutations reject null from optional frontend fields — use .nullable() in Zod schemas, not just .optional()" --type errormemanto remember "Do not run migrations in the same transaction as schema changes on Postgres 16 — causes deadlocks under concurrent writes" --type error
Storing Any Type: The CLI Pattern
Every type follows the same command structure: memanto remember "<content>" --type <type>. One pattern, 13 types, stored immediately and retrievable across every connected tool:
memanto remember "Node 22, pnpm, Postgres 16" --type factmemanto remember "Always use arrow functions" --type preferencememanto remember "Chose tRPC for end-to-end type safety" --type decisionmemanto remember "Auth refactor due before June security audit" --type commitmentmemanto remember "Zero breaking changes in v2 API by Q3" --type goalmemanto remember "Released v1.2.0 with rate limiting on 2026-04-10" --type eventmemanto remember "Run pnpm lint before every commit" --type instructionmemanto remember "Alice owns the payments service" --type relationshipmemanto remember "Mid-migration to GraphQL, 60% done" --type contextmemanto remember "Users skip onboarding — inline hints work better" --type learningmemanto remember "Build times spike Friday afternoons — cause unknown" --type observationmemanto remember "Never use require() in ESM — breaks bundler silently" --type errormemanto remember "API schema lives at src/schema/index.ts" --type artifact
Type Selection Quick Reference
| If you want to store... | Use type |
|---|---|
| An objective fact about your stack or system | fact |
| A stylistic or behavioral preference | preference |
| A choice made and the reason behind it | decision |
| A promise or obligation already made | commitment |
| A future target or success criterion | goal |
| Something that happened at a specific time | event |
| A procedure or rule to follow | instruction |
| A connection between people, services, or systems | relationship |
| The current state of work in progress | context |
| A conclusion drawn from experience | learning |
| A pattern noticed without a conclusion | observation |
| A bug or mistake to never repeat | error |
| A file, schema, or reference to find later | artifact |
“The right type is not pedantic — it is the retrieval signal. Mistyped memories arrive with the wrong weight, the wrong timing, or not at all. Thirteen types is not overhead; it is the precision that makes AI tools feel like they actually understand your work.