Skip to content
Universal Manifest

External Agent Onboarding

This page is the canonical human-readable onboarding path for external agents and for humans configuring agents to work with Universal Manifest.

Use it when you need to seed an agent correctly, reduce hallucinated claims, or route an agent through the right surfaces without making it reverse-engineer the site.

What To Treat As Authoritative

Section titled “What To Treat As Authoritative”

Use these surfaces in order of authority:

  1. Versioned artifacts under /ns/universal-manifest/ for canonical schemas and JSON-LD contexts.
  2. Discovery files at /.well-known/universal-manifest.json and /llms.txt for route ownership, entry order, and public interaction posture.
  3. Standards documentation on universalmanifest.net for human-readable contract explanations, implementation guidance, and changelog context.
  4. Runtime contract documents on myum.net for UMID resolution behavior, resolver metadata, and OpenAPI.
  5. Browser-visible proof surfaces like Sandbox, Harness, Workbench, and Resolver UI for exploration and verification, not for discovering hidden capabilities.

If two sources appear to disagree, prefer the most contract-like source first: versioned artifacts, then machine-readable descriptors, then reference docs, then browser tooling.

Host Split

Section titled “Host Split”
  • universalmanifest.net is the landing, standards, discovery, tooling, and artifact host.
  • myum.net is the read-only runtime resolver host.
  • Do not collapse these into one implied service. The standards host explains the contract. The runtime host performs UMID resolution.
Section titled “Recommended Read Order By Intent”

Understand the project quickly

Section titled “Understand the project quickly”
  1. Landing page
  2. For Agents
  3. Agent Briefing
  4. Why Universal Manifest?

Implement or evaluate the contract

Section titled “Implement or evaluate the contract”
  1. /.well-known/universal-manifest.json
  2. Build Your Own Implementation
  3. Specification v0.1
  4. Conformance
  5. /agent/fixture-catalog.json
  6. Verification Harness

Verify runtime behavior

Section titled “Verify runtime behavior”
  1. https://myum.net/.well-known/myum-resolver.json
  2. https://myum.net/openapi.json
  3. Resolver API
  4. Resolver UI

Explore examples and proof surfaces

Section titled “Explore examples and proof surfaces”
  1. /agent/sandbox-scenarios.json
  2. Sandbox
  3. Workbench
  4. Proof Journeys

How To Seed An Agent In The Wild

Section titled “How To Seed An Agent In The Wild”

When introducing Universal Manifest to an external agent, provide a minimal seed packet instead of a loose product description.

The packet should include:

  • The project description: portable JSON-LD document format for identity, credentials, preferences, pointers, and consent between systems.
  • The host split: universalmanifest.net for standards/discovery/tooling and myum.net for read-only runtime resolution.
  • The current version posture: v0.1 stable, v0.2 draft adding the Ed25519 signature profile.
  • The canonical start URLs:
  • The non-support statement: these hosts do not currently expose a public A2A task lifecycle, public write API, or public MCP server.

This is enough for an external agent to start from real contracts instead of guessing.

Safe Default Workflow

Section titled “Safe Default Workflow”

If an agent has not been given a more specific job, it should default to this posture:

  1. Discover from /.well-known/universal-manifest.json.
  2. Confirm the route order in /llms.txt.
  3. Read the Agent Briefing for positioning and vocabulary.
  4. Read only the documentation needed for the current task.
  5. Use catalogs for fixtures and sandbox scenarios instead of scraping browser code.
  6. Check the Changelog before making capability claims.
  7. Treat unsupported or future-facing surfaces as unavailable unless explicitly documented otherwise.

Do Not Do These Things

Section titled “Do Not Do These Things”
  • Do not claim that universalmanifest.net or myum.net provides a public agent task API.
  • Do not describe the browser tools as the normative contract.
  • Do not call v0.2 stable.
  • Do not assume every example on the site represents a general recommendation.
  • Do not invent authority for undocumented endpoints, routes, or artifacts.

What Good Onboarding Looks Like

Section titled “What Good Onboarding Looks Like”

An external agent is correctly onboarded when it can do all of the following without correction:

  • distinguish the standards host from the runtime host
  • name the correct authoritative sources for a task
  • cite v0.1 as stable and v0.2 as draft
  • find fixtures and sandbox scenarios from catalogs instead of scraping bundles
  • avoid claiming unsupported public interaction modes

If it cannot do those five things, the onboarding is incomplete.