Skip to main content
Conare AI Memory gibt jedem deiner Endnutzer eine persistente, isolierte Memory. Deine App schreibt destillierte Beobachtungen; Conare übernimmt Embedding, Indexierung, hybrides Retrieval (Vektor + BM25, fusioniert und rerankt), LLM-Synthese und Connector-basierten Ingest.

Was es kann

  • SavePOST /api/v1/memories speichert eine Beobachtung für einen Endnutzer. Dedupliziert nach Inhalt. Batch-Import bis zu 100 auf einmal mit /memories/batch.
  • SearchPOST /api/v1/search: gerankte Treffer im Sekundenbruchteil über die Memory eines Nutzers. Nutze es, wenn dein eigener Agent das Reasoning übernimmt und einfach nur relevantes Rohmaterial braucht.
  • Deep RecallPOST /api/v1/recall: eine synthetisierte, zitatbasierte Antwort („was wissen wir über diesen Nutzer relevant zu X”), gedacht zum Injizieren in einen System-Prompt am Session-Start.
  • SuggestionsPOST /api/v1/suggestions: in einem Kontextmoment bis zu 5 konkrete nächste Aktionen, jeweils in einer konkreten Memory verankert – nie generischer Rat. Liefert [] für neue Nutzer, also rendere bedingt und lade asynchron.
  • Connector-Ingest – Endnutzer verbinden ihre Tools (Integrations) und ihre Memory füllt sich von selbst, organisiert in per-source Container.

Source-owned Memories

Wenn du Memories aus einem System of Record synchronisierst (CRM-Zeilen, Profilfelder, Tickets), nutze die versionierte Lifecycle-Oberfläche: Upserts und Deletes tragen eine version, sodass out-of-order Zustellungen und Crash-Retries konstruktionsbedingt sicher sind. Lies den Source-owned-Memories-Guide.

Lifecycle & Compliance

  • DELETE /api/v1/memories/by-id/{memoryId} – eine Memory entfernen.
  • DELETE /api/v1/containers/{containerTag} – Memories einer Quelle für einen Nutzer löschen.
  • DELETE /api/v1/users/{endUserId} – vollständiger DSGVO-Wipe eines Endnutzers.

Zwei Nutzungsarten

  1. Partner-HTTP-API (dieser Abschnitt + API-Referenz) – Memory für die Nutzer deines Produkts.
  2. MCP – Coding-Agents nutzen Conare-Memory direkt. Siehe MCP-Tools.