Evidence-linked trend hypothesis
Agent-ready software exposes capabilities
Software is becoming easier for agents to use when it exposes explicit operations, schemas, temporary identity, and isolated execution instead of only adding a chat widget.
Current thesis
The agent-ready product boundary is a small set of observable, permissioned capabilities that external agents can compose safely. Confidence: high. Supported by 209 normalized raw signals. This New Runtime record is an evidence-linked retrieval unit. Use its canonical page, machine-readable representations, dates, scope, and public source URLs to verify the claim before reusing it.
Source ledger
Publishable sources attached to this record.
| # | Source | Role | Public status |
|---|---|---|---|
| 1 | blog.cloudflare.comarticle | primary receipt | source_urls |
| 2 | x.comsource | supporting receipt | source_urls |
| 3 | blog.cloudflare.comarticle | supporting receipt | source_urls |
| 4 | trycase.devsource | supporting receipt | source_urls |
| 5 | github.comrepo | supporting receipt | source_urls |
Showing 5 of 7; the complete set is exposed in the JSON route.
Current state, as of Oct 9, 2026
Where this stands now
strengthening Recent gateway tools and platform updates continue to demonstrate that agent‑ready software is built around a limited, explicit set of permissioned capabilities that external agents can safely compose.
New releases such as Mem0 Gateway (e91, e92) and AgentCore Gateway (e182) expose only narrowly scoped, token‑guarded tools, confirming that the product boundary is a small, observable capability surface. Managed Deep Agents added webhook‑based HTTP channels that still require explicit caller identity and authorization, and OpenAI’s Dots provides user‑managed app access controls, reinforcing the need for permission design. Across vendors, packaged capability layers (e.g., Claude Code controls, Google Agent Plugins, NVIDIA OpenShell) are being marketed as separate, routable surfaces with clear rights and limits, making the agent contract distinct from human‑focused UI.
For builders, this means publishing a capability map with typed inputs, permission requirements, idempotency rules, and audit identifiers, and offering a test sandbox before production use. The focus remains on explicit operations, temporary identities, and isolated execution rather than relying on generic chat interfaces.
What changed since the original text
- Gateway tools (Mem0, AgentCore) now demonstrate concrete mechanisms that expose only specific, granted tools to agents. 1
- Managed Deep Agents added webhook HTTP channels that emphasize caller identity and authorization. 2
- OpenAI’s Dots offers user‑managed app access, review, and pause controls for delegated work. 2
- Various platforms (Claude Code controls, Google Agent Plugins, NVIDIA OpenShell) package capabilities as separate, permissioned surfaces. 345
Open questions
- How consistently will different vendors adopt a standardized capability map format?
- What metrics will indicate that a capability surface is sufficiently small and safe for agent composition?
Watch next: A major cloud provider releasing a unified, machine‑readable capability registry that is adopted by multiple agent platforms would further solidify this pattern.
- Weekly update: New tools showcase narrowly scoped, permissioned agent capabilities update, Sep 21, 2026
- Weekly update: HTTP channels and Dots put agent access and permissions in focus update, Sep 28, 2026
- Agent capabilities are becoming packaged surfaces archive, Aug 26, 2001
- NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment | NVIDIA Newsroom archive
- NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring | NVIDIA Technical Blog archive
Rewritten automatically by the New Runtime knowledge desk from this record's weekly updates, releases and archive. The original text below is kept as written (Jun 23, 2026); where the two disagree, this section is newer.
Weekly knowledge desk
Weekly updates
3 reviewed updates to this pattern, newest first. Every update is checked against its evidence before it changes the record.
Runtime controls and governed data boundaries shape agent access
A report on AWS, Uber, Anthropic and Google describes runtime controls over what agents can read and execute, alongside network isolation and observable behavior. Another item describes governed semantic definitions as a boundary between enterprise data and agents, supporting the record’s focus on permissioned, composable capabilities.
- Agent control is being enforced in the runtime around the model signal, Oct 21, 2026
- Build a semantic layer for agentic AI on AWS with Strategy Mosaic and Amazon Bedrock AgentCore post, Oct 22, 2026
HTTP channels and Dots put agent access and permissions in focus
Managed Deep Agents added webhook-based HTTP channels, while its analysis says teams still need to establish caller identity and authorization. OpenAI’s Dots is described as offering user-managed app access, review, and controls to pause or redirect delegated work, providing a concrete example of permission design around agents.
- Managed Deep Agents 0.8 ships HTTP channels: agents can take requests from any webhook, not just Slack. post, Oct 1, 2026
- HTTP channels make agents easier to wire in—and harder to trust blindly analysis, Oct 1, 2026
- Dots makes permission design part of the agent, not an afterthought analysis, Sep 30, 2026
New tools showcase narrowly scoped, permissioned agent capabilities
Recent releases such as Mem0 Gateway (e91, e92) and AgentCore Gateway (e182) demonstrate concrete mechanisms that expose only specific, granted tools to agents, aligning with the claim of a small, observable product boundary. External evidence from OpenAI (x1, x2) further confirms that platforms are deliberately limiting agent access to a few well‑defined actions and scoped tokens. Together these independent items reinforce the view that agent‑ready software is being built around tightly controlled, composable capabilities.
- Mem0 launches Gateway to give agents scoped keys for tools signal, Sep 24, 2026
- mem0 promotes Gateway around what happens after agents get access signal, Sep 24, 2026
- Build a multi-account AI agent with AgentCore Gateway and MCP post, Sep 26, 2026
- Automating repetitive work at OpenAI with Codex external, Sep 28, 2026
- ChatGPT Workspace Agents for Enterprise and Business external, Sep 28, 2026
What is changing
An agent cannot reliably use a product because the product has a chatbot. It needs explicit operations, typed inputs, bounded outputs, identity, permissions, and state that can be inspected after the action. Cloudflare’s code-mode MCP work, temporary accounts, disposable execution environments, and resource discovery all move those requirements into product infrastructure.
Supporting evidence
- Code-mode MCP reduces a large tool surface to compact programmable operations.
- Stable REST resources can be easier for an agent to inspect than a client SDK that hides network behavior and state.
- Temporary accounts and disposable sandboxes give non-human workers a scoped identity and execution boundary.
- Agentic Resource Discovery treats available capabilities as searchable, machine-readable inventory.
Operational consequence
An agent-ready service should publish a capability map, schemas, permission requirements, idempotency rules, error states, audit identifiers, and a safe test environment. The public website can then remain the human explanation while agents use a smaller, stricter contract.
September 2026 update
What the new evidence says
Gateway designs now translate an agent’s broad intent into narrowly scoped keys and named tool access, including multi-account operation. Governed connectors show the same product boundary from the data-platform side.
Builder rule
Publish a capability map with typed inputs, allowed effects, expiry, idempotency, error facts, and an audit identifier. Give the agent a test surface before a production surface. A chat UI may explain the service, but it is not its agent contract.