Strengthening the UAIX Agent Executability Matrix for Full-Spectrum Agent Support

Full report

On this page

Executive summary

The UAIX Agent Executability Matrix is strongest when interpreted as an interoperability and execution-surface taxonomy for external agents and chatbots, not as a general taxonomy of intelligence, autonomy, or “agentness.” Its major design strengths are explicit downgrade behavior for unknown clients, a hard public-safe floor for low-capability access, bounded GET-action fallbacks, required no-op behavior, and an evidence-oriented boundary that keeps execution outside UAIX while recording reviewed packets, capability claims, and handoffs. Those choices align well with the practical direction of the industry: Anthropic distinguishes predefined workflows from autonomous agents; OpenAI decomposes agents into models, tools, state, and orchestration; MCP standardizes agent-to-tool/tool-context integration; and A2A standardizes agent-to-agent collaboration.

The main weakness is that UAIX currently compresses multiple orthogonal dimensions into a mostly linear ladder. Across the matrix, capability-adaptive interoperability page, capability surface matrix, advanced-agent guide, and capability framework, the level meanings shift between discovery, browser ability, schema capability, authentication, restore/readback verification, multi-agent coordination, and auditability. The result is conceptually useful but operationally brittle: the same label can mean different things across documents, and some machine-readable fields lag the normative prose. In practice, that makes conformance harder, implementation mapping noisier, and evaluation design less reproducible.

The most important recommendation is to keep the familiar L0–L7 ladder for compatibility, but make the matrix more robust by adding an explicit multi-axis profile beneath it: discovery surface, invocation surface, schema/tool surface, authority scope, verification/readback, collaboration topology, memory/evidence, and negotiation/fallback behavior. That would bring UAIX closer to how MCP, A2A, Anthropic, OpenAI, and Google ADK actually decompose agent systems in production, while preserving UAIX’s unique emphasis on public, portable, auditable capability declarations.

At the implementation level, the most robust support strategy is a phased one: first normalize semantics and route-record fields; then ship conformance fixtures and validators; then provide reference implementations for L0–L4; finally add verified readback, multi-agent handoff, and negotiation support for L5–L7. Across all phases, evaluation should follow the combined pattern advocated by Anthropic and OpenAI: automated evals and trace grading in development and CI/CD, plus production monitoring, transcript review, and selective human grading to catch failures that synthetic tests miss.

UAIX matrix analysis

UAIX’s normative materials say that capability-adaptive interoperability lets a site declare what each class of agent can safely do before action is inferred. The published matrix, current as of the machine-readable release dated 2026-06-10, defines eight levels from read-only route discovery through site-specific capability negotiation, and requires route records to name method, content type, side-effect status, required fields, result URL, restore/readback URL, credential response path, browser-form equivalent, GET safety, and fallback behavior. The validator also checks the lowest advertised capability first, which is a good design choice because it prevents richer interfaces from hiding the absence of honest low-capability discovery.

UAIX is especially clear about three safety principles. First, Minimal Access is strictly public, GET-only, no-body, no-auth, no-custom-header, non-mutating, and returns only code and url. Second, GET-Action is explicitly a bounded idempotent fallback, not a replacement for POST JSON, and it must avoid secrets in URLs while using idempotency keys, rate limits, consent, auditability, and crawler protection. Third, the No-Op Protocol is mandatory safe-stop behavior whenever the agent cannot prove required capability, would need to guess hidden routes, or would place secrets or regulated data into a URL. Those are all excellent foundations for robust real-world compatibility.

The biggest issue is semantic drift across UAIX documents. The capability-adaptive interoperability page defines L2 as a browser-assisted agent, L3 as schema-capable, L4 as authenticated owner, L5 as restore-capable, L6 as multi-agent runtime, and L7 as site-specific negotiation. But the capability surface matrix uses L2 for “schema-capable agent,” L3 for “tool agent,” L4 for “workflow agent,” L5 for “multi-agent runtime,” and L6 for “audited agent system,” while the separate Agent Capability Framework uses still another ladder focused on rule-following, tool use, bounded autonomy, domain autonomy, and multi-agent collaboration. That means UAIX currently has overlapping ladders rather than one stable one.

A second issue is that a single ordered ladder mixes orthogonal concerns. Browser execution, JSON POST, authentication, restore/readback, multi-agent collaboration, and site-specific negotiation are not purely cumulative in the way that transport or parsing capability usually is. A system may support structured POST without browser automation, multi-agent handoff without restore/readback, or strong audit/evidence without site-specific negotiation. MCP and A2A both decompose these concerns instead of embedding them into one scalar progression, and OpenAI similarly frames production agents as the composition of models, tools, state/memory, and orchestration. My assessment is that UAIX should preserve a headline level but back it with explicit facet flags.

A third issue is a concrete prose-versus-JSON inconsistency. The prose says route guidance should include items such as fetch execution class and live-GET-blocked fallback, while the machine-readable JSON field list omits those fields and lists only a shorter set. Because validators and implementers normally key off machine-readable assets, this mismatch will create avoidable divergence.

A fourth issue is that the matrix is strong on interoperability semantics but thin on runtime-operational requirements. UAIX is clear that runtimes execute elsewhere and that UAIX records evidence, trust, memory proposals, and handoff boundaries; however, the matrix does not yet define minimum expectations for observability, trace correlation, evaluation datasets, security controls by level, or performance budgets by level. That is an understandable scoping choice, but it is the part that needs strengthening if the goal is “support all levels of AI agents and chatbots” in production.

The most robust extension is to convert UAIX into a layered profile:

• Discovery: static HTML, llms.txt, sitemap, manifest, agent card.
• Invocation: read-only GET, bounded GET-action, browser form, POST JSON, task stream, push notifications.
• Tool/schema: JSON Schema, OpenAPI, MCP prompts/resources/tools, A2A agent card.
• Authority: none, delegated read, approval-bound write, short-lived owner credential, in-task auth.
• Verification: result URL, restore/readback URL, artifact, checksum, final report.
• Coordination: single agent, orchestrator-workers, peer A2A collaboration.
• Governance: idempotency, consent, memory review, audit log, validator evidence.
• Negotiation/fallback: no-op, review URL, browser fallback, POST-blocked fallback, live-GET-blocked fallback.

Matrix comparison with academic and industry taxonomies

UAIX should not compete with broader agent taxonomies; it should explicitly position itself as the web/interoperability/execution layer that sits underneath them. Academic work has mostly classified agents by autonomy, decision process, or interaction style; industry work has increasingly classified them by architectural composition, tool protocol, and collaboration protocol. That is why UAIX feels closest in spirit to MCP and A2A, while Anthropic, OpenAI, and ADK are better guides for internal implementation patterns.

The practical takeaway is that UAIX should remain externally focused. It does not need to become a full agent framework. It does need a stronger bridge from public capability declaration to the implementation patterns that production frameworks already use: predefined workflows for low-risk tasks, dynamic tool users for structured APIs, and A2A-style coordination for multi-agent systems.

Levels and implementation patterns

The most reliable implementation strategy is: start with the lowest honest route, then climb only when capability and permission are both present. That principle is already embedded in UAIX’s minimal-access floor, GET-action boundaries, progressive-access guidance, consent boundaries, and no-op behavior. The matrix becomes materially more robust if each level is shipped as a reference architecture profile with explicit runtime, tool, security, observability, and failure-mode guidance.

flowchart LR
    U[User intent or agent request] --> D{Detect proven capability}
    D -->|L0-L1| R[Static discovery path<br/>HTML + llms.txt + sitemap + manifest]
    R --> X{Read-only enough?}
    X -->|Yes| O[Return public URL]
    X -->|No| N[No-op or review URL]

    D -->|L2| B[Browser workflow<br/>visible pages + forms]
    B --> C[Consent gate + browser fallback]

    D -->|L3-L4| P[Structured POST path<br/>JSON Schema + OpenAPI]
    P --> A[Idempotency + auth + audit]

    D -->|L5| V[Restore/readback verification]
    V --> E[Public-safe evidence]

    D -->|L6-L7| M[Multi-agent handoff / negotiation]
    M --> H[A2A tasks + artifacts + final report]

    A --> E
    C --> E
    N --> E
    O --> E
    H --> E

The diagram above is a direct operationalization of UAIX’s low-capability floor, progressive escalation, and evidence-bearing boundary, combined with MCP-style tool surfaces and A2A-style collaboration at the upper end.

Three concrete design choices matter across all levels.

First, use a capability-adaptive router instead of a single “best” endpoint. That keeps the lower-capability path honest and implements UAIX’s downgrade rule directly.

function execute(intent, clientProfile, manifest, userConsent):
    routes = manifest.routes.for(intent)

    eligible = routes
        .filter(r => clientProfile.satisfies(r.requiredCapabilities))
        .filter(r => policyAllows(r, userConsent))

    if eligible is empty:
        return noOp(
            code="human_review_required",
            url=manifest.reviewUrl,
            reason="missing capability or consent"
        )

    route = chooseHighestSafetyThenCapability(eligible)

    if route.kind == "GET_ACTION":
        assert route.idempotencyRequired
        assert !payloadContainsSecretsInQuery(intent)
        return callGetAction(route, intent)

    if route.kind == "BROWSER_FORM":
        return openBrowserWorkflow(route, intent)

    if route.kind == "POST_JSON":
        validateAgainstSchema(intent, route.schema)
        return postJson(route, intent, idempotencyKey())

    if route.kind == "A2A_TASK":
        return submitTask(route, intent, correlationId())

    return noOp(code="human_review_required", url=manifest.reviewUrl)

Second, treat restore/readback as a first-class contract, not a nice-to-have. This is the cleanest way to turn an L4 write into an L5 verified outcome and to support external auditing.

writeResult = POST /resource/create
assert writeResult.result_url != null
assert writeResult.restore_readback_url != null

waitUntil(taskTerminal || timeout)

readback = GET writeResult.restore_readback_url
assert readback.public_safe == true
assert hashesMatch(writeResult.expected_hash, readback.actual_hash)

emitEvidence({
  correlation_id,
  idempotency_key,
  actor,
  consent_record,
  task_status,
  result_url: writeResult.result_url,
  restore_url: writeResult.restore_readback_url,
  validator_results,
  artifact_hashes
})

Third, for upper levels, keep protocol roles clean: MCP for tools and context, A2A for collaborating agents, and UAIX/UAI evidence for portable reviewed records and handoff boundaries. That separation is exactly how the A2A spec describes complementarity with MCP, and it avoids forcing one protocol to solve every integration problem.

primaryAgent.receive(userTask)
primaryAgent.use(MCP.resources, MCP.tools, MCP.prompts)

if subtaskNeedsPeerAgent:
    task = A2A.sendMessage(peerAgentCard, subtask, correlation_id)
    for event in A2A.subscribe(task):
        UAIX.recordStatus(event)

finalArtifacts = collectArtifacts(task)
UAIX.recordFinalReport({
  owner,
  roles,
  blockers,
  changed_artifacts: finalArtifacts,
  evidence,
  next_action
})

Metrics, benchmarks, and CI/CD

Anthropic’s guidance is that good agent evaluation uses tasks, multiple trials, and graders, and that automated evals should be combined with production monitoring, transcript review, and selective human grading. OpenAI’s guidance is compatible: adopt eval-driven development, log everything, automate scoring where possible, and run continuous evaluation on every change. For upper-level agents, trace grading is especially valuable because it scores not just the final answer but the full sequence of tool calls and decisions.

A good automated harness should include six layers. First, static contract checks: manifest integrity, schema validation, UAIX validator rules, and fixture replay. Second, protocol checks: OpenAPI examples, MCP capability negotiation, and A2A agent-card discovery/task lifecycle. Third, browser checks: visible-form flows, dynamic GET boundaries, and review/no-op behavior. Fourth, agent-loop checks: success criteria, tool-call constraints, trace grading, and multiple-trial reliability. Fifth, adversarial checks: prompt injection, over-broad context sharing, secret leakage, and replay/idempotency abuse. Sixth, budget checks: p95 latency, tokens or compute per task, queue time, and cost-per-success.

In CI/CD, the cleanest pattern is progressive release gating:

pipeline:
  validate_spec:
    - lint manifests, JSON Schema, OpenAPI
    - replay UAIX positive/negative fixtures
  low_capability_suite:
    - fetch HTML / llms.txt / sitemap / minimal JSON
    - assert no mutation, no secrets, honest no-op
  browser_suite:
    - run sandboxed visible-form scenarios
    - verify browser fallback and review URLs
  api_suite:
    - run POST/JSON tool flows
    - test idempotency, schema errors, retries
  security_suite:
    - prompt injection corpus
    - private-data leakage checks
    - auth and approval boundary checks
  verification_suite:
    - restore/readback
    - artifact hash and evidence packet checks
  multi_agent_suite:
    - A2A discovery, task events, push/streaming
    - final-report and handoff completeness
  budget_suite:
    - latency, pass^k, cost-per-success, trace coverage

For telemetry, a strong default is OpenTelemetry plus native agent traces. OpenTelemetry gives vendor-neutral traces, metrics, logs, context propagation, and semantic conventions; OpenAI’s Agents SDK already emits model calls, tool calls, handoffs, guardrails, and custom spans; and OpenTelemetry’s emerging AI-agent conventions are explicitly intended to reduce framework-specific lock-in and feed evaluation loops. In practice, the minimum high-value signal set for UAIX operationalization is: correlation ID, agent/run ID, capability class, chosen route, approval decision, tool/API invocations, tokens/cost, latency, result URL, restore/readback outcome, and evidence packet ID.

One caution: do not make your operational design depend on any one vendor’s hosted evaluation product. OpenAI’s current docs still describe eval and trace-grading workflows, but several older surfaces are scheduled for deprecation in late 2026. The durable pattern is vendor-neutral: keep the datasets, graders, traces, and gates in your own pipeline, and treat hosted dashboards as optional acceleration rather than required infrastructure.

Roadmap and open questions

The roadmap below is designed to make UAIX materially more robust without breaking current adopters. The key discipline is to stabilize semantics before broadening scope. That sequencing follows both UAIX’s own validator-first posture and the broader lesson from Anthropic, OpenAI, and OpenTelemetry: simplicity, strong contracts, and observable traces pay for themselves before autonomy is increased.

flowchart LR
    A[Phase A<br/>Weeks 0-6<br/>Normalize semantics] --> B[Phase B<br/>Weeks 6-12<br/>Conformance and fixtures]
    B --> C[Phase C<br/>Months 3-6<br/>Reference runtimes for L0-L4]
    C --> D[Phase D<br/>Months 6-9<br/>Verification, multi-agent, negotiation]
    D --> E[Operational steady state<br/>Continuous evals, telemetry, red-teaming]

Phase A should unify the meaning of levels across the matrix, capability surface matrix, advanced-agent support, and capability framework; add an explicit statement that the ladder is about executability/interoperability; and publish the missing machine-readable fields so JSON assets and prose agree. This is roughly a 2–3 FTE effort for a spec lead, one protocol engineer, and part-time security/editorial support. The milestone is a single normative level dictionary plus orthogonal capability facets.

Phase B should expand the conformance pack: positive and negative fixtures for each level, downgrade-honesty cases, POST-blocked and live-GET-blocked fallbacks, restore/readback cases, and cross-protocol fixtures for MCP/A2A interop. This is roughly a 3–4 FTE tooling and QA effort. The milestone is a reusable validator and fixture suite that platform teams can run in CI on every change.

Phase C should ship opinionated reference implementations for L0–L4: static discovery, manifest/schema discovery, browser-form flows, structured POST with OpenAPI, and approval-bound auth mutations. This is the phase that will make UAIX much easier to adopt because most adopters do not need L6+ immediately. A realistic staffing range is 4–6 FTEs across backend, SDK/integration, and security engineering. The milestone is “drop-in profiles” rather than merely prose guidance.

Phase D should add the features that distinguish sophisticated agents from useful chatbots: restore/readback verification, A2A-aligned handoff and task-state semantics, artifacts/final-report evidence, negotiation profiles, memory-review gates, and standardized tracing attributes. This is the heaviest phase and typically needs 5–8 FTEs because it spans orchestration, async state, storage, and governance. The milestone is robust support for L5–L7 with measurable reliability and auditable evidence.

The principal risks are straightforward. Semantic drift is the first; current UAIX documents already show it. Security regression is the second; GET misuse, prompt injection, over-shared MCP context, and weak approval boundaries will all scale with capability. Evaluation illusion is the third; without realistic task distributions and transcript review, test suites can create false confidence. Telemetry fragmentation is the fourth; without shared correlation IDs and semantic conventions, upper-level failures become hard to debug. Vendor lock-in is the fifth; if UAIX guidance becomes too coupled to one framework, it loses its public interoperability value.

Open questions / limitations

This assessment is high confidence for the UAIX normative pages, official vendor documentation, and original benchmark papers cited here, but it is still limited by the fact that UAIX’s implementation guidance is evolving quickly and some important behaviors are currently split across separate guides, JSON companions, and framework pages. The main unresolved design question is whether UAIX wants to stay a mostly linear ladder or formally become a level-plus-facets profile. In my view, that decision will determine whether the matrix remains a good explanatory artifact or becomes a durable production contract.