DEV Community: Shubham Vernekar

Zero-Hallucination Reverse Proxies for AI DevOps: Building a Caddyfile Connector for Cognee

Shubham Vernekar — Mon, 26 Oct 2026 07:24:19 +0000

Autonomous AI DevOps and site reliability engineering (SRE) agents—such as Claude Code, Devin, Cursor, and GitHub Copilot—are increasingly being used to diagnose routing issues, configure SSL certificates, and manage reverse proxies for microservices.

But there's a catch: an AI agent can generate a plausible configuration without knowing how your infrastructure is actually configured.

That gap can lead to problems such as:

Port confusion: Routing requests to localhost:8000 when the service actually listens on port 8080.
Incorrect path matching: Confusing Caddy's named matchers, such as @api, with directives such as handle_path, or overlooking when a path prefix needs to be stripped.
Header-handling mistakes: Misunderstanding how request headers such as X-Forwarded-For and X-Real-IP are configured or propagated.
TLS misconfiguration: Suggesting invalid directives or overlooking existing HTTPS and certificate settings.

Why does this happen? An LLM may rely on general examples instead of the application's actual routing rules, upstream addresses, and server configuration.

Caddy is a modern web server known for automatic HTTPS and its human-readable, declarative Caddyfile configuration format. A Caddyfile describes site addresses, handlers, matchers, reverse proxies, and other aspects of server behavior.

As part of Mergetober, I built the Caddy Web Server Data-Source Connector for Cognee, named cognee-community-connector-caddy.

The goal is to make Caddy configuration available through Cognee's knowledge and retrieval workflow, helping AI agents access relevant routing context before recommending infrastructure changes.

In this article, we'll explore why Caddyfile context matters, look at the connector's intended architecture, and walk through an example ingestion workflow.

1. Why Caddyfile Routing Context Matters

In modern cloud and edge infrastructure, Caddy often acts as an entry point for web traffic. A production Caddyfile may define several important pieces of infrastructure context:

Site addresses and ports: Hosts and listening addresses such as example.com, api.example.com, :80, and :443.
Path matchers and handlers: Routing rules such as @api path /api/* and handle_path /docs/*.
Reverse proxy upstreams: Backend addresses and proxy targets, such as reverse_proxy 127.0.0.1:8080.
Headers and URL rewrites: Request and response header behavior, along with path transformations.
TLS configuration: Automatic HTTPS behavior and custom certificate settings.

Imagine asking an AI DevOps agent to:

"Add a route for the analytics service."
"Troubleshoot why the docs endpoint returns a 404."
"Find out which backend handles requests to /api/*."
"Check whether the existing reverse proxy uses the correct port."

Before suggesting changes, the agent needs to understand the existing configuration.

Making the Caddyfile searchable gives the agent a way to retrieve relevant routing definitions rather than relying entirely on generic configuration patterns.

2. Introducing Cognee: Memory for Web Routing

Cognee is an open-source framework for building AI memory systems using structured knowledge and retrieval.

The Caddy connector aims to make routing configuration easier for developers and AI agents to discover.

Its intended use cases include:

Site and proxy discovery: Finding site blocks, matchers, and reverse proxy definitions.
Routing relationships: Representing relationships between hosts, path matchers, and upstream backends where supported by the connector and ingestion pipeline.
Semantic retrieval: Asking natural-language questions such as, "Which backend handles requests to /auth/?"
Context-informed configuration: Providing relevant configuration details before an agent proposes routing or reverse proxy changes.

For example, an agent could ask:

What backend port handles /v1/* requests on api.company.com?

If the corresponding configuration has been ingested and the retrieval pipeline returns the relevant information, the agent can use that context to inform its answer.

The important distinction is that retrieval provides evidence for an agent to reason from. It doesn't automatically guarantee that every answer is correct or that a proposed configuration is safe to deploy.

3. Architectural Overview: The Caddy Connector

The intended workflow connects a Caddyfile to Cognee's ingestion and retrieval pipeline, making configuration information available to an AI DevOps agent.

┌───────────────────────────────┐
│       Caddyfile               │
│  Sites, Matchers, Proxies     │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│  Caddy Web Server Connector   │
│  cognee-community-connector-  │
│  caddy                        │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│  Parse Relevant Configuration │
│  Sites, Proxies, Matchers,    │
│  and Directives               │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│      Cognee Ingestion         │
│  Knowledge Processing         │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│  Structured Knowledge and    │
│  Retrieval                    │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│       AI DevOps Agent         │
│  Context-Informed Suggestions │
└───────────────────────────────┘

The diagram illustrates the intended architecture, not a claim that every stage has been independently validated in production.

3.1. Stable Entity Identifiers

A connector can assign deterministic identifiers to site blocks and other configuration entities.

For example:

caddy:site:{primary_address_slug}

Possible identifiers include:

caddy:site:example_com
caddy:site:api_company_com

Consistent identifiers can help identify the same logical entity across repeated imports. Whether this prevents duplicate knowledge nodes depends on how the connector and Cognee ingestion pipeline handle entity identity and deduplication.

3.2. Keeping Routing Knowledge Synchronized

Web server configurations change as services are deployed, decommissioned, and reconfigured. A useful connector should account for those changes so that retrieved knowledge doesn't continue to describe routes that no longer exist.

A replacement strategy, such as write_disposition="replace", may be relevant to this workflow. However, replacing imported data does not by itself prove that all obsolete knowledge entities and relationships will be deleted. That behavior depends on the connector's implementation and Cognee's cleanup semantics.

For reliable synchronization, test the complete lifecycle:

Ingest a Caddyfile containing a site and upstream.
Remove or change that site or upstream.
Re-ingest the modified configuration.
Search for the old route and verify that obsolete information is no longer returned.

This is especially important when AI agents use retrieved configuration to recommend changes to production infrastructure.

3.3. Agent-Friendly Configuration Representations

A Caddy site can be summarized in a compact, readable representation:

Site: api.company.com
Matchers:
  - name: "@api"
    path: "/v1/*"
Handlers:
  - type: reverse_proxy
    upstream: "127.0.0.1:8080"
Headers:
  - Strict-Transport-Security: "max-age=31536000"
TLS: Automatic HTTPS

This is an illustrative summary, not native Caddyfile syntax. The exact representation produced by the connector depends on its parser and data model.

It highlights the information an agent may need when reasoning about routing:

Site address
Path matcher
Reverse proxy target
Relevant headers
TLS behavior

The more accurately these details are represented and retrieved, the better the agent can ground its recommendations in the application's existing configuration.

4. Step-by-Step: Ingesting a Caddyfile into Cognee

Let's look at an example workflow for loading routing configuration into Cognee and querying it.

Note: The commands and code below illustrate the intended integration. Confirm the connector's published package name, import path, function signature, and supported Cognee API parameters against the implementation in PR #496 before running the example.

Step 1: Install the Dependencies

Install Cognee and the connector:

pip install cognee cognee-community-connector-caddy

If the connector has not been published to the package index, install it using the installation instructions provided by the pull request instead.

Step 2: Prepare Your Directory

Create a project directory containing your Caddyfile and Python script:

routing-project/
├── Caddyfile
└── index_routes.py

For this example, the Caddyfile defines separate routes for the API and analytics services.

api.company.com {
    @api path /v1/*
    reverse_proxy @api 127.0.0.1:8080

    @analytics path /analytics/*
    reverse_proxy @analytics 127.0.0.1:9090
}

Here:

Requests matching /v1/* are sent to 127.0.0.1:8080.
Requests matching /analytics/* are sent to 127.0.0.1:9090.

The path matcher selects matching requests. Unlike handle_path, it does not itself strip the matched path prefix before proxying.

Step 3: Ingest and Search the Routing Configuration

Create index_routes.py:

import asyncio

import cognee
from cognee_community_connector_caddy import caddy_source


async def main():
    # 1. Load the Caddyfile through the connector.
    print("Loading Caddyfile into Cognee...")

    source = caddy_source(
        caddyfile_path="./Caddyfile"
    )

    # 2. Ingest the configuration.
    await cognee.remember(
        source,
        dataset_name="web_routing",
        max_rows_per_table=0,
    )

    # 3. Process the ingested information.
    print("Building routing knowledge...")

    await cognee.cognify(
        dataset_name="web_routing",
    )

    # 4. Search for routing information.
    print("Searching routing configuration...")

    results = await cognee.search(
        "What backend port handles /v1/* requests on api.company.com?",
        dataset_name="web_routing",
    )

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


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

The example demonstrates four conceptual stages:

Load: Read the Caddyfile using the connector.
Ingest: Pass the source to Cognee.
Process: Build the knowledge representation.
Retrieve: Ask a natural-language question about a route.

The caddy_source import, caddyfile_path argument, and max_rows_per_table parameter are example API usage and should be checked against the actual connector and Cognee versions. You may also need to configure Cognee's storage and language-model settings before ingestion.

Step 4: Inspect the Results

For the sample configuration, the expected answer to the query is that requests matching /v1/* on api.company.com are proxied to 127.0.0.1:8080.

Treat this as the expected result of the example, not a verified execution result.

Before relying on the connector in a real environment, test several cases:

A route that exists.
A route that does not exist.
A changed upstream port.
A removed matcher or site.
Multiple site blocks with different upstreams.

These tests help establish whether the connector captures the relevant configuration correctly and whether retrieval reflects subsequent changes.

5. From Retrieved Context to Better-Informed Proxy Changes

Suppose an AI agent retrieves the existing routing configuration and discovers that the API and analytics services use different backend ports.

It can use that context when proposing a configuration such as:

api.company.com {
    @api path /v1/*
    reverse_proxy @api 127.0.0.1:8080

    @analytics path /analytics/*
    reverse_proxy @analytics 127.0.0.1:9090
}

Instead of guessing the upstream targets from generic examples, the agent can reference the configuration available through the retrieval workflow.

That distinction matters in DevOps: a plausible configuration isn't necessarily the right configuration for a particular application.

The connector is intended to support a more grounded workflow:

Retrieve the existing configuration.
Identify the relevant site, matcher, and upstream.
Propose a change based on the retrieved information.
Validate the proposed configuration.
Test the behavior before deploying it.

Retrieval alone doesn't eliminate hallucinations or guarantee safe changes. Production use should still include Caddy configuration validation, appropriate tests, and human review for consequential changes.

6. Open-Source Pull Request and References

This connector was developed as part of the Cognee Mergetober community contribution series.

Connector pull request: Cognee Community PR #496
Related issue: Cognee issue #6318
Cognee repository: github.com/topoteretes/cognee
Caddy documentation: caddyserver.com/docs

Check the pull request for the connector's current implementation, supported configuration features, and installation instructions.

7. The Grand Finale: Five Connectors for AI Engineering Context

This concludes my five-connector Mergetober series for Cognee!

Throughout this series, I explored ways to make different kinds of software engineering context accessible to AI agents.

Day	Connector	Input Source	Problem Addressed	Pull Request
1	Hoppscotch	`collection.json`	API endpoints, query parameters, authentication, and payload schemas	#490
2	Prisma	`schema.prisma`	Database models, relations, field constraints, and enums	#491
3	Docker Compose	`docker-compose.yml`	Container services, network links, and port bindings	#492
4	GraphQL SDL	`schema.graphql`	Typed operations, inputs, mutations, and unions	#495
5	Caddy	`Caddyfile`	Web server routing, reverse proxies, path matchers, and TLS configuration	#496

The common idea behind these contributions is simple: AI agents need access to relevant engineering context, not just general programming knowledge.

An agent that can retrieve information about an application's APIs, database models, container topology, GraphQL schema, and web server configuration has more project-specific evidence to work with when answering questions or proposing changes.

That doesn't remove the need for validation, but it creates a foundation for more context-aware engineering workflows.

A huge thank you to the Cognee team and community for hosting Mergetober and providing an opportunity to contribute to the open-source ecosystem!

Which of these five connectors would be most useful in your engineering stack? Let me know in the comments!

GraphQL Schema Memory for AI Coding Agents: Building a GraphQL SDL Connector for Cognee

Shubham Vernekar — Mon, 26 Oct 2026 07:13:31 +0000

Imagine asking an AI coding agent to fetch a user's profile, and it generates this query:

query {
  user(id: "123") {
    id
    profilePicture
  }
}

It looks reasonable. There is just one problem: your API does not have a profilePicture field. It uses avatarUrl instead.

The query fails validation, and you have to correct the agent's assumption before continuing.

This illustrates a frustrating challenge with AI-assisted development: GraphQL schema hallucination.

Agents invent nonexistent field names or subfields.
They confuse input types, such as input CreateUserInput, with output object types, such as type User.
They miss required non-nullable arguments, such as String!, or use incorrect argument names like filter instead of where.
They request subfields on scalar fields or assume union members that do not exist.

As part of Mergetober, I built the GraphQL Schema Data-Source Connector for Cognee, named cognee-community-connector-graphql.

The goal is to make GraphQL Schema Definition Language (SDL) files accessible through Cognee's knowledge and retrieval workflow, giving AI agents relevant schema context before they generate queries or mutations.

In this article, I'll explain why GraphQL SDL memory matters, explore the connector's architecture, and walk through an example ingestion workflow.

1. Why GraphQL Schema Context Matters

GraphQL is strongly typed by design. Its Schema Definition Language (SDL) describes the contract between a client and a server.

A typical schema.graphql file defines:

Object types and scalars: Entities such as User, Product, and Order, with fields and type modifiers such as String! and [Item!]!.
Root operations: Query, Mutation, and Subscription types, including operation names, arguments, and return types.
Input types: Dedicated input objects such as CreateUserInput and PaginationInput.
Enums and unions: Allowed values and alternative result types.
Interfaces and directives: Shared type contracts and additional schema behavior.
Descriptions: Documentation explaining the purpose of types, fields, and arguments.

Consider this schema fragment:

type User {
  id: ID!
  name: String!
  avatarUrl: String
}

type Query {
  user(id: ID!): User
}

An agent with access to this definition can determine that:

The user query field accepts an argument named id of type ID!.
The return type is User, which may be null.
The User type exposes avatarUrl, not profilePicture.
The id and name fields are non-nullable.

Without this context, an LLM may generate a query based on patterns it has encountered in other applications rather than the actual contract of the current API.

Pasting an entire large schema into every prompt can consume tokens and make relevant information harder to locate. A more scalable approach is to ingest schema definitions, organize them as searchable knowledge, and retrieve relevant context on demand.

2. Introducing Cognee: Knowledge Graphs and Retrieval

Cognee is an open-source framework for building AI memory systems using structured knowledge and retrieval.

The GraphQL connector aims to make schema information easier for developers and AI agents to discover and use.

The intended workflow focuses on four capabilities:

Schema discovery: Make types, operations, and input definitions searchable.
Relationship preservation: Represent useful connections between fields and the types they reference.
Semantic retrieval: Allow developers to ask questions in natural language, such as, "Which mutation updates a user's subscription, and what arguments are required?"
Context-informed generation: Supply relevant schema definitions to a coding agent before it writes a query or mutation.

For example, a developer could ask:

Which mutation updates an organization's subscription, what arguments does it require, and what fields does it return?

Retrieved schema information can help the agent generate code that better matches the API contract instead of relying exclusively on learned conventions.

This approach can reduce schema-related mistakes, although the generated operation should still be validated against the current schema.

3. Architectural Overview: The GraphQL Connector

The high-level workflow can be represented as follows:

schema.graphql / schema.gql SDL File
                |
                v
       GraphQL Schema Connector
  (cognee-community-connector-graphql)
                |
                v
 Parse schema entities and definitions
 Types, fields, inputs, enums, arguments
                |
                v
         Cognee Ingestion
                |
                v
    Structured Knowledge + Retrieval
                |
                v
         AI Coding Agent
                |
                v
    Schema-Informed GraphQL Code

3.1. Stable Entity Identifiers

A connector can use deterministic identifiers to represent different GraphQL entities:

graphql:{kind}:{name}

Examples:

graphql:type:user
graphql:input:createuserinput
graphql:enum:role
graphql:mutation:updatesubscription

Consistent identifiers can help identify the same entity across repeated imports. Whether they prevent duplicate records depends on the connector's identity and deduplication logic.

3.2. Keeping Schema Knowledge Synchronized

API schemas evolve as features are added, changed, and removed.

A useful ingestion workflow should account for these changes so retrieval does not continue returning obsolete definitions.

A snapshot-based replacement strategy, such as write_disposition="replace", may be used to replace previously ingested data. However, its exact effect depends on the ingestion API and how existing entities and relationships are managed.

Before relying on replacement behavior, verify that re-ingestion also removes stale definitions and relationships associated with deleted schema elements.

3.3. Agent-Friendly Schema Representations

A mutation can be represented in a compact, readable format:

Kind: mutation
Name: updateSubscription
Description: Updates the billing tier for an active organization.
Arguments:
  - orgId: ID!
  - plan: SubscriptionPlan!
Return Type: SubscriptionPayload!
Payload Fields:
  - success: Boolean!
  - subscription: Subscription
  - errors: [String!]

This is an illustrative representation, not GraphQL SDL. It highlights information useful for code generation:

Operation name
Argument names and types
Return type
Relevant nested fields
Descriptions and constraints

The objective is to make the API contract easier to retrieve and interpret when an agent needs to generate a specific operation.

4. Step-by-Step: Ingesting `schema.graphql` into Cognee

The following example illustrates the intended ingestion and retrieval workflow.

Before running it: Verify the connector's current package instructions, exported function names, and function signatures against the actual implementation.

Step 1: Install Dependencies

pip install cognee cognee-community-connector-graphql

Step 2: Prepare Your Schema

Place your GraphQL schema and Python script in the same directory:

graphql-project/
├── schema.graphql
└── index_schema.py

Your schema.graphql file should contain the SDL definitions for your API.

Step 3: Ingest and Search GraphQL Memory

Create index_schema.py:

import asyncio
import cognee

from cognee_community_connector_graphql import graphql_source


async def main():
    # 1. Load the GraphQL schema file
    print("Loading schema.graphql into Cognee...")

    source = graphql_source(
        schema_path="./schema.graphql"
    )

    # 2. Ingest the schema into Cognee
    await cognee.remember(
        source,
        dataset_name="graphql_api",
        max_rows_per_table=0,
    )

    # 3. Process the ingested information
    print("Building GraphQL knowledge...")

    await cognee.cognify(
        dataset_name="graphql_api",
    )

    # 4. Search for a relevant operation
    print("Searching the GraphQL schema...")

    results = await cognee.search(
        "Which mutation updates a user's subscription, "
        "and what arguments are required?",
        dataset_name="graphql_api",
    )

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


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

This example illustrates four stages:

Load the GraphQL schema through the connector.
Ingest the schema into Cognee.
Process the ingested information.
Search for relevant operations using a natural-language question.

The meaning of max_rows_per_table=0, as well as the connector import path and ingestion API signatures, should be confirmed against the actual package version. Do not assume this setting guarantees a complete schema snapshot without checking the implementation.

5. Result: More Schema-Informed GraphQL Queries

Suppose the schema defines an updateSubscription mutation that accepts orgId and plan arguments and returns a SubscriptionPayload.

With relevant schema context available, an agent could generate an operation like this:

mutation UpdateBilling(
  $orgId: ID!,
  $plan: SubscriptionPlan!
) {
  updateSubscription(
    orgId: $orgId,
    plan: $plan
  ) {
    success
    subscription {
      id
      plan
      renewalDate
    }
    errors
  }
}

This is an illustrative example, not a verified operation from a specific API. It is valid only if the actual schema defines the mutation, argument types, return fields, and nested fields shown here.

The key difference is the workflow: the agent has relevant schema information to consult before generating code instead of relying exclusively on learned patterns.

For a more reliable development workflow:

Retrieve the relevant schema definitions.
Generate the query or mutation using that context.
Validate the operation against the current GraphQL schema.
Run tests and handle any remaining errors.

Schema retrieval can reduce unsupported assumptions, but it does not guarantee zero hallucinations or eliminate all validation and runtime errors.

6. Open-Source Pull Request and References

Connector pull request: Cognee Community PR #495
Related issue: Cognee issue #6308
Cognee repository: github.com/topoteretes/cognee
GraphQL documentation: graphql.org

These links provide starting points for exploring the contribution, its motivation, and the GraphQL concepts discussed in this article.

I'm curious about your experience: What's the most common mistake your AI coding agent makes when working with GraphQL—wrong field names, incorrect arguments, or confusing nested return types?

Share your experience in the comments!

Stop AI Agents from Hallucinating Infrastructure: Building a Docker Compose Connector for Cognee

Shubham Vernekar — Mon, 26 Oct 2026 06:56:22 +0000

Autonomous AI DevOps and coding agents such as Claude Code, Devin, Cursor, and GitHub Copilot are increasingly trusted to troubleshoot deployment failures, configure CI/CD pipelines, and manage local multi-container development environments.

Yet, when developers ask an agent to "write an end-to-end test script" or "debug the backend network connection", they can encounter a common problem: container topology hallucination.

For example:

Hallucinating service hostnames: Calling localhost:5432 instead of the internal network alias db:5432.
Port confusion: Guessing incorrect host-to-container port mappings, such as assuming Redis is exposed on 6380 when the Compose file maps 6379:6379.
Missing volume mounts: Assuming persistent file paths that do not match the configured mounts.
Dependency blind spots: Missing depends_on relationships or health-check conditions such as service_healthy.

Why Does This Happen?

Large language models (LLMs) generate responses based on learned patterns and the context available to them. Without reliable access to an application's actual infrastructure configuration, they may generate plausible-looking but incorrect commands and deployment scripts.

In containerized development, compose.yaml or docker-compose.yml defines services, networks, volumes, port mappings, and environment configuration.

What if AI agents could retrieve this infrastructure information instead of guessing?

As part of Mergetober, I worked on a Docker Compose data-source connector for Cognee, intended to make container configuration available through a structured knowledge graph and retrieval pipeline.

In this article, I'll explain why infrastructure context matters, outline the connector architecture, and demonstrate the intended workflow for ingesting Docker Compose configuration into Cognee.

1. Why Docker Compose Topology Matters

In a multi-container application, services communicate through configured networks, expose ports, mount volumes, and depend on other services.

A typical Docker Compose file defines several important components:

Services and images: Container images such as postgres:16-alpine and redis:7, along with build contexts and Dockerfiles.
Port bindings: Host-to-container mappings such as "8080:80" and "5432:5432".
Service dependencies: depends_on relationships and conditions such as service_healthy.
Environment variables: Connection strings, credentials, and service URLs.
Volumes and networks: Named volumes, bind mounts, and custom networks such as app-network.

When an AI DevOps agent attempts to run migrations, seed a database, write integration tests, or debug network connectivity without this context, it may make incorrect assumptions.

Pasting an entire 500-line Compose file into every prompt is one possible workaround, but it can consume context-window space and make relevant configuration harder to find.

A better approach is to ingest, structure, index, and retrieve infrastructure topology on demand.

2. Introducing Cognee: Infrastructure Memory for AI Agents

Cognee is an open-source framework for building AI memory systems using structured knowledge and retrieval.

The idea behind combining Docker Compose with Cognee is to make infrastructure configuration easier for AI agents to retrieve when needed:

Service entities: Represent services and their configuration as searchable information.
Dependency relationships: Preserve relationships between services where supported by the ingestion pipeline.
Semantic retrieval: Let developers ask natural-language questions about ports, volumes, networks, and dependencies.
Grounded DevOps workflows: Provide configuration context before an agent generates commands, tests, or deployment scripts.

For example, a developer could ask:

What services depend on PostgreSQL, which ports are published, and what health-check conditions are configured?

A retrieval system can provide relevant Compose configuration as context for the agent's response. The quality of the result depends on how completely the configuration is parsed, represented, and retrieved.

3. Architectural Overview: The Docker Compose Connector

The intended data flow looks like this:

docker-compose.yml / compose.yaml
              |
              v
   Docker Compose Connector
              |
              v
Parse Services, Ports, Volumes, Networks and Dependencies
              |
              v
       Cognee Ingestion
              |
              v
Knowledge Graph + Vector Retrieval
              |
              v
       AI DevOps Agent
              |
              v
Infrastructure-Grounded Commands

3.1. Stable Service Identifiers

A connector can assign stable identifiers to individual services:

docker_compose:service:{service_name}

Stable identifiers help distinguish services across repeated imports. Whether they prevent duplicate nodes depends on how the connector and the ingestion pipeline handle entity identity.

3.2. Full-Snapshot Synchronization

Infrastructure configurations evolve as services are added, removed, or modified.

A snapshot-based synchronization strategy can help keep indexed infrastructure information aligned with the current Compose file. However, a setting such as write_disposition="replace" only provides the expected replacement behavior if the connector and the underlying ingestion pipeline explicitly support it.

Removed services must be handled by the synchronization process; simply ingesting an updated file does not necessarily delete stale entities from existing memory.

3.3. Rich, Agent-Friendly Service Representations

A connector can represent each service in a structured, human-readable format:

Service: api
Image: my-org/api:v1.2.0
Ports:
  - "8000:8000"
Environment:
  - DATABASE_URL: postgres://<user>:<password>@db:5432/app
Depends On:
  - db:
      condition: service_healthy
  - cache
Volumes:
  - ./logs:/var/log/api

This is an illustrative representation of a service, not a complete Docker Compose file. In a real implementation, sensitive environment values should be redacted or excluded before configuration is stored or exposed to an AI agent.

4. Step-by-Step: Ingesting Docker Compose into Cognee

Step 1: Install Dependencies

The intended installation command is:

pip install cognee cognee-community-connector-docker-compose

Confirm that the connector package is published and that its installation instructions match the implementation you are using.

Step 2: Prepare Your Directory

Locate your Docker Compose configuration and create a Python script for ingestion:

infrastructure-project/
├── docker-compose.yml
└── ingest_topology.py

Step 3: Ingest and Query Infrastructure Memory

The following example illustrates the intended workflow. Verify the connector's actual import path, function signature, and Cognee API against the repository before running it.

import asyncio
import cognee

from cognee_community_connector_docker_compose import (
    docker_compose_source,
)


async def main():
    # Step 1: Load the Docker Compose configuration
    print("Loading Docker Compose configuration...")

    source = docker_compose_source(
        compose_path="./docker-compose.yml"
    )

    # Step 2: Ingest the configuration into Cognee
    await cognee.remember(
        source,
        dataset_name="infrastructure_topology",
    )

    # Step 3: Build the knowledge representation
    print("Processing infrastructure knowledge...")

    await cognee.cognify(
        dataset_name="infrastructure_topology",
    )

    # Step 4: Search infrastructure memory
    print("Searching container architecture...")

    results = await cognee.search(
        "What services depend on PostgreSQL, and which ports are published?",
        dataset_name="infrastructure_topology",
    )

    for result in results:
        print(result)


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

This example demonstrates the intended sequence:

Load the Compose configuration through the connector.
Submit the source to Cognee.
Process the ingested information into a searchable representation.
Query the resulting infrastructure context.

The exact behavior depends on the connector implementation and the Cognee version being used.

5. Result: More Reliable, Topology-Grounded DevOps Workflows

With infrastructure-aware retrieval, an agent can consult the relevant configuration before recommending commands.

For example, a Compose file might define a service named db and an application service named api. Depending on the configuration and the commands supported by the application, the resulting workflow might include:

docker compose exec db pg_isready -U postgres
docker compose run --rm api python manage.py migrate

These commands are examples, not universal solutions. The service names, database user, executable, and migration command must match the actual project.

The objective is to help AI agents make better-informed decisions about service names, ports, dependencies, and execution contexts.

Retrieval can reduce configuration-related guesswork, but it does not guarantee hallucination-free output. Agents should still validate commands against the current configuration and test them in an appropriate environment before using them in production.

6. Open-Source Pull Request and References

Pull request: topoteretes/cognee-community#492
Related issue: topoteretes/cognee#6307
Cognee repository: github.com/topoteretes/cognee
Docker Compose documentation: docs.docker.com/compose

Stop AI Agents from Hallucinating Database Schemas: Prisma ORM Connector for Cognee

Shubham Vernekar — Mon, 26 Oct 2026 06:48:38 +0000

Autonomous AI coding agents such as Claude Code, Cursor, Devin, and GitHub Copilot are increasingly trusted to write database migrations, backend services, and API controllers. But when developers ask an agent to "add a feature that filters orders by organization role", they can encounter a common problem: database schema hallucination.

For example:

The agent invents field names, calling user.organizationId when the actual field is user.org_id.
It hallucinates relationships that do not exist between tables.
It invents enum variants or overlooks foreign key constraints.
It produces code that looks syntactically correct but fails at runtime.

Why does this happen?

Large language models (LLMs) generate responses based on learned patterns and the context available to them. Without reliable access to the application's actual database schema, they may generate plausible-looking but incorrect code.

In modern full-stack engineering, the schema.prisma file defines Prisma models, relations, field types, constraints, enums, and indexes.

What if AI coding agents could retrieve this schema information instead of guessing?

As part of Mergetober, I worked on a Prisma Schema Data-Source Connector for Cognee, intended to make Prisma schema information available through a structured knowledge graph and memory pipeline.

In this article, I'll explain why Prisma schema context matters, how the connector is designed, and how developers can use a schema-ingestion workflow to give AI agents more reliable database context.

1. Why Prisma Schemas?

Prisma is an ORM used across the TypeScript, Node.js, and web development ecosystem.

A typical schema.prisma file defines several kinds of information that are essential for generating correct database code:

Models and scalar fields: Types such as String, Int, Boolean, and DateTime, along with optional fields (?) and list fields ([]).
Primary keys and attributes: @id, @default(uuid()), @unique, and @updatedAt.
Relational mappings: Relations and foreign key declarations such as @relation(fields: [authorId], references: [id]).
Enums and custom types: Allowed values for roles, statuses, and permissions.

For example:

enum Role {
  USER
  ADMIN
  OWNER
}

Documentation comments: Triple-slash comments (///) that describe models and fields.

If an AI agent does not have access to the actual schema, it might invent an enum value, use an incorrect field name, or misunderstand a relationship.

Pasting an entire 2,000-line schema into every prompt is one possible workaround, but it can consume context-window space and make relevant details harder to retrieve.

A better approach is to structure, index, and retrieve schema information when it is needed.

2. Introducing Cognee: Structured Knowledge for AI Agents

Cognee is an open-source framework for building AI memory systems using structured knowledge and retrieval.

The idea behind integrating Prisma with Cognee is to make database schema information easier to retrieve when an AI coding agent needs it.

A schema-aware workflow can support:

Schema entities: Represent models and enums as distinct pieces of information.
Relationship context: Preserve relationships between models where supported by the ingestion pipeline.
Semantic retrieval: Search for relevant models, fields, and relationships using natural-language questions.
Reduced guesswork: Provide schema context before an agent generates ORM calls, queries, or backend services.

For example, a developer could ask:

Which model links Users to Organizations, and which field is used as the foreign key?

The system can retrieve relevant schema information and provide it to the agent as supporting context.

The goal is to ground code generation in the application's actual schema rather than relying on the model's assumptions alone.

3. Architectural Overview: The Prisma Connector

The connector is located in cognee-community/packages/connector/prisma.

The conceptual architecture looks like this:

schema.prisma File
        |
        v
Prisma Schema Connector (cognee-community)
        |
        v
Extract Models, Relations, Enums and Documentation
        |
        v
Cognee Ingestion Pipeline (dlt resource)
        |
        v
Knowledge Graph + Vector Retrieval
        |
        v
AI Coding Agent (Cursor, Devin, Claude Code)
        |
        v
Schema-Grounded ORM Code

3.1. Deterministic Primary Keys

A connector can use stable identifiers to distinguish models and enums:

prisma:model:{model_name}
prisma:enum:{enum_name}

Stable identifiers help track schema entities across repeated imports. However, identifier stability alone does not guarantee idempotent synchronization; the ingestion and storage layers must also handle updates, renamed entities, and duplicate records correctly.

3.2. Full-Snapshot Synchronization

Database schemas evolve rapidly. Developers add models, rename fields, change relationships, and remove obsolete definitions.

A snapshot-based synchronization strategy, such as write_disposition="replace", may help keep indexed schema information aligned with the current source file.

However, verify the actual cleanup behavior before assuming that deleted models are automatically removed from every graph and vector index.

3.3. Rich, Agent-Friendly Schema Representations

A connector can represent schema information in a structured, human-readable format:

Model: User
Description: Active user account
Fields:
  - id: String @id @default(uuid())
  - email: String @unique
  - role: Role (default: USER)
  - orgId: String
Relations:
  - organization: Organization (optional)
  - posts: Post[] (one-to-many)

This is an illustrative representation. The actual fields, relationships, and formatting depend on the source schema and connector implementation.

4. Step-by-Step: Ingesting `schema.prisma` into Cognee

The following workflow illustrates the intended integration. Verify the package name, import path, function arguments, and supported APIs against the actual connector implementation before running the example.

Step 1: Install Dependencies

If the connector is published under the package name shown below, install it using:

pip install cognee cognee-community-connector-prisma

If the connector is available only through a GitHub branch or pull request, follow the repository's installation instructions instead.

Step 2: Prepare Your Schema

Locate your Prisma schema file:

my-project/
├── prisma/
│   └── schema.prisma
└── index_schema.py

Your schema may be located elsewhere depending on your project configuration.

Step 3: Ingest and Search Schema Memory

The following Python script assumes that the connector exposes prisma_schema_source() and that the installed Cognee version supports the APIs shown.

import asyncio
import cognee

from cognee_community_connector_prisma import (
    prisma_schema_source,
)


async def main():
    # Step 1: Load schema.prisma.
    print("Loading schema.prisma into Cognee...")

    source = prisma_schema_source(
        schema_path="./prisma/schema.prisma"
    )

    # Step 2: Ingest the schema.
    await cognee.remember(
        source,
        dataset_name="database_schema",
    )

    # Step 3: Build the knowledge representation.
    print("Processing schema knowledge...")

    await cognee.cognify(
        dataset_name="database_schema",
    )

    # Step 4: Query schema memory.
    print("Searching database schema...")

    results = await cognee.search(
        "Which model links Users to Organizations, "
        "and which field is used as the foreign key?",
        dataset_name="database_schema",
    )

    for result in results:
        print(result)


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

Implementation notes:

Verify that the connector exposes prisma_schema_source() with a schema_path argument.
Confirm that the installed Cognee version supports the shown ingestion, processing, and search interfaces.
Configure any required LLM, embedding, and storage providers according to Cognee's documentation.
Test retrieval against known models, fields, and relationships from your schema.
Treat retrieved schema information as supporting context, not a guarantee of correct generated code.

This is an illustrative integration pattern, not a verified, drop-in script until the connector's actual APIs have been checked.

5. Result: More Reliable, Schema-Grounded Database Queries

With schema-aware retrieval, an AI coding agent can first retrieve relevant model definitions and use them to construct a query.

For example:

const usersInOrg = await prisma.user.findMany({
  where: {
    orgId: organizationId,
    role: "ADMIN",
  },
  include: {
    organization: true,
  },
});

Important: This query is valid only if the actual Prisma schema defines orgId, the ADMIN enum value, and the organization relation as shown. If the schema uses different field names or relationships, the query must be adapted accordingly.

The goal is to help AI agents use the real schema instead of inventing fields or relationships.

To evaluate whether this approach works, compare generated code with and without retrieved schema context.

Potential evaluation metrics include:

Field-name accuracy.
Model and relationship accuracy.
Enum-value validity.
Type correctness.
Successful Prisma type checking.
Query execution against a test database.
Frequency of unsupported fields and relations.

Testing representative database tasks can help measure whether schema retrieval improves the reliability of AI-generated code.

6. Open-Source Pull Request and References

This work is part of my exploration of open-source tools that can make AI-assisted software development more reliable.

Pull request: topoteretes/cognee-community#491
Related issue: topoteretes/cognee#6306
Cognee repository: https://github.com/topoteretes/cognee
Prisma ORM: https://www.prisma.io/

Check the repository and pull request for the connector's current implementation, installation instructions, and contribution status.

Eliminating AI Hallucinations in API Integration: Building a Hoppscotch Connector for Cognee

Shubham Vernekar — Mon, 26 Oct 2026 06:40:42 +0000

Autonomous AI coding agents such as Claude Code, Cursor, GitHub Copilot, and other AI-powered development tools are rapidly changing how we build software. Yet, developers who ask an agent to "write a client to call our internal billing and user service" often encounter the same problem: API hallucination.

An agent might invent nonexistent query parameters, omit required headers like X-Workspace-ID, choose the wrong authentication method, or generate requests for outdated endpoints.

Why does this happen?

Large language models (LLMs) generate responses based on learned patterns and the context provided to them. Without reliable, up-to-date API specifications, they may produce plausible-looking but incorrect integrations.

What if AI coding agents could retrieve structured API knowledge instead of guessing?

As part of Mergetober, I worked on a dedicated Hoppscotch data-source connector for Cognee to address this problem.

In this article, I'll explain why API schema memory matters, how the connector fits into the architecture, and how API collections can be ingested into Cognee to provide reliable context for AI-generated integration code.

1. Why Hoppscotch?

Hoppscotch is an open-source API development platform that helps developers create, organize, and test API requests.

Hoppscotch collections contain critical information about how an API should be used:

Endpoints: HTTP methods, paths, path parameters, and query parameters.
Headers: Required and optional HTTP headers.
Authentication: Bearer tokens, Basic authentication, OAuth 2.0, and API keys.
Request bodies: JSON payloads, nested objects, and sample data.
Environment variables: Dynamic values such as <<baseUrl>> and <<apiToken>>.
Organization: Collections, folders, and request names.

When API collections remain isolated in exported JSON files or desktop tools, an AI agent cannot reference them. Pasting an entire 10,000-line JSON export into a prompt floods the context window, burns tokens, and degrades attention.

A better approach is to ingest, structure, index, and retrieve API knowledge on demand.

2. Introducing Cognee: Knowledge Graphs and AI Memory

Cognee is an open-source framework for building AI memory systems using structured knowledge and retrieval.

Instead of relying exclusively on raw text chunks in a vector database, Cognee organizes API information into a hybrid knowledge graph + vector index:

Structured endpoint knowledge: Represents API requests with methods, URLs, headers, parameters, and payloads.
Relationship preservation: Maintains parent-child relationships between collections, folders, and individual requests.
Semantic retrieval: Allows AI agents to search for relevant API information using natural language questions.
Zero guesswork: Provides ground-truth API context before an agent generates integration code.

3. Architectural Overview: The Hoppscotch Connector

The connector bridges exported API collections and Cognee's memory pipeline:

Hoppscotch API Collection (.json)
           │
           ▼
Hoppscotch Connector (cognee-community)
           │
           ▼
Parse, Normalize & Resolve Variables
           │
           ▼
Cognee Ingestion Pipeline (dlt resource)
           │
           ▼
Knowledge Graph + Vector Store
           │
           ▼
AI Coding Agent (Claude, Cursor, Devin)
           │
           ▼
Schema-Grounded, Hallucination-Free Code

Key Design Considerations

3.1. Stable Endpoint Identifiers

The connector assigns a deterministic composite identifier to each API request:

hoppscotch:{collection_slug}:{folder_path}:{request_name}

Stable IDs ensure idempotent syncs. When you re-export your collection, existing graph nodes are cleanly updated rather than duplicated.

3.2. Synchronization and Deleted Endpoints

APIs evolve continuously. The connector sets write_disposition="replace" so that when an obsolete endpoint is deleted upstream, Cognee's automatic orphan cleanup purges it from both the vector index and the knowledge graph.

3.3. Environment Variables and Secret Handling

Hoppscotch environments use <<variable>> syntax. The connector resolves non-sensitive base URLs (e.g., <<baseUrl>>/v1/orders ➔ https://api.example.com/v1/orders) while ensuring real production credentials and access tokens are not uploaded to memory.

3.4. Structured, Agent-Friendly API Context

Each endpoint is formatted into a clean, markdown representation:

### POST /v1/orders
Collection: E-Commerce / Orders
Headers:
  - Content-Type: application/json
  - Idempotency-Key: <uuid>
Request Body:
{
  "customer_id": "string",
  "items": [
    { "sku": "string", "qty": 1 }
  ],
  "currency": "USD"
}

4. Step-by-Step: Ingesting a Hoppscotch Collection

Step 1: Install Dependencies

pip install cognee cognee-community-connector-hoppscotch

Step 2: Export Your Hoppscotch Workspace

In Hoppscotch, open Collections ➔ click Export ➔ save as collection.json.
(Optional) Export your active environment as environment.json.

api-memory-project/
├── collection.json
├── environment.json
└── main.py

Step 3: Ingest and Query the Collection

import asyncio
import cognee
from cognee_community_connector_hoppscotch import hoppscotch_source

async def main():
    # 1. Load the exported API collection
    print("Loading Hoppscotch collection...")
    source = hoppscotch_source(
        collection_path="./collection.json",
        environment_path="./environment.json",  # optional
    )

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

    # 3. Cognify: Build the semantic knowledge graph
    print("Processing API knowledge graph...")
    await cognee.cognify(
        dataset_name="api_documentation",
    )

    # 4. Search API memory with natural language
    print("Searching API memory...")
    results = await cognee.search(
        "Which endpoint creates a customer order, and what headers and request fields are required?",
        dataset_name="api_documentation",
    )

    for result in results:
        print(result)

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

5. What Does Better API Grounding Look Like?

With a searchable API memory system, the agent retrieves the exact endpoint contract before writing code:

{
  "customer_id": "string",
  "items": [{ "sku": "string", "qty": 1 }],
  "currency": "USD"
}

Instead of guessing query params or inventing auth headers, the coding agent writes correct, production-ready integration clients on the very first try.

6. Open-Source Pull Request & Links

🔗 Pull Request: topoteretes/cognee-community#490
📌 Issue Tracking: topoteretes/cognee#6305
💻 Cognee Repository: https://github.com/topoteretes/cognee
🚀 Hoppscotch: https://hoppscotch.io

What is the biggest source of hallucinations in your AI coding workflows: API contracts, database schemas, or infrastructure configs? Let me know in the comments!

DEV Community: Shubham Vernekar

Zero-Hallucination Reverse Proxies for AI DevOps: Building a Caddyfile Connector for Cognee

1. Why Caddyfile Routing Context Matters

2. Introducing Cognee: Memory for Web Routing

3. Architectural Overview: The Caddy Connector

3.1. Stable Entity Identifiers

3.2. Keeping Routing Knowledge Synchronized

3.3. Agent-Friendly Configuration Representations

4. Step-by-Step: Ingesting a Caddyfile into Cognee

Step 1: Install the Dependencies

Step 2: Prepare Your Directory

Step 3: Ingest and Search the Routing Configuration

Step 4: Inspect the Results

5. From Retrieved Context to Better-Informed Proxy Changes

6. Open-Source Pull Request and References

7. The Grand Finale: Five Connectors for AI Engineering Context

GraphQL Schema Memory for AI Coding Agents: Building a GraphQL SDL Connector for Cognee

1. Why GraphQL Schema Context Matters

2. Introducing Cognee: Knowledge Graphs and Retrieval

3. Architectural Overview: The GraphQL Connector

3.1. Stable Entity Identifiers

3.2. Keeping Schema Knowledge Synchronized

3.3. Agent-Friendly Schema Representations

4. Step-by-Step: Ingesting schema.graphql into Cognee

Step 1: Install Dependencies

Step 2: Prepare Your Schema

Step 3: Ingest and Search GraphQL Memory

5. Result: More Schema-Informed GraphQL Queries

6. Open-Source Pull Request and References

Stop AI Agents from Hallucinating Infrastructure: Building a Docker Compose Connector for Cognee

Why Does This Happen?

1. Why Docker Compose Topology Matters

2. Introducing Cognee: Infrastructure Memory for AI Agents

3. Architectural Overview: The Docker Compose Connector

3.1. Stable Service Identifiers

3.2. Full-Snapshot Synchronization

3.3. Rich, Agent-Friendly Service Representations

4. Step-by-Step: Ingesting Docker Compose into Cognee

Step 1: Install Dependencies

Step 2: Prepare Your Directory

Step 3: Ingest and Query Infrastructure Memory

5. Result: More Reliable, Topology-Grounded DevOps Workflows

6. Open-Source Pull Request and References

Stop AI Agents from Hallucinating Database Schemas: Prisma ORM Connector for Cognee

Why does this happen?

1. Why Prisma Schemas?

2. Introducing Cognee: Structured Knowledge for AI Agents

3. Architectural Overview: The Prisma Connector

3.1. Deterministic Primary Keys

3.2. Full-Snapshot Synchronization

3.3. Rich, Agent-Friendly Schema Representations

4. Step-by-Step: Ingesting schema.prisma into Cognee

Step 1: Install Dependencies

Step 2: Prepare Your Schema

Step 3: Ingest and Search Schema Memory

5. Result: More Reliable, Schema-Grounded Database Queries

6. Open-Source Pull Request and References

Eliminating AI Hallucinations in API Integration: Building a Hoppscotch Connector for Cognee

Why does this happen?

1. Why Hoppscotch?

2. Introducing Cognee: Knowledge Graphs and AI Memory

3. Architectural Overview: The Hoppscotch Connector

Key Design Considerations

3.1. Stable Endpoint Identifiers

3.2. Synchronization and Deleted Endpoints

3.3. Environment Variables and Secret Handling

3.4. Structured, Agent-Friendly API Context

4. Step-by-Step: Ingesting a Hoppscotch Collection

Step 1: Install Dependencies

Step 2: Export Your Hoppscotch Workspace

Step 3: Ingest and Query the Collection

5. What Does Better API Grounding Look Like?

6. Open-Source Pull Request & Links

4. Step-by-Step: Ingesting `schema.graphql` into Cognee

4. Step-by-Step: Ingesting `schema.prisma` into Cognee