September 2026 Summaries

Company Brain, a discontinued product now released as open source, is presented as a Cloudflare-based Slack agent harness designed to behave like a reliable teammate rather than a simple prompt-response bot. Built around a Cloudflare Durable Object per organization, it manages event routing, persistent turn state, permissions, tool access, approvals, recovery, telemetry, and integrations with Slack and connected applications. Its triage system evaluates usefulness, confidence, urgency, noise, and interruption cost to decide whether to answer, investigate, acknowledge with a reaction, or remain silent, with configurable proactivity by channel. The architecture separates durable organizational memory from live operational data, scopes memory by public channels, direct messages, and private channels, and uses progressive tool disclosure to reduce context overhead and enforce policy. Long-running work is governed by a phased model loop that streams progress, limits steps, supports approval checkpoints for consequential actions, and ensures the model produces a final response rather than ending on an unfinished tool call. The system also handles active-thread updates by determining whether new messages should add context, replace a request, stop work, or be ignored, reflecting its emphasis on concurrency, privacy, reliability, and minimizing disruptive or unnecessary interventions.

A founder of Supermemory examines how Jev, a fast decision-focused model from TypeSafe AI, could affect common agent-memory pipelines involving chunking, observation, storage, retrieval, and context injection. Tests described in the post found that Jev improved initial retrieval rankings over BM25 and performed competitively with specialized rerankers, although it was generally more expensive than lower-cost alternatives and did not consistently lead on quality. The model reportedly produced particularly strong semantic chunking results, including for messy and multilingual material, but at substantially higher cost than rule-based or embedding-based approaches. Using Jev to filter sentences before memory extraction reduced content tokens by 58% in internal tests, yet the approach risked losing important context and was judged unsuitable as a general memory compactor. The author found more promise in using Jev for harness-level decisions, such as determining whether an agent should retrieve memory for a user prompt, including requests that explicitly exclude memory use. Overall, the post presents Jev as a potentially useful component across memory systems while emphasizing that specialized models and existing methods remain preferable for some tasks.

An author describes a speculative reverse-engineering of Instinct’s iMessage assistant memory system based on interface probing rather than source-code access, concluding that it likely combines a persistent user profile, a daily updated memory summary, compacted conversation context, a todo index, and git-tracked Markdown records. The reported file structure organizes people, organizations, facts, preferences, decisions, communications, timelines, and workstreams using structured metadata, aliases, and cross-links, while background ingestion appears to reconcile, compress, correct, and occasionally prune information roughly every 24 hours. Instinct reportedly retrieves records through grep-like keyword matching rather than vector or BM25 search, making aliases important, and keeps memory read-only for the main agent while separate processes update it. The assessment finds it strong at explicit factual recall, temporal updates, contradiction handling, and in-session learning, but weaker in multi-hop retrieval, natural personalization, multimodal memory, procedural knowledge, and automatic forgetting. The author then argues that the same design could be reproduced with Supermemory, promoting its profiles, dynamic memory buckets, search tools, automated reconciliation and forgetting, multimodal ingestion, and on-demand versioned record construction as alternatives to Instinct’s file-based approach.

Evaluating Zep should focus on tracing how application source events become agent context, including identity handling, event updates, retrieval quality, and responsibilities that remain with the application. A useful assessment follows a fictional timestamped customer event from ingestion through association with a user or group to the evidence returned for a later query, distinguishing retrieval failures from cases where an agent misuses available context. Testing should include explicit corrections and late-arriving older records while preserving both event and ingestion times, and teams should verify the exact product’s supported behavior rather than assuming graph queries, historical reconstruction, or deletion capabilities. Authentication, authorization, source ownership, transactional state, error handling, delays, conversation history, and cache invalidation are application-level concerns, while managed Zep and the open-source Graphiti framework should be evaluated as distinct deployment choices. Comparisons with alternatives such as Supermemory should use identical histories, questions, access scenarios, latency conditions, API versions, and configurations, with implementation selected based on demonstrated behavior and an operating model suited to the workload.

Supermemory’s comparison post argues that Mem0’s competing comparison page contains incomplete or misleading claims about benchmarks, pricing, token use, and product capabilities, while acknowledging that the post is published by Supermemory and should be read with that bias in mind. It says Supermemory achieved 95% Recall@15 on LongMemEval_s with aggregation and leads on LoCoMo, whereas Mem0 cited a lower non-aggregated Supermemory result and left other benchmark entries blank; it also notes that BEAM is Mem0’s proprietary benchmark. The post contrasts Mem0’s Apache 2.0 core library, large community, broad framework integrations, and SOC 2 and HIPAA-supported managed offering with Supermemory’s MIT-licensed full engine, offline single-binary self-hosting, multimodal ingestion, managed data connectors, automatic user profiles, versioning, contradiction resolution, and forgetting. It describes Mem0 as using manually managed memory objects and memory-count pricing, while Supermemory emphasizes usage-based pricing, published retrieval and token metrics, and broader lifecycle automation. It concludes that Mem0 may suit users seeking a lightweight embeddable library and established integrations, while Supermemory may better suit those needing managed ingestion, automatic memory maintenance, profiles, reproducible benchmark results, or simplified self-hosting.

OpenCode Supermemory is an open-source plugin designed to give OpenCode persistent memory across sessions by automatically injecting relevant user, project, and prior-session context, selectively recalling memories, capturing completed conversations, recognizing custom “remember” prompts, and preserving knowledge during context compaction. Installed through Bun commands or by having OpenCode process its README, the plugin stores configuration in the user’s OpenCode settings and includes an initialization command that explores a codebase to record its architecture and conventions. Its central feature is repository-based shared memory: OpenCode, Claude Code, and Codex plugins can access the same memory container derived from a repository’s Git origin, while separating personal and shared project memories and preserving compatibility with legacy containers. Agents use a Supermemory tool to add, search, view, list, and delete categorized memories, with configurable retrieval thresholds, capture schedules, compaction behavior, and keyword triggers. The plugin supports privacy through redaction of content inside private tags and can run fully offline through a self-hosted, MIT-licensed Supermemory instance. Unlike the Supermemory MCP alone, which depends on an agent choosing to invoke memory tools, the plugin ensures automatic context injection, capture, and compaction integration.

Hermes offers a native Supermemory provider intended to give agents persistent, cross-platform memory across channels such as Telegram, Discord, Slack, WhatsApp, Signal, and the CLI, addressing the limitations of large flat MEMORY.md files. After installation and API-key configuration, the provider automatically retrieves relevant context before conversations, captures cleaned turns after responses, ingests full sessions for richer updates, and supplies tools to save, search, forget, and retrieve profile information. Supermemory maintains evolving user profiles containing stable details and current priorities, supports separate memory containers for work, personal, and project contexts, and provides hybrid memory and document search, versioned updates, and deletion capabilities. It also preserves salient information before context-window compression, can mirror local MEMORY.md and USER.md files rather than replace them, and offers configurable recall, capture, search, and profile-refresh settings. The system can additionally be self-hosted through its MIT-licensed implementation so memory data can remain within an organization’s infrastructure.

Supermemory is a Claude Code plugin designed to provide persistent, evolving memory across coding sessions, addressing the need to repeatedly supply project details, technical constraints, and personal preferences. Installed through Claude Code’s plugin marketplace, it automatically captures relevant conversations and tool activity, selectively recalls information before prompts, separates shared project knowledge from personal memory, and offers commands for indexing codebases, configuring projects, and managing sessions. Its approach complements rather than replaces CLAUDE.md files, which remain useful for fixed rules while persistent memory records changing decisions, work context, coding style, and past solutions. The system uses “hybrid memory” to extract and update facts over time rather than relying only on similarity-based retrieval, and it claims a 95% score with aggregation on the LongMemEval benchmark. Unlike the Supermemory MCP integration, the plugin can automatically inject a user profile at session start and capture interactions without depending on Claude to invoke tools, while also supporting self-hosted local operation for users who want data to remain on their own machines.

A founder of Supermemory presents a competitor-biased comparison of Mem0 and several memory-management alternatives for AI agents, arguing that users often seek broader document ingestion, user profiles, connectors, managed infrastructure, and scalable retrieval beyond conversational fact extraction. The piece cites Scira AI’s reported migration from Mem0 to Supermemory, claiming improvements in latency and usage, while characterizing Mem0 as better suited to scoped chat memory when document retrieval is already handled elsewhere. It positions Supermemory as a managed and open-source memory engine with profiles, graph-based retrieval, connectors, local deployment, and multi-tenant controls; Zep as a temporal conversation-memory graph; Letta as a stateful autonomous-agent runtime; OpenMemory as a privacy-focused local MCP option; and Postgres with pgvector as a practical but more labor-intensive choice for early prototypes. It also contrasts pricing approaches, claiming Mem0’s request caps offer predictability while Supermemory’s usage-based model can be cheaper for high retrieval volumes, and outlines an export-and-import migration path from Mem0.

Migrating from Mem0 Platform v3 to Supermemory requires redesigning application integration rather than simply renaming APIs, because the systems differ in isolation boundaries, ingestion, retrieval scoring, lifecycle behavior, and identifiers. The key architectural decision is mapping Mem0’s user, agent, app, and run scopes into Supermemory’s single deterministic containerTag authorization boundary while preserving other dimensions as metadata, with careful validation to prevent tenant data exposure. The process calls for an immutable, deduplicated Mem0 export; separate handling of extracted facts through direct memory creation and raw content through normal ingestion; metadata flattening; source-to-destination ID ledgers; and retry-safe checkpoints. Teams should dual-write production events, retain Mem0 as the read authority while backfilling, compare retrieval quality using a golden query set, and tune Supermemory limits and similarity thresholds independently rather than transferring Mem0 scores. Validation should test fact recall, isolation, expiration, duplicate handling, asynchronous indexing, latency, and lifecycle operations, since updates, deletion, forgetting, and expiration do not map directly between providers. A reversible rollout using shadow reads, feature flags, an append-only write log, and a representative pilot tenant is recommended, while Mem0 data should remain intact until rollback risks and production behavior have been fully verified.

Cognee and Supermemory are presented as differing approaches to AI memory systems: Cognee is described as an open-source framework that combines relational, vector, and graph databases operated by the user, while Supermemory is positioned as a managed or self-hosted memory engine with a unified API. The comparison, published by Supermemory and stated to have been reviewed against documentation in September 2026, argues that Cognee emphasizes infrastructure flexibility and requires users to configure storage backends, extraction pipelines, integrations, and retrieval behavior, whereas Supermemory includes built-in ingestion, profiles, memory versioning and expiration, multimodal processing, connectors, hybrid retrieval, and SDK integrations. It also contrasts Cognee’s manual deletion and temporal querying with Supermemory’s claimed lifecycle features for updating, resolving, and expiring memories, and cites Supermemory’s published benchmark results and latency figures while noting Cognee’s separate BEAM benchmark. The piece suggests Cognee may suit developers interested in assembling and operating their own memory infrastructure, while portraying Supermemory as better suited to production applications that require managed memory, user profiles, data-source connectors, tenant isolation, and measured retrieval performance.

Selecting an alternative to Mem0 should begin with a clear, evidence-based description of the specific behavior that needs replacement, such as missed corrections, unavailable records, source-support gaps, operational burden, or deployment limitations. A replacement brief should document reproducible failures, configurations, SDK versions, source history, success criteria, and whether requirements such as isolation, deployment location, and deletion support are non-negotiable release gates rather than preferences. Evaluations should distinguish vendor claims from observed API responses, retrieval tests, contracts, and configured deployments, while also accounting for engineering responsibilities across ingestion, extraction, synchronization, retrieval, permissions, profiles, and lifecycle management. Pilots should use limited authorized data, stable source identifiers, shadow reads, retained source records, and rollback plans until correction, retry, and deletion behavior has been validated. Supermemory or other candidates should be assessed against the same failed cases and operating requirements, with migration decisions based on testable evidence rather than generic vendor rankings.

Supermemory’s Scira customer story is presented as a source of practical migration test ideas rather than proof of universal performance, focusing on indexing, retrieval, context preservation, and integration compatibility. Organizations should translate reported problems into measurable acceptance tests using their own representative documents, user questions, conversation patterns, scopes, corrections, unavailable sources, updates, and deletions. Evaluations should distinguish failures caused by connectors, permissions or scopes, processing delays, retrieval, and prompting, while also measuring diagnostic effort, recovery time, observability, and support responsiveness. A fair migration assessment runs identical workloads on current and candidate systems, investigates disagreements, documents test conditions and results, maintains a rollback plan, and validates indexing, recall, correction, and deletion behavior before moving production data.

Migrating from Mem0 to Supermemory requires mapping the application’s actual behavior and data contract rather than assuming similarly named APIs provide equivalent results. Teams should inventory all reads, writes, searches, updates, deletions, exports, background processes, identity assignments, and provider-specific error or retry handling, while distinguishing conversation-derived memories from ingested documents. User, tenant, source, and derived-memory relationships should be preserved through deliberate identity and provenance mapping, with authorization enforced by the trusted application rather than metadata alone. A small test fixture covering preferences, corrections, temporary exceptions, and deletion requests can validate retrieval evidence, cached context, and whether deletion fully removes related records. Rollout should use an isolated project, representative pilot data, shadow reads, disagreement reviews, source mappings, and a plan for transition-period writes, with performance evaluated using equivalent models and settings rather than unrelated demonstrations.

RAG retrieves authorized external information, including documents and potentially conversation history, while agent memory adds persistent policies for retaining, updating, scoping, retrieving, and deleting information across interactions. Whether memory is needed depends on application requirements beyond retrieval, such as maintaining user preferences, handling corrections, isolating users’ data, and preserving relevant cross-session context; graphs are optional implementation tools rather than universal prerequisites. Different questions require distinct sources, with policy questions needing authoritative documents, customer-history questions needing scoped interaction records, and live status questions requiring current systems of record. A document-retrieval baseline may be sufficient for simple, stable use cases, but memory lifecycles become valuable when records change, require provenance and scope, or must be expired or deleted. Applications should combine shared knowledge, personal context, and transactional data appropriately, avoid indiscriminately supplying full histories, and evaluate simpler and memory-enhanced architectures using consistent tests for correctness, permissions, deletion, latency, cost, and source support.

Estimating a custom memory system should focus on the full effort needed for correctness, observability, maintenance, and ongoing operations rather than simply counting endpoints or demonstrating that embeddings can be stored. The work should be divided into areas such as source ingestion, parsing, identity and authorization, storage, retrieval, context assembly, corrections and deletions, evaluation, observability, and recovery, with specific completion tests for each and clear separation between prototype and production requirements. Estimates should include low, expected, and high effort ranges, dependencies, unknowns, coordination, investigations, staffing constraints, and recurring operational work such as schema changes, re-embedding, policy updates, incidents, and upgrades. Teams should compare custom and managed options over equivalent scope and time periods, including remaining application work and opportunity costs, rather than comparing a complete internal system with a vendor’s base API price. Uncertainty can be reduced through narrow technical spikes that test the least-understood requirement, while reviews of AI-generated architectures and tools such as Supermemory can help identify omitted requirements and evaluate managed alternatives.

Supermemory discontinued its Company Brain product and Nova personal knowledge platform on September 9, refunding all charged users and ending access to the Company Brain dashboard and Slack bot. Its MCP integrations and plugins, including support for Claude Code, will remain available through the developer platform, while Nova’s underlying capabilities are being shifted to the company console. The company says the decision reflects a need to focus on its core mission of building memory systems for AI agents, avoid competing with customers that use its memory engine, and position itself as infrastructure for other organizations developing company-brain and agent products. Supermemory plans to concentrate on its memory API, which it describes as a frontier system for adding persistent, unified memory to commercial and personal agents.

Self-managed agent memory should be chosen only when specific, verified requirements cannot be met adequately by managed services and the organization has the capacity to operate the added infrastructure. Teams should identify the exact control needed, consider hybrid architectures that retain ownership only at necessary boundaries, and define contracts covering identity, revisions, readiness, corrections, and deletion. The decision should account for operational responsibilities such as upgrades, incidents, backups, index rebuilds, source changes, and evaluation regressions, alongside initial delivery time, recurring maintenance, product delays, and migration costs. Designing for reversibility through preserved source identifiers, exportable evidence, narrow interfaces, and shared acceptance tests enables future changes as requirements or workloads evolve. Before adopting a custom stack, organizations should establish a managed-service baseline, including testing Supermemory against the most important requirement and explicitly comparing the remaining work.

Effective chatbot personalization requires distinguishing explicit, inferred, and confirmed preferences while accounting for whether information is current, authoritative, and applicable to a particular task or project. Temporary requests should be stored as scoped exceptions rather than overwriting enduring preferences, and high-impact decisions should rely on current application records instead of memory alone. Testing should define clear precedence among general, project-specific, and current-request preferences, while logging the records and versions delivered to the answer system helps separate retrieval failures from application failures. Evaluation should focus on real tasks rather than simple memory recall, verify corrections across new sessions, users, and projects, and ensure deleted records do not reappear after synchronization. Failures should be categorized by their cause and severity, with end-to-end testing beginning from a manageable preference that users can view, edit, and remove.

Debugging AI agent memory failures requires tracing a specific fact from its source through storage, processing, retrieval, context assembly, and final response rather than treating “bad memory” as a single problem. A reproducible incident should record identifiers, timing, authorized scope, queries, retrieval results, model context, settings, and expected behavior while protecting private data through redaction or synthetic examples. Common causes include missing writes, indexing delays, incorrect or insecure scope handling, low retrieval ranking, stale or conflicting records, context truncation, and models failing to use supplied evidence; each requires a different fix. Investigators should identify the first stage where evidence disappeared, distinguish event time from ingestion time, verify what the model actually received, and avoid assumptions such as expanding context windows or repeatedly writing duplicate records. Performance should be measured separately across search, context preparation, model output, and end-to-end completion according to user-facing requirements. Incidents should become regression tests with positive and nearby negative cases, while trajectory-level auditing should track both failed steps and failed runs using explicit denominators, preserve evidence for classifications, and compare replayable cases before and after changes.

Effective memory observability links source events to the evidence used in model responses, allowing teams to diagnose issues such as stale preferences, missing corrections, delays, rejected records, or improper context use. Tracing should cover capture, processing, retrieval, context selection, and generation, with logs emphasizing event identifiers, authorization scopes, revisions, processing states, correlations, and evidence IDs rather than routinely storing sensitive content. Monitoring should use actionable, workload-specific alerts for conditions such as processing backlogs, timeouts, and scope-check rejections, while interpreting empty retrieval results in context. Reported failures should be preserved as permitted, replayable fixtures containing relevant history, query, scope, configuration, and expected evidence, enabling controlled regression testing. The approach distinguishes infrastructure health from answer quality because retrieval, prompt construction, and generation can fail independently, and recommends tracing a fictional record through a test workflow before building broader dashboards.

Multi-tenant agent memory requires authorization and a stable, server-derived scope for every write, retrieval, update, deletion, cache access, and background job, as namespaces or container tags alone do not establish permission boundaries. Applications should map authenticated tenant and user identities to opaque, stable scope IDs, use distinct document identifiers for separate conversations, and authorize personal and shared knowledge sources independently while preserving their provenance. A shared memory store can provide logical isolation if access controls and scoped queries are enforced, while dedicated databases or deployments may be justified by contractual, regional, recovery, or resource-isolation needs but do not eliminate authorization requirements. Security should be tested with adversarial multi-tenant scenarios, including duplicate user IDs, forged container identifiers, cross-scope document lookups, cache reuse, revoked access, and background retries, with verification extending to retrieved context and model input rather than final answers alone. Deletion must cover associated memories as well as application-controlled exports, caches, logs, and pending ingestion, while performance testing should separately assess noisy-neighbor effects through per-tenant measurements, quotas, scheduling, or workload separation.

Reliable data ingestion should combine push notifications, scheduled polling, and on-demand retrieval according to freshness requirements, source behavior, and recovery needs. Webhooks provide prompt change alerts but may be duplicated, delayed, or incomplete, so integrations need stable record identities, version rules, validation, and protection against older events overwriting newer data. Cursor-based polling supports reconciliation after outages, provided cursors are committed only after records reach a durable checkpoint, while also accounting for deletions, permission changes, and incomplete source change feeds. On-demand pulls are appropriate for volatile, authoritative information such as order status or access rights, and systems should clearly report when current verification fails rather than presenting stale data as current. All ingestion paths should map to a common source ID, preserve revision provenance for troubleshooting, consider full operational costs for call-based sources, and be tested against duplicate events, missed updates, and permission changes before broad deployment.

Personalization should focus on reducing repeated user effort through minimal, purpose-specific context rather than building broad personal profiles. Effective implementations begin with an observable benefit, such as remembering an agreed report format or unresolved support steps, and define the data source, scope, retention, and correction process needed to support it. Explicit user preferences should be distinguished from inferred patterns, with clear provenance and easy ways to correct or remove persistent assumptions. Teams should measure personalization by improvements in task completion, reduced repeated instructions, and lower correction effort, while recognizing that self-contained requests may require no memory. Initial rollouts should test a single inspectable behavior using fictional users, verify persistence and user separation, and consider memory-based approaches before fine-tuning models, expanding stored context only when measurable benefits justify it.

Memory containers organize records for retrieval but do not enforce access control, so applications must authenticate users, determine tenant, user, project, and workspace permissions, and construct memory scopes server-side rather than trusting client-provided identifiers. Personal and shared project context require separate authorization checks, and permissions must apply consistently to reads, writes, corrections, exports, deletions, background jobs, caches, generated summaries, and provider API access. The guidance emphasizes unambiguous identifiers, protection against scope collisions and stale cached results, and keeping broad API credentials on trusted infrastructure. Effective integration testing should simulate cross-user and revoked-access scenarios, altered identifiers, and unauthorized deletion attempts while examining retrieved evidence, and managed-memory pilots should use fictional users while retaining authentication and authorization within the application.

A reliable custom connector requires more than fetching and uploading data: it must preserve stable source identities, distinguish content revisions from delivery attempts, track recoverable progress, respect permissions, and handle deletions. The design should begin with a single source collection and a clear acceptance contract, separating source-specific retrieval logic from the ingestion adapter and retaining key metadata such as source, collection, record ID, revision, timestamps, access scope, and content or references. Sync cursors should advance only after durable acceptance, while rejected records remain visible with explanations rather than being silently treated as successful. Connectors should apply source ordering rules to late revisions, propagate removals through derived records and caches, define how lost access is handled, and periodically reconcile source inventories because event feeds may be incomplete. Testing should simulate failures and edge cases including duplicate events, delayed old revisions, deletions, permission changes, and crashes between ingestion and cursor updates, using Supermemory’s document operations and ingestion guidance to validate one source before broadening the implementation.