DEV Community: Priyansh Narang

Teaching an AI agent what’s blocking the sprint: a ClickUp connector for cognee

Priyansh Narang — Thu, 15 Oct 2026 04:03:36 +0000

Most teams have the same problem: the answer to "why is this blocked?" exists, but it's spread across a task status, a custom field, three comments and a Doc someone wrote last month. Nobody reads all of that before stand-up.

I wanted an agent that could, so I built a ClickUp connector for cognee, the open-source memory layer for AI agents, as part of Mergetober. It turns tasks, comments and Docs into memory an agent can query, and keeps that memory in sync as the workspace changes.

This post is about what it took to make that reliable. The ClickUp API had a few surprises, and two of them only showed up when I tested against a real workspace.

Ten lines to a sprint memory

import asyncio

import cognee
from cognee_community_connector_clickup import clickup_source


async def main():
    await cognee.remember(
        clickup_source(space_ids=["90120001"]),  # token from CLICKUP_API_TOKEN
        dataset_name="sprint_memory",
        primary_key="id",
        write_disposition="merge",
        max_rows_per_table=0,
    )
    answer = await cognee.search(
        query_text="Which tasks are blocked, and what are they waiting on?",
        query_type=cognee.SearchType.GRAPH_COMPLETION,
        datasets=["sprint_memory"],
    )
    print(answer)


asyncio.run(main())

Authentication is a ClickUp personal API token (avatar → Settings → Apps → API Token → Generate). You choose what to ingest with space_ids, folder_ids or list_ids. Run it again tomorrow and only what changed gets fetched.

The catch with ClickUp's hierarchy

ClickUp nests everything: Workspace → Space → Folder → List → Task, and each level is its own API call. The obvious implementation walks the whole tree before it sees a single task, and does it again on every sync. ClickUp allows 100 requests per minute, so on a large workspace that walk is most of your budget.

The way around it is the filtered team-tasks endpoint, GET /team/{team_id}/task. It returns tasks from every list in the workspace, 100 per page, and accepts a date_updated_gt filter. Each task already carries its list and folder names. The only thing it doesn't name is the Space, so the connector fetches Space names once, caches them in the dlt state, and refreshes them only when a task points at a Space it hasn't seen.

On my test workspace that meant one Space lookup on the first sync and zero on every sync after.

Custom fields don't return what you see

Custom fields are where teams keep the important stuff: severity, components, the reviewer. But the API returns them in a form only ClickUp understands. A dropdown comes back as 2, labels as a list of option IDs, and a people field as a list of user objects.

Feed that straight into a knowledge graph and the agent learns that "Severity is 2". The connector resolves each value through the field's type_config, so the document says "Severity: High". It also handles dates, checkboxes, currency, ratings, locations and progress. Here's the connector's real output for an example task:

Each task document also carries status, priority, assignees, tags, its Space / Folder / List location, checklists and every comment. The comment endpoint returns only the 25 newest, so the connector pages back through the rest. ClickUp Docs are synced too, through the v3 Docs API, with nested pages rendered as sections.

Two things I only found on a real workspace

My test suite passed. Then I pointed the connector at a real ClickUp workspace, and two assumptions turned out to be wrong.

1. date_updated_gt isn't strictly "greater than". I passed the newest task's own timestamp, and ClickUp still returned that task (newest − 1 ms returned it, newest returned it, newest + 1 ms didn't). So every "nothing changed" rerun was re-ingesting the latest task and re-fetching its comments. The fix: skip a task whose timestamp equals the cursor if it's already been ingested, while still picking up a genuinely new task created in that same millisecond.

2. Deleting a comment is invisible. I posted a test comment on a real task and watched the task's date_updated. It moved, so new comments are picked up. Then I deleted the comment, and date_updated stayed exactly the same. A cursor-based sync would have kept that deleted comment in the agent's memory forever.

Action in ClickUp	Changes `date_updated`?	How the connector handles it
Add a comment	Yes (verified live)	Next incremental sync
Delete a comment	No (verified live)	Daily comment re-check

The fix is a comment re-check, once a day by default. The connector re-reads comments on the tasks in scope, compares them with a fingerprint it stored last time, and re-renders only the tasks whose comments changed. I verified it against the live workspace too: the deleted comment was gone from memory after the next check.

What a sync costs

These numbers are from my test workspace (12 tasks, 1 Doc). The first sync made 17 requests, most of them comments, one per task. A rerun with nothing changed made 4: the workspace lookup, the incremental listing, the deletion check and the Docs listing. The daily comment re-check costs about one request per task, which is why it runs daily rather than on every sync.

Forgetting is part of memory

ClickUp has no deletion feed, so every run re-lists the IDs in scope. Tasks and Docs that were deleted, archived or moved out of the selection become tombstone rows ({"id": ..., "_deleted": true}). dlt hard-deletes them, and cognee's orphan cleanup removes them from the graph and vector store.

Two guards stop a bad day from wiping memory. If a listing comes back empty while items are known, the connector assumes an outage and skips the cleanup. And it only saves its progress after a run fully succeeds, so a crash halfway through just means the next run repeats the work.

What it doesn't do (yet)

Threaded replies to comments aren't fetched; ClickUp serves them through a separate endpoint per comment.
Attachments aren't downloaded.
Docs are scoped by their direct parent: selecting a Space includes Docs that live directly in it.

What I learned

Mocked tests told me the code did what I expected. Only the real API told me whether my expectations were right. Both of the bugs above passed every unit test, because the fake API behaved the way I assumed ClickUp did. Now the fake behaves the way ClickUp actually does, so the tests guard against those bugs coming back.

Try it

The connector is in review as topoteretes/cognee-community#278, for issue #4701. Until it's merged, you can install it from my branch:

pip install "cognee-community-connector-clickup @ git+https://github.com/priyansh-narang2308/cognee-community@feature/clickup-connector#subdirectory=packages/connector/clickup"

If your team lives in ClickUp, I'd like to hear what you'd ask a sprint agent first.

I gave an AI assistant a memory of PubMed - and learned why "forgetting" is the hard part

Priyansh Narang — Thu, 15 Oct 2026 03:51:03 +0000

I wanted to see whether an AI assistant could keep up with a fast-moving corner of cancer research instead of answering from whatever it saw during training. So I picked one narrow question: how do KRAS G12C lung and colorectal tumours become resistant to sotorasib and adagrasib? Then I built a PubMed connector for cognee, the open-source memory layer for AI agents, as part of Mergetober.

This post covers how to use it, what actually happened when I pointed it at real PubMed data, and three things about NCBI's API that surprised me.

The problem with "just ask the model"

Resistance to KRAS G12C inhibitors is an active research area, with new case reports and preprints every month. A model's training data is frozen. Pasting a few abstracts into a chat window doesn't scale and is gone the next session.

What I wanted was memory: a store that pulls in the relevant literature, keeps it up to date on its own, and turns it into something an agent can reason over (entities and relationships, not just text chunks). That's what cognee does with documents. It was missing a way to get PubMed into it.

Ten lines to a literature memory

The connector is a dlt source you hand to cognee.remember. You choose what to ingest with an ordinary PubMed query, exactly what you'd type into the PubMed search box.

import asyncio

import cognee
from cognee_community_connector_pubmed import pubmed_source

TERM = '"KRAS G12C" AND (adagrasib OR sotorasib) AND resistance'


async def main():
    await cognee.remember(
        pubmed_source(term=TERM, mindate="2024/01/01"),
        dataset_name="kras_g12c_resistance",
        primary_key="id",
        write_disposition="merge",
        max_rows_per_table=0,
    )
    answer = await cognee.search(
        query_text="Which secondary KRAS mutations cause resistance to G12C inhibitors?",
        query_type=cognee.SearchType.GRAPH_COMPLETION,
        datasets=["kras_g12c_resistance"],
    )
    print(answer)


asyncio.run(main())

No API key is required, because PubMed is public. If you create a free NCBI key, the rate limit goes from 3 to 10 requests per second:

export NCBI_API_KEY="your_key"      # account.ncbi.nlm.nih.gov → Account settings → API Key Management
export NCBI_EMAIL="you@example.org" # NCBI asks tools to send a contact address

What happened on real data

Before involving an LLM at all, I wanted to see the ingest side behave, so I ran the sync twice against live NCBI and counted the requests.

The query matches 253 PubMed records in total. Limiting it to records added since 2024 left 155.
The first sync stored all 155 in about 7 seconds, using just two EFetch batches.
The second sync made zero EFetch calls and finished in about 2.4 seconds. Nothing had changed, so nothing was downloaded or sent to the LLM again.
36 of the 155 had structured abstracts. The connector keeps those sections (Background, Methods, Results, Conclusions) as headings, which gives cognify much cleaner text to work with.

Three of the papers mention Y96, a mutation in the switch-II pocket where these drugs bind. One of them, a 2026 case report in The Oncologist (PMID 42474245), describes a patient whose tumour developed both Y96S and Y96C after about nine months on a G12C inhibitor. Adding cetuximab and trametinib to sotorasib didn't hold it back; progression-free survival was 1.9 months.

This is the kind of finding I want an assistant to remember and connect: drug → target → resistance mutation → which combinations didn't work. A frozen model can't know about a paper from this summer, but the memory layer now does.

Under the hood

E-utilities is a two-step API. esearch.fcgi turns a query into PMIDs, and efetch.fcgi returns the full XML for up to 200 of them at a time. The connector parses that XML into Markdown (title, authors, journal, DOI and PMCID, labelled abstract sections, MeSH terms) and writes one row per article. cognee then ingests each row as a document and runs entity extraction on it.

Getting that basic loop working took an afternoon. Making it correct took longer, because of these three surprises.

1. ESearch stops at 10,000 results

ESearch never returns more than 10,000 PMIDs for a query. My first test, plain CRISPR gene therapy, matches 10,930 records. A naive loop would silently drop the last 930.

The fix: if a date window has more than 10,000 hits, split it in half and search each half, repeating until every slice fits. On the CRISPR query that took 13 requests and listed all 10,930 records with no duplicates.

2. Entrez dates are in US Eastern time

Incremental sync uses the Entrez date (edat), the day a record entered PubMed. After each run the connector saves the last day it covered and searches from there next time.

NCBI assigns those dates in US Eastern time, though, so a run just after midnight UTC can miss records added late on the previous Eastern day. The connector re-reads one day of overlap and skips PMIDs it already has, so the overlap costs one extra search rather than re-ingesting anything.

3. A retraction doesn't change the date

A memory layer has to be able to forget, especially in medicine. If a paper is retracted, you don't want your assistant citing it next month.

But retracting a paper doesn't change its Entrez date, so a date-based cursor would never notice. Each run also searches (your query) AND retracted publication[pt] and removes any article you already ingested that has since been retracted.

Deleted records work the same way. Each run re-lists the PMIDs your query currently matches, and anything that has disappeared gets a tombstone row ({"id": "pubmed:<PMID>", "_deleted": true}). dlt hard-deletes those rows, and cognee's orphan cleanup removes them from the graph and vector store.

There's one safety rule. If PubMed suddenly returns nothing at all while articles are known, the connector assumes an outage rather than "everything was deleted", and skips the cleanup. It also only saves its progress after a run fully succeeds, so a crash halfway through just means the next run repeats the work.

What it doesn't do (yet)

Abstracts only. Full text lives in PubMed Central, which is a separate API.
Corrections to an existing record aren't picked up, because a revision doesn't change the Entrez date. NCBI tracks revisions with a different date field (mdat), which would be a natural next step.
Very broad queries are expensive. Something like cancer matches millions of records. Narrow the query or set mindate before your first run.

What I learned

The interesting part of a connector isn't fetching data, it's deciding what changed and what should be forgotten. Each of the three issues above came from asking "what happens on the second run?" instead of only testing the first.

Try it

The connector is in review as topoteretes/cognee-community#275, for issue #4807. Until it's merged, you can install it from my branch:

pip install "cognee-community-connector-pubmed @ git+https://github.com/priyansh-narang2308/cognee-community@feature/pubmed-connector#subdirectory=packages/connector/pubmed"

If you're working on research assistants or literature-review tools, I'd love to hear which queries you'd point it at.

RepairVision: An Intelligent Repair Café Platform for Multimodal Fault Diagnosis and Sustainable Electronics Repair

Priyansh Narang — Thu, 08 Oct 2026 10:12:32 +0000

Every week, perfectly fixable things end up in the bin. A kettle with a tripped fuse. A lamp with a loose wire. A jumper with a hole in the elbow. Repair cafés exist to stop that: free, volunteer-run sessions where people bring something broken and fix it together.

For Hacktoberfest Hack Day Coimbatore 2026, our team, The Blacklisted, built RepairVision: a platform that runs a repair café day to day and adds AI where it genuinely helps: working out what is wrong, and deciding whether a repair is worth it.

The problem

Repair cafés do great work, but three things hold them back:

Running a session is chaotic. Paper sign-in sheets, a queue of visitors, keeping track of who is fixing what.
Diagnosis depends on who turns up. The volunteer who knows bikes might not know hairdryers.
People don't know if repair is worth it. Without a clear comparison, the default is "just buy a new one".

What we built

RepairVision follows an item from "it's broken" to "it's fixed":

AI Diagnosis

Describe the device and add a photo. Gemma 4 suggests up to three likely faults, each with the evidence that supports it and the evidence that's still missing, then recommends safe checks and asks one question at a time to narrow it down.

Every result is labelled as provisional, and a hazard screen that doesn't depend on the model keeps risky devices (mains appliances, e-bike batteries) on the safe side. Each suggestion is backed by our own repair knowledge base of 100+ entries, the café's past repairs and iFixit guides.

Repair or Replace?

The question people actually ask next: is it worth fixing? The advisor compares the repair cost with a replacement, allows for the chance the repair fails, and shows the CO₂ and waste a repair avoids, with all the working shown.

A site assistant that knows what's happening

A friendly 3D character sits in the corner of every page. Ask it "What events are on right now?" and it answers from the café's live data, then opens the right page for you.

It only ever sees what the public website already shows, so it can't leak anyone's name, contact details or repair, whatever you ask it.

Everything a café needs on the day

QR check-in, a live repair queue, a waiting-room display, session planning and impact statistics. All of it is in one place, in a clean dark interface.

How we built it

Frontend: SvelteKit, TypeScript and Tailwind CSS
Backend: a single Cloudflare Worker serving the pages and the API
Data: Cloudflare D1 (SQLite) with Drizzle ORM, and R2 for photos
AI: Google Gemma 4 (gemma-4-26b-a4b-it) through the Gemini API

A few decisions we're proud of:

We never trust raw AI output. Gemma's replies must be valid JSON that passes a schema, and safety rules run in our own code afterwards.
No invented answers. If the AI is unavailable, people see an honest error. Prices are never made up.
Privacy by design. The public assistant reads only public data, and photos sent for diagnosis aren't stored.
Free to run. Cloudflare's free tier plus Gemma via the Gemini API means a volunteer café can host it at no cost.
Tested offline. All 199 tests use fake AI responses and run in the real Workers runtime.

Challenges and what we learned

Making AI safe to show to the public took more than a good prompt. Strict schemas and code-level guardrails made the difference.
Four people, one codebase, one day. Small focused commits, shared types in one package and a fast test suite let us merge each other's work without breaking things.
Free-tier limits shape design. Working within about 10 ms of CPU per request pushed us towards caching and keeping AI calls as network waits rather than computation.

What's next

Deploying it for a real repair café and gathering feedback from volunteers
Live part prices in the Repair or Replace advisor
Growing the knowledge base with every repair the community completes

Try it

Code: https://github.com/Kanishk-Rungta/RepairVision_AI
Live demo: https://repair-cafe-hub.circularity-cloudflare.workers.dev
Demo video: https://drive.google.com/drive/folders/18YFLWch7_9b4JTImlz_1wdl1-F-F6WVc?usp=drive_link

Built by The Blacklisted:
Kanishk Rungta, Keertan Vasani, Adiseshan Ramanan and Priyansh Narang.

Fix more. Throw away less.