Why adding a source changes no API

This page makes the consequence of the faceted contract explicit: when Echo gains a new source, nothing changes for existing consumers.

What happens when a source is added

1. The source is implemented behind the contract — it exposes discover, search, fetch, and (if time-ordered) activity.
2. Projects that connect the new source see it in their discover response.
3. search queries begin returning hits from the new source, fused into the same ranked list.
4. Those hits carry refs that resolve via the same fetch endpoint.

No new endpoint is created. No new MCP tool is added. No client-side code changes. The consumer's existing integration starts returning richer results automatically.

Why this is unusual

Most systems treat sources as first-class API surfaces — a code API, a tickets API, a documents API. That works until the tenth source, at which point the client is maintaining ten integrations. Echo treats the contract as first-class and sources as data flowing through it. The client maintains one integration, forever.

What this means for agents

An agent wired to Echo's MCP server calls four tools. It discovers what sources exist, searches them, fetches the detail, and reads the timeline. If the organization connects a new database or a new document store, the agent's prompts do not change, its tool definitions do not change, and its context assembly logic does not change. It simply starts getting answers that draw on more knowledge.

Next: Code — the first source.