Keenable Team
Keenable Team
Keenable is now a web-fetch backend for cognee agent memory
Keenable is now a web-fetch backend for cognee agent memory
Keenable is now a web-fetch backend for cognee agent memory
A page that goes into your agent's memory stays there. cognee turns it into a knowledge graph your agent queries later. From 1.5 onward, Keenable fetches those pages: hand it a URL and Keenable returns it as markdown, from our index or from a live read.
A page that goes into your agent's memory stays there. cognee turns it into a knowledge graph your agent queries later. From 1.5 onward, Keenable fetches those pages: hand it a URL and Keenable returns it as markdown, from our index or from a live read.
Fetch quality matters more in agent memory than in search
A search result is read once and discarded. A page that enters memory doesn’t: it’s chunked, embedded, turned into entities and left in the graph, where it can surface in any later recall.
An ingest mistake is not corrected by the next query: the navigation, the cookie banner and the footer links get embedded along with the content, and removing them means editing the graph by hand. You pay for that junk twice: once at ingest and again in every recall that pulls it back.
The fetch step decides what the graph is made of, and that’s where Keenable puts two controls.
Choose what content goes into the knowledge graph
You name it in the fetch call. It takes an instruction of up to 2000 characters and returns only what you named. Hand that result to cognee.add() and run chunking and entity extraction on it instead of the full page:
The extraction prompt has no environment variable, so you narrow on a direct call like the one above, not on the cognee.remember() path.
Control content freshness
One flag does it: live=True on the job, or KEENABLE_LIVE_FETCH in the environment. Either one tells us to read the page live instead of serving our indexed copy.
For a page you re-read on a schedule, every run overwrites that page's node with a fresh SHA-256 of the content it fetched, so a change on the page gives a different hash. Without the live read, the hash tracks our indexed copy rather than the page.
Start with Keenable in cognee
Setup is two lines: pip install cognee, then KEENABLE_API_KEY in your environment.
cognee picks the backend from the keys it finds in your environment: keep KEENABLE_API_KEY the only fetch key there and we run. Pass preferred_tool="keenable" to the fetch layer to settle it in code instead. Nothing else to install: cognee calls us through the HTTP client it already ships with.
Both controls, with every parameter and its default, are documented at docs.keenable.ai/integrations/cognee.
Fetch quality matters more in agent memory than in search
A search result is read once and discarded. A page that enters memory doesn’t: it’s chunked, embedded, turned into entities and left in the graph, where it can surface in any later recall.
An ingest mistake is not corrected by the next query: the navigation, the cookie banner and the footer links get embedded along with the content, and removing them means editing the graph by hand. You pay for that junk twice: once at ingest and again in every recall that pulls it back.
The fetch step decides what the graph is made of, and that’s where Keenable puts two controls.
Choose what content goes into the knowledge graph
You name it in the fetch call. It takes an instruction of up to 2000 characters and returns only what you named. Hand that result to cognee.add() and run chunking and entity extraction on it instead of the full page:
The extraction prompt has no environment variable, so you narrow on a direct call like the one above, not on the cognee.remember() path.
Control content freshness
One flag does it: live=True on the job, or KEENABLE_LIVE_FETCH in the environment. Either one tells us to read the page live instead of serving our indexed copy.
For a page you re-read on a schedule, every run overwrites that page's node with a fresh SHA-256 of the content it fetched, so a change on the page gives a different hash. Without the live read, the hash tracks our indexed copy rather than the page.
Start with Keenable in cognee
Setup is two lines: pip install cognee, then KEENABLE_API_KEY in your environment.
cognee picks the backend from the keys it finds in your environment: keep KEENABLE_API_KEY the only fetch key there and we run. Pass preferred_tool="keenable" to the fetch layer to settle it in code instead. Nothing else to install: cognee calls us through the HTTP client it already ships with.
Both controls, with every parameter and its default, are documented at docs.keenable.ai/integrations/cognee.
