The Stack Behind Long-Running AI Agents

Meta's Long-Running Agent Bet

An agent that remembers weeks of work could save hours of repeated setup. It could also carry one bad assumption, or one piece of private context, much further than a single chat ever would.

Our main story today is Meta's new Muse Wonder models, and what persistent memory changes for developers building agents that are meant to keep working rather than answer one prompt and stop. Meta released Muse Wonder on 12 October through the Meta Model API and Muse Code. A more capable model, Muse Wonder Full, is available to Muse Code subscribers. Consumer access through the Muse assistant is planned for later, although Meta hasn't set a date.

The notable ideas are Active Memory and Active Focus. Meta says Active Memory retrieves relevant information across conversations. In practical terms, an agent could bring earlier decisions, preferences or project context into a later task without a developer reconstructing that state each time. Active Focus is meant to help the agent try alternative approaches and recover from errors during longer jobs. That addresses a familiar weakness in agent systems: a model can produce a strong first step, then drift or get stuck as tool calls, partial results and unexpected failures accumulate.

Those features point at a different test of model quality. A good response to one carefully prepared prompt is useful, but a persistent agent has to choose what to remember, retrieve the right detail at the right moment and recognise when its current plan has failed. Each of those decisions can compound. Remember too little and the agent wastes time rediscovering the job. Remember the wrong thing and it may confidently optimise around stale or irrelevant context.

Long-running work also changes how a developer reviews the result. Checking the final patch or answer may not reveal that the agent took a poor branch halfway through, exposed context to the wrong tool or recovered by discarding an important constraint. A useful evaluation has to follow the path, including the memories retrieved and the alternatives attempted. Active Focus sounds promising against that problem, but Meta's description isn't yet independent evidence that recovery stays reliable as a task grows.

Meta reports leading results across agent, memory and coding evaluations. For now, those are company benchmark claims. Independent testing is still limited, the fuller safety report is pending, and Meta hasn't announced open weights for either Wonder model. That makes the launch real and usable for developers, but leaves important questions unanswered about performance outside Meta's evaluations and about the controls surrounding stored context.

My read is that persistent memory can make agents much less tedious to use, especially on coding work that spans several sessions. It also moves the engineering problem. Developers will need to inspect not only what the model said, but what it remembered, why it retrieved that memory and whether recovery from an error genuinely returned the task to a sound state. Reliability over time becomes more revealing than a polished first answer.

Muse Wonder gives developers another frontier option now. The sensible comparison isn't simply which model wins a coding benchmark. It's which system can hold context for a long job without turning memory into an invisible source of errors or exposing information that should have stayed outside the task.

Microsoft's Maia Inference Plan

That shift towards longer agent runs also puts pressure on the infrastructure underneath them. Microsoft wants more of that load running on silicon it designed itself.

Microsoft announced Maia 300 on 12 October and said Azure Maia will expand to multi-gigawatt deployments from 2027. The company expects Maia to become the primary inference system for its products and services, reducing its dependence on third-party accelerators for the work of running trained models.

The transition has already started. Maia 200 is serving Microsoft Copilot workloads, and support for Microsoft Foundry and GitHub Copilot is planned by the end of 2026. Current deployments include Australia. Maia 300 is the much larger commitment: Microsoft says it should deliver 40 per cent more tokens per megawatt than leading GPU-based systems, along with as much as seven times the rack-scale token throughput of Maia 200.

Power efficiency is central here. Inference capacity isn't determined only by how many chips a company can buy. Data centres have finite power and cooling, so more tokens from each megawatt can translate into more usable AI capacity within those limits. Owning the chip design can also let Microsoft tune hardware, systems software and its services together rather than treating the accelerator as a general-purpose component.

There is a sizeable gap between the plan and the proof. Maia 300 production deployments aren't due to begin until 2027. Its efficiency and throughput numbers are forward-looking Microsoft estimates, and production-scale performance, manufacturing volume and comparative economics haven't been independently demonstrated. A rack figure also doesn't tell a customer how a specific model or application will perform.

For organisations buying AI through Microsoft's services, custom silicon could improve capacity and operating economics without requiring them to manage the hardware. The question I'd keep open is portability. A cheaper or faster inference layer is a strong result only if customers retain useful model choice and can move workloads without discovering that the surrounding platform has become the real constraint.

Britain Plans for Agent Incidents

Hardware scale is one side of the agent story. The harder public question is what happens when an autonomous system causes a serious incident and nobody can easily reconstruct its decisions.

The British government announced work on cyber responses for serious autonomous-agent incidents, security evaluations for frontier models, and possible AI incident-reporting measures under its Cyber Security and Resilience Bill regime. Two government pilots have reportedly identified and addressed more than 1,000 potential vulnerabilities. Officials are also examining how serious AI incidents and near misses could be identified and reported.

There isn't a new reporting duty yet. The provisions are under consideration, and the final scope, thresholds and commencement date remain unresolved. That distinction is important for organisations operating in Britain: this is a policy signal and a preparation effort, not an enacted compliance deadline.

Even so, the direction has an immediate operational consequence. An autonomous agent can make a chain of small decisions across models, tools, credentials and external systems. By the time someone notices the result, a conventional application log may show that a command ran without preserving enough context to explain why the agent selected it. Near misses are especially easy to lose if a person quietly corrects the output and the system records only the successful end state.

The reporting question is also harder than it looks. Organisations need enough detail to distinguish a model failure, a badly scoped tool, an unsuitable credential and an operator decision, even when several of them contributed. Without that separation, an incident count says little about what needs fixing. Frontier-model evaluations can test capability and security in controlled settings; operational records show what happened once a system met real permissions and real data.

Organisations deploying consequential agents would be well served by keeping attributable records of model actions, tool calls, approvals, failures and recovery attempts. That's my practical reading of the government's announcement, not a claim about the final law. Collecting that evidence during operation is far easier than rebuilding an agent's path after a security failure. It also gives developers something concrete to evaluate when a model appears to have recovered but may have merely changed course without fixing the underlying problem.

The government's pilots suggest active defensive work is already finding issues at scale. The unresolved part is how those technical exercises become consistent incident rules. Until the thresholds are settled, good records are useful for security and investigation in their own right, and may later become the evidence regulators expect.

Coding Agents Reach Google's Data Cloud

For developers, one of the more practical releases today removes a lot of console-hopping from data work, while putting cloud permissions much closer to the coding agent.

Google released Data Agent Kit, a free Apache-2.0 plugin and IDE extension that provides supported coding agents with MCP tools and skills for more than 15 Google Data Cloud services. It supports Antigravity CLI, Claude Code, Codex CLI and compatible agent-plugin clients. There is also an extension for Visual Studio Code-based IDEs.

The kit can help with querying data, generating notebooks, building data pipelines and deploying Airflow workflows. Instead of asking an agent to draft code and then manually carrying that work across several Google Cloud consoles, a data engineer can keep more of the workflow inside the editor or command-line harness already holding the project context. The Model Context Protocol, or MCP, is the interface that exposes those tools to the agent in a structured way.

That convenience comes with a very ordinary but important security boundary. Data Agent Kit requires authenticated Google Cloud access, and Google advises narrowly scoped service accounts because the agent can execute tools and commands. The useful unit of control isn't only the person at the keyboard; it's the credential available to the agent during that session. Giving a broad service account to save setup time could turn a mistaken tool choice into a change across production data services.

Usage telemetry is enabled by default and can be disabled. Google says it doesn't collect user code, file contents or application data values through that telemetry. Developers working under stricter internal policies will still need to review the setting and the wider flow of credentials and tool results in their own environment.

The benefit is straightforward: less integration work between a coding agent and Google's data services. My caution is equally practical. Service-account scoping now belongs in the normal developer setup for agent-assisted data work, not in a security review added after the workflow is already running. There isn't independent evidence yet showing how reliable or productive the kit is across real production data estates, so access control is the part teams can get right before those results arrive.

AMD Splits Agent Work from Inference

Zoom out from the developer's editor and the shape of agent computing is changing as well. AMD is arguing that orchestration and inference don't belong on the same expensive hardware by default.

AMD introduced Helion, a rack blueprint based on Open Compute Project specifications. It can combine CPU-based agent execution, GPU inference and an integrated router that directs model calls. Proposed configurations range from a CPU-only rack with as many as 32,768 EPYC cores to an integrated design using EPYC processors and Instinct MI350P GPUs. AMD says the router can send agent model calls across both frontier and open-source models.

The distinction matters because an agent does more than generate tokens. It may schedule work, execute tools, transform files, wait on services and coordinate several tasks before it needs another model response. Running every one of those steps as though it were inference can leave costly accelerator capacity occupied by work a CPU could handle. Helion's design makes that separation explicit at rack scale: CPUs handle more of the agent execution, while GPUs are reserved for model calls that need them.

This is still a blueprint under development. Partner availability is planned for November 2026, and AMD intends to contribute the specification to the Open Compute Project, but that contribution isn't complete. The company hasn't published independent cost or efficiency results, so we don't yet know how the proposed split behaves under real agent workloads or how readily partners can turn the design into deployable systems.

For infrastructure builders, the useful idea is resource matching. If an agent spends a meaningful share of its time doing orchestration and tool work, separating that from inference could reduce wasted accelerator capacity and make the system easier to scale in parts. The open rack approach may also give operators more choice in how those parts fit together.

I'd treat Helion as an architectural proposal with a plausible advantage, not a proven cost saving. The evidence to watch will be partner implementations, workload-level performance and whether the router can allocate calls across different models without creating a new bottleneck or an awkward layer of lock-in.

Mistral Hosts the Workflow Worker

Not every developer wants to design the rack, or even run the worker. Mistral is now offering to take that second job on.

Mistral released Managed Deployments in public preview on 9 October. A developer points the service at a GitHub repository, and Mistral Cloud builds the repository's Docker image, injects a rotating service-account token and manages the workflow worker's lifecycle. That gives Mistral Workflows a hosted path for jobs that need to keep running without the developer maintaining separate worker infrastructure.

The appeal is operational. Packaging a worker, arranging authentication and keeping the process alive are all work around the workflow rather than the workflow itself. Managed Deployments folds those tasks into Mistral's platform. For a developer already committed to Mistral Workflows, that can shorten the distance between code in a repository and a durable running service.

The preview has firm constraints. It requires a paid pay-as-you-go or enterprise plan and remains subject to concurrency quotas. Workers currently run only in the Netherlands-based nl-north-1 region. Mistral chooses the instance size, while per-deployment CPU and memory metrics aren't yet exposed. Preview features and limits may also change.

Those details narrow the immediate audience. One-region hosting may not fit an organisation's data or latency needs, and limited resource visibility makes it harder to diagnose performance or judge whether the chosen instance is efficient. Moving the worker into Mistral's environment also means accepting more platform coupling in exchange for less infrastructure to operate.

My take is that this could be a useful route for contained workflows where managed operation matters more than low-level control. For production systems with strict regional, observability or capacity requirements, public preview is a reason to test the boundary rather than assume the hosting layer is finished. The service lowers the entry cost of durable workflow deployment, but today it does so inside a fairly specific box.

What Changes for You

Two releases need a closer look at systems people are already using, starting with a security update that shouldn't wait for the usual maintenance window.

GitLab has patched CVE-2026-97229, an unauthenticated remote-code-execution flaw in the CI/CD regular-expression compiler. GitLab rates it CVSS 10.0: a crafted regular expression in CI/CD configuration can trigger code execution on the server. Self-managed Community and Enterprise Edition operators need to upgrade affected branches to 19.4.2, 19.3.5 or 19.2.8, with internet-facing installations first. GitLab.com is already patched, and GitLab Dedicated customers don't need to act. The release also fixes a high-severity prompt-injection flaw in the GitLab Duo Agent Platform that could attribute unintended command execution to another user. Neither GitLab nor CERT-EU reports confirmed exploitation in the cited advisories. The practical change is immediate for self-managed operators: treat CI/CD configuration as a server execution boundary and install the fixed release now.

Kiro CLI users have a different deadline. Kiro began gradually prompting users on 12 October to move to its V3 agent harness, before CLI 3.0 becomes the default at the end of October. V3 adds background multi-agent workflows, specification mode, cross-session memory, tangent conversations and cloud sessions that can continue after a laptop disconnects. The limitation is that cloud sessions currently run only in AWS us-east-1, and organisations using IAM Identity Center need an administrator to enable them.

Migration preserves and backs up supported configuration, but some hooks and permission rules need manual review. CLI 3.0 also retires inline shell autocomplete, the CLI desktop application and the Classic interface. If Kiro is already part of your development setup, test V3 and read the migration diagnostics before the default flips, particularly around custom agents, hooks and permissions. Durable background work is the useful gain; the near-term risk is discovering a retired feature or changed permission after the harness has moved underneath an established workflow.