Myco is the connected index of everything your organisation knows.

Documents sit in wikis and drives. Code sits in repositories. Rules sit in databases. Services sit behind APIs. Each one has its own login, its own search, and its own idea of what a result looks like.

A person can live with that. They learn where things are and they move between systems by hand.

An agent cannot. Ask it where invoice approval is handled and what it touches, and it has to visit five systems, get five different shapes of answer, and stitch them together with no way of knowing whether it saw everything. Usually it did not, so it guesses.

Every source becomes the same two things. Things, and links between things. A file is a thing. So is a class, a table, an API endpoint, a section of a document.

Because every source produces the same two things, the links cross between them. A mobile screen links to the API endpoint it calls. That endpoint links to the database table it reads. A stored procedure reads the same table. Three systems, one chain, and you can follow it.

Search tells you what is relevant to your words. A map tells you what depends on what, and what breaks if you change it.

There is also a channel based on meaning, because two systems that do the same job may share no words at all. It is kept separate and it is clearly labelled. It is never mixed into the structural map and never presented as a fact.

Most of what an organisation knows was written down rather than compiled. Documents, wiki pages, shared drives, PDFs, spreadsheets and slide decks are first class sources here, not an import path bolted on the side.

A team with no repository at all gets one map of what it knows, real links between the pages that refer to each other, and one address to ask. A law firm, a school office, a research group and a two person studio all keep their work in that pile of systems, and none of them has an engineering department.

Code, schemas, live databases and live APIs are first class as well, and that is the unusual half. Most tools that read your documents stop at documents, and most tools that read your code stop at code. Holding both kinds in one graph is the whole point, and you can start from whichever kind you have.

Every source becomes the same two things: things, and typed links between them. That shape is fixed, so a system nobody here has seen still meets the same shape at the edge. A system built in house, a file format that never caught on, a database older than the team that runs it: each one is read by a parser and comes out as things and links like everything else.

That is what makes it safe to build on. Connecting more systems does not add commands to learn and does not change the shape of an answer, so what you built against the map keeps working after the next source is added.

The contract a parser writes against is the one we mean to publish, so an organisation with a system of its own can write one instead of waiting for us. It is not published yet. If that is your situation, tell us what the system is.

One program. The index is ordinary files on disk. The part that turns text into something searchable runs in the same process that answers the query. There is no separate database to host, no external service to call, and nothing it phones home to.

Organisations that cannot send their data anywhere. Regulated industries, government and defence adjacent work, and any organisation with a large, mixed technology estate. They have the worst version of this problem and the clearest reason to want something that runs entirely on their own hardware.

Organisations with no engineering function at all. A practice, a department, a charity, a business whose work is documents and spreadsheets rather than repositories. Same pile of systems, same question about what is in them, same map.

Individuals and small teams. People who want to point an agent at their own work without setting up infrastructure first.