topoteretes

AIエージェントの「記憶」と「共有知識」を分けて考える：Graphiti・Cognee・LangMem・Mem0・Hindsightの役割整 背景 AIエージェントに「記憶」を持たせるOSSが、この1年で一気に増えました。Mem0、LangMem、Graphiti、Cognee、Hindsight、Letta……名前を並べるだけでも一苦労です。 私は複数のエージェントが経験から学び、その知識を組織で共有する仕組み（自己進化する組織AI）をPoCしようとしています。ところが、いざ選ぼうとすると次の点で迷いました。 どれも「メモリ」を名乗るが、守備範囲がバラバラ ベンチマークの数字は、提供元が自社で出したものが多い 「ナレッジグラフ」「長期記憶」「共有知識」が同じ意味で使われている そこでPoCに入る前に、各OSSを役割別に整理することにしました。 目的 この記事の目的は次の2つです。 記憶系OSSを「何を解く道具か」で分類し、選ぶ前の地図を作る PoCで最初に検証すべき仮説と、比較の組み合わせを決める なお、この記事は公式READMEや論文、ドキュメントを読んだ整理です。性能比較の実測は含みません。実測はこの後のPoCで行います。 結論 結論は3つです。 「記憶（Memory）」と「共有知識（Knowledge）」は別物として設計する。エージェントが残した経験は、検証前の「候補」にすぎません。検証を通ったものだけを組織の知識に昇格させます。 OSSは役割ごとに1つずつ選ぶ。全部を載せるのではなく、差し替えられる境界（アダプタ）を作って比較します。 最初の比較は、LangGraph + LangMem を基準にする。そのうえで、共有知識はCogneeとGraphitiを比べます。事実が時間で変わる要件が強いならGraphitiが有力です。 結論を得た方法 次の手順で整理しました。 各OSSの公式README・ドキュメント・論文から、「何を保存し、どう検索するか」を読む 保存するものの種類（事実／経験／手順／関係）で分類する 「個別エージェントの記憶」と「組織で共有する知識」のどちらを担うかで切り分ける 提供元の主張（ベンチマークなど）と、自分で確かめるべき点を分けて書く 根拠 1. 記憶には種類がある LangMemは、記憶を3種類に分けて説明しています。 種類 中身 例 Semantic（意味） 事実・知識 ユーザーの好み、ドメイン知識 Episodic（エピソード） 過去の経験 前回のタスクの成否 Procedural（手続き） ルール・やり方 プロンプトや手順の更新 この分け方は、他のOSSを読むときにもそのまま使えます。「このOSSは、どの種類を主に扱うのか」を見ると、守備範囲の違いがはっきりします。 2. OSSの役割別マップ 役割 代表OSS 特徴 長期記憶の基準 LangMem LangGraphのStoreと統合。3種類の記憶を扱う 汎用の記憶レイヤー Mem0 add・searchで既存のエージェントに後付けできる 経験の振り返り Hindsight retain・recall・reflectの3操作。事実・経験・観察・意見を分けて持つ 時間軸つき知識グラフ Graphiti 事実の有効期間を持ち、矛盾する事実を無効化できる 知識エンジン Cognee 文書を取り込み、グラフとベクトルの両方で検索する ひとことで言うと、LangMemとMem0は「覚える」、Hindsightは「振り返る」、GraphitiとCogneeは「構造化して持つ」道具です。 3. 各OSSの要点 LangMemは、LangGraphのレイヤーに自然に載るのが強みです。すでにLangGraphで組んでいるなら、新しい基盤を立てずに試せます。そのため、今回の基準系にします。 Mem0は、メモリ専用のライブラリで、エージェント本体は作り変えません。公式ブログによると、2026年4月に新しい抽出アルゴリズムが出ています。ただし、公開されているベンチマークは提供元自身が出した数字です。そのまま鵜呑みにせず、同じ条件で自分でも測ります。 Mem0の最小コードfrom mem0 import Memory m = Memory() m.add("I prefer Python over JavaScript", user_id="alice") print(m.search("好きな言語は？", user_id="alice")) Hindsightは、記憶を「世界の事実」「エージェントの経験」「観察（要約）」「意見（信念）」に分けて持ちます。事実と推測を区別して残す点が、共有知識の設計に参考になります。 Hindsightの最小コードfrom hindsight_client import Hindsight client = Hindsight(base_url="localhost") 覚える client.retain(bank_id="my-bank", content="Alice works at Google") 思い出す（生の記憶を返す） client.recall(bank_id="my-bank", query="Where does Alice work?") 振り返る（記憶をもとに答えを返す） client.reflect(bank_id="my-bank", query="What should I know about Alice?") Graphitiは、事実に時間の情報を持たせる知識グラフです。いつ起きたか、いつシステムが知ったかを別々に記録します（bi-temporal）。そのため「今は違うが、前は正しかった事実」を扱えます。グラフDBはNeo4j、FalkorDB、Kuzu、Neptuneから選べます。 Cogneeは、文書を取り込んで知識グラフとベクトル検索の両方で引ける形にします。READMEによると、1.0ではメモリ層全体を1つのPostgresで動かせるようになっています。小さく始めやすい点が魅力です。 Cogneeの最小コードimport asyncio import cognee async def main(): await cognee.add("Cognee turns documents into AI memory.") await cognee.cognify() # 知識グラフを作る results = await cognee.search("What does Cognee do?") for r in results: print(r) asyncio.run(main()) 4. 「保存した記憶」は「信頼できる共有知識」ではない ここが、この整理でいちばん大事な点です。 エージェントが「うまくいった」と記録した経験は、たまたま成功しただけかもしれません。環境の揺らぎを、根本原因の解決と取り違えている可能性もあります。それをそのまま組織の知識にすると、誤った手順がほかのエージェントに広がります。 そこで、経験を次の流れで扱う設計を考えています。 EPISODE → CANDIDATE → VALIDATED → SHARED → ARCHIVED (経験) (候補) (検証済み) (共有) (退役) CANDIDATEからVALIDATEDへ上げる条件（Knowledge Promotion Gate）は、たとえば次のとおりです。 出典と元のトレースが残っている 変更なしで再実行した場合と、記憶・手順を使った場合を同じ条件で比較して、改善が再現する 既存の知識と矛盾していない 影響の大きい手順は、人間が承認する 共有後も、使われた結果で信頼度を更新し、失敗が増えたら降格させます。 5. PoCの進め方 フェーズ 比較 確かめたいこと 1. 基準系 記憶なし / LangGraph Store / LangMem / Mem0 記憶がタスクの成功率に効くか 2. 経験学習 Hindsight / LangMem など 振り返りが未知のタスクに転用できるか 3. 共有知識 Cognee と Graphiti 時間変化・矛盾・出典を持てるか 4. 昇格ゲート 昇格なし / 自動昇格 / 検証ゲート 誤った知識の拡散を防ぎつつ改善率を保てるか 評価は同じLLM、同じEmbedding、同じ評価データで揃えます。指標は、検索ではRecall@K、タスクでは成功率と未知タスクへの転用率、品質では誤昇格率と古い事実の採用率を見ます。提供元のベンチマークとは別に、自前のテストも用意します。 まとめ 記憶OSSは「覚える」「振り返る」「構造化して持つ」で役割が違う 「記憶」と「共有知識」は分け、昇格の関門を挟む まずLangMemを基準に、共有知識はCogneeとGraphitiで比べる ここまでは文献ベースの整理なので、次はPoCで実測する 次の記事では、LangGraphとGraphiti、LangGraphとLangMem・Cogneeを実際に組み合わせて、この仮説を確かめます。 参考 LangMem SDK launch（LangChain Blog） Graphiti Overview（Zep） Zep: A Temporal Knowledge Graph Architecture for Agent Memory（arXiv） Cognee（GitHub） State of AI Agent Memory 2026（Mem0） Hindsight is 20/20（arXiv） Hindsight（GitHub）

Stop letting your AI wake up with amnesia every session. Cognee (31K+ GitHub stars) gives Claude Code persistent Knowledge Graph memory for $0: • Runs locally on CPU (no API key) • remember & recall CLI commands • Built-in MCP server Repo: topoteretes/cognee t.co

I built OptMem plugin for Hermes. It's one of the 24 in the official catalog. Zero dependencies. No database, no embeddings, no API key. An append-only log: summaries keep context small, the raw record is never deleted. OptMem from @VictorTaelin rarf/optmem-hermes-plugin

my first-ever open-source contribution That morning email saying the maintainer assigned me an issue was pure happiness😆 PR is up for #Mergetober with @cognee_ x @WeMakeDevs blog: afreenhossain.vercel.app PR: cognee-community#459

I Built a QuickBooks Connector for an AI Knowledge Graph — Here’s What I Learned What if you could ask AI questions about invoices, unpaid bills, and financial records instead of searching through them manually? That’s the idea behind my latest open-source contribution to Cognee Community: a QuickBooks Online data connector. 🔗 Pull Request: cognee-community#402 📌 Issue: cognee#4802 🧠 What does it do? QuickBooks stores useful business information, but AI systems need a way to ingest and understand that data. I worked on a connector that brings QuickBooks financial records into Cognee's AI memory workflow. The connector supports: - 📄 Ingesting invoices, vendor bills, and credit memos. - 🔐 OAuth 2.0 authentication and token refresh. - 🔄 Incremental sync to retrieve new and updated records. - 🗑️ Deletion detection to help remove outdated information. - 🛡️ Retry handling and safeguards against accidental deletion. - 🧪 Automated tests and offline pipeline verification using DuckDB. ⚙️ How does it work? The basic workflow is: QuickBooks → Python Connector → DLT → Cognee → Knowledge Graph The connector retrieves financial records, formats them into readable Markdown documents, and sends them through Cognee's ingestion workflow. For example, instead of working with raw invoice JSON, the system can process information such as customer names, invoice totals, payment status, and line items. This makes the information more useful for downstream AI search and knowledge extraction. 🔍 The biggest challenge: keeping data in sync Fetching records is only one part of building a reliable connector. What happens when an invoice changes? What if someone deletes a record? And what if an API request fails and returns no data? I worked on incremental synchronization using Metadata.LastUpdatedTime, deletion detection through QuickBooks Change Data Capture (CDC), and a fallback reconciliation mechanism. I also added a safety check to prevent an empty synchronization sweep from accidentally marking previously known records for deletion. The submitted test suite documents 12 passing tests, covering data formatting, synchronization, deletion handling, and retry behavior. 💡 What I learned This contribution taught me that building a data connector is about much more than calling an API. You need to think about data consistency, authentication, synchronization state, failure handling, and testing edge cases. Working on these details gave me practical experience with Python, REST APIs, DLT, data pipelines, testing, and AI knowledge graphs. 🙌 Explore the project - My pull request: cognee-community#402 - Original issue: cognee#4802 - Cognee: topoteretes/cognee - Cognee Community: topoteretes/cognee-community Thanks to the Cognee maintainers and community for creating opportunities to learn and contribute to open-source AI infrastructure. The pull request is currently open for review, and I welcome feedback from other developers. 💬 Let's discuss!

##I Built a Brex Connector for Cognee: Bringing Business Expense Data Into AI Memory 🚀 I Built a Brex Connector for Cognee: Bringing Business Expense Data Into AI Memory 🚀 What I learned building an open-source data connector during MergeTober by WeMakeDevs. What if you could ask an AI assistant about business expenses instead of manually searching through transaction records, notes, and budgets? That question captures the idea behind my recent open-source contribution to Cognee Community. During MergeTober by WeMakeDevs, I worked on building a Brex data-source connector for Cognee. The work involved much more than fetching data from an API. I also had to think about how the data should be organized, how future syncs should work, and how to protect existing data when something goes wrong. Here is what I built, how it works, and what I learned. 🌍 My entry into MergeTober Open source can feel intimidating when you're starting out. You might wonder which project to choose, how to understand an unfamiliar codebase, or what maintainers expect from a contribution. MergeTober gave me an opportunity to work on a real integration issue rather than build another standalone demo. My workflow was straightforward: 1. Find an open issue that matches a real project need. 2. Understand the requirements and existing architecture. 3. Implement the feature and submit a pull request. 4. Document the work so other developers can understand it. I chose a connector issue because I wanted hands-on experience with APIs, data engineering, and AI infrastructure. 🧠 Why connectors matter for AI Consider a company that stores information across different tools. Expense records live in a financial platform, project updates live elsewhere, and important context is buried in notes. Even a capable AI system cannot use information it cannot access. Cognee is an open-source project focused on turning data into structured AI memory. Data connectors help bring information from external systems into that workflow. That led me to a practical question: How can we make business expense information available to an AI knowledge system in a useful, structured, and maintainable way? My contribution was an attempt to solve that problem for Brex. 🔌 What I built: the Brex connector Brex provides business expense and budget management capabilities. My connector brings selected Brex data into Cognee's ingestion workflow. You can explore the implementation here: - GitHub issue #4797 — Brex connector requirements - Pull request #389 — My implementation The connector supports three data resources: | Resource | Information collected | | --- | --- | | Expenses | Amounts, merchants, categories, statuses, and dates | | Memos | Expense notes and business justifications | | Budgets | Budget limits, spending, and budget relationships | The interesting part is that these resources don't all need to be represented in the same way. Expense memos can become readable documents for contextual knowledge extraction, while expenses and budgets can remain structured records for organized data processing. This gives downstream workflows access to both business context and structured information. ⚙️ How the connector works Here is the simplified architecture: Brex Platform API | v Authentication + Pagination | v Fetch Expenses, Memos and Budgets | v Transform the Data / \ v v Document Mode Structured Mode \ / v v DLT Ingestion | v Cognee Workflow | v AI Knowledge Retrieval Let's break down the engineering decisions behind it. 1. Authentication and API requests The connector uses Bearer token authentication to access the Brex Platform API. It also handles paginated responses, so the integration can retrieve records across multiple API pages rather than stopping at the first batch. API integrations must account for failure cases, too. The implementation includes handling for authentication errors, permission errors, and rate limits. 2. Turning raw data into useful information Raw API responses aren't always the best representation for an AI knowledge pipeline. For example, consider an expense containing a merchant, amount, department, budget, and a note explaining why the purchase was necessary. The connector can transform that context into a readable document card while preserving expenses and budgets as structured records. This separation makes the data easier to consume in different downstream workflows. 3. Incremental synchronization Fetching every record during every run can be inefficient as datasets grow. The connector uses Brex's posted_at_start filter and stores synchronization state through DLT's resource-state mechanism to track the latest processed timestamp. Subsequent runs can then use that timestamp to retrieve relevant new or updated expense records. The important lesson: reliable integrations need to remember where the previous synchronization ended. 4. Handling deletions safely One of the more interesting challenges was deletion reconciliation. Suppose a record disappears from the source. Eventually, the destination should stop treating that record as current. However, imagine the API temporarily fails while the connector is checking which records still exist. Treating an incomplete response as a complete snapshot could incorrectly mark valid records as deleted. The implementation therefore includes a guardrail: if reconciliation encounters API or network errors, deletion-marker generation is aborted rather than proceeding with potentially incomplete information. This is an important distinction between simply syncing data and building a connector that considers data integrity. 💻 What does using it look like? The pull request includes a usage example following Cognee's API. After installing and configuring the connector and providing the required Brex API credentials, the basic ingestion pattern looks like this: import asyncio import os import cognee from cognee_community_connector_brex import brex_source async def main(): source = brex_source( token=os.environ["BREX_API_TOKEN"], include=["expenses", "memos", "budgets"], ) await cognee.remember( source, dataset_name="brex_spend", primary_key="id", write_disposition="merge", max_rows_per_table=0, ) if __name__ == "__main__": asyncio.run(main()) This example illustrates how the connector is configured and passed to Cognee's ingestion API. A complete setup also requires installing the relevant dependencies, configuring valid credentials with appropriate permissions, and checking the compatibility of the project's installed versions. Once the data is ingested, it can be used in a Cognee search workflow according to the configured pipeline and supported query types. For the full implementation and query example, see the pull request. 🧪 Testing is part of the feature A connector should not be considered reliable just because it works with one successful API response. The pull request includes offline unit tests for important paths, including: - Authentication and API error handling. - Pagination and data transformation. - Incremental synchronization state. - Deletion-marker generation and failure guardrails. The PR also documents an end-to-end DLT pipeline run using DuckDB. These tests matter because connectors operate at a boundary between systems. A mistake can affect not only the data being fetched but also what downstream applications believe is current. I came away with a stronger appreciation for testing failure scenarios—not just the happy path. 📚 What I learned from this contribution This project taught me several practical lessons. Understand the existing architecture before coding. Following established connector patterns makes a contribution easier to review and maintain. Think about synchronization from day one. Initial ingestion is only one part of the problem. Updates, deletion handling, and persistent state matter just as much. Protect data when dependencies fail. A partial API response should not automatically be treated as the complete truth. Treat documentation as part of the implementation. Clear setup instructions and realistic examples help other developers use a feature without first having to understand every line of code. Most importantly, I learned that a meaningful open-source contribution often involves making many small engineering decisions correctly. 🙏 Thank you, Kunal Kushwaha, Cognee, and WeMakeDevs! A big thank you to Kunal Kushwaha and the WeMakeDevs team for encouraging developers to build in public, learn by contributing, and participate in open-source initiatives like MergeTober. Thank you to the Cognee team and community for maintaining the project and creating opportunities to work on real integration challenges. I am also grateful to the maintainers and community members who helped with the issue assignment and contribution process. Open source is about more than individual pull requests. It is about a community where developers can learn from one another and gradually help improve the tools everyone uses. 🔗 Explore the project If you're interested in AI memory, data engineering, or contributing to open source, these resources are a good starting point: - My pull request: Brex spend data-source connector - Original issue: Add a Brex data-source connector - Cognee: Explore the main repository - MergeTober: Learn about the initiative 🚀 Your turn: build something useful You don't need to start with a groundbreaking idea to contribute to open source. Pick a real problem. Read the existing code. Ask questions when you need to. Test your implementation. Document what you learn. That is how small contributions become useful improvements to real software. My MergeTober journey is another step in that direction, and I'm looking forward to learning and contributing more. Have you built an API integration or contributed to an AI open-source project? Share your experience in the comments. I'd love to learn what challenges you encountered. ---

CogneeでAIに長期記憶を持たせる｜ペルソナ・ブランド戦略を忘れない記事作成AIを構築する はじめに 普段、AIを使ってマーケティング戦略の立案やSEO記事の作成を行っています。 しかし、AIを継続的に利用するうえで課題があります。 - AIが以前設定したペルソナの性格を忘れる - ブランドの世界観や文章のトーンが変わる - 過去に決めたマーケティング戦略が引き継がれない - 新しいチャットを始めるたびに同じ情報を説明する必要がある - 複数のAIエージェントで知識を共有しにくい そこで、AI向けの知識管理ツール「Cognee」を使い、ペルソナやブランド戦略を長期記憶として管理する仕組みを構築してみます。 この記事は、自分用の技術メモも兼ねた実践記録です。 1. Cogneeとは？ Cogneeは、LLM向けのメモリ・知識管理フレームワークです。 文章やドキュメントなどの情報を取り込み、AIが検索・活用できる知識として構造化できます。 主な特徴： - ナレッジグラフの構築 - ベクトル検索 - GraphRAGへの応用 - AIエージェントの長期記憶 - 複数の情報間の関係性の管理 公式サイト： cognee.ai 公式ドキュメント： docs.cognee.ai GitHub： topoteretes/cognee 2. 今回実現したいこと 目標は、AIマーケティングチームの共通知識をCogneeに保存することです。 ┌────────────────────┐ │ Cognee │ │ 長期記憶DB │ └─────────┬──────────┘ │ ┌────────────┼────────────┐ │ │ │ ペルソナ記憶 ブランド戦略 過去の学習 │ │ │ └────────────┼────────────┘ │ 検索・情報取得 │ ┌────────────┴────────────┐ │ │ 記事作成AI Marketing AI │ │ └────────────┬────────────┘ │ コンテンツ生成 │ 結果を評価 │ 記憶を更新 ※ Cogneeと各AIの接続処理は別途実装します。 3. 長期記憶の設計 記憶を3つのカテゴリーに分けます。 3.1 固定記憶 頻繁に変更しない情報です。 - ペルソナの性格 - 価値観 - 購買心理 - ブランド理念 - ブランドの世界観 - 禁止表現 - 文章のトーン 3.2 戦略記憶 定期的に更新する情報です。 - SEO戦略 - ターゲットキーワード - 競合分析 - コンテンツ戦略 - 商品の訴求ポイント - コンバージョン戦略 3.3 学習記憶 実践から蓄積する情報です。 - 記事のパフォーマンス - 成功した施策 - 失敗した施策 - 顧客からのフィードバック - AIが生成した記事への修正履歴 重要なのは、AIが勝手に固定記憶を書き換えないようにすることです。 記憶の更新には承認プロセスを設けます。 4. 環境構築 必要なもの - Python - pip - Cognee - LLM APIキー 今回はPythonを使って最小構成を構築します。 4.1 仮想環境を作成 python -m venv .venv macOS / Linux： source .venv/bin/activate Windows PowerShell： .venv\Scripts\Activate.ps1 4.2 Cogneeをインストール pip install cognee 4.3 APIキーを設定 macOS / Linux： export LLM_API_KEY="YOUR_API_KEY" Windows PowerShell： $env:LLM_API_KEY="YOUR_API_KEY" 使用するLLMプロバイダーやモデルによっては、追加の環境変数設定が必要です。 5. ペルソナ情報を作成 最初は架空のペルソナで検証します。 data/persona.md # ペルソナ：佐藤美咲 ## 基本情報 - 年齢：35歳 - 職業：マーケティング担当者 - 関心：AI、自動化、SEO、業務効率化 ## 性格 - 論理的 - 慎重 - 新しい技術に興味がある - 誇張された広告表現を嫌う ## 悩み - 記事作成に時間がかかる - AIの出力品質が安定しない - マーケティング業務を自動化したい ## 購買心理 - 導入効果を重視 - 実例や数値を求める - 誇大広告を信用しない ## 好むコンテンツ - 実践的な技術記事 - 比較記事 - ステップ形式の解説 - コード付きチュートリアル 6. ブランド戦略を作成 data/brand_strategy.md # ブランド戦略 ## ブランドの目的 AI技術を活用してマーケティング業務を効率化する。 ## ターゲット - マーケティング担当者 - 個人事業主 - コンテンツ制作者 ## ブランドの性格 - 専門的 - 誠実 - 実践重視 - 論理的 ## 文章のルール - 結論を先に伝える - 専門用語を説明する - 実例を含める - 誇張表現を避ける - 根拠のない成果を約束しない ## コンテンツ戦略 - SEOを意識する - 読者の検索意図を満たす - 実践できる情報を提供する - 読者の課題解決を優先する 7. Cogneeに長期記憶を登録 ingest.py import asyncio import cognee async def main(): # ペルソナ情報を追加 await cognee.add("data/persona.md") # ブランド戦略を追加 await cognee.add("data/brand_strategy.md") # 知識を構造化 await cognee.cognify() print("知識の登録が完了しました") if __name__ == "__main__": asyncio.run(main()) 実行： python ingest.py cognify() により、登録した情報が検索可能な知識として処理されます。 8. 記憶を検索する search.py import asyncio import cognee async def main(): questions = [ "佐藤美咲の性格は？", "佐藤美咲が嫌う広告表現は？", "ブランドの文章ルールは？", "このペルソナ向けの記事では何を重視すべき？" ] for question in questions: results = await cognee.search( query_text=question ) print(f"\n質問: {question}") print(f"検索結果: {results}") if __name__ == "__main__": asyncio.run(main()) 実行： python search.py 別のPythonプロセスから検索することで、登録情報が永続化されているかを確認します。 ※ データベースの保存先や設定が変わると、同じ記憶を参照できない場合があります。 9. 記事作成AIとの連携 記事作成前にCogneeから関連情報を取得します。 ユーザー： 「AIマーケティングについて記事を書いて」 ↓ Cogneeから検索： 1. ターゲットペルソナ 2. ブランドの文章ルール 3. コンテンツ戦略 4. 関連する過去の知見 ↓ 記事作成AIへコンテキストを渡す ↓ 記事生成 ↓ 人間が確認・修正 ↓ 修正内容や成果を記録 これにより、AIの出力をブランド戦略と整合させやすくなります。 ただし、検索結果が不完全な場合やLLMが指示に従わない場合もあるため、生成内容の検証は必要です。 10. 検証項目 以下の項目を実際に確認します。 - [ ] Cogneeをインストールできる - [ ] ペルソナ情報を登録できる - [ ] ブランド戦略を登録できる - [ ] ナレッジグラフを生成できる - [ ] ペルソナの性格を検索できる - [ ] ブランドの文章ルールを検索できる - [ ] Pythonを再起動しても検索できる - [ ] 記憶を利用して記事を生成できる - [ ] 記憶にない情報への回答を検証できる 実行結果 ※ 実践後に追記 実行環境： OS： Pythonバージョン： Cogneeバージョン： LLMモデル： データベース設定： 成功したこと： 発生したエラー： 改善したこと： 11. 今後の改善計画 Phase 1：基本的な長期記憶 - ペルソナを保存 - ブランド戦略を保存 - 自然言語検索を実装 Phase 2：記事作成AIとの連携 - 記事生成前に記憶を検索 - 検索結果をプロンプトへ注入 - ブランドとの整合性を評価 Phase 3：複数AIエージェントへの展開 - Marketing AI - SEO AI - 記事作成AI - 編集・品質管理AI 複数のAIが共通の記憶を参照できる構成を目指します。 Phase 4：継続学習 - 記事の成果を記録 - 戦略の変更履歴を管理 - 成功・失敗パターンを蓄積 - 記憶の更新を承認制にする 12. まとめ Cogneeを使えば、AIが参照するペルソナやブランド戦略を、チャットの外部に永続的に保存できます。 今回目指すのは、単なるチャット履歴の保存ではありません。 AIマーケティングチームが共通の知識を持ち、過去の意思決定を参照しながら、継続的にコンテンツを制作できる環境です。 今後は実際にCogneeを動かし、検索精度、記事品質、運用コストなどを検証していきます。 --- 参考資料 - Cognee公式サイト - Cognee公式ドキュメント - Cognee GitHub --- タグ Python AI RAG LLM Cognee

I made my contribution to open source with Mergetober! !Image description## Integrating Clay Enterprise with Cognee Using dlt For Mergetober, I worked on building a connector that brings Clay Enterprise data into Cognee using dlt's REST API source. The main goal was to make it easier to bring structured data from Clay tables into Cognee. I worked on configuring the API endpoint, request parameters, and pagination so the connector could fetch data from the API. Pagination was an important part of the implementation because the API can return data across multiple pages. The connector needs to handle those pages to retrieve the available records properly. I also worked on preparing the data so it could be used in Cognee's ingestion workflow. I tested the implementation with unit tests and a real Clay Enterprise workspace. Working on this connector gave me a chance to contribute to an open-source project and explore how data integrations can connect external sources with AI applications. You can check out my contribution here: Clay Enterprise connector for Cognee — PR #313. Acknowledgments A big thank you to WeMakeDevs for organizing Mergetober and giving developers a chance to contribute to open source. Thanks to the Cognee team for building the project and making this contribution possible. I'd also like to thank Kunal Kushwaha for encouraging and supporting the developer community. I'm glad I got the opportunity to contribute to Cognee through Mergetober. It was a great way to get involved in open source and work on a practical integration.

Inside My MergeTober Contribution: Integrating Salesforce with Cognee Introduction AI agents are only as useful as the information they can access. But business knowledge often lives in separate tools, such as CRM platforms, documents, and communication systems. That is why I participated in MergeTober, contributing to the open-source Cognee ecosystem by working on a Salesforce connector. Cognee provides a memory layer for AI agents, helping turn data into connected knowledge that can be retrieved by downstream applications. My contribution aims to make Salesforce CRM data available to those workflows. Why Connect Salesforce with Cognee? Salesforce contains valuable business information, including customer accounts, sales opportunities, support cases, and Chatter conversations. Connecting this data to Cognee could help developers build AI applications that retrieve relevant business context instead of relying only on isolated records. The goal of my connector is to support: - Authentication: OAuth 2.0 with a Salesforce Connected App. - Data ingestion: Accounts, Opportunities, Cases, and Chatter records. - Incremental synchronization: SOQL queries using LastModifiedDate. - Deletion handling: Detect deleted source records and support downstream cleanup. - Testing and documentation: Unit tests, setup instructions, and a runnable example. How It Could Work in the Real World Imagine a sales team using a CRM knowledge assistant. A representative asks: “What open opportunities are associated with this customer, and are there any related support cases?” A configured application could retrieve relevant Salesforce records through the connector, process the information with Cognee, and use the resulting knowledge as context for an answer. This is an illustrative use case, not a claim that I have tested a complete assistant against a live Salesforce organization. Incremental synchronization could help keep the information current, while deletion handling could help prevent outdated source records from remaining in the knowledge system. Testing My Contribution I tested the connector locally using mocked Salesforce responses and verified that 9 out of 9 mocked unit tests passed. These results validate the behavior covered by those tests. They do not independently establish that authentication, synchronization, and knowledge retrieval have all been verified against a live Salesforce environment. My pull request is currently open and awaiting review. View my Salesforce connector PR on GitHub Why MergeTober Matters I appreciate MergeTober's focus on building integrations that solve real problems. Code demonstrates what we build, while a practical blog post helps other developers understand why it matters and how they might use it. Contributing to open source is an opportunity to learn, collaborate, and create tools that others can build upon. A special thank you to Kunal Kushwaha, Founder of WeMakeDevs, for creating opportunities that encourage developers to contribute to meaningful open-source projects. Thank you also to the Cognee team and community for building an open-source memory layer for AI agents and supporting its growing integration ecosystem. Learn more about Cognee at cognee.ai. Conclusion My MergeTober contribution explores how Salesforce CRM data can become part of AI knowledge workflows through authentication, structured ingestion, incremental synchronization, and deletion handling. With my local mocked tests passing and the pull request awaiting review, I look forward to continuing to improve the contribution through feedback and validation. I'm excited to contribute to open source and explore how connected business knowledge can make AI applications more useful.

Cognee- Turn documents, code, and conversations into connected knowledge graphs. topoteretes/cognee