Myco, from RootNet
One connected map of everything your organisation knows.
Myco indexes your documents, code, schemas, live databases and live APIs. It links them into one graph. Anything that can call an endpoint can use it, running on hardware you own.
Myco is not generally available yet. If this is the shape of the problem you have, write to us and tell us about it.
Litter
Every system has its own search box.
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.
Root
One address, and anything that can call an endpoint can use it.
Not one integration per system. One place to ask. Connecting a hundred more systems does not change what you call or what comes back.
Every answer carries where the result came from and how fresh it is. That is the same for an agent, for a search box and for a nightly report.
You do not need an AI budget, or an engineering team, to want a connected map of what your organisation knows.
- Search, walk the graph, read exact content, make read only calls to live systems
- One box across every system, ranked properly, with the source of every result
- Go to definition and find references, across repositories and languages
- What breaks if we change this table, answered from real links
- A service catalogue, an ownership map, a dependency view
- Somebody new traces how something works end to end without asking six people
- What exists, what touches what, and what it looked like on a given date
One of those doors, as an example.
Agents reach it through a small fixed set of commands. Not a set per source: this set in total, and connecting more systems adds none. The HTTP surface is shaped for the things that call HTTP, and it answers from the same graph with the same ranking.
- search Find things across every permitted source at once, by meaning and by keyword
- summarize Get oriented. Show the shape of one thing, or of the whole graph
- neighbors Walk the links. What does this call. What reads this table
- read Fetch the exact content. This file, these lines. This table's schema
- list Enumerate by filter. Every endpoint in this service
- query Run a read only query against a real, live database
- invoke Call a real, live API endpoint
Most of them read the index. Two reach live systems, and they are marked as such wherever they appear.
Fewer, higher level tools produce better results than a large surface of narrow ones. Anthropic on writing tools for agents
Hyphae
A map, not a pile of search boxes.
Every source becomes the same two things. Entries, which are the things: a file, a class, a table, an API endpoint, a section of a document. Edges, which are typed, directed links between them.
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.
Search tells you what is relevant to your words. A graph tells you what depends on what, and what breaks if you change it.
Most systems that build a graph over your content ask a language model to read the text and identify the relationships. Ours come from a parser that read an import statement, a call site, or a SQL reference. Each link is directed, typed, and points at a line in a file.
A guessed link is a hypothesis. A parsed link is a fact.
| Guessed | Parsed | |
|---|---|---|
| Direction | Often unclear | Directed. "A calls B" is not "B calls A" |
| Type | Generic relatedness | Imports, reads, writes, implements, and more |
| Provenance | None | Points at a line |
We do also have a meaning based channel, because two systems that do the same job may share no symbols at all. It is kept separate and clearly labelled. It is never mixed into the structural walks and never presented as a fact.
Plain retrieval wins on single hop questions. Graph retrieval wins on multi hop and whole corpus questions. Combining them beats either one alone. arXiv 2502.11371
Substrate
It runs inside your network.
One program. The index is ordinary files on disk. The search model runs in the same process that answers the query. There is no vector database to run, no external embedding service to call, and no cloud service it phones home to.
The most common way an organisation breaks its own air gap is by sending text to a remote embedding API. Myco does not do that.
We will also offer a more convenient deployment where the text to vector step is hosted for you. That one is not air gapped, and we will never call it private.
The EU AI Act's data governance requirements for high risk systems take effect on 2 August 2026. Prediction Guard
Air gapped and on premises is now the top sovereignty tier in procurement, and it is commonly required for public sector, defence adjacent and critical infrastructure work. Knowlee, 2026
Sample
This is built, not designed.
Myco is working software. Code in a dozen languages, internal documents, crawled sites, PDF and office files, images, schema contracts, live databases and live API catalogues all become entries and typed links in the same graph.
It is built for the heavy, large, mixed environments the modern tools handle badly, because those tools assume everything is Git, mainstream languages, and hosted in the cloud. Nothing about it requires an estate that size. The smallest useful version of this is one person pointing it at their own work.
An installer, a plain HTTP API, history and multi node operation have all shipped. Search quality is measured on every change, on a fixed set of questions, using recall, mean reciprocal rank and normalised discounted cumulative gain. A change that quietly buries the right answer fails the build.
- 1
- program to run
- 20+
- types of link between your systems
- 0
- external services required
You do not need any code for this.
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 the same thing everyone else does: 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. Holding both kinds in one graph is the point, and you can start from whichever kind you have.
A new kind of source is a new parser, not a new product.
Every source becomes the same two things: entries, 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 entries 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 graph 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.
Bedrock
Tell us what you are trying to connect.
Myco is not something you can buy or download today. What we can do is talk to you properly. Messages go straight to the person who built it, and you will get a real answer rather than a sequence.
Useful things to say, if you have them: the kinds of systems you would want in one graph, whether your data is allowed to leave your network, and the question you keep having to answer by hand.
We will not give you a date, because we do not have one.
Write to usrutvik@flareware.app