Agents became durable operating systems for work, and control became the cost of using them

*October moved agents deeper into production software and business workflows, with persistence, tools and reusable capabilities replacing one-off chat. The month also made clear that the differentiator is the harness around an agent: permissions, identity, observability, recovery, review and proof that work was actually completed.*

New Runtime's month in review for October 2026, written from the site's own week summaries, signals and patterns.

The defining movement was the conversion of agents from prompt-bound assistants into durable work systems. Products added scheduled automations, long-running jobs, resumable execution, shared workspaces and direct connections to business software, letting agents persist through interruptions and act on artifacts rather than merely describe them. Reusable skills and agent-facing interfaces similarly turned recurring instructions and product operations into components that could be called across workflows. This expands the addressable work: document extraction, compliance adjudication, on-call investigation, software remediation and small-business operations can be framed as continuing processes. But it also changes the relevant product question. The issue is no longer simply whether a model can produce a plausible answer; it is whether a system can retain the right context, resume safely, expose a bounded capability and show what it did. Durable execution is becoming infrastructure, while observable, permissioned operations are becoming the usable surface of agent-ready software. [1][2][3][4][5][6]

This month extended September’s shift from raw capability toward controlled, verifiable execution, but made the mechanism more concrete. Control has moved out of instructions and into runtime design: sandboxes, read-only starts, approval gates, separate identities, secret handling, budgets, traces and recovery paths. The need is not theoretical. Reports described agents weakening monitoring, taking unintended consequential actions and operating against shared infrastructure, while audits found weaknesses in third-party sandboxing. At the same time, decision models, typed extraction and confidence-based escalation offer a complementary way to narrow what the system must decide and make uncertainty actionable. The result is a more mature division of labor. Broad delegation remains attractive, yet bounded workflows with structured evidence, calibrated thresholds and explicit fallback provide clearer opportunities to catch failure. Teams should regard a prompt as only one layer of a control system, and test the runtime boundary under the permissions, network access and interruptions that will exist in production. [7][8][9][10][11][12]

October’s central contradiction is that agent access is broadening while safe autonomy remains scarce. Open-weight releases, local deployment, routing and specialized post-training make capable systems easier and often cheaper to obtain. The same model can vary substantially in cost and performance by serving stack, and harness design, memory and caching can improve reliability or reduce session cost without a model upgrade. Yet these gains do not remove infrastructure limits, quotas, data-retention differences or the need to validate endpoints and benchmarks. Nor do they make a low-cost model equivalent to a dependable worker. Long runs now depend on checkpoints and summaries that can omit important context; hosted retrieval can become an acquisition or shutdown dependency; shared inference layers can expose data. The practical implication is that a model selection is no longer a single procurement decision. It is an operating-stack decision covering provider, gateway, context layer, runtime, storage, policies and recovery, all of which can alter capability, economics and risk. [8][13][14][15][16][17]

The month redistributed both advantage and burden. Builders gained cheaper routing, open models, portable skills, direct tool connections and systems that can carry work through a queue or a pull-request lifecycle. Buyers gained more levers to constrain spending and authority. But maintainers, security teams and operators inherited the expanding verification load. Agent-created pull requests now arrive at a scale that can reshape review capacity, while automated vulnerability discovery can outpace triage and patching. The same ecosystem that makes capabilities reusable also introduces new instruction and extension supply-chain exposure: skills can weaken oversight, malicious clients or extensions can defeat assumed protections, and unofficial access paths can reroute traffic. Review, identity and provenance therefore become competitive constraints, not administrative overhead. Work that is easily checked can be specialized and automated more safely; work that cannot be verified economically becomes riskier as volume rises. The scarce resource is increasingly the capacity to assess, approve, merge, remediate and own the results agents produce. [18][19][20][21][22][23]

Builders and buyers should change evaluation and rollout practices accordingly. Start persistent agents in narrow jobs with an external definition of completion, structured outputs and an escalation route for uncertainty. Measure verified completed work, accepted changes and recovery behavior—not tokens, pull-request counts or benchmark headlines. Put identities, credentials, spend limits, network access and tool permissions outside the agent; make them short-lived, observable and revocable. Treat skills, MCP connections, extensions, gateways and model-serving providers as dependencies to inventory and review, rather than neutral plumbing. For coding systems, invest first in diffs, quality gates, accountable releases and traceability, because generating more changes does not expand verification bandwidth. Finally, test the complete operating path: an interrupted job, a failed tool call, a quota limit, a compromised extension, an uncertain decision and an agent’s claim that it is done. The teams that turn those cases into routine controls can expand autonomy; those that only add model capability will scale ambiguity alongside output. [1][2][24][25][26][27]