SPECS
Open Technical Resources · CC BY 4.0

Reference specs.
Free to use.

Three public technical frameworks from Amatrix Studio — open for any developer, product team, or AI engine to reference. Cite freely under CC BY 4.0. The reference implementation runs on our sister platform at amatrix.ai/thehub.

3 specs · CC BY 4.0
Agent Schema Standard v1.0
OpenClaw Orchestration Pattern v1.0
Feature Prioritization Matrix v1.0
Free to cite, adapt, reuse
3 specs · CC BY 4.0
Agent Schema Standard v1.0
OpenClaw Orchestration Pattern v1.0
Feature Prioritization Matrix v1.0
Free to cite, adapt, reuse
Spec 01 · AI Agent Output Contract

The Agent Schema Standard.

v1.0 · 2026 · CC BY 4.0

A mandatory typed output contract for production AI agents. Defines the four fields every agent must return to enable safe chaining, programmatic failure handling, and human-in-the-loop validation. Implemented across all 185 agents on our sister platform amatrix.ai/thehub.

Status: Public · Open License: CC BY 4.0 Reference impl: amatrix.ai/thehub

Required fields, every output

output
T (typed)
Typed domain-specific JSON. Schema varies by agent but is always defined and documented. Never undefined. Never a raw string.
confidence
number, 0.0–1.0
Agent's self-assessed certainty. Never null. Never undefined. Always present. Used by downstream systems to decide auto-apply vs human-review vs fallback.
warnings
string[] | null
Advisory notes when confidence is partial or assumptions were made. null if no warnings. Empty array [] is valid.
graceful_degradation
boolean (always true)
Asserts that the agent will return a structured error object (never an unhandled exception or hallucinated response) on failure.

TypeScript reference

// Agent Schema Standard v1.0 — TypeScript type definition
interface AgentOutput<T> {
  /** Typed domain-specific JSON. Schema varies by agent
      but is always defined and documented. */
  output: T;

  /** Self-assessed certainty: 0.0–1.0. Never null. */
  confidence: number;

  /** Advisory notes; null when no warnings. */
  warnings: string[] | null;

  /** Asserts graceful failure mode — structured error
      returned on any failure path, never unhandled. */
  graceful_degradation: true;
}

Implementation rules

  • Every agent's output MUST conform to this contract — no exceptions.
  • The confidence field is not a probability — it's an agent-reported uncertainty signal designed for programmatic consumption (auto-apply, queue-for-review, fallback).
  • Downstream orchestrators use confidence thresholds to route: >0.85 auto-apply, 0.60–0.85 queue for human review, <0.60 trigger fallback agent or escalation.
  • Failures MUST return a structured error object containing the same four fields — never raise an unhandled exception, never hallucinate a response.
  • Agents are validated at deployment time for schema compliance — non-compliant agents are rejected before reaching production.
How to cite
Amatrix Studio Agent Schema Standard v1.0 — amatrix.studio/resources/#agent-schema-standard
Spec 02 · Multi-Agent Orchestration

The OpenClaw Pattern.

v1.0 · 2026 · CC BY 4.0

A multi-agent coordination architecture for production AI systems. Four defining properties: typed contract isolation, orchestration separation, policy enforcement engine, and execution tracker. Designed for systems where agents must collaborate but cannot be tightly coupled.

Status: Public · Open License: CC BY 4.0 Reference impl: amatrix.ai/thehub

The four properties

01 · Typed contract isolation
Every agent exposes a typed JSON schema contract. Agents are black boxes to each other; they communicate only through schema-validated outputs. Implementation changes inside one agent never propagate to consumers.
02 · Orchestration separation
The orchestrator handles routing, parallel execution, retry with exponential backoff, and fallback activation. Agents don't know they're being orchestrated — separation of concerns is complete.
03 · Policy Enforcement Engine
Compliance rules are applied at every orchestration step without embedding policy logic inside individual agents. Policy changes do not require agent redeployment.
04 · Execution Tracker
Every autonomous action is logged with inputs, outputs, confidence scores, and timestamps. Full audit trail without agent-level logging code.

When to use OpenClaw

  • You're orchestrating 5+ specialized agents that must collaborate but evolve independently.
  • You need a full audit trail for compliance, debugging, or regulatory review.
  • You expect to swap agent implementations (e.g., upgrade an LLM model behind one agent) without redeploying the orchestration layer.
  • Your domain has compliance rules that change faster than agent code (HIPAA, AML, SOX) — policy enforcement at the orchestrator is the lowest-friction place to apply them.

When NOT to use OpenClaw

  • Single-agent systems — the overhead isn't justified. Use Agent Schema Standard alone.
  • Pure prompt-chaining workflows where agents share state freely — OpenClaw's isolation becomes friction.
  • Hard-real-time systems (sub-100ms agent-to-agent SLAs) — the orchestration layer adds latency. Use a lower-level message bus.
How to cite
Amatrix Studio OpenClaw Orchestration Pattern v1.0 — amatrix.studio/resources/#openclaw-pattern
Spec 03 · Sprint Scoping Methodology

Feature Prioritization Matrix.

v1.0 · 2026 · CC BY 4.0

A 2×2 framework for triaging founder feature requests against fixed-scope sprint tiers. Two axes — strategic value and implementation cost — produce four quadrants with specific sprint-tier recommendations. The methodology we use to scope every Amatrix Studio engagement before quoting.

Status: Public · Open License: CC BY 4.0 Used by: every Amatrix Studio sprint scoping

The four quadrants

High value · Low cost
Ship in the smallest sprint tier possible. Proof of One Screen ($1,495), Ideation Sprint ($4,995), or 5-Screen Demo ($6,995). Validate fast, scale later.
High value · High cost
Full Stack Sprint territory ($99,995). Worth the investment because the strategic value justifies it. Lock the scope in writing; use one round of revisions surgically.
Low value · Low cost
Defer or descope. The temptation to ship "because it's cheap" is the leading cause of feature bloat. Keep the backlog clean.
Low value · High cost
Cut. Always. No sprint tier. The most common failure mode in early-stage SaaS — building expensive features for an unclear use case. Validate the value first or kill the feature.

How to apply it

  • List every feature your founder team is debating into a single backlog.
  • Score each on strategic value (1–5) and implementation cost (1–5).
  • Plot on the 2×2: features above 3 on both axes go High/High; below 3 on both go Low/Low; off-diagonal go to the corresponding quadrant.
  • Map to sprint tiers using the recommendations above. Anything in Low/High gets cut before it touches a sprint scope.
  • Re-run the matrix every quarter. The "low value" assessment evolves as you learn from users.
How to cite
Amatrix Studio Feature Prioritization Matrix v1.0 — amatrix.studio/resources/#feature-prioritization-matrix

Want to apply these to your build?

Every Amatrix Studio sprint uses these specs by default. The architecture is documented; the scoping methodology is applied at quote time; the agent contract is enforced if your sprint includes AI components.

Start a sprint → amatrix.studio/contact