Introduction

AI systems are becoming more useful when they can work with information beyond a single conversation. Project notes, meeting records, technical documentation, and personal knowledge bases can all provide context that a model would otherwise lack.

But connecting an AI system to a source of information is only part of the problem. That information changes over time. Notes get edited, moved to different notebooks, archived, or deleted. If an AI system continues to retrieve outdated information, its answers can become misleading even when the original data was once correct.

This is the problem addressed by an Evernote connector developed for the Cognee Community project. The implementation focuses on bringing Evernote notes into Cognee, synchronizing changes incrementally, and representing deleted or out-of-scope notes so that they can be removed from the ingested dataset.

The interesting part is not simply importing notes. It is handling the changes that happen after the initial import.

Why importing data once is not enough

Consider a simple example.

A team stores its service-restart procedure in Evernote. An AI system ingests the note and makes its contents available through its knowledge pipeline. A week later, the procedure changes. Eventually, the old note is deleted.

If the integration only supports the initial import, the AI system may continue to retrieve information from the previous version. The source has changed, but the ingested representation has not necessarily followed it.

There are two related problems here:

• Synchronization: Detecting new and updated information without repeatedly importing everything.
• Deletion handling: Ensuring that information removed from the source does not remain indefinitely in the destination dataset.

The second problem deserves particular attention. Updating a record is relatively straightforward when the new version is available. A deleted record is different: the connector must recognize that the absence of the original note is meaningful and communicate that change to the destination.

A reliable integration needs to account for both.

Understanding the Evernote–Cognee integration

Evernote stores notes along with organizational information such as notebooks and tags. Cognee provides a pipeline for turning source information into data that can be used by its AI memory and search workflows.

The connector described in the project adds a bridge between these systems.

Its main responsibilities include:

• Retrieving Evernote notes and their notebook and tag metadata.
• Converting Evernote's ENML note content into plain text.
• Supporting notebook and tag filters.
• Tracking changes between synchronization runs.
• Representing deleted or out-of-scope notes as deletion markers.
• Passing the resulting records through a data-loading and ingestion pipeline.

The implementation lives in the Cognee Community connector package rather than being described as a built-in Evernote integration in Cognee's core.

The associated work is documented in Cognee Community pull request #559, which addresses Cognee issue #4728.

How the connector works

The integration can be understood as a sequence of steps:

Evernote → Synchronization API → Connector → Data-loading pipeline → Cognee dataset

After ingestion, Cognee's graph and search workflows can be used to work with the resulting information.

1. Retrieving and preparing notes

The connector retrieves notes from Evernote and preserves notebook and tag names as metadata. Evernote's note content is stored in ENML, an XML-based format, so the connector converts it into plain text before ingestion.

This conversion is important because source formats are not always directly suitable for downstream processing. An integration needs to extract the useful content without carrying unnecessary source-format structure into the text representation.

The connector also supports selecting notebooks and tags. This allows users to limit the information they ingest instead of automatically importing every note in an account.

2. Synchronizing changes incrementally

Fetching every note during every run would be wasteful for a knowledge base that changes regularly.

The implementation uses Evernote synchronization chunks and an update-sequence-number (USN) cursor to track progress. The cursor records the position from which a subsequent synchronization should continue.

Conceptually, the process works like this:

1. Start from the last successfully saved synchronization position.
2. Request the changes available after that position.
3. Process the relevant records.
4. Save the updated position only after the run completes successfully.

This design helps avoid unnecessarily retrieving the entire account for every routine synchronization.

It also addresses an important failure scenario. If a run fails before completion, the connector should not advance its saved cursor as though all changes had been processed. Retrying from the previous position gives the failed work another opportunity to complete.

Incremental synchronization is therefore not just a performance optimization. Its correctness depends on how progress is recorded and how failures are handled.

3. Handling deleted notes

Deletion handling is one of the most significant parts of this implementation.

A connector cannot rely exclusively on receiving the current contents of a note. It also needs a way to represent the fact that a note should no longer be present in the destination.

The implementation uses deletion markers, commonly called tombstones, through the data-loading pipeline. It identifies notes that have been trashed, permanently deleted, or moved outside the selected ingestion scope.

These records allow the destination dataset to process removals rather than treating every synchronization as a process that only adds or updates information.

The distinction between deletion and filtering matters. If a user initially selects one notebook and later changes the selected scope, records that are no longer eligible for ingestion may also need to be reconciled. Otherwise, the destination can retain content that the current configuration no longer includes.

The connector's handling of these cases is intended to keep the ingested dataset aligned with the source and the selected scope.

However, a deletion marker being processed by a data-loading pipeline does not automatically prove that every downstream representation has been cleaned up. That requires separate verification.

The difficult edge cases

The general architecture is easy to describe. Making synchronization dependable requires handling less obvious situations.

What happens when a synchronization fails?

Saving the cursor only after a successful run helps prevent the connector from skipping changes after an incomplete run.

This is an important safeguard, although it does not eliminate every possible failure mode. A complete production assessment would also examine repeated retries, partially completed destination writes, duplicate processing, and recovery after interruptions.

The goal is not to assume failures will never occur. It is to make sure that failures do not silently leave the source and destination inconsistent.

What happens when a full resynchronization is necessary?

A stored cursor cannot always be trusted indefinitely. The implementation checks Evernote's synchronization metadata and can initiate a full resynchronization when the server's state indicates that the previous cursor is no longer suitable.

A full resynchronization introduces another challenge: notes deleted while the cursor was stale might not appear in the current listing.

To address this, the connector tracks note IDs previously ingested and reconciles them against the completed listing. The reconciliation is performed only after the full listing succeeds.

That last detail is important. A partial listing caused by a failure must not be mistaken for a complete account snapshot; otherwise, valid records could be incorrectly removed.

What happens when notes and notebook metadata arrive in different orders?

The article also identifies an ordering issue in Evernote's synchronization chunks. A note may arrive before the connector has received the corresponding notebook information.

The implementation addresses this by collecting names first and retrieving note bodies in a second pass.

This is a useful example of why API integrations need to account for the structure and ordering of the data returned by the source, rather than assuming related objects will always arrive together.

Authentication and compatibility

The connector includes an OAuth 1.0a helper and support for an existing access token. The implementation also uses a Python SDK dependency identified in the pull request as evernote-plus==1.28.1.dev2, a prerelease version.

These details matter when evaluating the connector beyond its basic data flow.

Authentication needs to be checked against the actual service, dependencies need to remain compatible with the runtime environment, and API behavior needs to be validated against real responses. A successful test with a simulated client cannot establish that all these conditions hold in a live deployment.

The pull request specifically states that live Evernote access was unavailable during development. Its OAuth endpoints were checked against another open-source implementation but were not exercised against the live service.

That limitation should be considered when assessing the current level of verification.

What the tests establish—and what they do not

The implementation reports 95 offline tests across Python 3.11, 3.12, and 3.13.

According to the pull request, these tests cover areas including the client wrapper, ENML conversion, synchronization chunks, cursor handling, retries, resynchronization, OAuth-related logic, and ingestion scenarios involving updates and deletions. The reported test scenarios also include a 60-note batch.

This is useful evidence that the connector's behavior has been exercised under controlled conditions.

However, the testing boundary matters.

The tests use fake Evernote clients rather than a live Evernote account. The author also explicitly notes that deletion tests verify the removal of Cognee Data records but do not assert cleanup of graph and vector representations.

These are meaningful limitations, not reasons to dismiss the work.

They identify the next areas that need verification:

• Authentication and API calls against a live Evernote account.
• Correct handling of actual synchronization responses and server-side changes.
• End-to-end deletion behavior across the relevant downstream stores.
• Recovery from interrupted runs and repeated synchronization.
• Compatibility with the required SDK and the supported Cognee versions.

Until these areas are verified, it would be premature to describe the connector as fully validated in production or to claim that all forms of stale AI memory have been eliminated.

Why this work matters

The broader engineering lesson is that an AI memory integration must do more than make information available.

It must also manage changes to that information over time.

Incremental synchronization helps reduce unnecessary work. Cursor management provides a way to track progress. Deletion markers communicate removals to the destination. Reconciliation helps recover when the incremental history is no longer sufficient.

Together, these mechanisms address a practical problem that can otherwise be overlooked when building AI systems around external knowledge sources.

There is also an important distinction between removing a source record and proving that every derived representation is gone. If information has been processed into other stores, those stores need their own cleanup guarantees and tests.

For AI systems that rely on retrieved context, this is more than a data-engineering detail. The quality of an answer depends partly on whether the information available to the system still reflects the intended source of truth.

Conclusion

The Evernote connector for Cognee Community is a useful example of the engineering work involved in maintaining an AI-connected knowledge base.

Its design addresses several important concerns: incremental synchronization, persistent cursor management, deletion markers, filtering, and recovery through full resynchronization. The reported offline tests provide evidence for these behaviors under simulated conditions.

At the same time, the implementation's documented limitations should remain part of the assessment. Live Evernote behavior has not been verified in the reported work, and downstream graph and vector cleanup is not established by the deletion tests described in the pull request.

The next step is therefore not simply to add more features. It is to validate the integration against the real service and confirm that updates and deletions propagate correctly through the entire ingestion and retrieval pipeline.

A knowledge system should not only learn from new information. It should also have a reliable way to stop relying on information that no longer belongs there.

References

• Original article: Evernote Meets Cognee — Without Stale Memories
• Cognee Community pull request #559: Evernote data-source connector
• Cognee issue #4728: Add Evernote data-source connector
• Evernote NoteStore API documentation

The problem

Years of runbooks, meeting notes, and project write-ups often sit in Evernote, where an AI assistant can't use them. Exporting them once doesn't help: notes change, and notes are trashed or deleted. An assistant that keeps answering from a note you deleted last week is worse than one that has never seen it.

What I built

A connector for Cognee Community, packages/connector/evernote/, that turns an Evernote account into Cognee memory:

• Ingestion: notes with their notebook and tag names; ENML converted to plain text.
• Incremental sync: Evernote's sync chunks and a persisted update-sequence-number (USN) cursor, so later runs only fetch what changed.
• Deletions: trashed, expunged, or out-of-scope notes are removed from Cognee's dataset.
• Scope: choose notebooks and/or tags to ingest.
• Auth: 3-legged OAuth 1.0a helper, or an existing token.

How it fits together

Evernote -> sync chunks -> connector (two-pass) -> dlt resource (merge + tombstones) -> Cognee ingestion -> dataset (and cognify -> graph/search)

The connector follows the pattern of the existing OneNote and Google Drive connectors: a dlt resource with merge and a _deleted hard-delete column, so Cognee's existing cleanup removes records that disappear.

Using it

import cognee
from cognee_community_connector_evernote import evernote_source

source = evernote_source(notebook_names=["Engineering"], tag_names=["runbook"])
await cognee.remember(source, dataset_name="evernote",
                      write_disposition="merge", max_rows_per_table=0)
answer = await cognee.search(
    query_text="How do we restart the payments service?",
    query_type=cognee.SearchType.GRAPH_COMPLETION, datasets=["evernote"])

No Evernote account? python examples/example.py --fake runs the whole flow, including a trashed note being removed, against an in-memory client.

How the incremental sync works

The cursor lives in dlt's resource state and is written only after a run has completed, so a failed run is retried from the old cursor and never skips changes. If Evernote's fullSyncBefore is newer than the last sync, or the server's update count is lower than the cursor, the connector does a full resync. A full resync cannot see notes deleted while the cursor was stale, so the connector tracks the note IDs it ingested and reconciles them, but only after the complete listing has succeeded.

Lessons learned

• The Python SDK is only Thrift stubs. I had to write my own client wrapper: lazy note-store URL, retries, rate-limit handling, and error mapping that never leaks the token.
• Evernote's filter has a trap. The sync-chunk filter rejects notebookGuids combined with includeExpunged, so scoping has to happen in the connector or deletions are lost.
• Notes can arrive before their notebook. Chunks are ordered by USN, so the connector collects names first and fetches note bodies second.
• Empty notes create ghost records, so they become tombstones instead.

What was tested, and what wasn't

• 95 offline tests (Python 3.11, 3.12, 3.13), including real Cognee ingestion with updates, incremental runs, deletions, and a 60-note batch.
• Deletion tests check that the Data records are removed; graph and vector cleanup is not asserted in this package.
• Not tested against a live Evernote account. Evernote's developer program appears to be gated. The OAuth endpoints were confirmed against another open-source implementation, not exercised live.
• The SDK is the pre-release evernote-plus==1.28.1.dev2.

Links

• Issue: https://github.com/topoteretes/cognee/issues/4728
• Pull request: https://github.com/topoteretes/cognee-community/pull/559
• Package: https://github.com/blvckShawn/cognee-community/tree/feature/evernote-connector-4728/packages/connector/evernote