Enterprise agents moved closer to real execution this week. Oracle introduced 25 Fusion applications that coordinate workflows, approvals, and deterministic computation. AWS released an early research runtime that suspends agents while they wait, reporting 75,000 idle agents in 8 GB. Open Responses moved into independent governance under AAIF. The signal is infrastructure. The noise is calling any of it autonomous business operation.
The most important AI news today is not another model. It is the machinery that lets agents do useful work without holding a server open for three days, welding an application to one model provider, or bypassing the approvals that already govern a business.
Oracle, AWS, and the Agentic AI Foundation arrived at the same conclusion from different directions: the next agent problem is execution. A model can already write the plan. The difficult part is keeping that plan inside permissions, pausing it safely, resuming it when the world changes, and moving it to another provider without rebuilding the application.
Signal: Oracle turns Fusion from a system of record into a system of execution
At Oracle AI World on October 26, Oracle announced a broader set of Fusion Agentic Applications powered by a runtime called Fusion Claw. Release 26D includes 25 Claw-powered applications across ERP, HCM, supply chain, and customer experience, according to Oracle's product announcement.
The important part is not the number of agents. It is where Oracle puts them.
Fusion already owns the business context, permissions, transactions, and approvals for work such as reconciling accounting entries, investigating payroll variances, or coordinating supply-chain actions. Claw sits above those pieces. Oracle describes it as a governed execution runtime that combines model reasoning with deterministic computation, handles longer-running work, and re-plans when conditions change.
That is a more credible architecture than sending a browser agent into an ERP and hoping it clicks the right buttons. The agent does not need to impersonate an employee or invent its own control system. It operates inside a platform that already knows who may see a record, who may change it, and which actions require approval.
The caveat is equally important: these are Oracle's product and availability claims. Twenty-five applications being available is not the same as 25 independently measured business outcomes. The architecture is worth studying. The ROI still has to be proven in each deployment.
Signal: AWS treats waiting as the agent runtime problem
Most agent demos look busy because the model is producing text. Production agents spend much of their lives doing nothing.
A coding agent waits for a build. A procurement agent waits for an approval. A monitoring agent waits for the next event. In a conventional harness, the process and memory can stay alive while the tool is working, even when the wait lasts hours.
AWS and UC Berkeley's Hydro project released Infinity on October 23 under Apache 2.0. Its core idea is borrowed from asynchronous programming: when an agent calls a tool, Infinity saves the conversation state, dispatches the call, and suspends the agent. When the result arrives, any available process can reload the history and continue.
AWS reports fitting roughly 75,000 idle agents into 8 GB of memory, at around 100 KB per idle agent. That number needs its full label: it came from an AWS benchmark using a simulated model and in-memory stores. It is not proof that a Raspberry Pi can run 75,000 production agents.
The useful insight survives the caveat. An agent waiting three days for a CI pipeline should consume stored state, not three days of compute. Infinity also treats events and child-agent reports as messages that wake the parent only when work arrives. That is exactly the kind of boring runtime behavior long-running agents need.
Infinity is an early research release, not a production recommendation. Its own open questions include event authenticity, scheduling priorities, and compaction across large agent trees. That honesty is part of the signal.
Signal: Open Responses gets a vendor-neutral home
An agent application can be locked to a provider long before anyone signs a cloud contract. The lock-in can live in the request format, streaming protocol, tool-call schema, and conversation-state model.
On October 22, the Agentic AI Foundation announced four new projects: Agent Skills from Anthropic, Open Responses from OpenAI, OpenEnv from Hugging Face, and OpenSandbox from Alibaba. Open Responses now sits under the same independent foundation as MCP and A2A.
AWS describes Open Responses as a shared API format for model calls, streaming, stateful conversations, and tool use. Amazon Bedrock already supports the format across models from Amazon, Anthropic, Meta, Mistral, OpenAI, DeepSeek, Google, and others.
The practical promise is simple: write orchestration code against one open format, then evaluate or switch providers without rewriting the agent loop. A standard does not eliminate differences in model behavior, tool semantics, or safety controls. It does remove one unnecessary layer of switching cost.
Noise: enterprise software is now autonomous
It is not.
Oracle's own examples still contain organizational policies, authorized actions, deterministic computation, and human review. Infinity pauses an agent efficiently; it does not make the agent correct. Open Responses standardizes the wire format; it does not standardize judgment.
That distinction matters because the word "autonomous" hides the real engineering. A useful enterprise agent is not one that escapes the workflow. It is one that can coordinate the workflow while remaining inside identity, permissions, approvals, observability, and rollback.
The strongest announcement this week is therefore not autonomous software. It is software that knows how to wait, how to ask, how to resume, and how to remain governed while doing it.
What should builders do with this?
Three decisions now belong in an agent architecture review:
- Execution: Which steps require model judgment, and which must remain deterministic transactions or calculations?
- Waiting: Can the runtime suspend long tasks without keeping compute alive, and can it resume idempotently after duplicate events or failures?
- Portability: Are the model API, tool contracts, prompts, and evals separable from the provider-specific control plane?
We use the same separation in our own multi-agent content engine: models handle bounded judgment, deterministic code checks what can be checked, and a person controls publication. That case does not run on Oracle Claw or Infinity. The shared lesson is architectural: autonomy should be narrow, observable, and interruptible.
If you are planning a production agent and the diagram ends at "LLM calls tool," show us the workflow. We will help map the identity, state, approvals, and failure paths that begin where the demo ends.