DEV Community: Pranav

Building Context-Aware Multilingual AI Agents with Cognee and Crowdin

Pranav — Sun, 25 Oct 2026 10:48:18 +0000

In the era of autonomous AI applications, LLMs are increasingly deployed to interact with global audiences across dozens of languages. From multilingual customer support agents to automated documentation generators, modern systems must communicate fluently and accurately in the target dialect.

However, LLMs possess a well-known vulnerability: terminology drift. When asked to translate domain-specific software concepts, models frequently invent literal, inconsistent, or prohibited translations rather than adhering to officially approved glossaries.

Enter Crowdin: the enterprise localization platform trusted by GitHub, GitLab, Discord, and Microsoft open source to orchestrate translations, brand glossaries, and string catalogs.

With the release of the Crowdin Connector for Cognee, engineering teams can now stream localization repositories, approved terminology glossaries, and translation memory directly into Cognee's AI-native knowledge graph.

Why Connect Crowdin to Cognee?

Integrating Crowdin into Cognee's memory engine empowers autonomous agents with:

Deterministic Terminology Grounding: When an AI agent responds in German, French, or Japanese, it queries Cognee's memory graph to ensure it uses the approved glossary term (e.g., using "Passkey" instead of a mistranslated "Passwort").
Context-Aware Translation: LLMs can inspect string keys, UI context descriptions, and character limits stored in Cognee memory before generating localized copy.
Automated Localization Audits: Autonomous agents can inspect translation completion metrics across branches, flagging missing translations or out-of-date strings.
Orphan Cleanup: When outdated strings or deprecated terms are removed from Crowdin, Cognee's write_disposition="replace" ensures they are automatically forgotten from graph memory.

Architectural Deep Dive

The Crowdin connector is designed for production reliability:

Full Data Ingestion:
- Projects: Ingests project identifiers, source languages, target locales, and web dashboard links.
- Glossaries: Maps approved terminology, prohibited synonyms, parts of speech, and linguistic definitions.
- Localization Strings: Ingests developer context comments, string keys, English source text, and target translations.
Cognee Pipeline Integration:
- Sets DOCUMENT_SOURCE_ATTR = "crowdin" on all emitted documents, ensuring seamless processing through Cognee's cognify() pipeline.
- Employs write_disposition="replace" on the crowdin_localization table to clean up deleted or deprecated terms.
- Generates deterministic uuid5 document IDs based on project IDs and report types, preventing duplicate nodes in the knowledge graph.
Enterprise-Grade Resilience:
- Exponential backoff with jitter on HTTP 429 rate limits and 5xx transient server errors.
- Automatic credential and token sanitization ([REDACTED_CROWDIN_TOKEN]) in all logs and exception messages.
- Clean Markdown document generation structured for optimal chunking and embedding retrieval.

Quickstart Guide

1. Installation

Install Cognee and the community Crowdin connector:

pip install cognee cognee-community-connector-crowdin

Or using uv:

uv add cognee cognee-community-connector-crowdin

2. Ingesting Localization Knowledge

import asyncio
import os
import cognee
from cognee_community_connector_crowdin import (
    CrowdinConfig,
    crowdin_connector,
)

async def main():
    # Configure the connector
    config = CrowdinConfig(
        api_token=os.getenv("CROWDIN_PERSONAL_TOKEN", "your-crowdin-token"),
        include_glossaries=True,
        include_strings=True,
    )

    print("Fetching Crowdin localization knowledge...")
    documents = await crowdin_connector(config)
    print(f"Retrieved {len(documents)} localization documents.")

    # Ingest into Cognee Memory
    print("Ingesting into Cognee...")
    await cognee.add(documents, dataset_name="localization_knowledge")
    await cognee.cognify(dataset_name="localization_knowledge")

    # Natural Language Terminology Reasoning
    query = "What is the approved German translation for Passkey?"
    print(f"\nQuerying Cognee: '{query}'")
    results = await cognee.search(query, dataset_name="localization_knowledge")

    for r in results:
        print(f"\nMemory Result: {r}")

if __name__ == "__main__":
    asyncio.run(main())

What Does Ingested Memory Look Like?

The connector parses Crowdin REST API v2 JSON into structured Markdown reports optimized for graph extraction:

# Terminology Glossary: Acme Technical Lexicon (ID: 501)

**Total Terms Recorded**: 2

## Approved Terms & Conceptual Definitions
### Term: `Passkey` (EN)
- **Term ID**: 9001
- **Part of Speech**: noun
- **Status**: approved
- **Definition / Context**: FIDO2 WebAuthn cryptographic credential.

### Term: `Passkey` (DE)
- **Term ID**: 9002
- **Part of Speech**: noun
- **Status**: approved
- **Definition / Context**: Do not translate as Passwort. Keep as Passkey.

When Cognee processes this markdown through cognify(), it constructs knowledge graph nodes representing:

Terms (e.g., Passkey)
Languages (e.g., EN, DE)
Concepts & Guidelines (e.g., Do not translate as Passwort)
Relationships (e.g., Acme Technical Lexicon -> CONTAINS -> Passkey, Passkey -> HAS_RESTRICTION -> Do not translate as Passwort)

Open Source & Community

The Crowdin connector is an open-source contribution to the Cognee Community ecosystem.

Cognee Core: https://github.com/topoteretes/cognee
Community Connectors: https://github.com/topoteretes/cognee-community
Crowdin: https://crowdin.com/

Empower your AI agents with reliable, multilingual memory today!

Bridging Container Orchestration and Autonomous AI: The Cognee Portainer Connector

Pranav — Sun, 25 Oct 2026 10:47:52 +0000

Managing modern cloud-native architectures is fraught with container sprawl. Across distributed development teams, thousands of microservice containers, Swarm stacks, and Kubernetes deployments run simultaneously across local workstations, staging clusters, and remote edge gateways.

While Portainer (boasting over 33,000+ GitHub stars) provides a premier GUI and management plane for containerized infrastructure, the rich architectural context inside those containers—such as exposed ports, volume mount topologies, restart policies, and Docker Compose definitions—remains siloed inside dashboards and daemon sockets.

With the release of the Portainer Connector for Cognee, developers can now seamlessly stream their live container infrastructure directly into Cognee, transforming raw DevOps telemetry into an AI-queryable knowledge graph and memory layer.

Why Portainer + Cognee?

Autonomous AI coding agents, DevOps assistants, and Site Reliability Engineers (SREs) frequently require real-time infrastructure answers that static codebases cannot provide:

"Which containers in our staging cluster have port 6379 open without authentication?"
"Show me the compose definition and volume mounts for the caching stack."
"Are any edge nodes running outdated container base images?"
"What microservices depend on the internal messaging broker?"

By connecting Portainer to Cognee:

Semantic Container Discovery: Natural language searches across container names, image tags, network ports, and storage volumes.
Topology Synthesis: Cognee's cognify() pipeline automatically extracts graph relationships between environments, stacks, and containers.
Orphan Cleanup: Decommissioned containers or deleted stacks are automatically forgotten thanks to Cognee's write_disposition="replace".
Idempotent Synchronization: Deterministic document hashing ensures re-running the connector updates existing graph nodes without duplicate entities.

Architectural Deep Dive

The Portainer Cognee connector is built to production standards:

Cluster & Environment Discovery: Maps all registered Docker standalone engines, Swarm managers, Kubernetes clusters, and remote Edge agents.
Stack & Compose Ingestion: Extracts stack names, deployment statuses, and raw docker-compose YAML definitions into memory.
Container Catalog: Ingests container names, image digests, running states, health statuses, port forwardings, and volume mounts.
Resilient HTTP Communication: Built-in exponential backoff with jitter on HTTP 429 rate limits and 5xx transient server errors.
Credential Sanitization: The connector automatically masks tokens, passwords, and API keys ([REDACTED_PORTAINER_CREDENTIAL]) in logs and exception traces.

Quickstart Guide

1. Installation

Install Cognee and the community Portainer connector:

pip install cognee cognee-community-connector-portainer

Or using uv:

uv add cognee cognee-community-connector-portainer

2. Ingesting Infrastructure into Memory

import asyncio
import os
import cognee
from cognee_community_connector_portainer import (
    PortainerConfig,
    portainer_connector,
)

async def main():
    # 1. Configure the connector
    config = PortainerConfig(
        api_url=os.getenv("PORTAINER_URL", "https://portainer.local:9443"),
        api_key=os.getenv("PORTAINER_API_KEY", "ptr_your_api_key"),
        include_containers=True,
        include_stacks=True,
    )

    print("Fetching Portainer environment & container telemetry...")
    documents = await portainer_connector(config)
    print(f"Retrieved {len(documents)} infrastructure documents.")

    # 2. Ingest into Cognee memory
    print("Ingesting into Cognee...")
    await cognee.add(documents, dataset_name="infrastructure_topology")
    await cognee.cognify(dataset_name="infrastructure_topology")

    # 3. Query container and cluster topology with natural language
    query = "What containers are currently running with exposed ports?"
    print(f"\nQuerying Cognee: '{query}'")
    results = await cognee.search(query, dataset_name="infrastructure_topology")

    for r in results:
        print(f"\nMemory Result: {r}")

if __name__ == "__main__":
    asyncio.run(main())

What Does Ingested Memory Look Like?

The connector parses complex Docker daemon JSON into clean, structured Markdown reports optimized for embedding and graph extraction:

# Container Runtime State: Primary Docker Cluster (ID: 1)

**Total Containers**: 2

## Container Catalog
### Container: /redis-master
- **Container ID**: `abc123456789`
- **Image**: `redis:7-alpine`
- **State / Status**: `running` (Up 4 days, healthy)
- **Port Forwarding**: 6379->6379/tcp
- **Volume Mounts**: `/var/lib/redis` -> `/data`

When Cognee processes this markdown through cognify(), it constructs knowledge graph nodes representing:

Environments (e.g., Primary Docker Cluster)
Containers (e.g., /redis-master)
Images (e.g., redis:7-alpine)
Relationships (e.g., Primary Docker Cluster -> RUNS -> /redis-master, /redis-master -> MOUNTS -> /data, /redis-master -> EXPOSES -> 6379)

Summary & Open Source

The Portainer connector is an open-source contribution to the Cognee Community ecosystem.

Cognee Core: https://github.com/topoteretes/cognee
Community Connectors: https://github.com/topoteretes/cognee-community
Portainer: https://github.com/portainer/portainer

Try it out today to bring intelligent container topology memory to your DevOps workflows!

Building an Autonomous AI Incident Knowledge Engine with Cognee and Uptime Kuma

Pranav — Sun, 25 Oct 2026 10:45:52 +0000

In modern infrastructure management, keeping services online is only half the battle. When downtime, degraded performance, or cascading outages occur, engineering teams scramble across alert histories, heartbeat charts, and incident post-mortems to understand what failed, when, and why.

While monitoring tools like Uptime Kuma (with over 65,000+ GitHub stars) excel at real-time alerting, health-checking, and status-page communication, their historical telemetry often remains locked in transient time-series logs and relational tables.

Enter Cognee: an open-source, AI-native memory engine that transforms unstructured text, logs, and relational data into interconnected knowledge graphs and vector databases.

In this guide, we introduce the Uptime Kuma Cognee Community Connector, enabling autonomous LLMs, triage agents, and site reliability engineers (SREs) to query, reason over, and correlate infrastructure incidents using natural language.

Why Connect Uptime Kuma to Cognee?

Integrating Uptime Kuma telemetry into Cognee's memory graph unlocks several high-leverage capabilities:

Incident Post-Mortem & Timeline Synthesis: Automatically generate root-cause summaries by correlating heartbeat latency spikes, HTTP error codes, and maintenance windows.
Context-Aware Alert Triage: When a critical service degrades, LLM agents can query Cognee memory to determine: "Has this endpoint timed out before during scheduled maintenance, or did it coincide with a specific deployment?"
Automated Status Page Summaries: Ingest public status pages and incident announcements into conversational AI assistants for customer support and engineering teams.
Self-Healing Infrastructure: Power autonomous troubleshooting agents that inspect monitor topologies, analyze failure trends, and suggest remediation steps before incidents escalate.

Architectural Deep Dive

The Uptime Kuma connector is designed to be resilient, modular, and privacy-first:

Full Data Ingestion:
- Monitors: Health check types (http, ping, port, dns, keyword), target URLs/hosts, check intervals, retry strategies, and active tags.
- Heartbeats: Ping latency metrics, response codes, downtime durations, and error descriptions.
- Incidents & Status Pages: Published incident timelines, maintenance windows, and status-page service groups.
Cognee Pipeline Integration:
- Sets DOCUMENT_SOURCE_ATTR = "uptime_kuma" on all emitted documents, ensuring seamless processing through Cognee's cognify() pipeline.
- Employs write_disposition="replace", ensuring orphan records are cleaned up when monitors are reconfigured or resolved.
- Generates deterministic uuid5 document IDs based on monitor IDs and slug identifiers, preventing duplicate nodes in the knowledge graph.
Enterprise-Grade Reliability:
- Exponential backoff with jitter on HTTP 429 and 5xx responses.
- Automatic credential and token sanitization in all debug log outputs.
- Clean Markdown document generation structured for optimal chunking and embedding retrieval.

Quickstart Guide

1. Installation

Install Cognee and the community Uptime Kuma connector:

pip install cognee cognee-community-connector-uptime-kuma

Or using uv:

uv add cognee cognee-community-connector-uptime-kuma

2. Basic Usage

Run the connector to ingest your monitors and status pages into Cognee memory:

import asyncio
import os
import cognee
from cognee_community_connector_uptime_kuma import (
    UptimeKumaConfig,
    uptime_kuma_connector,
)

async def main():
    # Configure your Uptime Kuma instance
    config = UptimeKumaConfig(
        api_url=os.getenv("UPTIME_KUMA_URL", "https://uptime.example.com"),
        api_key=os.getenv("UPTIME_KUMA_API_KEY", "your-api-key"),
        slug="main-status", # Optional status page slug
        heartbeat_limit=50,
    )

    print("Fetching Uptime Kuma telemetry...")
    documents = await uptime_kuma_connector(config)
    print(f"Generated {len(documents)} incident & monitor reports.")

    # Ingest into Cognee Memory
    print("Ingesting into Cognee...")
    await cognee.add(documents, dataset_name="infrastructure_telemetry")
    await cognee.cognify(dataset_name="infrastructure_telemetry")

    # Natural Language Incident Reasoning
    query = "Which services experienced downtime or high latency in the last 24 hours?"
    print(f"\nQuerying Cognee: '{query}'")
    results = await cognee.search(query, dataset_name="infrastructure_telemetry")

    for result in results:
        print(f"\nMemory Result: {result}")

if __name__ == "__main__":
    asyncio.run(main())

What Does Ingested Memory Look Like?

The connector parses complex JSON telemetry into structured markdown documents tailored for vector similarity and graph extraction:

# Uptime Kuma Status Page: Production Infrastructure (main-status)

**Description**: Live public status for core APIs, auth services, and databases.

## Services & Monitors
- **Primary API Gateway** (HTTP Monitor)
  - Target: `https://api.internal.network/health`
  - Current Status: UP
  - Interval: 60s
  - Average Latency: 42ms

## Recent Incident Log
- **2026-10-23 14:15 UTC**: Elevated Latency on Auth Cluster
  - Status: Resolved
  - Impact: Response times peaked at 1,450ms before auto-scaling engaged.

When Cognee processes this markdown through cognify(), it constructs knowledge graph nodes representing:

Services (e.g., Primary API Gateway, Auth Cluster)
Incidents (e.g., Elevated Latency on Auth Cluster)
Relationships (e.g., Auth Cluster -> EXPERIENCED -> Elevated Latency, Auth Cluster -> RESOLVED_BY -> Auto-scaling)

This enables downstream AI agents to uncover hidden failure patterns across distinct services and cloud providers.

Open Source & Community

The Uptime Kuma connector is an open-source contribution to the Cognee Community ecosystem.

Cognee Core: https://github.com/topoteretes/cognee
Community Connectors: https://github.com/topoteretes/cognee-community
Uptime Kuma: https://github.com/louislam/uptime-kuma

Try it out today to bring intelligent incident memory to your observability stack!

Giving AI Agents Website & Conversion Memory: Building a Plausible Analytics Connector for Cognee

Pranav — Sun, 25 Oct 2026 10:43:13 +0000

How connecting privacy-first web analytics with Cognee's open-source memory layer lets AI agents answer operational questions about traffic, top content, and conversions without dashboard fatigue.

The Problem: AI Agents Have Traffic Amnesia

Modern AI agents and LLM companions are great at writing code, drafting emails, and summarizing documents. But when you ask them basic questions about your business or open-source project:

"How did our new release blog post perform this week?"
"Which referrer drove the most signups yesterday?"
"What are our top 5 most visited documentation pages right now?"

The agent has no idea.

Every API call to an LLM starts from scratch. For web and product metrics, developers are forced to manually export CSVs, copy-paste numbers, or switch back and forth between analytics dashboards. The knowledge of how users discover and interact with your product remains trapped in isolated analytics silos.

For Mergetober (the open-source contribution sprint hosted by WeMakeDevs and Cognee), I set out to solve this by building a dedicated Plausible Analytics connector for Cognee.

Why Plausible Analytics?

Plausible Analytics is one of the most popular open-source, privacy-focused web analytics platforms. It delivers lightweight, cookie-free web metrics without tracking personal data. Tech startups, open-source maintainers, and developer tools around the world rely on Plausible for real-time visibility into traffic and conversions.

By connecting Plausible to Cognee, AI agents gain continuous memory of site traffic, visitor trends, page engagement, and conversion goals.

How Cognee Powers Memory: From Metrics to a Knowledge Graph

Cognee is the open-source memory engine for AI agents. Instead of treating data as disconnected text chunks, Cognee uses a multi-stage cognitive pipeline:

add() / remember(): Ingests raw data through data-source connectors.
cognify(): Uses LLMs and entity extractors to build a rich knowledge graph of entities and semantic relationships.
recall() / search(): Lets agents traverse the graph to answer questions with verifiable context.

The Document-Mode Architecture

Relational database connectors in Cognee typically yield tabular schemas. But web performance insights are most useful to agents when formatted with high-signal context.

The Plausible connector utilizes Cognee's document-mode (DOCUMENT_SOURCE_ATTR = "plausible"). Rather than dumping raw JSON numbers, the connector normalizes metrics into structured Markdown documents:

Site Traffic & Performance Overview: High-level visitor counts, pageviews, bounce rate, and average session duration.
Top Content & Pages: URL paths ranked by visitor volume.
Acquisition Channels: Referral sources (GitHub, Google, Twitter, Hacker News, direct).
Audience Demographics: Top visitor countries and device distribution (Desktop vs Mobile).
Custom Goals & Events: Conversion triggers (signups, button clicks, downloads).

When cognify() processes these documents, it establishes graph nodes such as WebSite, WebPage, ReferralSource, and Goal, linking them through relationships like (:WebSite)-[:HAS_TOP_PAGE]->(:WebPage) and (:WebSite)-[:RECEIVES_TRAFFIC_FROM]->(:ReferralSource).

Building the Connector

The connector is implemented as a standalone package under packages/connector/plausible/ in the cognee-community repository, powered by dlt:

packages/connector/plausible/
├── README.md
├── pyproject.toml
├── cognee_community_connector_plausible/
│   ├── __init__.py
│   └── plausible.py
├── examples/
│   └── example.py
└── tests/
    └── test_plausible.py

Key Engineering Features:

Robust Resilience & Rate Limiting: The client automatically catches HTTP 429 responses and applies exponential backoff honoring the Retry-After header.
Pre-Ingestion Redaction: Tokens and secrets are sanitized before logging or raising exceptions, preventing API key leakage.
Full Snapshot Sync & Forget-on-Delete: Configured with write_disposition="replace". Deterministic document IDs (plausible:<site_id>:<period>:<report_type>) ensure unchanged reports aren't re-processed, while obsolete periods are purged through Cognee's automated orphan cleanup.
Self-Hosted Support: Works with Plausible Cloud (https://plausible.io) and self-hosted Plausible Community Edition instances by supplying a custom base_url.

Running It in 6 Lines of Code

Using the connector in any Cognee project is straightforward:

import asyncio
import os
import cognee
from cognee_community_connector_plausible import plausible_source

async def main():
    # 1. Instantiate the connector source
    source = plausible_source(
        site_id="myproject.com",
        api_key=os.environ["PLAUSIBLE_API_KEY"],
        period="30d",
    )

    # 2. Ingest into Cognee memory
    await cognee.remember(source, dataset_name="web_traffic")

    # 3. Ask your AI agent anything about your site performance
    answer = await cognee.search(
        query_text="What were our top 3 referral sources and what was our bounce rate?",
        query_type=cognee.SearchType.GRAPH_COMPLETION,
        datasets=["web_traffic"],
    )
    print(answer)

if __name__ == "__main__":
    asyncio.run(main())

Real-World Use Cases

Here is where this integration shines for development teams:

DevRel & Community AI Assistants: "Which docs page had the highest traffic spike after our v2 launch?"
Founder & Product Briefings: Daily standup bots that summarize weekly visitor acquisition and signup conversion rates without checking dashboards.
Incident & Traffic Correlation: Correlating sudden server load spikes with specific referral campaigns or viral articles stored in the graph.

100% Offline Testing

To ensure reliability in CI and prevent test flakes, the test suite (tests/test_plausible.py) features 18 offline unit tests covering:

Aggregate traffic parsing & formatting
Top page & referral markdown compilation
Rate limit 429 exponential backoff & token scrubbing
Deterministic ID stability across syncs
Document-mode invariant verification (DOCUMENT_SOURCE_ATTR)

All 18 tests pass in under 2 seconds:

uv run --project packages/connector/plausible --with pytest pytest packages/connector/plausible/tests -v
# 18 passed in 1.25s

Conclusion & Links

Bringing Plausible Analytics into Cognee gives AI agents situational awareness of the metrics that matter most to growing products.

GitHub PR / Community Repo: topoteretes/cognee-community
Cognee Core: topoteretes/cognee
Mergetober: WeMakeDevs Mergetober Hackathon

Built as part of Mergetober 2026. Happy building!