State of the Agentic World 2027: What the Evidence Actually Proves

2027 outlook edition · Evidence cut-off: 2 November 2026 · DN Agent Evidence Map v0.1

The agentic world is becoming easier to describe and harder to compare. A directory listing, a benchmark score, a working local demo and a paid customer outcome can all appear under the same word: “agent.” They answer different questions. Treating them as interchangeable creates weak procurement decisions, unreliable security claims and misleading economics.

This report brings together ten selected Decentralised News research assets. It distinguishes documentation from execution, and planning from observation. The accompanying evidence map lets readers inspect those boundaries directly. It is deliberately small: a traceable starting point is more useful than a large list whose labels imply tests that never happened.

The Signal: Capability Is Becoming Easier to Find Than Proof

Protocols and platforms expose increasingly structured ways to discover and use capabilities. The MCP specification describes a protocol for connecting applications with tools, resources and prompts. The x402 documentation describes payment-related HTTP exchanges. These are important building blocks. Their documented scope does not establish whether an arbitrary deployment is secure, commercially viable or delivering what a buyer intended.

Evaluation projects also define specific environments. WebArena’s project hub links browser-agent evaluation environments, while TheAgentCompany provides a simulated company environment for agent evaluation. A result in a defined environment is valuable precisely because its task, setup and scoring boundaries can be examined. Moving that result into an unrelated financial workflow requires new evidence.

DN interpretation: the next content opportunity is to explain the missing links between those layers. Which capability was advertised? Which identity supplied it? Which policy permitted its use? What happened when the process stopped? What counted as acceptance? Those questions turn broad agent enthusiasm into an inspectable operating system for decisions.

The DN Alpha Thesis: Follow the Evidence Chain

There are six boundaries worth following from discovery to economic outcome. None can be inferred safely from the previous one.

1. Discovery: an agent, service or tool can be found and its claimed capability read.
2. Authority: the requesting identity has permission to invoke a specific operation within a defined scope.
3. Execution: the operation runs with observable state, bounded side effects and a recovery path.
4. Payment: charges, settlement and receipts correspond to the agreed transaction.
5. Acceptance: the output satisfies a criterion established before the result is known.
6. Economics: revenue and attributable costs are reconciled across accepted outcomes, retries and interventions.

A successful connection proves a connection. A signed instruction proves something about the signing process under its assumptions. A completed task proves completion under the chosen task definition. None automatically proves the whole chain. The commercial opportunity is to make those transitions explicit and then test the ones that matter to the buyer.

What DN’s Executed Evidence Supports

Runtime recovery: distinguish visibility from financial side effects

The Runtime Recovery v0.2 manifest records 100 local extension trials and 120 core rerun trials. In the extension’s paused-tool case, the observability criterion changed from 0/10 in the baseline package set to 10/10 in the current package set. That is a bounded local finding, not evidence that an older deployment sent unauthorized payments.

The underlying baseline results and current results report no model calls, no paid requests and no managed-provider runs. Both tested package sets held the fixture’s side effect until approval. Both passed the mocked SDK reconnect case. Several package versions changed together; the comparison does not isolate one package as the sole cause.

The practical lesson is a testing requirement: record whether an interruption remains visible, whether execution resumes in the intended state and whether approval still gates the side effect. “The graph finished” is too coarse a claim when the meaningful failure could be inside the pause-and-resume boundary.

Risk evidence: keep the execution boundary in the headline

The DN Agent Risk Graph v1.6 contains five profiles with executed evidence. Those profiles use different boundaries, including upstream unit tests, mocked authorization and payment flows, and a forked-chain execution case. They cannot be flattened into five equivalent production audits.

Liquid remains unclassified in that version because important backend and production-containment questions remain unresolved. Unmeasured dimensions remain unmeasured. This restraint is a feature of the dataset: a missing score should identify the next investigation, not quietly turn into a favorable rating.

What the Planning Assets Help You Decide

A calculator is useful when it exposes assumptions. It becomes misleading when its output is presented as an observed result. The API-call economics article separates attempts from accepted outcomes. In the illustrative case, 22,000 billable calls at $0.01 produce $220 of API charges. Dividing that by 9,000 accepted outcomes gives about $0.0244 per accepted outcome before other operating costs. These are hypothetical inputs, not a DN customer-margin study.

A particularly important question follows: if payment settles only after an accepted outcome, who carries the retries that did not count? The contract determines the answer. A provider may absorb unsuccessful work within its price. An operator may still owe upstream per-call charges. A marketplace may allocate an included retry allowance and charge beyond it. Accepted-only settlement changes who is paid and when; it does not erase compute, tool or intervention costs already incurred.

The Runtime Portability Index is another planning aid: it helps identify migration boundaries that require testing. It is not proof that a workload has already moved successfully between clouds. The 2030 scenario engine similarly explores overlapping futures through explicit assumptions. Its support points are not probabilities or market shares.

Explore the DN Agent Evidence Map

Choose a research question and evidence category. Filters intersect: “Security” plus “Execution” shows records carrying both labels. Mixed remains its own category because one asset can combine documentation and execution without validating every record. The full table remains readable when interactive filtering is unavailable.

Download JSONDownload CSVRead dataset methodology

Directory composition: two execution records, four documentation records, three planning records and one mixed record. These counts describe the selected ten assets only. They do not estimate market maturity, product quality or safety.

The Most Overlooked Gap: Evidence Between Organizational Boundaries

Many workflows cross several organizations: a user delegates a task, an orchestrator selects a tool, a provider runs it and a payment service settles the charge. Each party may have valid internal logs while the combined outcome remains difficult to reconstruct.

A useful operating record should connect the task identifier, authority version, selected tool version, attempt identifier, acceptance criterion and billing receipt. Sensitive payloads need not become public. The objective is to preserve enough authorized evidence for the relevant parties to distinguish a rejected attempt from an accepted delivery, and a duplicate request from an intended second transaction.

This is a research and product opportunity for receipts, reconciliation tools and narrowly scoped audits. It is also an editorial opportunity: report where the chain breaks, show a reproducible example and explain the business consequence. A directory of features alone cannot answer those questions.

A Practical 2027 Research Agenda

For buyers: compare one workload before comparing platforms

Write down the task, accepted output, permitted actions, spending limits and stop conditions. Fix the model, tools and representative input set where possible. Record differences in harness, infrastructure and policy configuration separately. Include failed attempts and human interventions rather than reporting only successful demonstrations.

Ask for a recovery test and a negative control. A system should show what happens when approval is absent, a response is malformed or a result arrives twice. Passing one test should not become a claim about every task or deployment. The Managed Agent Runtime Index provides comparison dimensions; the next step is a matched workload with a reproducible record.

For builders: sell a bounded outcome with an explicit cost allocation

Specify which attempts are chargeable, who decides acceptance, how quotes expire and when retries require new authorization. Distinguish a timeout from an unsuccessful task and a refund from the reversal of every downstream cost. Publish enough configuration detail to make a buyer’s pilot meaningful.

Security documentation should state what an agent can sign, which destinations and operations are permitted, who can change policy and how authority is revoked. The Transaction Permission Risk Index explains why policy-mutation rights belong beside transaction permissions. A protected key is not a substitute for bounded authority.

For researchers and publishers: publish the uncertainty as data

Use separate fields for observed results, vendor documentation and planning assumptions. Preserve failed trials, software versions and unavailable measurements. Record the workload and environment before introducing a leaderboard. Seek independent replication without describing internal reruns as outside validation.

For DN, the highest-value next additions are matched runtime tests, measured migration exercises and accepted-outcome cost cohorts. Their value will come from reproducibility and useful decisions, not the number of rows added. This edition establishes the map through which later evidence can be connected.

Methodology, Scope and Corrections

Selection: ten existing DN assets were selected to span runtime, security, discovery, economics and outlook. The selection is editorial and not statistically representative. Original JSON artifacts and relevant article text were reviewed for this edition. No new managed-provider benchmark, paid API experiment, production transaction or customer-margin measurement was performed for this synthesis.

Classification: “execution” means an executed test within a named boundary; “documentation” means a review of described capabilities or methods; “planning” means a worksheet or hypothetical model; “mixed” preserves multiple evidence types inside one asset. Classifications are not quality grades. Read each limitation before using a result.

Reproducibility: JSON and CSV expose the ten record identifiers, questions, claims, limits, source links and review date. The JSON additionally includes SHA-256 identifiers for normalized snapshots of six source datasets reviewed for this edition. Those hashes identify content; they are not cryptographic publisher signatures, independent timestamps or proof that a claim is true.

Reuse: the map is available under CC BY 4.0. Attribute Decentralised News and retain the limitations. Third-party source material retains its own terms. To suggest a correction, contact DN with the record identifier and replacement evidence. Material changes should receive a new dataset version.

Primary Sources and Underlying Evidence

1. MCP specification, 2026-07-28 revision — protocol scope.
2. x402 HTTP 402 documentation — payment exchange structure.
3. WebArena official project hub — defined web-agent evaluation environments.
4. TheAgentCompany official repository — simulated company evaluation environment.
5. DN Runtime Recovery v0.2 manifest and its linked artifacts — local trial boundaries.
6. DN Agent Risk Graph v1.6 — profile-specific executed evidence and open questions.
7. DN Discovery-to-Outcome v0.1 — mixed documentation and local-fixture records.
8. DN API Call Cost Scenarios v0.1 — hypothetical arithmetic.
9. DN 2030 Scenario Matrix v1.1 — planning assumptions, not probabilities.

Frequently Asked Questions

Is this a report on observed results from 2027?

No. This is a 2027 outlook edition with an evidence cut-off of 2 November 2026. Future developments are research questions and scenarios, not observed results.

Does the evidence map rank the best AI-agent platforms?

No. It classifies ten curated DN research assets by evidence type and question. It does not calculate provider rankings, market shares, safety scores or investment returns.

What does execution mean in this map?

Execution means a test ran inside its stated local, unit-test, mock or fork boundary. It does not automatically mean a managed service, a production deployment or a paying customer was tested.

Why are mixed records kept separate?

A single asset can combine documentation-only records and a local fixture. Keeping that combination visible prevents one executed example from being mistaken for validation of every record.

Does a signed payment prove that the user intended it?

A valid signature alone cannot establish that the preceding context, recipient selection and authority were correct. Those boundaries require separate controls and evidence.

Who pays for rejected agent attempts?

The agreement determines that. A provider may absorb failed attempts, an operator may owe upstream per-call charges, or the parties may allocate a retry allowance. Accepted-only settlement does not eliminate underlying execution costs.

Is the cheapest API call necessarily the cheapest accepted outcome?

No. Compare total attributable cost with independently defined accepted outcomes over the same period. Include billable retries, infrastructure and human intervention; if there are no accepted outcomes, the ratio is undefined.

Can I reuse the JSON and CSV?

Yes. DN Agent Evidence Map v0.1 is released under CC BY 4.0. Attribute Decentralised News, link to this article and retain the evidence limitations. The license does not transfer ownership of third-party source material.

What evidence would change the conclusions?

Reproducible matched-workload tests, documented migrations, production acceptance records and independently replicated controls would add evidence. Updates should preserve versions, configurations and failed trials rather than overwrite inconvenient results.

How can I suggest a correction?

Use the Decentralised News Contact page and identify the map record, the disputed claim and a primary source or reproducible artifact. A correction should change the affected record and its versioned methodology together.

Editorial edition: 2 November 2026. This outlook supports research and operational decisions; it does not certify a platform or project financial returns.