AI agents are only as good as what they remember. Cognee is an open-source memory layer for agents: you hand it documents, chats or data, and it builds a knowledge graph the agent can query later. For Mergetober (WeMakeDevs × Cognee) I spent my contribution on the Google Calendar connector, which turns your calendar into agent memory, so you can ask things like "what did I agree to in last week's design review?" or "when is my next 1:1 with Priya?".
The connector is a dlt source. You hand it to Cognee in one call:
import cognee
from cognee_community_connector_google_calendar import google_calendar_source
await cognee.remember(
google_calendar_source(calendar_ids=["primary"]),
dataset_name="calendar",
primary_key="id",
write_disposition="merge",
)
answer = await cognee.recall("When is my next design review?")
Each event becomes a short text document ("Calendar event: Design review / When: ... / Attendees: ..."), which Cognee chunks and turns into entities and relations. Later syncs use Google's sync tokens, so only changed events are re-read, and deleted events are forgotten.
In Google Calendar your main calendar has two names: the alias "primary", and its real id, which is your email address. The connector's helper script examples/login.py lists your calendars by their real ids, so a natural setup looks like this:
GOOGLE_CALENDAR_IDS=primary,me@gmail.com
The connector treated those as two different calendars. It kept separate sync state for each and built row ids from the configured string (gcal:primary:<event> and gcal:me@gmail.com:<event>), so every event was stored twice. That means double the LLM calls during cognify and duplicate facts in the graph. It's the kind of quiet bug that never crashes anything; your agent just gets noisier and more expensive.
The sync already lists your calendars to get their display names, and that listing marks which one is primary. So the fix reuses it:
"primary" and that id as the same key, and keep only the first spelling you configured.
Keeping the first spelling matters: someone with the default ["primary"] setup sees no change at all (same row ids, same sync state, nothing re-ingested). And if an earlier sync already stored both copies, the second spelling now counts as a calendar removed from the config, so the connector's existing forget path cleans the duplicates up on the next run.
The connector's tests run against an in-memory fake of the Calendar API, so no Google account is needed. I added three tests: both spellings sync as one calendar, the first spelling is kept, and a leftover duplicate from an older sync gets forgotten. Then I ran the whole suite plus ruff on Python 3.11 and 3.13 with GitHub Actions on my fork.
Links: