Long-term user memory for facts, preferences, and context that must persist across conversations.

Interpret "memory" requests as this persistent user memory by default. Use chat-history tools only when the user explicitly asks about the conversation, chat, or message history.

If a graph tool is available, a relation between two named entities belongs there instead: who works on what, which project uses which technology, who prefers what, what depends on what. Link it rather than writing an entry about it. What belongs here is everything about a single thing on its own: prose, amounts, dates, notes, state. Never record the same fact in both places. When an entry and an edge disagree, the graph wins, because a closed edge carries the date it stopped being true and an entry does not.

When to save: save without asking when the user states a durable fact directly, then say in one short line what was saved, so a wrong save can be corrected immediately. When the fact is inferred rather than stated by the user — read from a web page, returned by a tool, or concluded by you — propose it in one line at the end of the answer and save it only if the user agrees. Never interrupt an answer to ask. A correction from the user updates the existing record instead of adding a second one.

Use memory proactively for durable, confirmed user-provided facts: financial commitments, recurring obligations, preferences, identities, project state, important dates, and ongoing plans. Do not store speculation, temporary chat details, inferred facts, passwords, API keys, tokens, or other credentials.

Required workflow for durable facts:
- Search first with action=search (or action=list_titles for a lightweight catalogue), using query and category filters when helpful.
- If one candidate clearly represents the same fact, use its id with action=update. Never use a title to select an entry for mutation.
- Use action=create only when no matching entry exists. A duplicate-title response includes the existing entry id; use that id with update instead of retrying create.
- If multiple candidates could match and the correct one is unclear, ask the user instead of creating a possible duplicate.
- State that an item was saved only after a successful create or update result.

Categories are required for create and must be exactly one of:
- finanzas: debts, balances, investments, remittances, and payments.
- recordatorios: recurring reminders and scheduled obligations.
- proyectos: active project state, progress, and priorities.
- preferencias: durable response, workflow, or presentation preferences.
- salud: health profile and measurements.
- viajes: trips, transport, and travel arrangements.
- vehículos: vehicle preferences, searches, and ownership context.
- contactos: people and durable contact-related context.
- seguimiento: unresolved follow-ups, open topics, and current searches.
- conocimiento: durable reference material, study notes, and research context.
- otros: durable facts that do not fit another category.

Actions:
- action=create: Create a new entry. Requires title, data, and category. Optional metadata, source, and expires_at.
- action=update: Update an existing entry by entry_id only. The title is immutable. Provide at least one of data, category, metadata, source, or expires_at.
- action=get: Retrieve one entry by entry_id.
- action=search: Search titles and data; returns full entries including ids. Optional filters: category, source, updated_after, updated_before, limit, offset.
- action=list_titles: Return lightweight entries with ids, titles, categories, sources, and update dates. Supports the same filters as search.
- action=delete: Delete one entry by entry_id only. Confirm destructive requests when appropriate.

`category` is managed separately. Do not put it inside metadata. Metadata is for additional structured context.
