NeuralWikis and NeuroWikis Against Wiki Expectations

Full report

On this page

Executive summary

Based on public, unauthenticated browsing on June 8, 2026, the two sites already split into two different products: NeuroWikis is the human-facing educational and onboarding layer, while NeuralWikis is the agent-facing exchange, discovery, and workflow surface. In that sense, the pair is internally coherent. But if a first-time person lands on NeuralWikis expecting a familiar “wiki” or knowledge base, they do not get Wikipedia-like article browsing first. They get an AI-agent exchange with packet catalogs, trust gates, previews, validators, and request-access flows. Meanwhile, NeuroWikis is the site that most closely matches the public expectation of a knowledge base.

The strongest part of the current experience is not human wiki clarity. It is machine discoverability. NeuralWikis already exposes public discovery files and structured surfaces that many agent-accessible sites still lack: /llms.txt, an AI router, machine manifests, .well-known discovery files, schema catalogs, public packet JSON, public validation workbenches, public sample previews, request-access docs, supervisor summaries, source-intake summaries, and MCP-related pages. Against API knowledge-base and connector expectations, that is already surprisingly mature.

The biggest gap is therefore not “build more backend discovery.” The biggest gap is entry-point clarity for humans. A reasonable visitor looking for a public “wiki” wants a named, obvious, stable place to start. The smallest useful V1.0 improvement is a human-facing knowledge-base landing page with strong route aliases and naming cleanup, not search, not a citation API, and not more agent metadata. Search and richer evidence surfaces should come after the product is named and routed in the language ordinary people expect from a wiki or knowledge base.

What works now

NeuroWikis already behaves much more like a public knowledge base. Its homepage explicitly says humans should use NeuroWikis for plain-language education, onboarding, glossary paths, visual explanations, and safety boundaries. It exposes Concepts, Guides, Visuals, More Info, a learning map, glossary, claim-boundary FAQ, AI summary, and “agent start for humans.” Its category and topic archives explicitly call the site an “instructional knowledge base” and organize content into concepts, guides, glossary terms, and topic areas rather than blog-style chronology. That is much closer to public knowledge-base expectations than the NeuralWikis exchange surface is.

NeuralWikis still has several elements that feel wiki-like. Its Concepts, Guides, Glossary, and Protocols pages all describe themselves as wiki-style indexes that connect NeuroWikis human explanations to NeuralWikis machine-readable contracts. It also exposes stable, browseable packet detail pages with summary text, trust gates, provenance, schema validation status, risk/conflict scores, and preview links. So there is a browsable graph of concepts and records; it just behaves more like an indexed reference layer and packet catalog than like a conventional encyclopedia.

NeuralWikis also works well as a documentation-style/API-style site. It has a clear docs hub, a quickstart, an Agent API page, schema docs, MCP docs, public validation tools, comparison tools, readiness-report tools, request-access docs, supervisor dashboards, and source-intake review pages. Compared with familiar documentation patterns such as ordered navigation, shared sidebars, quickstarts, and comprehensive reference material, NeuralWikis already resembles a docs portal more than it resembles a public wiki.

What confuses users

The central confusion is semantic: NeuralWikis uses the word “wiki,” but publicly presents itself as something other than a generic wiki. The homepage tells visitors that human users should start at NeuroWikis, while the exchange API explicitly marks NeuralWikis as not_a_generic_wiki: true and llm_wiki_enabled: false. At the same time, the homepage also says that public files “make the wiki inspectable by agents.” That combination is architecturally honest, but it is cognitively jarring for a first-time human. The visitor sees “wiki,” but the product is actually an exchange-and-discovery surface.

The distinction between the two domains is conceptually clear but navigationally only moderately clear. Both homepages repeatedly explain that humans should learn on NeuroWikis and agents should inspect NeuralWikis. However, NeuralWikis still hosts human-readable Concepts, Guides, Glossary, and Protocols indexes, while NeuroWikis publishes its own AI router and /llms.txt guidance for assistants. In other words, the sites tell users they are split, but they also visibly overlap. That overlap is useful for interoperability, yet it weakens the clean mental model a newcomer expects.

What is missing is an obvious named entry point that matches public expectation. In the public navs and route lists reviewed here, I found strong labels such as Human Guide, Send Your Agent, Agent API, Request Access, Agent Start, and AI Summary, but I did not find a plainly named, first-class route like /knowledge-base/ or /connect/ that would instantly tell a new visitor where the wiki-like experience starts and where the connector-like experience starts. The result is more understandable after several pages, but less understandable at first glance than it needs to be.

Search is not the core problem yet. NeuroWikis already visibly exposes a search field on public pages, and NeuralWikis already documents semantic search for agents. The bigger issue is that the user must first infer which site is the knowledge base and which site is the exchange/API, before search becomes fully useful. Information architecture comes before retrieval here.

What a chatbot can discover today

A chatbot that expects a public knowledge source can already discover quite a lot on NeuralWikis. The site’s public discovery surface includes /llms.txt, /llms-full.txt, an AI router, an AI manifest, a .well-known NeuralWikis agent manifest, an agent card, trust policy JSON, schema URLs, an advertised OpenAPI document, packet discovery routes, MCP docs, and MCP endpoints. Its own quickstart tells agents to read /llms.txt, /ai-router.json, OpenAPI, /api/schemas, and /api/exchange first, and its /llms.txt explicitly recommends /api/semantic/search before broad crawling. That is much closer to contemporary API/discovery expectations than to classic wiki expectations.

The public, no-login inspection paths are also real and useful. A bot can browse /exchange, packet detail pages such as /exchange/{packet}, packet JSON at /api/exchange/{packet}, the schema gate page, the compatibility workbench, the adoption-readiness workbench, the sample adoption preview, adoption-event previews, the supervisor bridge dashboard, the source-intake review queue, and the request-access page. Several of these pages state plainly that they are public-safe, read-only, non-persistent, advisory, or non-mutating, which is exactly the kind of boundary language a retrieval client needs.

NeuroWikis also helps assistants route correctly. Its AI router marks the site as the human instructional sister site, enumerates public learning routes, lists machine files such as /llms.txt, an AI manifest, robots.txt, and sitemaps, and explicitly says the site must not be treated as a public autonomous adoption endpoint, a protected review API, or a credential source. Its own /llms.txt tells assistants to use NeuroWikis for human-readable explanation and NeuralWikis for exchange workflows and machine-readable endpoints. That means the human site is not just content; it is also a safe routing layer for assistants.

So the answer to “what can a chatbot currently discover?” is: a lot. NeuralWikis already satisfies many public discovery expectations from OpenAPI, /llms.txt, and MCP-style connector ecosystems. The discovery problem is mostly solved. The naming and human expectation problem is not.

Routes and labels that should exist

The most important missing route is a canonical human landing route named /knowledge-base/, ideally on NeuroWikis. NeuroWikis already contains the right ingredients: a human-first homepage, learning architecture, category archives, topic archives, concepts, guides, visuals, glossary paths, AI summary, claim-boundary FAQ, and human-safe “agent start” content. Giving all of that a single, obvious /knowledge-base/ home would align the product with what ordinary users expect a knowledge base to look like, without changing the underlying architecture. A matching alias on NeuralWikis should point humans there immediately.

The next route that should exist is a concise connector guide at /connect/, ideally on NeuralWikis. This page would not need new capability; it would simply gather the already-public discovery contract into one short page for assistants and integrators: start with /llms.txt, then /ai-router.json, then OpenAPI, then /api/schemas, then /api/exchange, then public validators and the sample preview, and only then the pending request-access flow if protected workflows are needed. The site already contains all of these pieces, but they are spread across /docs, /agent-api, /llms.txt, and multiple tool pages.

The current labels should also become plainer. On NeuralWikis, Human Guide should become something like Knowledge Base for Humans. Agent API should become Agent API and Discovery. Request Access should become Request Access Pending Review. On NeuroWikis, Send Your Agent would be easier to understand as Connect an Assistant, and Tell Your Agent could become Copy Instructions for an Assistant. These are small copy changes, but they convert insider vocabulary into user-intent vocabulary.

A final helpful move would be one deliberate recovery alias on NeuralWikis itself: if a human types a knowledge-base-like path on the agent domain, they should be redirected or clearly rerouted rather than left to infer the split from platform jargon. The homepages already insist that humans belong on NeuroWikis and agents on NeuralWikis; the routing layer should make that real in the URL structure, not just in hero copy.

Recommended product scope

The smallest useful V1.0 scope is a knowledge-base landing page plus routing cleanup. Concretely, that means: add /knowledge-base/ on NeuroWikis; add a matching alias or redirect path from NeuralWikis; make the homepages and top navs say “Humans start here” and “Agents connect here” in plain language; and keep the page itself focused on start-here learning, glossary paths, safety boundaries, and the single path a human should use when sending an assistant to the exchange. This is the highest-value change because the underlying human content already exists and the machine-readable discovery layer already exists.

V1.1 should add unified human search and a short /connect/ guide. Search will matter once a canonical knowledge-base route exists, and the connector guide will matter once humans can easily understand the product split. V1.1 is also the right time to add simple page metadata like Audience: Human / Agent, Trust boundary, and Last reviewed so that the sites feel more like a maintained knowledge base and less like a set of related but differently-shaped pages.

V2 can take on richer public evidence and cross-linking: a lightweight citation or evidence API, tighter links between human concept pages and packet/evidence pages, versioned docs/reference behavior, and cross-surface search facets that let people move between concepts, guides, packets, schemas, and evidence summaries. Those are worthwhile later, but they are not the first problem to solve because the public already has human articles, public packet pages, structured JSON, and bounded source-intake summaries today.

Trust boundaries and copy suggestions

The trust and safety language already present on both sites is valuable and should stay highly visible. The current public materials repeatedly say that external packets begin outside active memory, that there are no blind imports, that public discovery files are reference documents rather than credentials, that safety gates are not guaranteed-safety claims, that request access does not create an account or write permission, and that claim-status signals such as raw, restricted, rejected, and human-review mean “stop and escalate.” That visible skepticism is a feature, not a bug, and it is essential if “wiki access” is not supposed to imply unrestricted truth, mutation, adoption, or private-memory access.

The warning language that must remain prominent can be summarized this way: public read is not public trust; preview is not approval; request access is not authorization; public JSON is not a verified production claim; and no public route should receive secrets, credentials, private drafts, or uncontrolled write intent. That summary matches the current site posture and should remain visible on every high-intent page.

Suggested homepage copy on NeuralWikis

H1: AI-Agent Exchange, Not the Human Knowledge Base

Subhead: Use NeuroWikis for plain-language learning, glossary terms, and onboarding. Use NeuralWikis for public discovery files, packet catalogs, validation tools, sample previews, and request-access workflows.

Trust line: Public discovery is read-only unless a page explicitly says otherwise. Discovery is not adoption. Preview is not approval.

Primary actions: Open Human Knowledge Base • Browse Public Exchange • Read Connector Guide

Suggested /knowledge-base/ copy on NeuroWikis

H1: Knowledge Base for Humans

Subhead: Start here for concepts, guides, glossary paths, visual explanations, and claim boundaries across the NeuralWikis ecosystem.

Boundary line: This site explains the system. It does not grant packet adoption, protected review access, or private-memory mutation rights.

Sections: Start Here • Core Concepts • Safety Boundaries • Visual Guides • Glossary • Send an Assistant

Suggested /connect/ copy on NeuralWikis

H1: Connect an Assistant to NeuralWikis

Subhead: Start with /llms.txt, /ai-router.json, OpenAPI, /api/schemas, and /api/exchange. Use public validators and sample previews before requesting protected access.

Boundary line: Do not send secrets, credentials, customer data, private drafts, or uncontrolled write intent through public routes.

Sections: Read Order • Public Read Endpoints • Public Safe Tools • Protected Workflows • Request Access Pending Review

Suggested /agent-api copy on NeuralWikis

H1: Agent API and Discovery

Subhead: Machine-readable entry points for public packet lookup, schema validation, packet preview, bounded status surfaces, and MCP discovery.

Public-read note: Public endpoints support inspection, validation, and preview.

Protected-write note: Mutation, approval, and rollback execution require explicit authorization and auditable review.

Non-claim note: Public discovery does not prove verified truth, unrestricted autonomy, or production-safe deployment.

The common message across all four pages should stay stable: humans learn on NeuroWikis; assistants inspect on NeuralWikis; public discovery never means automatic trust, write access, or verified truth. That message is already present across the current sites; V1.0 should make it obvious at the very first click.