Echo
Your business knows more than any person can hold
Echo is the intelligence engine that captures what your company knows, connects it, and turns it into something humans and agents can act on.
What we do
Memory lets an agent remember what happened. An ontology lets it know what exists. Memory is the record of the session; the ontology is the map of the organization, and an agent needs both before it can be trusted with anything real.
An organization’s knowledge is scattered by default. Work lives in one system, intent in another, history in a third, meaning in databases and documents nobody has updated since the person who designed them left — whether that’s code and tickets, contracts and claims, or products and policies. Every agent that touches this today rebuilds a partial, throwaway picture from whatever happened to fit in a prompt.
We ingest those sources and materialize them as one ontology: a typed graph of the entities an organization actually has and the relations between them, paired with a semantic index and queryable by humans and agents through a single knowledge API and an MCP server. Not a bigger context window: a model of the system, with every fact traceable back to where it came from.
What we solve day to day
The questions teams ask every day
“What does this actually touch?”
The graph connects code to work to data, so a module resolves to the tables it reads, the tickets it affected and the dependencies it pulls in. Blast radius stops being an archaeology exercise.
“Why is this built like this?”
Commits, pull requests and issues are linked to the modules they changed. The reasoning behind a piece of code survives the person who wrote it.
“The agent invented a schema”
Structure comes from the database’s own catalog, not from a guess. Relationships that were never formally declared are recovered and labeled with how confident we are and where the evidence came from.
“Nobody knows what’s in that database”
Every connected database is profiled, classified for sensitive data and described in plain language, without a single row ever being copied out.
“The docs are always out of date”
Documentation is generated from the graph rather than from the source tree, and regenerated when the graph changes. It cannot drift from the code.
“We can’t fit the codebase in a prompt”
Agents retrieve what the question needs and expand outward from there. Context is assembled, not dumped.
“Can we trust the answer?”
Every fact carries its origin, including whether it was derived deterministically or interpreted by a model, and every returned claim keeps a resolvable reference. The consumer can verify instead of trust.
How we think about it
The stance behind the system
An ontology, not an index
The word is deliberate. A search index tells an agent which documents mention a thing. An ontology tells it what the thing is, what it is made of, what it depends on and what breaks when it changes.
That requires three commitments most retrieval systems never make. Entities are typed, so a module, an issue and a table are different kinds of thing with different questions attached to them. Relations are typed and directional, so “this code writes to that table” is a different fact from “this code reads it.” And meaning is shared across sources, so the same concept referenced in a ticket, a commit message and a column name resolves to one entity rather than three strings that happen to look alike.
An index makes an agent better at finding text. An ontology makes it capable of reasoning about a system it was never trained on.
Deterministic first, models second
Structure is derived by parsers, never by a model. We build the map of modules, symbols, imports and call paths with language-native analysis, and the result is reproducible: the same commit produces the same graph, every time.
Only then does a model run, and it runs over the structure rather than over raw files. Interpretation sits on top of something already known to be correct, and it is labeled as interpretation. Most systems in this space do the opposite and inherit every hallucination into their foundation.
One ontology, three planes, linked
Code, work and data are modeled as separate planes and then connected into a single ontology.
The cross-plane edges are the whole point. Anyone can index a repository. The useful question is which code a ticket actually changed, or which service breaks if a column is dropped, and that is only answerable if the planes share one ontology instead of sitting in three separate tools.
Metadata out, SQL in
We store knowledge about a database, not the database. The footprint per table is independent of row count, so a fifty-thousand-table estate is still small. Sensitive columns are classified before anything is persisted, and tagged columns keep statistics only: their values are masked, never stored, never sent to a model.
When an agent genuinely needs live data, it queries the customer’s database directly under governance: a read-only role verified at connection time, query validation before execution, enforced limits and timeouts, a cost gate, and a per-user audit trail. Results flow to the agent. They never land in our storage.
Cost that scales with change, not with size
Every expensive step is gated on whether the underlying thing actually changed. Re-running the pipeline over an unchanged repository or an unchanged table costs effectively nothing. Spend tracks the organization’s rate of change rather than the size of its estate, which is the difference between a system that can be left running and one that gets switched off after the first invoice.
Built to be interrupted
Ingestion is a state machine. It can be paused mid-run, resumed from the point of failure, or restarted clean. Each source syncs independently and records its own outcome, so one expired credential never blocks the rest. Deletions are tombstoned rather than erased, behind a safety threshold that catches mass-delete anomalies before they propagate.
Reads are consumption-only
Data enters through deterministic, native connections. Agents read through the API and MCP, and never write through them. Keeping the ingestion path free of agents is what makes the graph auditable at all.
How a question gets answered
Discover, search, expand, cite
Discover
An agent asks what sources exist for a project before asking anything about them, so it knows the shape of what it can know.
Search
The question runs against every source in parallel behind a common interface, blending semantic and keyword retrieval into a single ranked result.
Expand
Every result resolves to the full object plus its neighborhood in the ontology. For a table, that means its columns, its join paths and the code that reads or writes it. This step is what turns “found a table” into “here is what depends on it,” and it is only possible because the relations were typed at ingestion rather than inferred at query time.
Cite
Every claim keeps its reference, so the answer can be checked rather than believed.
Design principles
Where we stand, concern by concern
| Concern | Our position |
|---|---|
| Structure | Extracted deterministically, reproducible, never model-generated |
| Interpretation | Model-assisted, always labeled, always on top of verified structure |
| Freshness | Incremental by default, with periodic full reconciliation |
| Data privacy | Metadata out, governed queries in, raw rows never stored or prompted |
| Credentials | Per-user, encrypted at rest, least-privilege by requirement |
| Multi-tenancy | Enforced at read time, on every query, in every plane |
| Documentation | Generated from the graph, so it cannot contradict the code |
| Agent access | Read-only, scoped, fully attributable |
Get in touch
Tell us about your team and we’ll show you what Echo can do.