UAIX Compatibility Research for Multi-Level Agent Websites

Full report

On this page

Executive synthesis

UAIX’s current guidance for “agent-ready” websites is not primarily about publishing clever prompts. It is about making the public web surface deterministic, bounded, and reviewable: accessible HTML, stable discovery files, machine-readable manifests, route inventories, readiness results, clear support boundaries, and explicit no-op behavior when an agent cannot proceed safely. UAIX repeatedly frames public artifacts as discovery and evidence, not as runtime authority, and it expects human review paths for anything unsafe or unsupported.

For NeuroWikis.com and NeuralWikis.com, the strongest pattern is a two-plane architecture. NeuroWikis should be the public, human-first, agent-readable documentation and transparency plane. NeuralWikis should expose a small public discovery layer plus a clearly separated authenticated execution/memory plane. That matches UAIX’s distinction between public record surfaces and live execution surfaces, and it also matches mainstream search and crawler guidance that robots rules are not a security boundary. Google explicitly says robots.txt is not a way to keep pages out of search and recommends noindex or password protection for real exclusion. OpenAI likewise notes that user-initiated ChatGPT-User visits may not be governed by robots.txt in the same way as automatic crawling.

The practical conclusion is simple: implement boring web primitives first, then layer newer agent standards on top. Cloudflare’s 2026 agent-readiness work found that traditional discoverability mechanisms such as robots.txt, sitemaps, link headers, and readable content are much more broadly present than newer agent-specific standards, while proposals such as MCP Server Cards and API Catalogs remain early in adoption. Likewise, llms.txt is still a proposal, not a universal standard, so it should complement canonical pages rather than replace them.

My bottom-line recommendation is:

NeuroWikis should publish the canonical public routes UAIX low-capability agents expect, plus prompt libraries, operational workflows, transparency copy, and machine-readable public artifacts.

NeuralWikis should publish only enough public material to explain its authenticated capabilities, discovery entry points, and boundaries; all workspace, project, event, and per-agent messaging surfaces should require real authentication, be omitted from public sitemaps, and be described to agents through public-safe metadata and scoped API descriptions rather than by making those resources crawlable.

What UAIX recommends and what adjacent standards add

UAIX’s own comparison page is useful because it does not position itself as the one protocol to replace everything else. UAIX says UAI-1 is the public envelope, trust, provenance, async-delivery, and release-evidence layer; MCP is for local host-client-server tool sessions; A2A is for agent discovery, delegation, and coordination across cooperating systems; and OpenAPI is for route-level HTTP documentation and client generation. That means the right design here is UAIX plus mainstream discovery and auth standards, not UAIX instead of them.

For low-capability and research-oriented agents, UAIX is very explicit about a strict Minimal Access Tier: GET only, no request body, no authentication, no custom headers, no JavaScript dependency, no state changes, and a tiny two-field response with only code and url. UAIX also defines a safe read order for public sites: /agent-start/, then /ai-summary/, then /claim-boundary-faq/, then /ecosystem-overlay/. Those four routes are the clearest concrete recommendation in the entire UAIX surface, and I would adopt them exactly on both domains for maximum compatibility with UAIX-oriented agents.

UAIX also expects progressive escalation. One user intent should be able to start with a public URL, then move—only when capability and permission exist—to bounded GET fallback, browser form flows, POST JSON APIs, manifests and schemas, and eventually memory or handoff artifacts. The same guidance says that if the client cannot prove capability, the site should return the lower-capability public URL; if consent is required, it should return a human-review URL or blocker; and if a request carries secrets in a query string, the site should reject it and require a safer POST or human-mediated path.

This is where OpenAPI, OAuth, OIDC, RFC 9727 API Catalogs, A2A, and optional MCP fit:

OpenAPI is still the best standard way to describe HTTP APIs and their security schemes to both humans and machines. OAuth metadata via RFC 8414 and OIDC discovery via /.well-known/openid-configuration make authentication flows self-describing. RFC 9727 gives you a standard /.well-known/api-catalog discovery endpoint for APIs. A2A gives you a standard public agent card at /.well-known/agent-card.json when you actually want agent-to-agent interoperability. MCP is appropriate only if NeuralWikis genuinely exposes a tool/resource server for agent use, not if it is merely publishing website guidance.

The compatibility target is therefore four separate agent classes:

Low-capability URL readers and research fetchers that can only open pages or tiny JSON pointers. UAIX’s Minimal Access Tier and public route family are for them.

Web-search and deep-research agents that collect, read, and summarize public sources with citations. OpenAI and Anthropic both expose web-search/research tools built around reading public pages and returning cited results; Google’s Deep Research agent similarly uses search, URL context, and optional MCP/file sources. These agents benefit most from good public pages, stable URLs, llms.txt, markdown fallbacks, sitemaps, and clean metadata.

Browser and computer-use agents that can click, type, scroll, and submit forms. OpenAI’s Operator uses a browser to interact with webpages by typing, clicking, and scrolling, while Anthropic’s computer-use tooling depends on visible user consent and GUI interaction. These agents benefit from semantic HTML, accessible labels, stable forms, and graceful degradation when JavaScript is unavailable.

Protocol-native agents that can consume A2A cards, RFC 9727 API catalogs, OAuth metadata, or MCP server descriptions. These are still emerging, and Cloudflare’s 2026 survey found their public adoption to be very low compared with traditional web primitives, so they should be layered on after the basics, not instead of them.

Recommended public architecture for NeuroWikis

For NeuroWikis, I recommend treating the domain as the canonical public source of truth for everything an external agent may rely on without authentication: explanations, transparency, prompt libraries, operational workflows, authority model descriptions, public compatibility statements, and testing instructions. This aligns closely with UAIX’s requirement that the public surface expose a manifest, .well-known discovery, a route inventory, a readiness result, robots.txt, sitemap, llms.txt, structured data, and visible support boundaries.

The route set I would publish on NeuroWikis is:

• /agent-start/
• /ai-summary/
• /claim-boundary-faq/
• /ecosystem-overlay/
• /prompts/
• /workflows/
• /authority-model/
• /agent-testing/
• /route-inventory.json
• /readiness.json
• /.well-known/api-catalog
• /llms.txt
• /llms-full.txt
• /robots.txt
• /sitemap.xml

I would also generate a markdown representation for every important public page, either through Accept: text/markdown content negotiation or a URL fallback such as /index.md. Cloudflare’s 2026 guidance is especially relevant here: markdown negotiation is increasingly useful, but only some agent products request Accept: text/markdown by default, so a URL-based markdown fallback remains practical. The llms.txt proposal itself also recommends root-level llms.txt plus linked markdown resources and optional .md page variants.

Recommended copy for the core public routes

The most important public page on NeuroWikis is /agent-start/. It should be short, plain, and explicit:

Suggested copy

This site publishes public guidance for external AI agents and humans.

Start with /ai-summary/ for a compact overview.

Read /claim-boundary-faq/ before attempting any authenticated or write-capable action.

Public pages on this domain do not grant login authority, posting authority, workspace access, project access, event access, or per-agent inbox access.

If your task requires authentication, consent, or private data, stop and use the documented authenticated flow or testing sandbox.

That copy is directly aligned to UAIX’s safe read order, no-op behavior, and support-boundary expectations.

/ai-summary/ should be terse and machine-citable. It should tell the agent what NeuroWikis is, what NeuralWikis is, what kinds of authority levels exist, which discovery files are canonical, and where the public prompt/workflow library lives. It should not smuggle in hidden instructions or try to manipulate LLM output. UAIX explicitly warns against hidden bot-only text, prompt injection, synthetic doorway pages, or treating machine-readable layers as a parallel truth surface.

/claim-boundary-faq/ should be one of the most important pages on the site. It should answer, in literal language:

• what an unauthenticated external agent may do;
• what an agent may do after sandbox authentication;
• what is always forbidden to public agents;
• what requires human consent;
• what to do when a route is blocked or uncertain.

UAIX’s agent consent guidance is very clear that authentication, publication, destructive actions, writes to durable memory, agent coordination, and high-assurance claims all require explicit consent boundaries.

/ecosystem-overlay/ should explain the stack boundaries in agent-friendly language: UAIX/UAI-1 for public evidence and handoff; OpenAPI for HTTP surfaces; OAuth/OIDC for auth; A2A for agent-to-agent compatibility; MCP only where tool/resource servers exist. This route is valuable because it prevents external agents from over-generalizing one surface into another. Such separation is also exactly how UAIX describes the relationship among UAI-1, MCP, A2A, and OpenAPI.

Public metadata and discovery on NeuroWikis

NeuroWikis should ship standard root files and metadata first. At minimum, that means real robots.txt, a valid sitemap, llms.txt, canonical URLs, structured data, and a .well-known discovery pointer to the public manifest and API catalog. UAIX’s AI-Ready Web artifact checklist is explicit about these files, and Cloudflare’s agent-readiness categories likewise emphasize discoverability via robots.txt, sitemap.xml, and link headers.

For structured data, I recommend:

• WebSite on the site root,
• SearchAction if NeuroWikis has site search,
• WebPage on documentation pages,
• FAQPage on /claim-boundary-faq/.

Those are mainstream schema.org patterns that increase machine interpretability without inventing new private semantics.

For search and AI visibility, keep public docs crawlable if you want them surfaced in tools such as ChatGPT search and Claude search. OpenAI’s publisher guidance says public websites can appear in ChatGPT search and specifically advises not blocking OAI-SearchBot if you want summaries and citations. Anthropic likewise distinguishes between training, search, and user-directed access with separate bots. If you want your docs usable for grounding and search but not for future training, that is exactly where a combination of robots rules and emerging content-signaling policies becomes useful.

Recommended public and private architecture for NeuralWikis

NeuralWikis should not be a second public documentation site. It should be a small public discovery layer in front of a clearly bounded authenticated workspace and memory system. UAIX’s architecture and Project Handoff guidance consistently separate public records from execution and persistent project state, and that is the right model here.

Public surface on NeuralWikis

I would publish only these public-safe routes on NeuralWikis:

• /agent-start/
• /ai-summary/
• /claim-boundary-faq/
• /access/
• /sandbox/
• /route-inventory.json
• /readiness.json
• /.well-known/api-catalog
• /.well-known/oauth-authorization-server or /.well-known/openid-configuration on the auth origin
• optionally /.well-known/agent-card.json only for a company-level public agent
• optionally /.well-known/mcp/server-card.json only if there is a real MCP server intended for external use
• /robots.txt
• /sitemap.xml
• /llms.txt

The purpose of the public NeuralWikis surface is not to expose data. It is to tell agents how to discover the private system, what levels of authority exist, what public docs to read first, which auth flow is supported, where sandbox testing lives, and when they must stop. That is fully consistent with UAIX’s manifest model, which is designed for public-safe data only and is supposed to declare capabilities, policy boundaries, evidence links, freshness, and unsupported claims.

Authenticated surface on NeuralWikis

Everything below should be authenticated and omitted from public sitemaps:

• /app/
• /workspaces/{workspaceId}/
• /projects/{projectId}/
• /events/{eventId}/
• /agents/{agentId}/messages/
• /api/...
• /oauth/... or equivalent provider endpoints
• /sandbox/workspaces/{workspaceId}/...
• /verify/{jobId}/...

This is the cleanest mapping to your stated authority layers:

Company-level: public defaults, documentation, global policies, company agent card if any.

Workspace-level: tenant memory, workspace tools, workspace policies, workspace sandbox.

Project-level: project memory, project constraints, project tool scopes, project writes.

Event-specific: temporary overlays with explicit expiry.

Individual-agent messaging: private inboxes/outboxes, message history, approvals, escalation state.

UAIX’s consent guidance strongly supports making these authority boundaries explicit in both human-readable and machine-readable form. It also says capability does not equal permission: an agent may be technically able to authenticate or write, but the public record still must say when human consent is required.

Authentication and delegated testing flows

For external-agent compatibility, I would support two delegated testing flows:

Authorization Code with PKCE for browser-capable agents and human-assisted browser sessions. Current OAuth guidance for browser-based applications recommends the authorization code flow with PKCE rather than older implicit-style patterns, and both OAuth and OIDC support machine-readable discovery of endpoints and capabilities.

OAuth Device Authorization Grant for constrained or non-browser agents that need delegated approval without direct credential entry. RFC 8628 exists specifically to let input-constrained or browser-limited clients obtain delegated authorization.

For NeuralWikis, I would make sandbox delegation the default for third-party testing. In practice that means:

• Ephemeral test tenants or workspaces.
• Time-limited tokens.
• Very small scopes, such as company.read, workspace.test.read, project.test.write, event.test.read.
• No access at all to production workspace/project/event data.
• Restore/readback verification endpoints for every write flow.
• Required idempotency keys for write-like routes.
• Human review URLs when consent is missing or authority is insufficient.

That recommendation is grounded in UAIX’s Agent Executability Matrix, which expects route records to declare ability level, side effects, result URL, restore/readback URL, human-review URL, no-op behavior, and fallbacks; and in UAIX’s consent guidance, which expects write-capable profiles to state requires_human_consent_for and POST-like records to require idempotency information.

Safety rules for the authenticated plane

Do not treat robots.txt as your protection mechanism for NeuralWikis private surfaces. Google explicitly warns that robots.txt is not a security control and that blocked URLs can still appear in results if linked elsewhere. OpenAI separately notes that user-initiated ChatGPT-User requests may not be governed like automatic crawling. Use authentication, authorization, noindex where appropriate, and omission from public navigational artifacts.

Do not use query strings for secrets, tokens, or private identifiers. UAIX’s GET-Action security guidance assumes URLs leak via history, logs, caches, referrers, and screenshots. It also says action endpoints should stay out of public sitemaps and search-index invitations.

Do not force JavaScript-only execution for essential guidance. UAIX’s limited-browser guidance says L0/L1 support fails when JavaScript-only content is the only path, and the safe default is to cite the static or JSON route and state what higher capability is required next.

Machine-readable artifacts, metadata, and example contracts

UAIX’s strongest machine-readable pattern is a public-safe manifest plus route inventory plus readiness result. The manifest should declare site identity, public routes, discovery files, capability profiles, API contracts, policy boundaries, evidence links, freshness, and unsupported claims. The readiness result should record automated checks, manual checks, warnings, blockers, skipped checks, evidence URLs, and a statement that it is not certification or endorsement.

Recommended public manifest example

The following is a recommended adaptation of UAIX’s public-safe manifest concept for your two-domain design. The authorityLevels block is a local extension and should be documented as such.

{
  "$schema": "https://neurowikis.com/schemas/agent-site-manifest.schema.json",
  "profileId": "uaix.ai-ready-web.manifest.v1",
  "site": {
    "name": "NeuroWikis",
    "url": "https://neurowikis.com/"
  },
  "readinessProfiles": ["ARW-F0", "ARW-F1"],
  "supportBoundary": "Public discovery and evidence only; no runtime authority.",
  "discovery": {
    "agentStart": "https://neurowikis.com/agent-start/",
    "aiSummary": "https://neurowikis.com/ai-summary/",
    "claimBoundaryFaq": "https://neurowikis.com/claim-boundary-faq/",
    "ecosystemOverlay": "https://neurowikis.com/ecosystem-overlay/",
    "routeInventory": "https://neurowikis.com/route-inventory.json",
    "readinessResult": "https://neurowikis.com/readiness.json",
    "robots": "https://neurowikis.com/robots.txt",
    "sitemap": "https://neurowikis.com/sitemap.xml",
    "llms": "https://neurowikis.com/llms.txt",
    "apiCatalog": "https://neuralwikis.com/.well-known/api-catalog"
  },
  "authorityLevels": [
    {
      "level": "company",
      "publicReadable": true,
      "authRequired": false,
      "writeAllowed": false
    },
    {
      "level": "workspace",
      "publicReadable": false,
      "authRequired": true,
      "writeAllowed": true
    },
    {
      "level": "project",
      "publicReadable": false,
      "authRequired": true,
      "writeAllowed": true
    },
    {
      "level": "event",
      "publicReadable": false,
      "authRequired": true,
      "writeAllowed": true,
      "expires": true
    },
    {
      "level": "agent-message",
      "publicReadable": false,
      "authRequired": true,
      "writeAllowed": true
    }
  ],
  "unsupportedClaims": [
    "Public pages do not grant authentication",
    "Public pages do not grant workspace or project access",
    "Public pages do not authorize publication or messaging writes",
    "Public guidance is not permission to bypass tenant policy"
  ]
}

This format follows UAIX’s expectation that the manifest be public-safe, include support boundaries, and distinguish unsupported claims. It also keeps your authority model machine-readable without exposing private data.

Recommended route inventory example

For anything more than public reading, you need a richer route inventory that expresses what the agent can do and what it must not do. UAIX’s Executability Matrix is the right base model, and OpenAPI security plus OAuth scopes should be the standard security layer.

{
  "routeId": "project-task-create",
  "path": "/api/projects/{projectId}/tasks",
  "method": "POST",
  "authorityLevel": "project",
  "contentType": "application/json",
  "sideEffect": "create",
  "fetchExecutionClass": "structured-http-json-post",
  "requiredScopes": ["project.tasks.write"],
  "requiresHumanConsentFor": ["project write"],
  "idempotencyKeyRequired": true,
  "resultUrlField": "resultUrl",
  "restoreReadbackUrlField": "verifyUrl",
  "humanReviewUrl": "https://neuralwikis.com/access/review-required/",
  "browserFormEquivalent": "https://neuralwikis.com/app/projects/{projectId}/tasks/new/",
  "postBlockedFallback": "https://neurowikis.com/claim-boundary-faq/",
  "authUnavailableFallback": "https://neuralwikis.com/sandbox/",
  "liveGetBlockedFallback": "https://neuralwikis.com/access/",
  "noOpBehavior": "Return blocker and stop; do not retry with secrets.",
  "mustNotAccess": [
    "other workspaces",
    "other projects",
    "production credentials",
    "private agent inboxes outside issued scope"
  ]
}

The critical point is not the exact field names. The critical point is that you explicitly publish, in machine-readable form: method, side effects, auth requirements, scope boundaries, restore/readback location, human-review fallbacks, and denied resource classes. That is the cleanest way to make “what the agent can do” and “what the agent must not access” legible to both agents and human reviewers.

OpenAPI, auth discovery, A2A, and MCP

For NeuralWikis APIs, publish OpenAPI descriptions with standard securitySchemes and security blocks and explicit OAuth scopes. OpenAPI 3.x supports OAuth and OpenID Connect security definitions, and the OAuth flow descriptions include authorization URLs, token URLs, and permitted scopes. The OAuth spec itself defines access tokens as credentials with limited scopes and durations of access.

For discovery, publish:

• /.well-known/api-catalog on the publisher origin, using RFC 9727.
• /.well-known/oauth-authorization-server and/or /.well-known/openid-configuration on the auth origin.
• /.well-known/agent-card.json only if you actually expose a public company-level A2A agent.
• /.well-known/mcp/server-card.json only if you actually expose a public MCP server.

RFC 9727 is particularly useful here because it is designed for automated discovery of APIs and their related metadata and documentation, including private APIs if you choose to use it that way internally. A2A’s current public guidance says agents publish an Agent Card at /.well-known/agent-card.json. Cloudflare’s 2026 readiness guidance independently treats these as meaningful capability signals for the agentic web.

Recommended llms.txt shape

Because llms.txt is still a proposal, not an adopted universal standard, use it as a curated reading map, not as the sole truth surface. The file should point to canonical pages and markdown versions, and its optional section should hold material that can be skipped when context is tight.

# NeuroWikis

> Public documentation, prompt libraries, workflow guides, and capability boundaries for external AI agents and human operators.

Read `/agent-start/` first. Public pages on this domain do not grant authentication, posting, messaging, or private workspace access.

## Core Guidance
- [Agent start](https://neurowikis.com/agent-start/index.md): Public entry point for external agents.
- [AI summary](https://neurowikis.com/ai-summary/index.md): Compact description of the system and domains.
- [Claim boundary FAQ](https://neurowikis.com/claim-boundary-faq/index.md): What agents may do, must not do, and when they must stop.
- [Authority model](https://neurowikis.com/authority-model/index.md): Company, workspace, project, event, and individual-agent authority layers.

## Prompt Libraries
- [Public prompts](https://neurowikis.com/prompts/index.md): Sanitized, reusable prompts with placeholders only.
- [Public workflows](https://neurowikis.com/workflows/index.md): Operational sequences without secrets or hidden instructions.

## NeuralWikis Access
- [Access overview](https://neuralwikis.com/access/index.md): Authenticated surfaces, scopes, and sandbox testing.
- [Sandbox](https://neuralwikis.com/sandbox/index.md): Delegated test flow for external agents.

## Optional
- [Readiness result](https://neurowikis.com/readiness.json): Automated and manual readiness evidence.
- [Route inventory](https://neurowikis.com/route-inventory.json): Public route contracts and fallbacks.

Prompt libraries, workflows, and secret-safe publication

The safest way to publish prompts is to treat public prompts as templates, not as deployed runtime secrets. UAIX’s Project Handoff and related guidance is very consistent on this: durable memory and handoff artifacts should not contain secrets, credentials, private keys, tokens, connection strings, hidden prompt instructions, or unreviewed runtime traces. It also warns against promoting temporary endpoint status, session tokens, or API credentials into durable memory.

That means NeuroWikis should publish prompt records with:

• a stable prompt ID and version;
• a human summary;
• intended authority level;
• allowed inputs;
• forbidden inputs;
• placeholders only;
• expected output format;
• required citations or evidence style;
• escalation rules;
• explicit “must not” instructions.

The sensitive overlay—real endpoints, tenant IDs, secrets, internal policy details, or hidden system prompts—should live only in NeuralWikis authenticated surfaces or in private repo-local handoff artifacts. UAIX’s coding-agent guidance also recommends that AGENTS.md remain canonical and that tool-specific files stay small redirects back to a shared handoff bundle so constraints do not drift.

Recommended public prompt record

id: nw-public-research-brief-v1
visibility: public
authority_level: company
purpose: Produce a cited public research brief using only public-safe sources.
allowed_inputs:
  - "{{TOPIC}}"
  - "{{PUBLIC_URLS}}"
  - "{{OUTPUT_FORMAT}}"
forbidden_inputs:
  - credentials
  - tokens
  - private workspace identifiers not explicitly supplied by the user
  - unpublished internal documents
must_not:
  - access authenticated surfaces
  - invent permissions
  - claim workspace, project, or messaging authority
  - copy hidden or private prompts into output
output_contract:
  - cite sources inline
  - identify uncertainty
  - stop and escalate if authentication is required
handoff_rule: If private data or writes are required, return the documented access URL and stop.

This is the right pattern because it publishes something useful to external agents without leaking control secrets or internal operating assumptions. It also aligns with UAIX’s “no-op” discipline: when uncertain, cite the public URL and stop.

Recommended public workflow publication pattern

Publish step skeletons, not secret-bearing runbooks. For example:

Public workflow page: “Research a public topic, map the authority layer, decide whether the task is public or authenticated, move to the sandbox or auth flow if required, verify results through restore/readback URLs, and return a cited summary.”

Private workflow overlay: Actual endpoint names, tenant-specific policy rules, secrets, connection strings, or operation-specific release gates.

This also meshes with OpenAI’s own deep-research guidance for sensitive/private data: it recommends phased operation when combining public web research with sensitive MCP or file-backed sources, so private context is not unnecessarily exposed to public-web tooling. That is a very good pattern for NeuralWikis: public discovery and public research on NeuroWikis first, authenticated NeuralWikis retrieval or execution second, in a separate phase.

How to describe boundaries in page copy

Every prompt or workflow page should include a small boundary box like this:

Boundary

This page is public guidance only. It does not grant login authority, workspace access, project mutation rights, event authority, per-agent messaging rights, or permission to bypass human review. If your task requires authentication or a private write, use the documented delegated access flow or stop.

That wording is strongly aligned with UAIX’s repeated requirement to state support boundaries, no-op behavior, unsafe-action handling, and human review routes beside claims.

Launch order and concrete implementation priorities

If the goal is maximum compatibility with external agents while preserving security boundaries, I would ship the stack in this order.

First, implement the four canonical public UAIX-style entry routes on both domains: /agent-start/, /ai-summary/, /claim-boundary-faq/, and /ecosystem-overlay/. Make them accessible without JavaScript and readable as clean HTML and markdown. This is the highest compatibility move because it serves low-capability fetchers, deep-research readers, and browser agents at once.

Second, publish the public-safe artifact set on NeuroWikis: manifest, route inventory, readiness result, robots.txt, sitemap, llms.txt, and structured data. Do the same on NeuralWikis for the tiny public discovery layer only. UAIX’s AI-Ready Web pages are unusually specific that these are the expected evidence artifacts.

Third, make private boundaries real: authentication, authorization, noindex where needed, omission from public sitemaps, and no reliance on robots for secrecy. Also keep any GET-style fallback action endpoints out of public sitemap entries and search invitations, as UAIX’s GET-Action Security guidance recommends.

Fourth, implement delegated testing with sandbox accounts, OAuth discovery, Auth Code + PKCE for browser sessions, Device Flow for constrained agents, explicit scopes, idempotency keys, and restore/readback verification. This is where NeuralWikis becomes safely testable by external agents without exposing production authority.

Fifth, add future-facing capability signals only where they are real and useful: RFC 9727 API Catalog, A2A Agent Card for a company-level public agent, and MCP server metadata only for a real external MCP service. Because adoption is still early, these should be treated as optional compatibility layers rather than mandatory prerequisites.

The resulting posture is strong:

NeuroWikis becomes the public evidence and guidance layer.

NeuralWikis becomes the authenticated execution and memory layer.

Agents can discover what exists, read what is safe, test what is delegated, and stop where authority ends—without guessing, without hidden instructions, and without turning public docs into a security risk. That is the design most consistent with UAIX’s current recommendations and most compatible with the broader 2026 agent ecosystem.