1. Executive Summary
The Agentic Readiness Index (ARI) is a benchmarking framework for evaluating the degree to which media and entertainment technology platforms are operable by autonomous software systems.
ARI does not measure whether a company has AI features.
ARI measures whether autonomous coding agents and operational agents can discover, authenticate, configure, orchestrate, monitor, govern, and economically interact with a platform through machine-operable interfaces under realistic enterprise governance constraints.
ARI is therefore an operational infrastructure benchmark, not an AI feature benchmark.
The primary audience includes:
- media technology buyers
- vendors
- product leaders
- infrastructure teams
- ecosystem partners
- analysts
- investors
- agentic workflow builders
2. Core Thesis
The next generation of enterprise software competition may increasingly depend on which platforms are most operable by autonomous systems.
Traditional enterprise software was designed around:
- human operators
- graphical user interfaces
- manual configuration
- implementation specialists
- professional services teams
- seat-based usage patterns
ARI assumes that future-ready infrastructure increasingly supports:
- machine-operable workflows
- autonomous provisioning
- programmatic governance
- software-to-software execution
- agent-mediated orchestration
- governed machine access
- usage-based or transactional economic models
The framework measures:
autonomous operability under realistic enterprise governance conditions.
3. What ARI Measures
ARI measures:
- agent-accessible documentation
- machine execution surfaces
- CLI/MCP/equivalent agent surfaces
- execution surface completeness
- autonomous provisioning capability
- governed operational accessibility
- workflow composability
- operational observability
- machine-operable governance
- commercial alignment with autonomous consumption
ARI does not measure:
- overall product quality
- customer satisfaction
- market share
- feature breadth
- generic AI sophistication
- AI marketing
- embedded copilots
- chatbot functionality
A company may have sophisticated AI features and still score poorly if its platform is not operable by autonomous systems.
A company may have little AI branding and score highly if it exposes strong machine-operable infrastructure.
4. Foundational Assessment Question
Every ARI assessment is governed by one question:
Could a modern autonomous coding agent independently implement and operate this platform using available machine interfaces and operational documentation with minimal human UI dependency?
This question governs scoring, evidence collection, and recommendations.
5. Public Discoverability vs Governed Operability
ARI does not assume that all operational interfaces should be fully public.
Enterprise systems, especially in media and entertainment, may have valid reasons to restrict access:
- rights complexity
- security concerns
- premium content protection
- financial workflows
- compliance requirements
- partner ecosystem boundaries
ARI distinguishes between:
| Concept | Meaning |
|---|---|
| Public Agent Discoverability | Can autonomous systems discover and understand operational capabilities? |
| Governed Agent Operability | Can autonomous systems operate the platform within controlled enterprise boundaries? |
A platform may score highly without unrestricted public exposure if it supports governed autonomous operation.
However, systems that depend on undocumented workflows, human-only onboarding, UI-only administration, or professional-services mediation should score lower.
6. Evidence Accessibility Tiers
ARI recognizes four evidence/access tiers.
| Tier | Description |
|---|---|
| E1 | Fully public anonymous access |
| E2 | Authenticated developer access |
| E3 | Partner or ecosystem access |
| E4 | Brokered or governed operational access |
Governed access is not inherently penalized.
Opaque access is penalized when it prevents reproducible assessment or autonomous operation.
7. Multi-Model Assessment Model
ARI assessments should be performed by multiple independent LLM evaluators.
Recommended evaluators:
- ChatGPT
- Gemini
- Claude
Each evaluator receives:
- the same rubric
- the same evidence set
- the same scoring instructions
- the same assessment template
Each evaluator returns:
- category scores
- subcategory scores
- penalties
- evidence notes
- confidence level
- recommendations
- final score
Final ARI score:
A product is assessed by all three evaluators in parallel. At least two of the three must return a valid result for the product to be scored (a single result is treated as insufficient evidence). The final score averages only the evaluators that ran:
ARI Final Score = (sum of participating evaluator scores) / (evaluators that ran)
Each individual signal and penalty is averaged the same way: its credit is the fraction of participating evaluators that detected it, applied to that item's weight. So when two of three evaluators run, an item detected by only one of them contributes half of its weight. This consensus averaging is why the index rewards capabilities the models agree on and damps single-model noise.
Human role:
- define rubric
- define weights
- review anomalies
- improve methodology
- manage evidence quality
Humans are prevented from overriding scores directly.
8. Scores and Classifications
ARI should publish both numeric scores and classifications.
Numeric scores preserve precision and enable trend tracking.
Classifications improve legibility and sharing. The score-range → classification band table is published on the methodology page, driven by the active rubric.
| Score range | Classification |
|---|---|
| 95–100 | Agent-Native Infrastructure |
| 90–94 | Agent-Native Infrastructure |
| 80–89 | Agent-Operable Platform |
| 65–79 | Automation-Capable |
| 50–64 | Human-Workflow Transitional |
| 35–49 | Human-Dependent Infrastructure |
| 20–34 | Pre-Operational |
| 0–19 | Human-Operated Legacy |
9. ARI Scoring Framework
Total score: 100
Category 1 — Agent-Accessible Documentation
Objective: Can an autonomous agent learn how to operate the platform from available documentation?
| Signal | Rationale |
|---|---|
| API documentation | Establishes machine-accessible operational surface |
| OpenAPI / Swagger / machine-readable schemas | Enables machine parsing and tooling |
| Executable implementation examples | Helps agents implement correctly |
| CLI documentation | Indicates non-UI operational design |
| MCP or equivalent agent protocol documentation | Indicates explicit agent-oriented access |
| Authentication flow documentation | Enables autonomous identity and access setup |
| Infrastructure-as-code examples | Enables repeatable deployment |
| Workflow orchestration examples | Demonstrates composability |
| Troubleshooting and recovery guidance | Helps agents recover from failure |
Penalties:
| Condition |
|---|
| Sales-gated technical documentation |
| Static/manual-style docs without executable guidance |
| Missing auth documentation |
| Documentation materially incomplete or stale |
Category 2 — Machine Execution Surfaces
Objective: Can autonomous systems execute operational tasks programmatically?
| Signal | Rationale |
|---|---|
| Mature operational APIs | Core execution surface |
| Official SDKs | Supports implementation |
| Webhooks/eventing | Supports event-driven workflows |
| Async job support | Supports scalable operations |
| Retry/idempotency semantics | Supports safe autonomous execution |
| Workflow APIs | Enables orchestration |
| Declarative orchestration | Enables machine-composable workflows |
| CLI execution capability | Indicates machine-first operation |
| MCP or equivalent execution interface | Enables structured agent interaction |
| Operational health/observability surfaces | Supports monitoring and remediation |
Penalties:
| Condition |
|---|
| No CLI or equivalent machine execution surface |
| No MCP or equivalent agent execution interface |
| UI-only execution of core workflows |
| Read-only machine interfaces only |
Category 3 — Execution Surface Completeness
Objective: How completely do CLI/MCP/API/agent surfaces cover the operational lifecycle?
This category addresses sincerity of implementation. A vendor should not receive high agentic-readiness credit for exposing a superficial CLI, toy MCP server, read-only adapter, or narrow wrapper that covers only a small portion of platform functionality.
Lifecycle areas:
| Lifecycle Area |
|---|
| Discover |
| Provision |
| Operate |
| Monitor |
| Recover |
| Govern |
| Deprovision |
Scoring:
| Coverage |
|---|
| 0–10% lifecycle coverage |
| 10–25% lifecycle coverage |
| 25–50% lifecycle coverage |
| 50–70% lifecycle coverage |
| 70–90% lifecycle coverage |
| 90–100% lifecycle coverage |
Rules:
- Do not count endpoints mechanically.
- Assess lifecycle coverage, not command count.
- Read-only coverage is materially weaker than execution authority.
- Admin/governance coverage matters.
- Recovery and observability coverage matter.
- Thin wrappers should receive low scores.
Penalties:
| Condition |
|---|
| CLI exists but covers only trivial/read-only functionality |
| MCP exists but is demo-only or non-operational |
| Machine surfaces omit provisioning entirely |
| Machine surfaces omit recovery/remediation entirely |
| Machine surfaces omit governance/admin entirely |
Category 4 — Autonomous Provisioning and Configuration
Objective: Can autonomous systems provision, configure, and administer the platform without significant human mediation?
| Signal | Rationale |
|---|---|
| Self-service provisioning | Enables autonomous onboarding |
| Usage-based onboarding | Aligns with elastic operation |
| API-key or token-based auth | Enables machine identity |
| OAuth/service principals | Enables governed enterprise automation |
| Infrastructure-as-code support | Enables reproducible deployment |
| Configuration-as-code support | Enables versioned configuration |
| Machine-operable administration | Reduces UI dependency |
Penalties:
| Condition |
|---|
| Human onboarding required for operational access |
| UI-required provisioning |
| Mandatory professional services for implementation |
Category 5 — Commercial Agentic Alignment
Objective: Can autonomous systems economically transact with the platform?
| Signal | Rationale |
|---|---|
| Usage-based pricing | Aligns with machine consumption |
| API monetization model | Indicates machine-oriented business model |
| Transactional economics | Supports autonomous operations |
| Elastic scaling | Supports variable agent workloads |
| Public pricing transparency | Improves discoverability |
| Autonomous payment/provisioning | Enables self-operating workflows |
Penalties:
| Condition |
|---|
| Pure seat-based licensing |
| Enterprise-sales-gated operational access |
| Mandatory professional services dependency |
Category 6 — Governance and Operational Trust
Objective: Can enterprises safely delegate operational authority to autonomous systems?
| Signal | Rationale |
|---|---|
| Service account support | Enables controlled machine identity |
| Auditability | Enables traceability |
| RBAC controls | Enables scoped permissions |
| Policy enforcement | Enables governed operation |
| Rights/security boundaries | Critical in media environments |
| Approval layers | Supports controlled autonomy |
| Operational observability | Supports governance and monitoring |