Compare by workflow concern
Each block maps a repeated agent-data problem to the Cortrix layer that keeps it reviewable and reusable.
Move ingestion and records out of app glue
Document ingestion, embedding, source context, and semantic records become shared storage lifecycle work instead of parser, chunker, embedding, index, and metadata code repeated inside each app.
Parser, chunker, embedding job, vector write, and record metadata are maintained as workflow code.
Semantic records, source context, embedding/index lifecycle, and review surface live in one shared layer.
Combine retrieval signals with evidence context
Vector search, keyword search, hybrid fusion, reranking, cross-namespace query, and advanced retrieval-quality patterns belong in a retrieval module agents can inspect, not in hidden prompt-time assembly.
Vector-only or framework-specific retrieval code carries ranking, filters, and citations separately.
BM25 and vector signals, RRF fusion, reranking, namespace scope, and evidence context stay connected.
Make memory records typed and reviewable
AI memory is easier to govern when session facts, typed memory records, extraction paths, and review state are stored as records instead of being scattered across chat state and tool callbacks.
Memory store, session facts, and conversation state are each managed in separate workflow surfaces.
Typed memory, extraction path, session scope, and reviewable memory records are available to agents.
Keep source links, traces, feedback signals, and scope labels inspectable
Source-level traceability, agent observability, and scope boundaries are part of the public contract. Retrieval feedback learning is a Roadmap direction, not a current automatic learning claim.
Responses, logs, citations, feedback, and scope docs must be reconstructed across tools.
Source-linked records, trace context, feedback signals, and scope labels can be reviewed together.
Give agents consistent paths into semantic records
Workflow connectors and the MCP server give agent workflows controlled access paths while REST, Python SDK, and framework adapters keep application integration explicit.
Each workflow maintains its own retrieval tools, memory adapters, and access policy glue.
REST, Python SDK, MCP, and framework adapter paths expose the same semantic storage layer.
Keep operational systems in place
PostgreSQL-backed applications can use the pgCortrix path. Other data stacks can keep their operational database in place and add Cortrix for semantic lifecycle work.
Application-owned sync paths connect database, retrieval index, memory, and agent code.
Docker, server, and PostgreSQL extension paths give semantic lifecycle work a clear deployment surface.
Keep your database and agent framework.
Add Cortrix where semantic records, retrieval evidence, memory, and trace context become repeated work.