ComponecatContext engine for coding agents: search or a catalog?
A context engine decides what an AI coding agent knows beyond the file it is editing. There are two broad ways to build one: search over everything your team has written, or a catalog of facts your team has declared. They answer different questions, and most teams need both.
Search: retrieve what was written
A search-based context engine indexes what already exists (code, pull requests, tickets, docs, chat) and, when the agent asks a question, retrieves the passages that look most relevant. Its strength is coverage: it can surface a design discussion nobody thought to write up, or the reason behind an odd line of code.
Its scope is what your team has written. It answers with the passages that match the question best, which suits questions whose answer lives in a discussion, a ticket or a commit. A question such as who owns the billing service is different: the agent needs the one current answer your team has declared, not every passage that mentions it.
A catalog: look up what was declared
A catalog holds facts someone declared on purpose: this service exists, this team owns it, it depends on these three services, this is its API. The agent does not infer the answer from text. It looks it up.
In Componecat that structure is explicit. Every entity has a kind and an
owning team, relationships are typed (depends-on, parent-of and your own),
and interfaces carry protocol, URL and auth for an API, or registry and
coordinates for a package. An agent can ask for a service's dependencies and
get a list, or run impact analysis and get the blast radius of a change,
upstream, downstream or both.
The cost of declared facts is keeping them true. That is why the catalog reads
componecat.yaml descriptors that teams commit next to their code (a scheduled
scan finds new ones and every push re-reads a changed one), syncs
documentation from Markdown in the repository, and mirrors team ownership from
GitHub, GitLab, Atlassian or Microsoft 365. These integrations come with Pro
and Enterprise.
Which questions go where
| The agent needs to know | Better answered by |
|---|---|
| Who owns this service, and who reviews a change | A catalog |
| What depends on this, and what a change would affect | A catalog |
| How to call another service's API | A catalog (its interfaces) |
| Which conventions apply to this kind of component | A catalog (its wiki guides) |
| Why a past decision was made | Search, or an ADR section on the entity |
| What a teammate said about a bug last week | Search |
The two meet in the middle. Componecat can also rank by meaning: on Pro and Enterprise, with an embedding model configured, an agent can describe what it is looking for ("the service that sends invoices") and get the closest entities or documentation sections, then follow declared relationships from there. Search finds the starting point; the catalog supplies the facts around it.
Giving agents the catalog
Componecat serves the catalog over MCP, so Claude, ChatGPT, Cursor, VS Code and other MCP clients can query it. Access is granted read or write per resource, and a read-only agent is never offered the editing tools. The MCP server page covers what an agent can do, and Connect AI agents walks through each client.
The Free plan includes the MCP server, up to 5 users and 50 catalog entities. That is enough to declare one system and the services around it.