Indentia Cortex

Cortex is the cold-path indexing and retrieval layer behind AgentFS and related Indentia tooling. It receives document and code updates asynchronously, builds richer retrieval representations over them, and serves the higher-latency questions that do not belong on a filesystem write path.

It is part of the sovereign AI knowledge platform behind Indentia Second Brain:

• Product docs: https://dbdocs.indentia.ai/indentia/
• Platform docs: https://dbdocs.indentia.ai/
• IndentiaDB repository: https://github.com/IndentiaPlatform/IndentiaDB

If AgentFS is the shared workspace that coding agents read and write, Cortex is the system that answers questions such as:

• what is the architectural role of this module?
• what depends on this package?
• why does this subsystem exist?
• where should an agent start editing?
• which files are semantically closest to this problem?

Why Cortex Exists

Coding agents need two very different kinds of access to code and documents:

1. immediate, byte-exact filesystem access
2. deeper retrieval over meaning, structure, dependencies, and historical context

Trying to do both in one hot path causes the wrong trade-offs:

• writes become expensive
• reads depend on indexing latency
• semantic work blocks ordinary developer operations
• graph-style enrichment ends up in the request path for cat, grep, or git

Cortex exists so that semantic and graph-aware retrieval can evolve independently from the filesystem hot path.

Position In The Stack

flowchart LR
  subgraph Agents["Agent Runtimes"]
    A["Claude Code"]
    B["Codex Harness"]
    C["Background automation"]
  end

  subgraph Workspace["Workspace Layer"]
    F["AgentFS"]
    I["agentfs-indexer"]
  end

  subgraph CortexPlane["Cortex"]
    API["Ingest + Query APIs"]
    PIPE["Indexing pipeline"]
    RET["Retrieval services"]
  end

  subgraph Backends["Cortex Backends"]
    STORE["Document / chunk storage"]
    EMB["Embeddings / vector indexes"]
    GRAPH["Optional graph runtime or adapter"]
  end

  A --> F
  B --> F
  C --> F
  F --> I
  I --> API
  API --> PIPE
  PIPE --> STORE
  PIPE --> EMB
  PIPE --> GRAPH
  RET --> STORE
  RET --> EMB
  RET --> GRAPH

Loading

What Cortex Does

At a high level, Cortex does four jobs.

1. Ingest content

Cortex accepts content updates from systems such as AgentFS.

Typical examples:

• a file changed in a shared workspace
• a repository was imported in bulk
• documentation was re-indexed
• a corpus item was tagged or reclassified

For AgentFS specifically, agentfs-indexer reads Redis change events and pushes updated file content into Cortex through /api/ingest/corpus/text.

2. Normalize and enrich

After ingest, Cortex can transform the incoming content into retrieval-oriented representations:

• normalized text
• chunked segments
• metadata and tags
• semantic embeddings
• dependency or relationship edges
• corpus-level routing hints

This is the point where graph-style enrichment belongs, not in the filesystem mount itself.

3. Serve retrieval

Cortex is the layer that serves slower, richer questions:

• semantic similarity
• dependency-aware discovery
• reasoning over structural relationships
• corpus-level “why” and “where to start” workflows

4. Isolate optional proprietary runtimes

Some graph or enrichment systems may remain closed-source or binary-only. Cortex is the boundary where those systems can be integrated without pushing proprietary code into AgentFS.

That is an intentional architectural boundary.

Ingestion Architecture

flowchart TD
  SRC["Source system\nAgentFS / importer / batch job"] --> API["Cortex ingest API"]
  API --> VAL["Validation + normalization"]
  VAL --> CH["Chunking + metadata extraction"]
  CH --> EMB["Embedding generation"]
  CH --> TAG["Tagging / corpus routing"]
  CH --> REL["Relationship extraction"]
  EMB --> IDX["Vector + text indexes"]
  TAG --> IDX
  REL --> G["Optional graph backend"]
  IDX --> READY["Queryable corpus"]
  G --> READY

Loading

Query Architecture

flowchart TD
  Q["Agent query / MCP tool / API request"] --> ROUTE["Query router"]
  ROUTE --> SEM["Semantic retrieval"]
  ROUTE --> TXT["Keyword / metadata filters"]
  ROUTE --> DEP["Dependency / relationship traversal"]
  ROUTE --> WHY["Explanatory / 'why' workflows"]
  SEM --> MERGE["Merge + rerank"]
  TXT --> MERGE
  DEP --> MERGE
  WHY --> MERGE
  MERGE --> RES["Ranked results / answer context"]

Loading

Why This Separation Matters

AgentFS and Cortex are designed together, but they solve different problems.

AgentFS should optimize for:

• byte-exact reads
• low-latency writes
• POSIX semantics
• shared workspace behavior
• git compatibility

Cortex should optimize for:

• richer indexing
• retrieval quality
• semantic and graph-aware exploration
• async processing
• flexible backends

That separation keeps both systems tractable.

Public Boundary

This repository is the public GitHub home for Cortex.

The public contract is:

• ingestion APIs
• retrieval APIs
• documentation
• deployment guidance
• openly publishable source and assets

Optional graph runtimes may remain:

• private source
• binary-only services
• separately deployed adapters

Those systems can sit behind Cortex without forcing private code into the public repositories.

flowchart LR
  PUB["Public Cortex repo + service contract"] --> API["Public API boundary"]
  API --> OSS["Openly published storage / retrieval components"]
  API --> PRIV["Optional private graph runtime\n(binary or separate service)"]

Loading

How Cortex Works With AgentFS

For the AgentFS integration, the usual flow is:

1. an agent edits a file through the AgentFS mount
2. AgentFS persists the byte-exact file blob and emits a change event
3. agentfs-indexer reads the event from Redis
4. agentfs-indexer pushes the updated file to Cortex
5. Cortex rebuilds the cold-path retrieval representation
6. future semantic or graph-style queries see the updated content

This keeps file operations fast while allowing retrieval to catch up asynchronously.

Deployment Model

flowchart LR
  subgraph K8s["Kubernetes"]
    subgraph PodA["Agent pod"]
      A["agent runtime"]
      M["AgentFS mount"]
    end

    subgraph PodB["Indexer pod"]
      I["agentfs-indexer"]
    end

    subgraph PodC["Cortex deployment"]
      C["Cortex API + retrieval services"]
    end

    R["Redis"]
  end

  A --> M
  M --> R
  I --> R
  I --> C

Loading

The main scaling rule is:

• scale AgentFS mounts with pods
• scale indexers with event volume
• scale Cortex according to retrieval and indexing load

Repository Scope

This repository is currently the public documentation and release home for Cortex. It is structured so that:

• the public architecture is documented clearly
• integration points are explicit
• public release metadata has a stable home
• implementation can expand without changing the product boundary

Related Repositories

• Cortex: https://github.com/IndentiaPlatform/Cortex
• AgentFS: https://github.com/IndentiaPlatform/AgentFS
• IndentiaDB: https://github.com/IndentiaPlatform/IndentiaDB
• Indentia platform docs: https://dbdocs.indentia.ai/
• Indentia Second Brain docs: https://dbdocs.indentia.ai/indentia/