The best solution we could find for this problem was a combination of a Wiki + "Saved Programs" (executable scripts).
When you ask a question, the system does a fuzzy Wiki search to see if any topic has relevant info. Wiki links serve as "graph edges" that form a Knowledge Graph.
So lets say I ask "What products from the FOOBAR API sold least last month?"
The agent would look up "FOOBAR API", and then write a script to call the "products" endpoint with a date range + SQL fetch from "sales" DB and do whatever it needs to do.
If none of this info exists (URL to FOOBAR, location of "sales" data), the agent asks for more info and offers to update the wiki for future.
Similar conclusion I've come to. For all the complex RAG and many SaaS startups selling knowledge engines - what we keep falling back to is simple a wiki (markdown) + simple tools to solve problems and help answer questions programmatically where possible. Cheap, fast, low complexity and no lock-in.
Very close to this at my company. We have docs each of which having its description in the yaml. An MCP tool lists the doc sections, a full section with its descriptions, or the entire contents of a doc. A kind of progressive disclosure. Works really well. We even write "skills" this way so they can be used in all our chat environments.
Does this solution use a private/local LLM or something else? Sorry if the answer is obvious. I’ve just started considering this for an internal wiki to my company.
It feels like there's a lot of overlap with the existing MCP "Resources" [0] concept, and that "Searchable Registry" + multi-protocol (MCP/A2A, etc) is the main difference?
Too many protocols got created (MCP, A2A, etc) and so now you've got to create a new standard that can consume them all, and Google being a search index would like to index them, please =)
Building an ontology of how people think of and organize information, processes, and actions is not solved via markdown. It’s not well solved intra company much less inter. The systems that do solve some of this are optimizing for unstructured retrieval and will continue to.
Imposing a structure on this unstructured discovery feels like it ignores all progress in IR, and imposes a farcical structure that doesn’t have a tangible benefit.
This seems useful as a standard interface, but, again, doesn’t solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc.
The homepage makes it clear this is not another centralized registry susceptible to such issues. The goal is to have a common mechanism inside enterprises. A key aspect here is having agents appear in discovery, so they can call each other. You can see this in pattern Gemini Enterprise
Why not ask the agent to read .well-known/agent.md (or better yet something.com/agent.md) and do a bootstrap if it is allowed! to do so. It can download skills, configure mcps, etc.
This is search. Please don't reinvent search with a new acronym.
Agents can use Google. They can also see all the same signals humans do to judge quality. Maybe there's a need for a specialized directory, but does it need a spec or an acronym? No.
for the internal use at my company we created a tool to partially solve this issue by building a manifest that MAY contain tags and other metadata for agentic resources lookup.
I work at a company with an LLM-adjacent tool.
The best solution we could find for this problem was a combination of a Wiki + "Saved Programs" (executable scripts).
When you ask a question, the system does a fuzzy Wiki search to see if any topic has relevant info. Wiki links serve as "graph edges" that form a Knowledge Graph.
So lets say I ask "What products from the FOOBAR API sold least last month?"
The agent would look up "FOOBAR API", and then write a script to call the "products" endpoint with a date range + SQL fetch from "sales" DB and do whatever it needs to do.
If none of this info exists (URL to FOOBAR, location of "sales" data), the agent asks for more info and offers to update the wiki for future.
Similar conclusion I've come to. For all the complex RAG and many SaaS startups selling knowledge engines - what we keep falling back to is simple a wiki (markdown) + simple tools to solve problems and help answer questions programmatically where possible. Cheap, fast, low complexity and no lock-in.
Very close to this at my company. We have docs each of which having its description in the yaml. An MCP tool lists the doc sections, a full section with its descriptions, or the entire contents of a doc. A kind of progressive disclosure. Works really well. We even write "skills" this way so they can be used in all our chat environments.
Does this solution use a private/local LLM or something else? Sorry if the answer is obvious. I’ve just started considering this for an internal wiki to my company.
We use Opus/Codex models
It feels like there's a lot of overlap with the existing MCP "Resources" [0] concept, and that "Searchable Registry" + multi-protocol (MCP/A2A, etc) is the main difference?
Too many protocols got created (MCP, A2A, etc) and so now you've got to create a new standard that can consume them all, and Google being a search index would like to index them, please =)
[0]: https://modelcontextprotocol.io/specification/2025-11-25/ser...
As always, relevant XKCD https://xkcd.com/927/
Building an ontology of how people think of and organize information, processes, and actions is not solved via markdown. It’s not well solved intra company much less inter. The systems that do solve some of this are optimizing for unstructured retrieval and will continue to.
Imposing a structure on this unstructured discovery feels like it ignores all progress in IR, and imposes a farcical structure that doesn’t have a tangible benefit.
This seems useful as a standard interface, but, again, doesn’t solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc.
The homepage makes it clear this is not another centralized registry susceptible to such issues. The goal is to have a common mechanism inside enterprises. A key aspect here is having agents appear in discovery, so they can call each other. You can see this in pattern Gemini Enterprise
Why not ask the agent to read .well-known/agent.md (or better yet something.com/agent.md) and do a bootstrap if it is allowed! to do so. It can download skills, configure mcps, etc.
There is no need for another file IMHO.
This is search. Please don't reinvent search with a new acronym.
Agents can use Google. They can also see all the same signals humans do to judge quality. Maybe there's a need for a specialized directory, but does it need a spec or an acronym? No.
MCPs: Json endpoints with a "description" field.
More like: JSON-RPC, but without all good stuff.
JSON-RPC is at the core of MCP
But "search" doesn't have "agentic" in it. But oh wait, we can make it:
Super Explanatory Agentic Resource Catalog Heurestics - SEARCH
[dead]
I thought the point of AI was that you wouldn't need stuff like this.
for the internal use at my company we created a tool to partially solve this issue by building a manifest that MAY contain tags and other metadata for agentic resources lookup.
https://theta.tamarillo.ai
This is reminiscent of Web Services Discovery (UDDI).
[dead]