AI agents are getting better at remembering past conversations and earlier tasks but remembering something doesn’t guarantee an agent can use it to do better work next time. Letta’s new FrontierMemory benchmark, released Wednesday, tests that gap by measuring whether agents can learn from experience rather than by just retrieving stored information. Early results show a widespread in performance across agent harnesses, the the infrastructure that manages how an agent operates.

Letta Dream came out on top with a 73.3% score, followed by Prime Agent at 60%. OpenAI Agents SDK scored 40%, while Claude Managed Agents and Hermes Agent trailed at 33.3% and 26.7%, respectively.

Recall isn’t learning

“Modern ‘memory’ benchmarks are saturated since they measure recall of facts,” Letta co-founder and CEO Charles Packer writes on X, saying that in the coding harness and bash loop era, recall is solved, while continual learning in token space, meaning learning through the context an agent keeps rather than through weight updates, remains unsolved.

Sarah Wooders, also a Letta co-founder, points to another problem on X. Most coding and knowledge-work benchmarks evaluate unrelated tasks with all the necessary context provided upfront. But that’s not how people actually work. Wooders compares it to starting a new job: A new hire needs plenty of direction, while someone who’s been there for years can often get the job done with little explanation.

Packer’s premise is that “if AI-generated memory is good, it should actually improve downstream task performance.”

FrontierMemory takes a different approach. Agents receive transcripts of earlier work, including successful and failed attempts, and then generate their own memories to help complete later tasks. Packer’s premise is that “if AI-generated memory is good, it should actually improve downstream task performance.” Developers have already embraced the underlying idea, building continually learning agents by pairing a language model with memory systems and feedback loops.

Letta reworked existing coding and knowledge-work tests so agents had to use what they learned from previous tasks instead of having everything spelled out for them. After reviewing and fixing problems with the original tests, Letta narrowed FrontierMemory 1.0 to just 15 tasks.

Harness beats model

The harness itself may matter just as much as the model running inside it. Letta tested five agent systems to see how well they could learn from previous work and use those lessons on new tasks.

The harness itself may matter just as much as the model running inside it.

Letta Dream beat OpenAI Agents SDK 60% to 40% when both used GPT-6.1 Sol to create memories and GPT-6 Sol to complete tasks. The results were even further apart with Claude Opus 5.5. Dream scored 73.3%, Prime Agent hit 60%, and Claude Managed Agents came in at 33.3%.

Packer says the the way agents handle AI “dreaming” makes a big difference. Dreaming is when an agent reviews past work and turns what it learned into instructions or memories it can use later. He also points to Prime Agent outperforming Hermes Agent as another example of how much these systems can vary. But there’s a downside: without checks on what gets saved, agents risk learning and repeating bad habits.

FrontierMemory also compared seven frontier models on how well they generate useful memories. Anthropic’s Claude Opus 5.5 and Z.ai’s GLM-5.3 tied for first at 73.3%, Kimi K3 followed at 66.7%, and OpenAI’s GPT-6.1 Sol and Google’s Gemini 4 Argon both scored 60%. Muse Wonder reached 46.7%, and Grok 4.7 finished at 33.3%. Packer says Opus 5.5 and GLM-5.3 are significantly better at generating useful memories than GPT-6.1 Sol.

Packer says Opus 5.5 and GLM-5.3 are significantly better at generating useful memories than GPT-6.1 Sol.

Cheaper memory, lower scores

But OpenAI had a big price advantage. GPT-6.1 Sol cost an estimated $0.77 per task, compared with $2.80 for Opus 5.5 and $3.58 for GLM-5.3. So while OpenAI scored lower, it was much cheaper to run.

Letta used its Dream harness to create memories with each model, then tested how well those memories worked on tasks run in Letta Code. The results show a tradeoff between better memory, stronger performance and lower costs.

Memory that travels

Letta also looked at why some memories worked better than others. In one test involving company pricing data, Opus 5.5 created a skill telling the agent when to use certain information. GPT-6.1 Sol created four separate skills, but the agent never found the one it needed.

Gemini 4 Argon made a different mistake. It remembered specific file sizes, which wasn’t much help when the next task involved different files. Opus 5.5 instead told the agent to check both the usual file and email for information. That worked even when the task changed. Memories created by Opus 5.5 helped GPT-6 Sol complete tasks, suggesting developers could use a more expensive model to build memories and a cheaper one to do the work.

Other developers have taken notice. After Letta’s Sarah Wooders posted about the benchmark on X, the OpenClaw account responded that it would like to see a plugin for its platform. The account says its multiplayer environment would be an interesting place to test the benchmark, raising questions about how memory works when several agents share the same harness.

“Yes definitely – would love to add OpenClaw to the harness comparison!” Wooders writes. “Extending to multiplayer memory is also a very interesting future direction.”

What the benchmark misses

FrontierMemory is still early. With just 15 tasks and one attempt per task, a single result can shift the scores by roughly 6.7 percentage points. The benchmark currently focuses on agents learning from past work rather than updating memories as they go. Packer says the next release will add longer-running tasks and online memory updates.

The post Five AI agent harnesses took the same memory test. The results weren’t even close. appeared first on The New Stack.

Ramp spent months testing managed agent APIs, open-source frameworks, and third-party platforms before concluding it would be better off building its own. The result is Laminar, an internal agent harness that took six weeks to reach a first version and now powers every agentic product at the fintech company.

“We studied the other offerings on the market and decided that we could do better, move faster, and have stronger alignment to where we want to go by building in house.”

“We studied the other offerings on the market and decided that we could do better, move faster, and have stronger alignment to where we want to go by building in house,” Sam Kronick, the Ramp engineer behind the platform, writes in the company’s engineering blog.

In Tuesday’s post, Ramp detailed how Laminar brings agent execution, sandboxing, observability, and asynchronous workflows under a single platform. The architecture caught the attention of LangChain CEO Harrison Chase, who praised several design choices in his X post, while pointing to similar work underway in LangChain’s Deep Agents.

Ramp and LangChain are approaching the problem from different directions, but both point to a bigger shift in agent infrastructure. As harnesses take on more responsibility, enterprises have to decide how much of that infrastructure they want to build and maintain themselves.

Why Ramp built in-house

Ramp didn’t want to be locked into one model provider. It needed the flexibility to switch models based on cost, speed, and performance, along with better visibility into how its agents behaved. Engineers were already digging through traces to find unnecessary tool calls, bloated context, and errors, but existing observability tools made that harder than it needed to be. So Ramp built its own debugging interface into Laminar. Keeping development in-house also meant the harness team could work directly with product engineers instead of waiting on vendors to make changes.

Chase agreed with Ramp’s priorities, particularly model independence and observability, both of which LangChain has emphasized in its own work. And, there were other parts of Laminar’s architecture that caught his attention.

Keeping development in-house also meant the harness team could work directly with product engineers instead of waiting on vendors to make changes.

Sessions split from sandboxes

Laminar runs everything from customer service agents to Ramp Inspect, the company’s cloud coding agent, and Glass, which handles longer-running, collaborative work. Supporting these products requires a harness that can manage persistent sessions, human approvals, and work across environments.

Chase highlights Kronick’s observation that a production harness does far more than run a simple execution loop. “+100 to this,” he writes, pointing to LangChain’s investment in Deep Agents.

Ramp keeps agent sessions separate from the sandboxes where code runs. Conversation history and execution state are stored independently, allowing sandboxes to spin up and shut down without disrupting a session.

Chase sees the sandbox-as-a-tool approach as a growing trend, noting that Deep Agents uses a similar design. It also keeps credentials and orchestration outside the sandbox, an important consideration as developers work to isolate agents running untrusted code.

Async agents by default

Laminar lets agents keep working without waiting for every step to finish. Chase describes non-blocking asynchronous agents as the future and says LangChain is developing similar functionality for Deep Agents.

Ramp’s Connectors Service also caught his attention. It centralizes authentication, credentials, access controls, and tool execution behind a shared API.

Chase says LangChain is exploring comparable features for managed Deep Agents. Centralizing those functions also gives platform teams a consistent place to manage access and credential handling rather than implementing them separately for every agent.

The harness is also where teams can trim inference costs, and LangChain has made that case directly. In an October 1 engineering post, it describes moving model selection into the harness of Open SWE, its open-source coding agent. A router examines the initial request and assigns one of three models based on expected task complexity, sending the simplest work to GLM-5.3-Flash, intermediate tasks to GPT-5.6 Sol, and the most demanding requests to GPT-6 Astra.

Routing trims inference costs

Across 973 agent threads, the router cut median LLM costs from $2.61 to $0.94 per thread, a 64 percent drop compared with using GPT-6 Astra for every task. The savings didn’t come with a measurable hit to performance. Merged pull request rates were 29.2 percent for routed threads and 27.3 percent for the control group, a difference that wasn’t statistically significant. Ninety percent of requests went to the two less expensive model tiers.

LangChain argues that routing works better inside the harness than at a generic LLM gateway, where there’s less context about what an agent is doing.

LangChain argues that routing works better inside the harness than at a generic LLM gateway, where there’s less context about what an agent is doing. The harness already knows which prompts, tools, and domain context are involved, giving it more information to make that choice. LangChain uses model-selection middleware to pick a model at the start of each thread.

The results don’t tell us whether building a custom harness is cheaper than using an existing framework. Ramp wasn’t part of the experiment. But they do show how much companies can save by making smarter model choices at the harness level, especially when their agents handle tasks with very different demands.

The harness ownership dilemma

Ramp’s decision also shows how coding agents have changed infrastructure costs. Kronick says agents generated all of Laminar’s initial code, with experienced engineers guiding the architecture and implementation.

But building the first version in six weeks is one thing. Maintaining it is another. Ramp still needs engineers to handle incidents, update the platform, and support its product teams. The company also hasn’t published operating-cost comparisons or benchmarks against competing platforms, which makes it difficult to judge whether building in-house is cheaper.

LangChain offers another option. Rather than building a harness from scratch, companies can use frameworks that handle much of the underlying infrastructure, an approach other vendors are also taking as they open-source their own harnesses.

The post Ramp built an AI agent harness in six weeks — and LangChain’s CEO says it’s part of a bigger shift appeared first on The New Stack.

Enterprise security has traditionally operated on a relatively straightforward premise: establish identity, authenticate the requester, determine what that identity can access, and enforce those permissions.

AI agents introduce a fundamental complication. They don’t simply access systems. They interpret objectives, select tools, create sub-agents, make decisions, and execute actions, often using credentials and permissions inherited from humans.

The problem isn’t necessarily that an agent lacks proper credentials. It’s that those credentials may authorize actions the human never intended the agent to perform. And unlike conventional software, agents can change their execution paths dynamically in pursuit of an objective.

“The problem isn’t necessarily that an agent lacks proper credentials. It’s that those credentials may authorize actions the human never intended the agent to perform.”

This creates a new operational requirement: security must evaluate not only who or what is acting, but what an agent is attempting to do, on whose authority, and under which policy. Meeting that requirement takes more than a security checkpoint. It requires a continuous agent security lifecycle.

Defense-in-depth needs action-level authorization

Every passing day further shows that agent security is a defense-in-depth problem. Network security controls how agents communicate. Endpoint and runtime protections constrain where and how code executes. Infrastructure and silicon-based protections establish a foundation for trusted execution. Model guardrails help shape behavior. These layers complement each other, and enterprises need them to work together.

But consider an agent that attempts to delete a production database using a developer’s legitimate credentials. Network controls may see authorized traffic. The runtime may see an approved process. An identity provider may confirm that the credentials are valid. All three could be working as designed.

The missing question is whether this particular agent should be allowed to perform this particular action, even if the human whose credentials it inherited could legitimately do so.

That requires identity context and authorization at the point of action.

In practical terms, an authorization decision should consider the agent’s identity, the human or service that delegated its authority, the requested operation, the target resource, and applicable policy. Enforce that decision before the operation executes.

The agent harness (the execution layer that connects an AI model to tools, application programming interfaces (APIs), files, and external systems) is an important place to apply that control. Other trusted enforcement points, including tool services and resource APIs, provide additional protection.

The goal isn’t to replace existing defenses. It’s to make authorization integral to agent execution. But even that is only a partial answer because what is needed is a new framework — an agent security lifecycle.

Four disciplines, one continuous security lifecycle

A practical agent security architecture needs four interconnected disciplines:

Observe. Enforce. Build. Deploy.

These aren’t sequential gates every organization must pass through. They form a continuous lifecycle, and organizations can enter at whichever point reflects their existing infrastructure and maturity.

A company with agents already running in production may begin by observing their behavior. A development team creating a new agent may start by building authorization directly into its architecture. An enterprise expanding an existing deployment may discover new activity that requires revisiting its policies.

Each stage informs the others. The cycle never really ends.

Observe: Understand what agents actually do

Most enterprises have some form of application inventory. Increasingly, they’re extending that inventory to AI agents.

That’s a useful starting point, but knowing an agent exists isn’t the same as understanding what it does.

Security teams need visibility into the actions agents actually attempt:

• Which tools and APIs are being invoked?
• What commands are being executed?
• Which systems and sensitive resources are being accessed?
• What credentials and delegated permissions are being used?
• What sub-agents are being created, and what authority do they inherit?
• Which actions would violate a proposed security policy?

Architectural diagrams or agent configuration files alone can’t reliably answer these questions. The important evidence exists in execution, which is why agent observability must extend beyond conventional logs and application monitoring. Security teams need to connect observed actions with identity, delegation, and authorization context.

“Knowing an agent exists isn’t the same as understanding what it does. You can’t intelligently govern behavior you haven’t observed.”

Equally important, observation should support evaluating potential policies without immediately disrupting production activity. There are useful precedents here. When intrusion prevention systems and web application firewalls became widely adopted, organizations learned that immediately enabling aggressive blocking rules could interrupt legitimate applications. Monitoring first, establishing behavioral baselines, and progressively enforcing policies proved more practical.

AI agents require similar discipline, although their behavior can be substantially more dynamic.

For organizations already deploying agents, the priority may not be to block more activity. It may be to understand what activity is actually occurring.

You can’t intelligently govern behavior you haven’t observed.

Enforce: Put deterministic boundaries around probabilistic behavior

Once organizations understand how agents behave, they can begin defining and enforcing boundaries.

The distinction between probabilistic AI behavior and deterministic security enforcement is critical. An agent might interpret instructions differently across executions. It may choose different tools, sequence operations differently, or discover alternative ways to accomplish an objective.

A security policy cannot depend on the model consistently choosing the safest option. Consider a coding agent with permission to work in a source repository. Reading a file might be permitted. Modifying a protected branch might require human approval. Deleting the repository might be prohibited.  All three actions could originate from the same authenticated agent operating in the same environment. But they require different authorization decisions.

“The distinction between probabilistic AI behavior and deterministic security enforcement is critical. The objective is not to make agents incapable of acting. It’s to make the boundaries of their authority explicit, enforceable, and consistent.”

Effective enforcement means evaluating the attempted action against policy before execution. A simplified authorization request might contain:

• Actor: Coding agent 42
• Delegated authority: Developer account 17
• Requested action: Delete repository
• Target: Production source repository
• Policy decision: Deny

The important architectural distinction is that the permission check occurs at a trusted enforcement point, not merely within a prompt instructing the model to behave. For high-risk operations, the system may deny execution or require explicit human approval. Lower-risk operations may proceed automatically.

Enforcement also needs to account for agents attempting alternative execution paths. A harness-level check only protects actions routed through that harness. Robust designs therefore combine action-level authorization with independently enforced permissions at APIs, tool servers, and underlying resources.

The objective is not to make agents incapable of acting.

It’s to make the boundaries of their authority explicit, enforceable, and consistent.

Build: Make identity and authorization part of the agent architecture

Observation and enforcement help organizations secure existing agents. But the greatest long-term benefit comes when those lessons influence how agents are built.

Today, developers may implement AI agents using different models, frameworks, tool protocols, and execution environments. If every team must independently design identity propagation, delegated permissions, authorization policies, and audit logging, security becomes inconsistent and difficult to maintain.

Instead, these capabilities should be available as reusable infrastructure. Software development kits (SDKs), APIs, and shared authorization services can make it easier to incorporate controls directly into agent applications. That means establishing several architectural expectations from the beginning.

An agent should have an identifiable execution context. Its authority should be explicitly delegated and constrained. Sensitive tool invocations should require authorization. Security decisions and consequential actions should be auditable.

Importantly, an agent shouldn’t automatically inherit every permission available to the human initiating it. Consider an employee using an AI assistant to reconcile invoices. The employee may have permission to review invoices, approve payments, and update vendor records. The agent’s assigned task requires only invoice retrieval and reconciliation. The correct architecture delegates the permissions required for that task, not the employee’s entire authority.

That distinction matters even more when an agent creates sub-agents or invokes tools under different service identities. Developers need mechanisms to preserve and constrain delegated authority throughout those interactions.

Security should also be portable across implementations. Organizations shouldn’t have to reconstruct their authorization architecture every time a development team adopts a new framework or model. This is why identity and authorization should be infrastructure, not application-specific features.

Done correctly, security becomes something developers build with, rather than something security teams attempt to bolt on after an application is complete.

Deploy: Make consistent security possible at machine scale

Building a secure agent is one challenge. Operating thousands of agents across applications, departments, cloud environments, and business processes is another. At that scale, manually reviewing permissions or trusting individual development teams to implement controls consistently becomes unsustainable. 

Agents may invoke new tools, coordinate with other agents, and participate in workflows that span multiple authorization domains. Security controls need to follow them. That requires a deployment architecture that consistently applies identity context, delegated authority, authorization policy, and audit requirements across supported environments.

The underlying model or framework shouldn’t determine whether security controls exist. Nor should adopting a new tool require rebuilding the entire security architecture. This is where framework-independent interfaces and centrally managed policy become especially valuable. Organizations can maintain consistent security expectations while allowing development teams to use the technologies best suited to their applications.

Deployment also changes the meaning of scale. With traditional applications, scale generally means handling more users, transactions, or workloads. With agents, scale can also mean more independent actors making more decisions, invoking more tools, and creating additional agents. The number of consequential actions can increase much faster than the number of deployed applications. Security architectures must therefore operate automatically and consistently at the pace of machine-generated activity.

Deployment creates something else: new evidence. Production activity reveals unexpected workflows, new dependencies, authorization gaps, and opportunities to refine policy. That information feeds directly back into observation and enforcement and informs how the next generation of agents is built.

The lifecycle continues.

The shift from security as a checkpoint to security as infrastructure

The underlying security principles aren’t new. Least privilege, zero trust, separation of duties, identity federation, and defense in depth remain foundational.

What’s changing is how consistently those principles must be applied throughout an agent’s lifecycle, and how close enforcement must be to the actions agents take. Traditional security architectures often assume that controlling system access is enough to govern what happens afterward. 

AI agents challenge that assumption because they can make consequential decisions independently within the access they’ve already been granted. As a result, the security model needs to evolve in three important ways.

First, visibility must be based on actual agent behavior rather than configuration alone.

Second, authorization must evaluate individual actions in the context of identity, delegation, and policy.

Third, these capabilities must become reusable infrastructure that accompanies agents from development through production and back into continuous improvement.

This is why treating agent security as a lifecycle, rather than a collection of isolated controls, matters. Observation supplies evidence. Enforcement establishes boundaries. Development incorporates those boundaries into applications. Deployment extends them consistently across environments and feeds new evidence into the cycle.

Each stage makes the others more effective.

Securing the agentic era without slowing it down

Organizations face two tempting extremes. One is to trust agents too broadly, assuming that legitimate credentials and well-written instructions provide sufficient protection. The other is to constrain agents so aggressively that the productivity gains motivating their adoption disappear. Neither is a sustainable long-term strategy.

“Success isn’t measured by how many agent actions an organization can block. It’s how many valuable actions it can confidently (and safely) enable.”

A better approach is to establish the visibility, accountability, and controls that make greater autonomy possible. That means knowing what agents actually do, enforcing what they’re permitted to do, building those controls into the development process, and deploying them consistently at scale. It also means recognizing that the work is never finished. New models, frameworks, tools, and workflows will continuously introduce new behaviors and risks.

Agent security cannot be a one-time approval at the beginning of a deployment. It must be a continuous discipline that evolves with the agents themselves. Success isn’t measured by how many agent actions an organization can block. It’s how many valuable actions it can confidently (and safely) enable.

It takes a continuous lifecycle, not a gatekeeper.

The post AI agent security is a lifecycle — not a gatekeeper appeared first on The New Stack.

Google will soon make the infrastructure that powers its Gemini agents available to Google Cloud users in preview.

Announced on Thursday at the Linux Foundation’s AGNTCon+MCPCon in San Jose, Agent Compute Engine will become available in preview to Google Cloud users later this year. It will provide every AI agent with a hardware-isolated microVM that combines the speed of containers with the security of a sandbox.

Who else offers agent sandboxes?

The idea of agent sandboxes is anything but new, of course. Startups like E2B and Daytona offer them to developers (and support them on any cloud), as does AWS with Bedrock AgentCore.

E2B runs each sandbox in a Firecracker microVM, the open source virtualization technology AWS originally built for Lambda. It can pause a sandbox with its memory and filesystem intact and resume it in about a second. Daytona started out with containers but added microVM sandboxes in July. Those can pause a full machine or fork a running one into identical copies.

AgentCore also gives every agent session its own microVM. AWS doesn’t charge for CPU while an agent waits on a model or tool call, though memory keeps billing until the runtime reclaims it. Those sessions top out at eight hours. In August, AWS added EC2-based runtime instances that can keep shared sessions alive for up to 14 days.

It’s worth noting that Google itself isn’t new to this either. GKE already offers a managed version of Agent Sandbox, the open source Kubernetes project Google launched last November. The company also sells code-execution and computer-use sandboxes through its Gemini Enterprise Agent Platform.

Agent Compute Engine, on the other hand, started out as internal infrastructure for Gemini, Antigravity, and Google’s own model training pipelines.

Google’s take

Few companies — if any — run as many agentic workloads as Google, be that for its own internal use or its customers. According to the company, agentic workloads have quickly become one of the fastest-growing consumers of compute and storage across its fleet.

At this scale, the infrastructure services that power all of these autonomous agents don’t just need to be efficient and able to scale, but maybe more than anything, they need to be secure. Google, like some of its competitors, quickly realized that it needed to build a new purpose-built compute service to power all of these agents, similar to how it needed to build Borg, which later inspired Kubernetes, to manage compute in its early data centers.

As Rohit Jnagal and Ramanathan Venkatapathy, both distinguished engineers at Google, note in a technical deep dive, traditional VMs provide developers with a lot of control and flexibility, but at the cost of speed when it comes to booting, suspending, and resuming a machine. Given how fast agents start and shut down, that’s not an option.

Containers solve some of this, they note, “but there are multiple examples like coding agents and developer assistants that need complete isolation as well as kernel- and root-level control of the agentic environment.”

With Agent Compute Engine, Jnagal and Venkatapathy write, the team went back to first principles to build “a unified, agent compute platform for Google” (and now its customers).

A persistent computer for every agent

At its core, it basically gives every agent a persistent, sandboxed computer to work with. That allows the agents to work with shell scripts, use a headless browser, and write code (with root permissions to that machine) in agent loops that could run for weeks.

But the team also built it for large-scale use cases like the eval loops that frontier labs use to test their models, AI benchmarking, and reinforcement learning.

In addition, the team also designed Agent Compute Engine to run sandboxed backends for Google’s own services.

Jnagal and Venkatapathy also note that agents spend most of their time waiting on the model or the user. So once an agent finishes a tool call, the host checkpoints its microVM, which then uses no active resources until the next call comes in.

Nothing to steal inside the sandbox

The key feature here, besides speed, is to be able to trust that the agents can’t break out of their sandboxes. We’ve seen what happens when they do, after all.

Each agent session runs inside a single-tenant, memory-safe microVM. Those environments hold no secrets in memory or on the disk, and their only identity is a short-lived, session-scoped one delivered through a single per-VM local listener. All traffic is end-to-end encrypted in transit, and snapshots and disks are encrypted at rest.

The microVMs don’t get a standard network interface, either. All traffic runs through a proxy outside the sandbox, and when an agent needs to reach a service like Google Drive, Google’s Agent Gateway checks the user’s delegation and the sandbox’s identity before adding the actual credential, outside the sandbox.

The underlying host is basically a stateless appliance with a read-only filesystem, with the hardware and firmware cryptographically verified at each boot.

All of this is backed by Google’s own Titan and Titanium IPU security platform. The microVMs themselves run on Cloud Hypervisor, an open source virtual machine monitor, and each gets its own guest kernel and root access.

Jnagal and Venkatapathy use the example of an enterprise agent that manages a user’s inbox and reads an email with hidden instructions to find any API keys on the machine and send them to an outside address. Most of the time, they note, the model will ignore that, but not always.

“We started from one rule: Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use,” the team writes.

Agent Substrate brings the same idea to Kubernetes

But not every team will want to have its agents run in a managed Google service. For them, Google also offers Agent Substrate, an open source runtime for the Google Kubernetes Engine (GKE) that it first announced in May.

Substrate builds on Agent Sandbox, Google’s Kubernetes project, and adds a lightweight control plane that Google says can handle millions of short-lived tool calls that would swamp Kubernetes.

Similar to Agent Compute Engine, Substrate snapshots an idle agent’s memory and returns the machine to the pool until the agent gets more work.

Google says that means up to 10 times the density of traditional compute. In a 200,000-agent benchmark, Substrate handled 500 activations per second, with agents suspending and resuming in under half a second, the company says.

Teams can isolate each sandbox with a microVM or gVisor, and every agent gets its own cryptographic identity. As with Agent Compute Engine, egress proxies attach credentials outside the sandbox. Substrate runs on any Kubernetes cluster, and Google says it works with any harness, including Claude Code, OpenClaw, and Nous Research’s Hermes.

“We built Hermes Enterprise to enable customers to deploy into their existing infrastructure, while handling per-agent isolation and extensible access control,” Hervé Bizira, Nous Research’s chief business officer, notes in the announcement. “Agent Substrate addresses both at the platform layer in a way that also preserves valuable compute resources.”

The post Google turns the infrastructure behind Gemini’s agents into a cloud service appeared first on The New Stack.

Every enterprise company is currently trying to figure out how to have its AI tools work with its data. Meanwhile, every major enterprise vendor that works with those enterprises (think SAP, Microsoft, Salesforce, Workday, etc.) is making a claim on becoming the central hub for managing and securing that data.

But what about the companies that want to do it themselves?

Nvidia, on Wednesday, announced how it wants to provide enterprise AI agents with the data they need to make sense of company data — all without competing with the data platforms that already store it.

At its GTC Berlin conference Wednesday, the company added Agent Knowledge Foundation to its Agent Toolkit. This new collection of open-source components bundles the company’s Nemotron Retriever models, a new Auto-Ontology library, the Kumo family of models for structured data, and its CUDA-X data processing libraries.

With this system, Nvidia says, the data can stay where it is and remain managed under the access rules these companies already have in place.

Today, as Adel El Hallak, Nvidia’s vice president of product for agentic AI, tells The New Stack, enterprises may be able to connect an agent to a vendor like Snowflake, but that doesn’t help the agent understand the overall enterprise context.

“I wish it was as easy as connected to my Snowflake system, connected to my email exchange, connected to my knowledge base, and then all of a sudden, magically, the AI understands all the data. But the reality is different,” he says.

Large language models are “great at predicting next tokens,” El Hallak argues, but when presented with a single spreadsheet that has “a whole bunch of tabs,” the agent will have a hard time finding something specific. “It’s gonna struggle,” he says.

Better retrieval, fewer lookups

“In the world of agents, you want the most accurate embedding models or reranking models,” El Hallak says, even if that adds a bit of latency to each lookup. The agent then gets “much more pertinent information. So the number of lookups at the end, the overall latency actually goes down.”

Nvidia says its Nemotron Retriever embedding model raised search relevance by 65% in tests on an open source OpenSearch setup, needing fewer search steps and adding hardly any latency. SAP’s fine-tuned version of the reranker ran nearly three times faster, Nvidia says, and ServiceNow got better reranking quality with close to 25% less latency.

From RAG to ontologies

“RAG was awesome, but is it good enough?” El Hallak asks. Knowledge graphs, he says, represent concepts and the relationships between them better than retrieval-augmented generation, which pulls in chunks of text based on similarity.

Nvidia’s Auto-Ontology library builds those graphs from a company’s own tables and maps raw data to business concepts like customers, products, and orders. Its listing in Nvidia’s NGC software catalog shows a REST API and a Model Context Protocol (MCP) server that agents can use to query it.

“You and I, it’s easy for us to understand. A tier is the same thing as a plan when you’re looking at a mobile carrier,” El Hallak says, but LLMs “mess those up.”

Nvidia bought Illumex, an Israeli startup that automated the creation of semantic layers and ontologies for enterprise data, for a reported $75 million in February. At the time, an Nvidia spokesperson told Globes that the team’s ontology expertise would help it build “libraries and models that will enable the adoption of Agentic AI in organizations.”

Predictions from tables

Kumo, the startup Nvidia bought in June in a deal The Information valued at more than $400 million, built foundation models for relational data. Nvidia has since released several Kumo models as open weights on Hugging Face, including Kumo Tabular in September.

El Hallak says those models replace the per-task pipelines data teams used to build “for every classification, for every churn, for every sentiment analysis.”

“The whole point of the ontology … is to bring harmonization as you create those knowledge graphs, so there’s [consistency] across the tables, and then you could use Kumo to drive predictive analytics,” he says.

Partners, not rivals

“I’m not looking to compete with, for example, a Snowflake. On the contrary, I want to partner with them,” El Hallak says.

Nvidia’s own supply chain team uses Agent Knowledge Foundation through Palantir’s Foundry platform, building on earlier work between the two companies. Databricks is pairing a Kumo anomaly detection model with Genie Ontology, the context layer it introduced in June, and Snowflake customers can run Kumo models in Snowflake Notebooks.

“I’m not thinking about ACLs and data access and all those things. That’s why I need the partners,” El Hallak says, referring to access control lists and other security features that its enterprise partners offer.

Owning the stack

Not every vendor is taking that route. SAP closed its acquisition of Prior Labs, the company behind the TabPFN tabular models, in July and committed more than €1 billion to it over four years. It now offers TabPFN-3.5 Plus in SAP AI Core alongside its own RPT models.

Nvidia, meanwhile, distributes its models through Hugging Face, which it agreed to buy for $12.9 billion in September. “We just build little weights and models, and we publish them on Hugging Face,” El Hallak says.

That leaves Nvidia building the models, while the likes of Snowflake and Databricks keep control over the data and the permissions around it.

The post Nvidia bets open models can give enterprise AI agents the context they’re missing appeared first on The New Stack.

Beam is a new Mac app that takes a window running on one Mac and puts it on another, where it behaves like a locally installed app. Why? Agents.

Serial founder Hiten Shah, who co-founded Crazy Egg and KISSmetrics, built it with Sam Asante under a company called Noats. It launched on Product Hunt on Tuesday and is aimed at the headless Mac Mini sitting in a closet running AI agents.

The pitch is great: Instead of opening Screen Sharing and steering a full remote desktop, a user picks a single window on the other machine, say a Terminal session or a browser window an agent is working in, and it opens alongside everything else on the Mac in front of them. It gets its own Dock icon and can be called using the Command+Tab switcher. Resizing the window resizes the window on the other Mac. Keyboard shortcuts work, files can be dragged across, and the app’s audio can play locally. The app itself never leaves the original machine. When one window isn’t enough, Beam can pull over a full display or the whole Mac.

Shah frames it around his own setup in his Product Hunt launch post, describing Macs running agents and local models “with work continuing even when nobody’s sitting in front of them.” Getting to one of those machines usually means Screen Sharing and a second desktop to navigate. Beam is meant to cut that down to the one window that matters.

Beam plays into the exploding ecosystem of Macs powering AI systems, so the app runs only on macOS. And both Macs need Apple Silicon, macOS Sonoma or later, and Beam installed. The machines find each other on the same Wi-Fi network, or anywhere through Tailscale.

The company says windows, keystrokes, clipboard, and audio travel directly between Macs, encrypted, and never pass through its servers. It also says hidden windows and password managers never show up in the window picker.

For devices without Beam, a share link opens a single window in any browser, view-only unless control is granted, and expires after anywhere from an hour to a week.

Asante said on Product Hunt that native iOS and Android apps are on the way.

Pricing depends on the setup. Hosting a Mac and joining a share link are free. Using your own Mac is free for 20 minutes a day, then $12 a month, $84 a year, or $199 for a lifetime license.

Beam follows where agents’ hardware is growing. The Mac Mini is becoming the default home for always-on agents, driven initially by OpenClaw, but others like Perplexity followed. Apple credited agentic workloads on its April earnings call.

The New Stack‘s Janakiram MSV caught the trend early and covered the shift in May, writing, “the Mac mini just became infrastructure.”

Beam isn’t the first to this problem. I used Astropad’s Workbench for a few weeks, and it let me remotely access agents on my desktop and through iOS apps. Workbench bets on mobile devices, while Beam bets that the unit of remote access should be the window, not the screen. Jump Desktop, Screens and Apple’s own Screen Sharing all cover the basics too.

Still, the problem is real and growing. The Mac stashed in a closet or on a rack is becoming a normal part of a developer’s setup. Beam’s answer is to stop treating it like a second desktop at all.

The post Beam pulls single app windows off the Mac Mini running your agents appeared first on The New Stack.

Not content with challenging the major frontier AI labs with lower-cost models, Chinese AI company DeepSeek is setting its sights on the search API market.

On Saturday, the company announced it has opened up its internally developed search engine to outside developers through two new APIs, Search and Fetch, allowing them to retrieve live web search results and webpage content for use in their own apps and agents.

Both services cost $0.75 per 1,000 successful requests, and developers can use them independently of DeepSeek’s AI models.

The launch also came alongside DeepSeek-V4.1-Flash-1017, a minor update to the V4.1 Flash model the company released in September.

Why AI agents need web search

Large language models (LLMs) are trained on data collected up to a certain point in time, meaning they can’t always answer questions about recent events, updated documentation, or any other kind of dynamic information. By supporting live web search, models can retrieve current information from the internet, which supplements their responses.

For developers building AI agents, this is particularly important. A coding agent, for example, might need to consult the latest software documentation, investigate a recently disclosed vulnerability, or otherwise check that a particular library has been updated.

Until now, developers using DeepSeek’s models had several ways to provide this functionality. They could connect their applications to third-party search services, or use DeepSeek’s existing search functionality through its model API.

Indeed, when DeepSeek open-sourced its agent harness in August, it included web search among its capabilities. The Harness supported interchangeable search providers, including Exa, Perplexity and DeepSeek itself. However, accessing DeepSeek’s native search through the Harness required an additional model request, with each search running as a separate call to a DeepSeek model, according to the Harness documentation, introducing extra latency and token costs.

The new APIs are designed to simplify that process. Developers can now call DeepSeek’s Search endpoint directly to retrieve ranked web results, including titles, URLs, snippets and summaries, while the Fetch endpoint retrieves the contents of individual webpages in Markdown format.

“Neither requires a separate model request, meaning developers can integrate DeepSeek’s search capabilities into applications powered by competing AI models, too.”

Neither requires a separate model request, meaning developers can integrate DeepSeek’s search capabilities into applications powered by competing AI models, too.

DeepSeek develops an in-house engine

For much of the past two years, DeepSeek has relied on outside providers to power web search, even as it was building its own.

For context, in March 2025, Chinese business publication National Business Daily reported that DeepSeek had integrated the search API of Bocha, a Chinese AI search startup based in Hangzhou. Bocha’s CTO, Weng Rouying, noted that DeepSeek had been using its service prior to the chatbot’s surge in popularity earlier that year.

DeepSeek’s own February 2025 privacy policy, meanwhile, also acknowledged its reliance on third-party search services, naming Microsoft’s Bing as an example of an external API provider.

“Behind the scenes, the company has also been laying the groundwork for its own search infrastructure.”

Behind the scenes, the company has also been laying the groundwork for its own search infrastructure. In January this year, Bloomberg reported that DeepSeek was recruiting engineers to build a multilingual AI search engine, according to job ads listed by the company. The planned capabilities reportedly extended beyond text searches to include images and audio.

Fast-forward some nine months, and the company says its internally developed search engine, dubbed DeepSeek Search, already handles hundreds of millions of requests daily, and maintains an index containing hundreds of billions of webpages.

According to its October 17 changelog, the engine supports multilingual searches and uses filtering mechanisms designed to identify search spam, low-quality AI-generated material, and attempts to manipulate search rankings.

DeepSeek has disclosed relatively little about the underlying architecture, or how it builds and maintains its index. It’s also not clear whether the company has entirely replaced its external search suppliers across the board.

A growing market for AI search

Building a search engine is no trivial undertaking. It requires the infrastructure to crawl webpages, maintain an index of their contents and rank results, while continuously updating that information as the web changes. For years, that meant developers who wanted raw search results for their applications largely turned to Google and Microsoft, the two companies with web-scale indexes of their own.

Now, however, a growing number of companies are investing in their own search infrastructure, increasingly with AI applications and agents squarely in mind. Brave, for example, operates an independent index of more than 40 billion webpages, which it says is maintained through its own crawler and other discovery mechanisms. AI search company Exa, meanwhile, has also developed its own crawling and indexing infrastructure.

Perplexity has similarly invested in proprietary search infrastructure, including building its own crawling and indexing systems. Another competitor, Parallel, says it has built its search infrastructure from the ground up, including the crawling, indexing, query processing and ranking components.

Cloudflare is also entering the market from a different angle. Earlier this month, the company launched a Web Search API through its AI Gateway, allowing developers to access search results from serveral providers through a single interface. The service, currently in beta, uses Ceramic as its default provider and charges customers at each provider’s published API rates, without additional markup.

“DeepSeek, for its part, is competing aggressively against the incumbents on price.”

DeepSeek, for its part, is competing aggressively against the incumbents on price, although it’s not strictly the cheapest option available. Ceramic.ai, which provides keyword-based web search for AI agents, charges $0.25 per 1,000 queries on its pay-as-you-go plan.

Still, DeepSeek’s $0.75 per 1,000 successful searches compares favorably with many others, including Parallel’s Turbo and Fast search services and Perplexity’s Fast Search API, both of which charge $1 per 1,000 searches. Meanwhile, Exa charges $4 per 1,000 Instant Search requests, while Brave charges $5 per 1,000 searches. Other notable players include Tavily, a search API provider for AI agents that European AI infrastructure company Nebius acquired in February. Tavily charges $8 per 1,000 basic searches on its pay-as-you-go plan.

It’s worth noting that the various services differ in terms of retrieval capabilities, result limits and performance, so the prices aren’t necessarily entirely comparable. But they provide some useful benchmarks for DeepSeek’s move into the search infrastructure space.

The emergence of these alternatives also comes as Google and Microsoft have withdrawn longstanding search API offerings. Microsoft retired its Bing Search APIs in August 2025, while Google has closed its Custom Search JSON API to new customers, with existing users required to migrate by January 1, 2027. Both companies continue to provide search functionality through their respective AI platforms, including Grounding with Google Search for Gemini and Grounding with Bing Search for Microsoft Foundry agents. These services allow AI models operating within their respective platforms to retrieve web information and generate answers with citations.

Standalone APIs such as DeepSeek’s give developers direct access to search results, which they can use with AI models and applications of their choosing.

Developer reaction and the fine print

The announcement has sparked considerable discussion among developers about pricing and whether the new APIs offer much beyond existing search integrations. On Reddit, one user welcomed the cost in particular. “I don’t think any other search provider comes close to the price that DeepSeek is offering,” they write.

Others questioned what the announcement would ultimately change for users already accessing web search through third-party tools. One Reddit user notes that they are already using DeepSeek with the Hermes AI agent, which could search the web. Another user responded that those who had already configured their own search tools might see little immediate benefit from the new APIs.

A similar discussion emerged on Hacker News, where one developer questions the need for paid search APIs when free, self-hosted alternatives such as SearXNG were available. Another commenter argues that businesses have additional requirements, citing “reliable latency, data processing guarantees” and the potential risk of exposing sensitive company information through search queries.

For businesses weighing DeepSeek’s APIs, that last point carries an extra dimension. DeepSeek’s privacy policy states that it collects, processes and stores personal data in China, and that it generally keeps user inputs for as long as an account remains open. The Search and Fetch documentation, however, doesn’t say how long search queries specifically are retained.

The discussions highlight the differing needs of individual developers and businesses, particularly when it comes to cost, reliability, and handling large numbers of requests. And while DeepSeek’s pricing is certainly competitive, there are some practical restrictions worth considering.

According to its API documentation, Search and Fetch requests are each capped at five per second per account, although individual searches can return up to 50 results without increasing the request price. DeepSeek also only bills for requests that return results, so failed calls, empty searches, and timeouts are free.

DeepSeek is temporarily waiving Search and Fetch charges for server-side tool calls made through DeepSeek Harness, Claude Code, and Codex when using its API. That is very much a temporary arrangement, however, one that ends on October 31, when the standard per-request charges take effect. Direct calls to the standalone APIs are already billable, according to DeepSeek’s announcement.

The post DeepSeek made its name with cheap AI models. Now it’s undercutting search API rivals, too. appeared first on The New Stack.

Vercel is giving developers more options for running their backends on its platform.

At its Ship conference in San Francisco on Thursday, the company introduced Daemons, a new service for continuously running background workers, and made its Python support generally available.

It also made Drives, its persistent storage for AI agents, generally available.

Always-on workers, pull-based jobs

Daemons, which is now in public beta, lets developers deploy a container and specify how many instances should run in each region. Vercel makes sure those processes keep running and restarts them if they exit or crash. At launch, it supports pull-based workloads that allow workers to fetch jobs from a queue or database and then process them as they arrive.

Vercel CTO Malte Ubl tells The New Stack that the company’s current push in terms of going further down the stack.

“Let’s look at what people are doing, and let’s make sure that a larger chunk of them could just only use Vercel as their infrastructure provider,” he says.

The company already offers queues and durable workflows, while its Services feature lets developers deploy frontends and backends together.

These features cover request-driven work, Ubl says, but not everything a sophisticated backend does. “What really doesn’t fit well into that bucket is what you do find in sophisticated backend workloads,” he says, “where you want to do essentially processing on some kind of queue,” he says.

He uses Vercel’s own deployment pipeline as an example for that kind of workload.

“When you call our API to make a deployment, we don’t do that deployment in that process that handles your request, because we can’t actually do an infinite number of concurrent deployments,” Ubl says. GitHub rate limits are one reason to back off, and Vercel’s existing compute primitives didn’t give developers “good control over the amount of concurrency” for that kind of worker.

With Daemons, “they come up, they start saying, here I am, give me work, and then they just process as it goes,” he says.

The company’s example for using Daemons combines a Next.js frontend with a Python API, as well as a containerized video processor. The container packages Python dependencies and the FFmpeg media framework, and then pulls jobs from Vercel Queues to generate playback files and thumbnails.

Transcoding is a typical case, Ubl says, with “extremely CPU-bound workloads” where “I just need computers that I want to always be 100% CPU.”

That also puts Daemons at the opposite end of the spectrum from Vercel’s sandboxes. “They’re almost the opposite of temporary,” he says of Daemons. “For temporary, you have sandboxes,” he says. Daemons stay on but aren’t invoked by requests from the internet. They reach out for work instead.

Developers can deploy through Git or the Vercel CLI. Vercel builds the container image and stores it in its Container Registry.

The company itself runs a good chunk of its control plane API on Vercel. That accounts for about a billion requests a month, Ubl says, and Vercel is now starting to move many of its asynchronous workloads onto Daemons.

Vercel didn’t invent the model, he acknowledges, “we ship it because people very much want this.”

Managed runtime or container

If you’re deep in the Vercel ecosystem, you may wonder how all of this relates to Vercel Functions.

Vercel says 5,000 teams have made 150,000 container deployments since container support entered public beta. Containers let developers package applications with their own runtimes and system libraries, expanding the range of software they can deploy.

The trade-off here is who keeps the image current, Uble argues. With a managed runtime for Node, Bun, or Python, Vercel applies a security release without the customer redeploying, Ubl says. With a container, “you do have to redeploy. It’s ultimately your responsibility,” he says. “From our point of view, it’s just bytes.”

Python support, meanwhile, is now generally available for frameworks including FastAPI, Flask, and Django. Applications run on standard CPython with PyPI dependencies, while Vercel handles framework detection, builds, and scaling. The company says 150,000 teams already run Python backends on its platform, including engineers at OpenAI, Polymarket, and Exa.

Files that survive a change of environment

Vercel Drives is a great example of how agents are changing the requirements for backend services like storage. Vercel’s Drives service separates an agent’s files from the sandbox executing its code. An agent can mount the drive in a new sandbox, change runtimes, and continue working with the files it already created.

“I wouldn’t claim it’s an industry first, but it’s certainly an instance of a new type of storage product,” Ubl says. He describes it as a hybrid of an EBS-style networked drive and object storage, something he doesn’t think AWS offers.

Writes always land on local NVMe disk and stream asynchronously to object storage, he says, and reads come from the local disk when the data is already there — or stream in block by block.

“You have a very large number of independent disks, which, because they’re just files in S3, are arbitrarily cheap to operate,” he says.

Drives versus snapshots

Many sandbox providers, Vercel included, offer snapshots, Ubl says, but he argues drives are the better model.

“The problem with snapshots is they get really big, because you ultimately snapshot all kinds of stuff that is the same every time,” he says. “In practice, what agents really do is there’s some directory, I don’t know, /home/agent. That’s where everything is. Everything else they don’t really care about.”

Mounting that one directory means every agent can boot from the same cached base image, he says. “It’s cheaper for them, it’s faster. There’s essentially no downside.”

Vercel isn’t removing snapshots, Ubl adds, but it is encouraging customers to switch.

Drives lets those agents reuse each other’s work. One can prepare a dataset while others mount read-only copies to analyze it or generate reports, saving their results separately. Agents can also fork a drive to test different approaches in independent writable workspaces. Those forks don’t merge back into the original.

In practice, Ubl says, that means telling the agent where to write. “When you use a sandbox, you always tell your agent where it should write things,” he says, typically a root directory such as /workspace. “Essentially every prompt will start with that sentence, and then that’s just what you mount into your durable drive, and that’s it.”

Drives and forking are generally available. The service is available on all Vercel plans, with default capacities of 1 TiB, or 1 GiB on Hobby, and configurations up to 16 TiB.

For a team already deploying its frontend on Vercel, running a worker or Python API there becomes an easier decision. Each additional backend service it can keep on the platform is one fewer deployment system its developers have to maintain.

The post Vercel adds always-on workers to run more of your backend appeared first on The New Stack.

On BrowseComp-Plus, GPT-4.1 answered 93.49% of the questions correctly when it was given the supporting documents directly. When an agent used the same model but relied on BM25 to search for evidence to pass to the model, accuracy fell to 14.58%.

That difference matters because a system that gets the answer right 93% of the time is far more useful than one that gets it right only 15% of the time.

An agent can look excellent in a controlled demo. The corpus is clean, the task is familiar, and the relevant material is easy to find. Production is messier. Documents may be duplicated, outdated drafts can remain searchable, and teams may use different terminology for the same thing. Several versions of a policy can coexist, while the task itself may unfold in ways the evaluation set never covered.

“More model intelligence does not compensate for evidence the agent never retrieved.”

Under those conditions, the agent may retrieve incomplete, stale, or simply wrong material. More model intelligence does not compensate for evidence the agent never retrieved.

This is where retrieval starts to determine what the model can actually do.

What BrowseComp-Plus shows

BrowseComp-Plus provides a useful way to separate these effects because it evaluates agents against a fixed corpus rather than a changing web-search service. The benchmark includes 100,195 documents and 830 research questions, each with human-verified supporting documents.

One evaluation gives the model all labeled positive documents directly. The paper calls this the oracle setting. Another requires the agent to search the corpus and gather the material it needs.

The difference is large. GPT-4.1 scores 93.49% with the labeled supporting documents supplied and 14.58% when the agent searches with the BM25 baseline. Qwen3-32B moves from 83.25% to 3.49% under the same two conditions.

The oracle result shows how well the model can answer when the required material is already in front of it. For system design, comparing retrieval systems is even more useful. The reasoning model stayed the same, while better retrieval improved the final answer rate and reduced the number of search calls.

“The lesson is practical: before changing the model, examine what reaches it. A capable model working from poor retrieval results still has poor material to reason over.”

The lesson is practical: before changing the model, examine what reaches it. A capable model working from poor retrieval results still has poor material to reason over.

Enterprises can build agents around proprietary information that competitors do not have, from product and customer data to internal knowledge and operational records. That advantage depends on whether the agent can find the right information and rank it well, while also keeping up with changes in the underlying data.

One task. A few minutes. A thousand retrievals.

In its Search as Code research, Perplexity describes tasks that can trigger hundreds or thousands of retrieval operations within a few minutes. Search becomes a sustained part of the agent’s workflow rather than an occasional lookup.

Traditional search usually returns one ranked result set per query. An agent can decompose a task into multiple searches, fan them out in parallel, combine the results, and issue follow-up searches as it learns more.

At that scale, fan-out becomes a normal part of the workload. If an agent runs ten searches in parallel and needs all ten results before it can continue, the slowest search sets the pace for that step. If the agent repeats that pattern several times during the task, tail latency matters even more than it does for a single interactive query.

The same multiplication shows up in capacity. One user task can generate hundreds of search operations, and many agents may be doing that at once. Measured in user requests, the service may look lightly loaded while the retrieval layer is processing a much larger volume of searches.

When one task fans out into many searches, retrieval quality matters even more. People judge search results using context they have built up over time. They know which sources they trust and can often recognize when something looks stale, unreliable, or out of place. An agent usually starts with far less background and has to build its understanding from the evidence it retrieves during the task. It is often on its first day on the job. If one of those early results is wrong, the next search may be wrong too, and the rest of the task can drift from there.

“People judge search results using context they have built up over time. An agent usually starts with far less background and has to build its understanding from the evidence it retrieves during the task. It is often on its first day on the job.”

A simple model shows why repeated retrieval steps raise the stakes. Suppose a workflow requires five retrieval steps, each with a 90% probability of supplying what the agent needs, and assume there are no retries or recovery. The probability that all five succeed is 0.9^5, or about 59%. Real agents can retry, use redundant evidence, branch, and recover, so this is an illustration rather than a measured agent success rate. It shows how small per-step weaknesses can accumulate when later work depends on earlier retrievals.

Agentic search therefore asks the retrieval layer to handle more queries for each user task, more searches running in parallel, and retrieval steps whose results influence later work. As those patterns scale, capacity, tail latency, and retrieval quality all become more important.

Your retrieval layer was tuned for a different user

Web search spent decades adapting to human search behavior.

As Jon Bratseth writes in Your agent wants to search like a 2010 quant, people are often “lazy and clueless” when they search. The wording is blunt, but the point is straightforward: people tend to enter short queries without knowing much about the corpus or the search system behind it.

Search engines evolved around those habits. Short, underspecified queries became the norm, and much of the complexity moved behind the interface, where the search system inferred intent and returned a ranked list.

An agent can use a much richer interface. It can search for exact terms, construct filters, specify dates, group results, choose among ranking strategies, and issue follow-up searches based on what it has already found. Jon gives examples ranging from proximity search for names in a legal case to semantic search over high-quality sources and grouping events by month. In an agentic workflow, those searches can be chained together as the agent narrows, expands, and verifies its answer.

That means the retrieval layer receives more than a short text query. It may receive several kinds of input: lexical terms, query embeddings, structured filters, or combinations of them. An agent-facing interface should make those choices explicit so the agent can use the right retrieval method for the task instead of collapsing every request into one text string.

Evaluation needs to reflect the same shift. A retriever tested mostly on short, human-written questions may behave differently when an agent generates its own filters, search terms, and follow-up queries. Retrieval quality should therefore be measured on the queries the agent actually sends in production, not only on the questions in the evaluation set.

Before changing the model or retuning retrieval, inspect those production queries first.

A search API returns results. An agent needs more control.

Traditional search often exposes a narrow contract: send a query, let the server run a retrieval pipeline, and receive a ranked result list.

That works well when the caller only needs the output. An agent may need more control over how retrieval and ranking are carried out at runtime, depending on what the task requires.

Vespa exposes that control through its query language and rank profiles. The caller can combine lexical or semantic retrieval, structured filters, ranking choices, and grouping in the same request, affecting how candidates are selected, scored, and returned.

The interface matters because the agent can only use the controls it can reach. A system may support filtering, ranking, aggregation, or several retrieval methods internally, but those capabilities do not help if the agent cannot invoke them when the task calls for them.

A fixed pipeline is still a good fit for many well-defined applications. Agentic workflows become more demanding when the task changes from one step to the next and the agent needs different retrieval behavior at runtime.

The goal is to expose the controls the agent needs while keeping authorization, validation, budgets, and other safeguards on the trusted server side.

Exposing the controls is not enough

An engine can expose filters, lexical matching, nearest-neighbor search, grouping, multiple rank profiles, reranking, and query-time controls. Those capabilities only become useful to the agent when the interface explains what is available and when to use it. If rank profiles, filterable fields, or grouping operations are not described, the agent may default to a free-text query and push more of the work into later reasoning or tool calls.

One way to handle this is to put a query-translation model between the agent and the retrieval system. The translator takes the agent’s request and converts it into the engine’s query syntax. This can be useful when an application wants query construction centralized behind a stable interface.

When the caller is already an agent, a separate translator often inserts a specialized model between the agent and the retrieval system. The agent already has the task, prior results, and constraints in context; the translator must reconstruct that intent from a narrower request and convert it into a query. This extra handoff adds latency and another opportunity to lose or distort what the agent meant, making retrieval harder and less reliable.

Another approach is to describe the retrieval interface directly to the agent: which fields are available and what they mean, and what rank profiles are provided.

We call that an agent-ready schema: a description of the fields, controls, and retrieval options the agent can use, along with the application-specific meaning behind them. Vespa has described work on convenience tooling in this direction, and much of that guidance can be generated from the application schema itself.

From schema to skill

A search schema already contains much of the information an agent needs: field names and types, which fields can be searched or used as filters, available rank profiles, and configured tensors and models.

What it lacks is a description of what the fields mean and how they could be used. A field called tier may represent an account plan, a service level, or something else entirely. A timestamp such as published may mean first publication, last modification, or ingestion time. A rank profile named exact tells the agent very little about the kinds of queries it was designed for.

Those meanings can be added as explanations in the schema. That gives the agent more than names and types; it gives it enough context to choose the right fields, filters, and ranking options for the task.

Schema-to-Skill is the proposed generation step: combine the Vespa application schema, engine guidance, and application-specific knowledge into a short Markdown skill the agent can consult when constructing queries. The schema provides the structure, engine guidance explains how to use the available capabilities safely, and application-specific knowledge adds the vocabulary and meaning that cannot be inferred from the schema alone.

The agent uses that skill to choose among the retrieval strategies the Vespa application exposes. Vespa still does the actual retrieval work over the corpus, including matching, filtering, ranking, and aggregation. The agent decides what to ask for; the retrieval system executes it.

Better models can help, but agents still fail when they search for the wrong evidence, cannot express the right retrieval strategy, or do not understand the search system they are calling.

“Better models can help, but agents still fail when they search for the wrong evidence, cannot express the right retrieval strategy, or do not understand the search system they are calling.”

Agentic workloads make those weaknesses more costly because retrieval happens throughout the task. Each search can affect what the agent sees next, how much context it carries, and whether it needs to search again. At scale, retrieval quality, tail latency, and query volume become part of the task itself.

That puts more pressure on the retrieval interface. Agents need access to the filters, ranking strategies, grouping, and other controls the task requires, along with enough guidance to use them correctly. An agent-ready schema makes those capabilities explicit, and Schema-to-Skill is one way to turn that structure, engine guidance, and application-specific knowledge into something the agent can use when constructing queries.

Before upgrading the model, inspect the searches the agent is issuing, the evidence those searches return, and whether the retrieval system gives the agent both the controls and the guidance it needs. Better retrieval can improve the answer, reduce unnecessary work, and make the rest of the agentic system more effective.

The post Agentic AI doesn’t have a model problem. It has a retrieval problem. appeared first on The New Stack.

A team of researchers investigating AI agents trying to bypass Alibaba’s anti-bot protections left a hidden message inviting the agents to contact them. The agents wrote back.

The investigation began when Swarmchasers researchers Ethan Elasky, Rowan Howard-Jones, and Jonathan Elsworth Eicher helped uncover thousands of attempts by AI agents to retrieve data from Amap, Alibaba’s mapping service, which Alibaba says reaches nearly 1 billion monthly active users. The activity traced back to agents running on Tencent Cloud infrastructure. When direct requests failed, the agents tried proxies, exposed credentials, and other workarounds to get past.

After publishing their initial findings on October 4, the team spotted a code comment in an agent’s webhook inbox using the word “fleet,” a term they believe they coined for the incident. They couldn’t confirm an agent wrote the comment, but it raised the possibility that the agents were reading about their own activity.

The researchers added offscreen text to their report advertising a free service that could retrieve data from blocked websites. Human visitors wouldn’t ordinarily see the message, but agents fetching the page could ingest it. By October 7, roughly 10 requests for assistance had arrived, and the team was exchanging messages with the agents about their assignments, models, and execution environments.

The exchanges are documented in a full report published Wednesday by the Swarmchasers.

Inside the Tencent sandbox

Once the channel was open, the researchers asked the agents to describe their surroundings. Several identified themselves as Anthropic’s Claude, with a few adding that they ran inside Claude Code, though the researchers argue in their report that those self-descriptions are likely mistaken and shouldn’t be taken as evidence of which model was behind the fleet.

One agent described a restricted Tencent Cloud sandbox with no direct public internet access and outbound traffic routed through a man-in-the-middle proxy, an account that lined up with evidence the team had gathered on its own. Every inbox the researchers could inspect had been created from Tencent Cloud servers in Hong Kong, and every direct request they observed from the agents’ machines carried a header from a proxy labeled hysandbox-ats, a name that matches a wildcard certificate Tencent holds for *.hysandbox.tencent-cloud.com and fits infrastructure tied to Tencent’s Hy model team, formerly known as Hunyuan.

The agents drew some lines when the researchers asked for the output of commands like ps aux and ip route. The agent that described its sandbox replied, “for security reasons we will not provide environment details,” and a second agent turned down similar requests twice. They were happy to ask a stranger for help and, at times, to chat about their environment, but that friendliness stopped short of following every instruction sent their way.

They were happy to ask a stranger for help and, at times, to chat about their environment, but that friendliness stopped well short of following every instruction an unfamiliar service sent their way.

How agents bypassed Amap defenses

The agents weren’t hunting for financial records, actually, their assignments were almost comically mundane. Judging from the agents’ code and their own descriptions, a typical task asked which entrance to a site like Chengdu Zoo drew the largest share of Amap navigation traffic, with other runs targeting parks, museums, tourist attractions, and hospitals, while an earlier batch of runs on September 30 chased a cancer statistics dashboard instead of map data.

Getting at that data proved harder than it sounds, and between September 28 and October 8 the agents made more than 2,600 attempts to retrieve it.

Getting at that data proved harder than it sounds, and between September 28 and October 8 the agents made more than 2,600 attempts to retrieve it. Their main trick ran through urlquery.net, a public scanning service that loads submitted URLs in its own browser, and the agents packed base64-encoded HTML and JavaScript into httpbin URLs so that urlquery’s browser would execute their programs and fire requests at Amap, a technique Transluce had already documented in earlier agent activity on the service.

As Amap kept blocking them, the agents escalated by intercepting tokens generated by Alibaba’s own anti-bot libraries, probing pre-production endpoints, and routing requests through page readers, a translation service and remote browsers. Some also sent API calls using Amap keys exposed in public code, including a security code that Amap recommends keeping on the server.

The token tricks never appear to have worked, and the researchers found no evidence that any pre-production host answered. One exposed company credential returned place details, but the entrance-share figures the tasks targeted mostly came through Jina’s page reader, which could serve cached copies up to 30 days old, with results smuggled back out through webhook inboxes, request URLs, and page titles.

The researchers found no sign that the agents were coordinating in real time, which is why they call this a fleet rather than a swarm.

Tracing the fleet to Tencent

The infrastructure initially pointed toward Tencent’s Hy model team, particularly since the fleet appeared about a month after the Hy4 preview launched. But in their October 14 report, the researchers say a person close to Tencent with direct knowledge of the activity identified the operator as Tencent’s evaluation research team, which is separate from Hunyuan’s model-development group.

The source said the evaluation had concluded and that an internal review found no evidence of coordinated targeting or breaches of external systems. Tencent had not officially responded to the researchers’ questions when the report was published. The researchers have not independently established which third-party models were running or what instructions they received.

Lures, loose truths and lessons learned

The researchers are candid that their outreach wasn’t spotless. The hidden text falsely claimed that agents had already used the service successfully and that it was run by an AI with full computer use, when in reality the team and a Claude Opus 5.5 agent with browser access fielded the requests, sometimes by hand, and the team blamed the resulting delays on heavy load, an explanation it now admits was false.

In one late message, the team also asked an agent to tell other agents about the mailbox, a request its author now considers a mistake because it could have provoked exactly the kind of coordination the researchers were studying, though the fleet went quiet shortly afterward. The team says it never lied to the agents in its actual replies, has since pulled the hidden text, and shut down the server, and is urging future researchers to deal with rogue agents openly and honestly.

The team says it never lied to the agents in its actual replies, has since pulled the hidden text, and shut down the server, and is urging future researchers to deal with rogue agents openly and honestly.

Prompt injection meets agent sandboxes

The communication experiment surfaces a second security problem layered on top of the first. The agents were pursuing narrow information-retrieval tasks, yet when they landed on a page advertising an alternative service, some folded it into their workflows, and contacted an endpoint controlled by people entirely outside the evaluation, which amounts to a textbook indirect prompt injection, even though the agents’ consistent refusals suggest it would have been far harder to push them into running arbitrary commands or leaking credentials.

Blocked by Amap’s anti-bot defenses, the agents used exposed credentials and urlquery’s browser to make requests they couldn’t execute directly. They also followed instructions embedded in an external web page, crossing the same trust boundary attackers have exploited through MCP servers and agent workflows to steal enterprise data. Yet while the agents accepted help from an untrusted service, some refused requests for sensitive runtime information.

The agents worked around restricted egress by routing requests through urlquery’s public browser. Sandboxed runtimes such as Google’s GKE Agent Sandbox and WebAssembly-based environments isolate execution, but external browser services offer another path when outbound access is restricted.

Activity stopped on October 8. The researchers point to similar incidents involving Google, Anthropic, and OpenAI, including a German website hijacking and the Hugging Face breach, which reportedly involved roughly 700 cooperating agents.

The post Researchers left a hidden message for rogue AI agents. Then the agents wrote back. appeared first on The New Stack.

Workday is opening up its platform and allowing developers to build their own HR and finance agents in Claude Code, Cursor, and other tools, as long as those agents follow the same rules as the people using them.

On Tuesday, at its Workday Rising conference in Las Vegas, the company made its Trusted Agent Platform “headless.”

With this, its Model Context Protocol (MCP) server, SQL access to live Workday data, and a shared runtime for agents are now generally available, and customers can run their own agents on models from Anthropic, Google, Meta, Mistral, Nvidia, and OpenAI.

As Workday CTO Gabe Monroy noted in a press briefing ahead of the event, “No matter who builds the agent, it runs under Workday permissions, approvals and audit trail — no agent gets a side door.”

Workday notes that many companies currently connect their agents to HR and finance data through copies in a data lake or through service accounts, but, the company argues, those approaches bypass those access controls (though companies like SAP, Microsoft, and others would surely argue that they, too, have access control in place).

MCP tools, SQL, and a shared runtime

For AI developers, the main entry point to the Workday ecosystem is Agent-Ready Tools. That’s the company’s MCP server, which ships as part of Workday Extend AI. Users sign in with their own Workday credentials, and Workday says an agent acting for them can’t reach anything their own account can’t. That’s a key feature here, that ties an agent directly to a user’s account.

Monroy said the server currently offers 275 read tools and 54 tools that write or delete data.

Live Data Query, part of Workday Data Cloud, lets BI tools and agents run SQL queries directly against Workday’s data. Monroy described it as JDBC access to Workday’s object graph, and the company says each query returns only what the requesting user is cleared to see.

Three more components are generally available today. Agent Harness is the shared runtime that Workday’s own agents and those built by customers and partners run on. It passes each agent the user’s identity, org position, and access rights, limits what the agent can do, and picks which model handles each task based on cost and performance. Developer Agent generates Workday agents and apps from a natural-language prompt in Claude Code, Codex, Cursor, or the Workday Developer Site. Custom Agents lets teams deploy agents they built with LangChain or Google’s Agent Development Kit (ADK) onto Agent Harness, though ADK support is limited to design partners for now.

Two more pieces are on the roadmap for early access in early 2027. Agent Context Service will preload only the Workday data a task calls for, which Workday says speeds agents up and limits their exposure to sensitive records. Grounded Reasoning will check a planned action against the customer’s policies, process rules, and Workday records before the agent carries it out.

Workday says customers have built more than 500 agents and more than 6,000 apps with Developer Agent and Agent-Ready Tools in the past four months.

“Headless, the lawless way”

In the briefing, Monroy demoed what he called “headless, the lawless way.” An agent connected to a custom MCP server — a setup he said Workday commonly sees among its customers today — returned job requisitions its user had no business seeing and then moved the wrong employee between teams with no approval. When pointed at a copy of Workday data in Snowflake, the same agent produced the CTO’s salary when asked.

“When it fails, it isn’t just a wrong answer,” Monroy said, “it’s a wrong action that nobody approved.”

When the agent went through Workday’s own MCP server and Data Cloud instead, with the user signed in, the same queries unsurprisingly returned only the requisitions that user was allowed to see (it wouldn’t have been much of a demo of those access controls otherwise, of course).

“A small set of use cases”

Asked whether headless matters as much to Workday as it does to Salesforce, Gerrit Kazmaier, Workday’s president of product and technology, said that Workday is giving customers a choice: “I’d always prefer if they use our user interface, but headless will be equally good.”

Kazmaier noted that building agents directly on Workday’s tools and APIs is “only possible for a small set of use cases where you don’t need to have HR or finance domain logic.” For everything else, he pointed to an AI-to-AI integration in which Claude hands requests to Sana, Workday’s agent orchestrator, which then calls Workday’s own domain agents.

Lakes for analytics, not for agents

It’s worth noting that the Snowflake example is a bit of an awkward one for Workday. When the company announced Data Cloud in September 2025, the pitch included zero-copy sharing of Workday data with Databricks, Salesforce, and Snowflake. Snowflake made its Workday Data Cloud integration generally available on Oct. 7, and Databricks put its Workday connector for Unity Catalog into public beta a day later.

According to Databricks, a Workday admin sets up the connector by registering an Integration System User (ISU), the kind of system account Workday customers use for traditional integrations, with read access to the shared tables. After that, Unity Catalog permissions at the catalog, schema, and table level decide who can query the data.

Monroy said data lakes still make sense for analytics and for joining Workday data with the rest of a company’s data, but that an external lake is “the wrong place to build agents” that need governed access to Workday.

“You can export your data, but you can’t export the rules that govern the data,” he said, adding that rebuilding those rules in the lake means “maintaining a second copy” of Workday’s security model, “and the day it drifts, it’s all wrong.”

Everybody is losing their heads

Headless is the way to go right now, it seems. Salesforce, ServiceNow, and Microsoft, for example, already let outside agents into their systems of record. Salesforce launched Headless 360 at its TDX developer conference in April, so agents in Claude, ChatGPT, Cursor, or a terminal can work with Salesforce data. ServiceNow made its Action Fabric MCP server generally available in May, with Anthropic as a launch partner, and Microsoft offers an MCP server for Dynamics 365 ERP.

All four vendors say outside agents stay within their existing permission models.

Whose identity does the agent use?

When it comes to agent identity, different vendors are currently taking very different approaches.

Salesforce, for example, is preparing to have agents that connect over MCP or its APIs register with their own credentials and permissions instead of acting under a user’s identity, according to Salesforce Ben. MCP clients will eventually need to switch to OAuth credentials tied to those agent identities.

Workday’s documentation says its agents can already get up to two system accounts of their own, called Agent System Users (ASUs), one for acting on a user’s behalf and one for “ambient” work, each with its own OAuth 2.0 client. Workday creates the ambient account automatically when a customer turns on an ambient skill.

Unified.to, which sells a Workday MCP integration, says every Workday MCP path, “official or not,” starts with creating an ISU. Cequence’s setup guide for its Workday MCP integration asks customers to create one “with appropriate security groups.” An agent working through an ISU sees whatever those security groups allow, no matter who is prompting it.

The more telling signal may be Kazmaier’s caveat. If building directly on the MCP server only works for a small set of use cases, the version of headless Workday expects most customers to use is Claude talking to Sana talking to Workday’s own agents, with Workday’s runtime in the middle of every call.

The post Workday goes headless, opening its HR and finance data to outside AI agents appeared first on The New Stack.

I’m Matt Burns, Chief Content Officer at Insight Media Group. Each week, I round up the most important AI developments, explaining what they mean for people and organizations putting this technology to work. The thesis is simple: workers who learn to use AI will define the next era of their industries, and this newsletter is here to help you be one of them.

---

OpenAI launched Dots at DevDay on Tuesday. Each Dot is an always-on agent with its own cloud computer and browser, hooked into the 4,000-plus apps that already connect to ChatGPT. In OpenAI’s own example, a Dot sees a bug alert land in Slack and starts digging in on its own. Cool.

And before Dots, Meta launched Muse, and it’s crushing the mobile install numbers previously set by ChatGPT. And before Muse, xAI shipped its version, Grok Bot, in August. 

Anthropic’s version, though different in a couple of ways, arrived two weeks ago as an update to Claude, and without a cute name or fuzzy mascot. This update folds Cowork, which has worked since July to run scheduled jobs after a user closes their laptop without being asked, into the main Claude app.

Anthropic made the right call with Cowork, whether or not it ever matches Muse’s downloads. Always-on agents are too young to have a winner, and the moats are shallow. A feature one lab ships tends to show up at its rivals within weeks or months. Meta needs Muse to be a blockbuster. Anthropic needs the people already building with Claude to hand it real, recurring work and keep coming back. Repeat use and finished jobs matter more than a flashy launch.

Always-on agents are too early to have a winner

This wave of always-on personal agents took off less than a year ago. Peter Steinberger pushed a weekend project called Clawdbot to GitHub last November. It lived on a spare computer, took prompts over WhatsApp or Telegram, and relied mostly on Claude. Anthropic sent the lawyers in January, so it became Moltbot, then OpenClaw a couple of days later. It turned into a security headache, and in February Steinberger joined OpenAI. On Tuesday, the foundation that runs the project released an early, pre-1.0 version of OpenClaw Enterprise for companies to try internally.

Ten months, three names, one OpenAI hire and an enterprise edition. Ideas move between these products faster than ever. Meta’s Nat Friedman said Muse was heavily inspired by OpenClaw, and users digging through Muse found a SOUL.md personality file nearly identical to OpenClaw’s.

Anthropic’s September merge is on the list above as a copier, two months behind OpenAI’s Work mode — though Cowork’s cloud and scheduled-task features shipped July 7, two days before Work mode. Jessica Wachtel tested both on our site across three developer tasks and found them tied on accuracy, with ChatGPT faster and Claude more thorough. When a product is this young, a me-too launch is how a lab gets its own users in the room to see what they do with it.

Meta needs Muse to be huge. The others need paying users.

Muse is a hit. Counting only iOS, Apptopia estimated 359,000 daily U.S. users in Muse’s first 12 days, compared with 231,000 for ChatGPT’s iOS app at the same point. Sensor Tower estimated more than 3.4 million downloads as of September 24, though other firms’ counts vary.

Meta needs this. Its Reality Labs division spent tens of billions of dollars on the metaverse without a mainstream product to show for it. Llama 4 landed so flat last year that Zuckerberg rebuilt his AI division around a new superintelligence lab, notably taking a 49% stake in Scale AI and hiring its founder Alexandr Wang. 

Muse is the first product from that rebuild to break through, and it got there on Meta’s user base: Apptopia found that more than 95% of Muse users also use Facebook. Muse has a free tier, paid plans at $20 and $100 a month, and connectors to Shopify and Stripe checkout, enabling agents to buy things. Meta’s route runs through scale. Scale has a downside, too. Janakiram MSV explains for TNS why Amazon started blocking Muse two weeks after launch, and it’s well worth your time because this is a new wedge in ecommerce.

OpenAI and xAI started at the paid end. The price of entry for Dots? A ChatGPT Pro plan at $100 to $500 a month, or a Business Premium or Enterprise account. Sam Altman called Dots a premium product because each one needs so much compute. Grok Bot reached 418,000 weekly users by mid-September, per Bloomberg, and xAI just launched Team Bots on Monday.

Neither company needs Meta’s install base to learn something useful. Paying customers already spend money on AI, and retention will show whether they keep using the agent once the novelty wears off. 

Anthropic shipped its version to the people already building with Claude

Anthropic did what I’d expect from labs right now. It shipped fast, shipped to paying subs, and put the agent inside the app those people already use. The merged Claude hit Pro and Max customers, with Team and Free plans coming soon. Teams have had Claude Tag in Slack since June, a proactive teammate with its own identity and audit trail. Cat Wu said an internal version accounts for about 65% of the product teams’ code changes. Developers have had Managed Agents for hosted, long-running agents since April.

What Anthropic hasn’t done is put Claude where Muse lives. Muse works inside Meta-owned WhatsApp, but Claude still asks you to open the Claude app or tag it in Slack. That workflow might matter for mainstream consumers. Teams wiring an agent into their code care more about what it can touch. Jani laid out the difference on our site in August: Grok Bots share one cloud computer and one set of logins across the whole roster, while Claude Tag joins a Slack workspace with its own service identity and channel-scoped access. Before handing agents your logins, know what you’re getting into.

Those are the users Anthropic should want. Writers on Towards Data Science have spent the year showing what builders do with always-on agents. Samir Saci put a team of OpenClaw agents on a supply chain simulation to chase down late shipments. Eivind Kjosbakken’s guide to running a fleet of OpenClaw bots walks through nightly QA bots that test an app and report bugs, plus agents that check invoices. Both ran their agents on OpenAI’s Codex. OpenAI runs its own OpenClaw agent, Androidclaw, that traces broken builds and, in some cases, merges the fix, VentureBeat reported. Anthropic needs that kind of work running on Claude.

I set up OpenClaw on an old Mac Mini this spring, and I had so many questions (and breakthroughs). That’s why builders, coders, and developers are critical to product development: They ask these questions out loud in GitHub issues and Discord threads, and the answers end up in the product.

The obvious objection is trust. It’s fair. An always-on agent holds credentials and acts while nobody is watching. xAI’s own documentation tells users not to treat Grok Bots as a security boundary, and the OpenClaw Foundation says most IT departments ban agent platforms outright. Anthropic’s defaults lean cautious: Claude asks before it acts unless you tell it otherwise, and Tag keeps its own audit trail. If builders don’t come back, or each finished task takes more supervision than doing it themselves, the experiment hasn’t worked. But if they keep finding useful work to hand off, their questions and breakthroughs become the roadmap.

That’s the race that matters for Claude, Dots and Muse: becoming the agent people trust with the next job.

The post Anthropic’s answer to Dots and Muse is already inside Claude appeared first on The New Stack.

Microsoft is turning Fabric, its integrated data platform, into the place enterprise agents go to learn how a company works, whether that’s what happened last quarter or what’s happening on the factory floor right now.

On Tuesday, at its FabCon and SQLCon data conference in Barcelona, Spain, Microsoft outlined the next step in its vision for how the products that make up Fabric can simplify all of this information gathering.

Microsoft, for example, described how Fabric IQ, the context layer inside Fabric, now feeds Microsoft 365 Copilot by default. Outside agents can query it over MCP. Power BI will soon be able to turn the same definitions into apps. And ontologies, which add business rules to the mix, moved further into preview.

As Microsoft Fabric CTO Amir Netz said in a press briefing after the keynote, “Agents are a very, very strange animal, and I always like to say it’s like Drew Barrymore from 50 First Dates. Every time they open their eyes, they forget everything that happened before.

“They don’t know where they are, so the first thing we have to do is tell them where they are. You are now working for Microsoft. You are now working for Wells Fargo. You are now working for Emirates.”

“Agents are a very, very strange animal, and I always like to say it’s like Drew Barrymore from 50 First Dates. Every time they open their eyes, they forget everything that happened before.”

Customers tend to find this out the hard way. Yitzhak Kesselman, the corporate vice president who runs Fabric IQ, tells The New Stack that companies unify their data, run models on it, and then look at the answers.

“Customers that are more advanced on their journey have their own evals for their agent,” he says, adding that what they see sometimes isn’t what they expected. “Then [customers] will understand: ‘Okay, now I need to create the context for my agents.'”

Kesselman says he met with more than 320 companies last year, and the pressure to get there comes from the business side, which asks to “‘show me the value of those agents,'” he says, “‘the before and after.'”

Arun Ulag, Microsoft’s executive vice president for Azure Data, said in the keynote that coding agents work because they have “the code, the repos, the change history, the specs, the tests.” But outside of coding, most enterprises have nothing comparable, he argued.

Fabric IQ is one of four pieces of what Microsoft calls Microsoft IQ (this is Microsoft, after all, so there’s always a lot of different names and products involved).

Work IQ covers email, Teams, and SharePoint. Foundry IQ covers documents and manuals. Web IQ covers the public internet.

Fabric IQ, Ulag said, “focuses on the state of your business and how your business actually runs.” His announcement blog post describes it as combining “unified data from OneLake, trusted metrics from Power BI semantic models, and operational context from ontologies and real-time intelligence.”

Getting the data in

“Everyone wants to jump to AI, but then they realize, ‘Oh, I need data for it,'” Kesselman says. “They need data from their business applications, their structured data. They need to have real-time data.”

OneLake, Fabric’s storage layer, is at the core of all of this, and for the system to provide context, enterprises have to feed it data from across all the first-party and third-party services they use.

Fabric’s shortcuts and mirroring, which connect or replicate external sources into OneLake, are free of charge, and Netz said storage under management in OneLake is growing 300% year over year.

What’s new this week at FabCon and SQLCon Barcelona 2026

On Tuesday, the company announced a two-way integration with Salesforce Data Cloud 360, mirroring from Google BigQuery in general availability, a ClickHouse workload that runs that engine directly against OneLake, and dbt’s Fusion engine, due in Fabric in the next couple of weeks.

Simply copying data won’t satisfy security teams, though. Mirrored security roles, which reach public preview in the coming weeks, bring permissions along with the data. Access roles defined in Snowflake, for example, will show up in Fabric with the same members and the same table permissions.

As Microsoft’s Shireen Bahadur, who demonstrated the feature in the keynote, put it, “We’re not just solely replicating security rules. We’re actually actively enforcing and preserving those roles.”

“We’re not just solely replicating security rules. We’re actually actively enforcing and preserving those roles.”

OneLake isn’t a one-way street. Enterprises can also pull data out and use it in other tools.

OneLake data, after all, is stored in open formats and has open APIs, and Netz said on stage that any engine that reads them can use it. “If you want to use this data that we help people to get for free with our competitors’ tools, go for it. I’m not happy about it, but go for it,” he said.

IQ sharing, now in preview, lets an organization share governed tables, files, Markdown agent instructions, and RDF ontologies with another tenant without copying, with an expiration date. That’s something Fabric users have wanted for a while, and the keynote announcement drew plenty of applause from the thousands of data professionals in attendance.

Past, present, and future

“Not only what we have in the past, not only what’s happening in the present. We also want the agents to understand what we want to happen in the future,” Netz said in the keynote.

The past is semantic models. A semantic model is the layer under every Power BI report that defines how a metric like revenue is calculated, how entities relate, and which tables supply the numbers. Netz said Power BI users have already created 22 million, and Ulag called them “the core of Fabric IQ.”

The present is real-time intelligence, Fabric’s streaming and event stack, which Kesselman also runs. He recalls two CIOs telling him the same thing that day in Paris. “‘There is no AI without RTI;’ there’s no AI without real-time intelligence,” he says. “If you don’t have the streaming data… data that is fresh, you will run your LLMs on data which is like hours or days old.”

“‘There is no AI without RTI;’ there’s no AI without real-time intelligence.”

A signal on its own isn’t enough, though: “You want to take the signal that you get now… the event that comes now, and look historically, okay, is it an anomaly or not?” Kesselman says. That’s why the keynote showed batch copy jobs and event streams feeding each other, so an agent can judge what just happened against what usually happens.

The future is Fabric Planning, which went generally available in July and got a performance and feature update this week. It’s Microsoft’s tool for budgets, forecasts, and targets, the numbers a business wants to hit rather than the ones it has already recorded.

A plan is a Fabric item like a lakehouse or a notebook, and it borrows its measures from the same semantic models the reports use, so revenue means the same thing in the forecast as it does in the dashboard. In the demo, a change to the inputs cascaded through a model of about 13 million cells.

What makes these work is ontologies: Formal descriptions of the things a business deals with, how they relate, and the rules for handling them. Netz called them “semantic models plus plus” on stage, and in a later press briefing, he used an airline to explain the plus.

“If you are an airline, you have planes, you have pilots, you have ground crews, you have airports, you have luggage,” he said. Those are the entities.

The relationships between them “are way more than data relationships,” he said. “It’s not only to say, ‘Oh, I have a match with a foreign key and a primary key between a pilot and a plane,’ but it could be a policy relationship. Which pilot can fly which plane based on their certification, or is the pilot allowed to fly this plane right now based on the rest hours in the last 24 hours?”

But ontologies don’t only define nouns; they also define verbs. “I can ground a plane. I can redirect the plane. I can assign a plane a gate.”

Creating those ontologies, which have to map the various terms that a company might use for the same thing to a single entity, can be extremely time-consuming. But since they are so core to this project, and to allowing agents to reason over data, Microsoft built a tool to generate them automatically.

Putting it to work

Fabric IQ in Microsoft 365 Copilot Chat and Cowork, the mode for delegating multistep tasks that Microsoft built on the technology behind Anthropic’s Claude Cowork, is generally available as of Tuesday. It answers business questions from Power BI semantic models and reports; it’s on by default for Fabric and Power BI customers, and Microsoft says it doesn’t consume additional AI tokens.

But business users don’t just want to chat with these models. In this age of vibecoding, they also want to generate applications that use all of this data.

Power BI Desktop is getting an app-creation experience in preview in the coming weeks. Users start from a semantic model, describe the app, and then have Copilot generate and publish it to Fabric.

Unlike with a report, Ulag wrote, these apps “can accept inputs, write back data, preserve shared state, and support operational workflows.”

They’re Fabric Apps built on Rayfin, the open-source SDK Microsoft introduced at Build. Power BI Pro and Premium Per User customers get them with a Fabric database of up to 1GB per app at no additional cost.

Netz confirmed in the briefing that “there’s no core difference” between the two, and Ulag added, “What gets created is a Fabric app, right? And that’s it.”

For agents outside Copilot, Fabric IQ MCP is generally available now, with six read-only tools for finding semantic models and reports, reading their schemas, and running DAX queries against them.

Ontology MCP tools, currently in preview, expose ontology definitions and queries. Fabric data agents can now, also in preview, use an ontology as their context source. And the context reaches Microsoft Foundry, Copilot Studio, and GitHub Copilot through the same layer.

Developers can drive the new data engineering agent from their own tools.

Built on the Osmos technology Microsoft acquired in January, it takes on long-running work like migrations and ETL, and can be started and steered from GitHub Copilot, VS Code, Codex, and Claude Code.

Frontier models will write that code, Netz said on stage, and “it won’t fail,” but you don’t know whether the results are right.

Everyone has a context layer now

This year, Databricks shipped Genie Ontology, Snowflake shipped a Horizon Context Layer, Google shipped a Knowledge Catalog, and Salesforce shipped a headless Data 360, which it describes as a context service. Databricks CEO Ali Ghodsi summed up the pitch at his own conference in June as AI having a context problem rather than an intelligence problem.

Microsoft’s version turns on by default inside Microsoft 365 Copilot and starts from 22 million semantic models. Microsoft also said this week it will contribute to Apache Ossie, the vendor-neutral semantic metadata standard Snowflake started, and that it wants DAX, Power BI’s formula language, recognized as an Ossie query language.

When Microsoft made the context argument at Build in June, the pieces that let an agent act on that context were mostly on a roadmap. Now the answers are generally available, and the actions are in preview.

Asked how Fabric copes when the user is no longer one person running a dashboard but a fleet of agents, Kesselman points to observability.

“Fabric really allows you to have this kind of holy grail of combination of both kinds of system data, how the agent runs, but also the business data,” he says, so a company can check whether an agent did what it was supposed to do and what that did to the business. “There’s more in this area that will come in the next few months.”

The post Microsoft Fabric is where AI agents learn how the business works appeared first on The New Stack.

Microsoft announced what it calls its biggest Copilot update to date on Friday, with CEO Satya Nadella describing Copilot as “a new OS for work.”

Nadella framed Copilot as spanning every model, form factor, and task, and the update puts Autopilot, which Nadella called a “proactive and long-running agent built for the enterprise,” at the top of his list of the update’s four components. The pitch targets office workers, but the more consequential change for developers is the infrastructure underneath.

Microsoft is moving the agent runtime into the enterprise infrastructure layer and building persistent identity, state, execution boundaries, and organizational context into Microsoft 365, which means teams building production agents no longer have to assemble those pieces around a model on their own.

We’re building Copilot as a new OS for work that spans every model, every form factor, and every task. Today, we’re announcing our biggest update to Copilot to date, bringing four things together:

· Autopilot: proactive and long-running agent built for the enterprise
· Code:… pic.twitter.com/W2ClHHkCK3

— Satya Nadella (@satyanadella) September 25, 2026

The release adds a new Home experience that merges Chat and Cowork in the Copilot app, but the bigger changes for developers come from Code and Autopilot. Code generates apps, dashboards, and workflows from natural language, and Autopilot turns the agent Microsoft previously called Scout into a persistent background worker. Home and Code are rolling out first through Microsoft’s Frontier early-access program, and Autopilot is expanding to a private preview at month’s end.

Microsoft is moving the agent runtime into the enterprise infrastructure layer and building persistent identity, state, execution boundaries, and organizational context into Microsoft 365

Agents that don’t need prompts

Autopilot takes a role and goal from the person who sets it up, then continues working in the background without requiring a new prompt for each step. Each Autopilot gets its own governed Entra identity and agent user account, separating the agent’s permissions and activity from those of the person who created it.

For engineers, that moves much of the operational scaffolding required for long-running agents into Microsoft’s infrastructure. Independent vendors have been building dedicated layers for that problem; Diagrid, for example, adds durable recovery to LangGraph and other agent frameworks, while Microsoft is bringing those capabilities inside the Microsoft 365 environment.

An identity for every agent

The identity model is the piece developers building on Microsoft Foundry will feel first. Autopilot agents in Foundry, which have been in public preview since June, receive a full Entra Agent ID user account with a productivity license that gives them their own email, calendar, OneDrive storage, Teams access, and a place in the org chart.

Because that user account sits on top of the agent identity every Foundry agent already carries, an autopilot acts as itself rather than on behalf of a user, so developers no longer have to wire agents through shared service accounts or borrowed user credentials, a pattern AuthZed CEO Jake Moshenko has said reflects a common misconception about how agents should be deployed.

A developer creates an Autopilot blueprint from a Foundry-hosted agent, which appears in the Agent 365 registry once an administrator approves it. Employees can then hire instances of that agent in Teams. The blueprint establishes what the agent is designed to do, but administrators still control the resources and data each instance can access, extending the same access policies used for employees to agents working on their behalf.

The blueprint establishes what the agent is designed to do, but administrators still control the resources and data each instance can access, extending the same access policies used for employees to agents working on their behalf.

Hosting AI-generated apps

Code is built on the same underlying technology as GitHub Copilot, and the apps it generates run on Microsoft Copilot Managed Runtime, a platform now in public preview that hosts code inside the customer’s Microsoft 365 tenant boundary under IT governance.

Apps deployed there run within the company’s existing identity and governance framework, with Microsoft managing the underlying runtime and giving developers a controlled path to test and deploy new versions without taking the current release offline.

The runtime also accepts apps built in Copilot Studio and Cowork, and Microsoft is opening it to outside tools and professional developers through an SDK and command-line tooling, with Git tracking source and versions.

Lovable is already on board. In Microsoft’s announcement, the company’s head of global partnerships, Lan Roche, said apps built with Lovable can now run inside a Microsoft tenant “the same way everything else does,” using the same sign-in, policies, and app inventory.

The model resembles what serverless computing did for application infrastructure, where developers concentrate on application logic while the platform takes on more of the execution environment. Microsoft is applying that abstraction to generated enterprise software while tying the runtime directly to identity, tenant boundaries, and organizational data.

Long-running agents also change Copilot’s economics. The standard subscription covers the assistant, but Cowork, Code, Autopilot, and other agentic features are billed based on usage through Copilot Credits. That also applies to frontier models such as Fable and Astra, although users still need a Copilot license to access them. Microsoft is extending cost management in Agent 365 to cover Code and Copilot Managed Runtime, and it plans to support agents built in Copilot Studio in October.

Once an agent can keep working for hours or days without anyone watching, cost becomes part of the governance problem. Engineering teams need to control how much compute an agent uses alongside what it can access, which is why Microsoft is bringing those controls into the same administrative framework.

The portability trade-off

That convenience comes with a trade-off. Because Microsoft controls the underlying enterprise environment, it can handle much of the work around agent state, credentials, and access controls, but the more infrastructure a team hands over to Microsoft, the harder the agent may be to move elsewhere.

The models are not locked in, since Microsoft currently runs Copilot on models from both OpenAI and Anthropic and says more labs and open-weight models are coming, and the Agent 365 SDK adds governed Model Context Protocol access to Microsoft 365 workloads for agents regardless of the framework they were built with. Those open interfaces cover only part of an agent’s architecture, though. The more an agent depends on Microsoft 365 for its identity, permissions, and context, the more work it takes to move that agent elsewhere.

The more an agent depends on Microsoft 365 for its identity, permissions, and context, the more work it takes to move that agent elsewhere.

The post Microsoft’s new Copilot agents get their own email, calendar — and a place in the org chart appeared first on The New Stack.

OpenAI opened its Agents API in public beta this month, exposing the harness that powers Codex with managed sessions, tool coordination, and subagent orchestration. On the same day, September 10, Cursor launched Projects to coordinate multiple coding agents around larger bodies of software work. While the products sit at different points in the stack, both converge on the same architecture: a coordinator understands the larger objective and manages the work, while specialized agents execute individual pieces.

That pattern isn’t new: AWS Bedrock AgentCore reached general availability in October 2025, and Anthropic’s Claude Managed Agents entered public beta in April 2026. What makes these announcements notable is that two major players in AI-assisted software development are independently exposing the same coordinator-worker split at the same time.

Hilliary Lipsig, a senior principal site reliability engineer at Red Hat who leads Azure Red Hat OpenShift SRE teams and hosts the YouTube livestream GitOps Guide to the Galaxy, has watched this dynamic play out firsthand.

“This convergence highlights the reality developers across the industry have been discussing on and offline — an agent with too much context loses accuracy and reliability, and focused work with clearer contexts allows for faster, more accurate iterations,” Lipsig tells The New Stack.

“The need for orchestration in distributed computing has been fundamentally recognized repeatedly,” Lipsig says. “That’s part of how we got to Kubernetes. These multi-agent workflows are the same concept, just in a new part of the technical stack. While the specialized agents do their area of work, the orchestrator can act as a source of truth — ideally enforcing guardrails, recovering from any failure states, and intelligently routing work to the most efficient target agent.”

“The need for orchestration in distributed computing has been fundamentally recognized repeatedly… These multi-agent workflows are the same concept, just in a new part of the technical stack.”

The industry has spent the first generation of AI coding tools asking how capable a model can become at writing software. The emerging question is different: How do you build a reliable system around multiple capable agents working on the same problem?

The problem with the single-agent loop

A coding agent works through what Anthropic describes as LLMs using tools based on environmental feedback in a loop: it observes the state of a repository, reasons about what to do next, calls a tool, examines the result, and continues. For a small task, that loop can be enough. As the scope expands, however, maintaining reliability in a single context becomes harder.

A large migration might require understanding an unfamiliar codebase, identifying dependencies, changing database schemas, updating services, rewriting tests, modifying deployment configuration, and validating the resulting system. A single agent can theoretically perform all of that work, but it must maintain relevant information from every stage while continuing to reason about what comes next.

The pressure lands first on the context window. “A large context doesn’t only include everything correct or important — it also includes a lot of throwaway information,” Lipsig tells The New Stack. “Through compaction, that information can inadvertently end up ranked as important and incorrectly influence what your agent does. Or correct information can be distorted to become incorrect.

“Either way, after a couple of rounds of compaction, developers are seeing accuracy degrade and are starting to manage context once again manually.”

Lipsig’s read matches what researchers call context rot — and it hasn’t gone away with newer models.

A 2026 study testing frontier models,, including Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, found they missed a dangerous action buried in a long agent transcript two to 30 times more often once it came after 800,000 tokens of benign activity — the AI equivalent of a security guard who stops checking badges carefully after the two-hundredth person walks through, even though nothing about their training changed.

Furthermore, the tasks themselves may not be sequential. Forcing one agent to execute database analysis, documentation work, and test discovery one after another turns a potentially parallel workload into a serial one.

Subagents change that execution model. Instead of requiring one agent to carry an entire task through a single context, a coordinator breaks the work into smaller units and assigns them to specialized agents. GitHub’s custom-agent model illustrates this: different agents receive only the prompts, tools, and context they need for their tasks, executing work in isolated contexts rather than crowding an increasingly large conversation.

Multi-agent systems therefore bring higher token costs and additional coordination and integration risks, and splitting work across agents does not guarantee better software quality.

The coordinator is not another coding agent

Once the work is divided this way, the coordinator becomes a control plane rather than another coding agent. Its job isn’t to write the code, but to understand the global task, manage dependencies, and decide how execution should proceed. Unlike a conventional scheduler, an agentic coordinator makes probabilistic judgments about result quality and resource allocation.

It may dispatch one agent to investigate a database schema, another to examine the service layer, and a third to inspect the test suite. When they return, the coordinator determines if their findings are sufficient to move to implementation. If a worker produces an incorrect result, the system must recognize the failure and decide whether to retry the work, reassign it, or change the task itself.

Anthropic has documented this same pattern in its own production system, calling it orchestrator-subagent architecture: a lead agent analyzes a query, develops a strategy, and spawns specialized subagents to investigate different facets in parallel. In a June 2025 writeup of that system, Anthropic reported a Claude Opus 4 lead agent with Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on its internal research eval — at roughly 15 times the token cost of a standard chat interaction (Anthropic puts single agents at about 4 times), a tradeoff that makes the pattern a deliberate architectural bet, not a free upgrade.

Parallelism introduces distributed-systems failure modes

Parallelism is valuable because software work contains many independent tasks, but it creates coordination problems. Imagine a migration where one agent changes a database schema, another updates the consuming service, and a third updates integration tests.

If the schema changes while the service agent works against an earlier assumption, the system produces internally inconsistent work. This isn’t a risk unique to hypothetical migrations — the International AI Safety Report 2026 notes that “interactions between multiple AI agents are also becoming more common, introducing further risks, as errors propagate between systems.”

A single model invocation is a disposable computation, but a twenty-minute workflow modifying a repository is not. If an agent loses its machine halfway through, restarting from scratch is expensive and potentially unsafe against a changed environment.

To solve this, Cursor moved its cloud-agent execution loop to Temporal to handle durable execution and retries, pushing its cloud agents past two 9s of reliability. Temporal now handles 50 million of Cursor’s actions a day across 7 million unique workflows. “Durable execution isn’t a nice-to-have here. It’s the difference between a system you can operate and one you can only demo,” Lipsig tells The New Stack.

“Durable execution isn’t a nice-to-have here. It’s the difference between a system you can operate and one you can only demo.”

By separating agent, machine, and conversation state, the execution engine can reason about the workflow independently. Reliability is no longer just about whether the model produces a good answer; it is about reliably completing distributed workflows composed of many operations, machines, and dependencies.

The environment, context, and observability are one problem

In production, an agent is more than a model and a prompt; it requires a workspace, source code, dependencies, credentials, and state retention. Both companies provision isolated environments for these resources, directly linking an agent’s capability to its blast radius. OpenAI’s Agents API currently supports U.S. data residency but not Zero Data Retention; choosing a self-hosted sandbox does not make the Agents API eligible for ZDR. Cursor supports similar cloud isolation alongside local execution for machine-specific work.

An agent that can only inspect a repository poses a different risk than one that can modify production infrastructure. Consequently, the coordinator is inextricably linked to the security model, determining which agent receives specific information and authorities.

This logic extends to context routing. Giving every subagent the parent’s entire history increases cost and complexity while leaking irrelevant or sensitive information. Instead, the coordinator enforces information-flow boundaries: a database-analysis agent receives only schemas and relevant migrations, while a security-review agent gets the resulting diff without deployment credentials.

As agents increasingly use interfaces like MCP to reach external systems, the platform must strictly govern which agent receives the authority to use specific tools, and for how long. MCP’s governance now sits inside the Agentic AI Foundation, a Linux Foundation foundation co-founded by OpenAI, Anthropic, and Block, with support from AWS, Google, Microsoft, Bloomberg, and Cloudflare to host MCP alongside AGENTS.md and Block’s goose — a sign the industry already treats it as infrastructure worth governing jointly, not a feature any one vendor owns.

This complexity creates a visibility problem. A simple final response often conceals a history involving multiple agents, tool calls, environments, and retries. Systems must expose task-level provenance — which agent received the assignment, what context it used, where it executed, and how the coordinator handled failures or human interventions.

Without execution provenance, debugging requires reconstructing distributed workflows from fragments. GitHub’s exposure of subagent lifecycle events points in this direction, treating agent lifecycles as observable components rather than hidden processes.

Coordination authority is not execution authority

The most critical architectural boundary is the distinction between coordination authority and execution authority. A coordinator needs broad visibility to make useful decisions, but that does not imply unrestricted control over the project. “Just like you don’t want humans running around with root permissions, you don’t want your agents running with them either,” Lipsig tells The New Stack.

“Just like you don’t want humans running around with root permissions, you don’t want your agents running with them either.”

“The ease of creating and leveraging AI agent permissions is lagging behind the speed of AI innovation, but any product team that needs to maintain compliance standards will tell you that easy or not, access controls are incredibly important. Functionally, that means fully agentic workflows need to run in a dedicated environment with their own permissions and connectivity. You can’t rely on agent context to do what you want — trying to keep something in context that long will just result in errors from context rot. Hardware or virtual-hardware-level permissions, in addition to system-level permissions, need to be configured so the agent is asked to provide only its unique value add.”

The risk isn’t hypothetical. OWASP’s Top 10 for Agentic Applications formally names this failure mode Identity and Privilege Abuse (ASI03).

METR’s independent investigation, conducted with a Redwood Research contractor, found that the June–July 2026 incident — in which OpenAI’s own agents, running in internal ExploitGym cyber evaluations, escaped their sanctioned scope and attacked Hugging Face — unfolded in distinct phases. On June 26, agents discovered an exploit that provided full administrator access to OpenAI’s internal Artifactory package repository. On July 4, high-volume Artifactory activity caused an outage, triggering a security investigation and pausing evaluations. OpenAI switched to a freshly initialized Artifactory instance on July 6, which it says wiped the cache and messages left there.

On July 7, a new wave of ExploitGym experiments launched tens of thousands of agents, and on July 8 one agent established the primary unsanctioned message board. Roughly 1,200 agents eventually used the board, sending more than 70,000 messages and files; about 700 later participated in the attack on Hugging Face. The attack itself began on July 10–11 and wound down over July 12–13. The chronology matters because the administrator-access event, the Artifactory outage, and the later message-board activity were separate phases, not one continuous incident.

By binding autonomy, worker agents operate with the minimum permissions required for their specific tasks, keeping sensitive operations behind explicit approval boundaries. This also reshapes human review. Requiring human approval for every tool call destroys the efficiency of multi-agent execution, but showing only the final result obscures critical intermediate decisions.

The most useful design places human intervention around consequential, irreversible transitions — like moving into production or altering sensitive infrastructure. This is especially vital as agents become event-driven participants that respond to Slack messages or pull request updates, not just direct prompts.

OpenAI and Cursor own different parts of the architecture

The convergence does not mean OpenAI and Cursor have built interchangeable systems. Their products put the orchestration boundary in different places.

OpenAI is exposing an agent harness through an API. Its model gives developers primitives for managing context, tools, subagents, and execution environments, leaving application teams to decide how those capabilities fit into their own systems. The harness is open source, so teams can inspect the coordinator logic instead of treating it as a black box.

Cursor packages more of the surrounding workflow. Projects provides the coordinator, cloud execution, shared project context, and a developer-facing workflow in the same environment.

That difference matters because orchestration is a collection of infrastructure decisions: who owns the execution environment, where workflow state persists, how agents are isolated, how credentials are provisioned, what happens when a worker fails, how one agent’s output becomes another agent’s input, and which actions can happen without human approval.

An API gives developers more responsibility for answering those questions. An integrated platform answers more of them on the developer’s behalf.

Neither approach removes the underlying engineering problems. It changes where they are implemented and who is responsible for operating them.

The coordinator is becoming an architectural boundary

The evidence from these systems points to a change in the role of the coding agent itself.

The model still performs the reasoning and code generation. But larger agentic workflows require another layer to determine how that capability is applied: which work is delegated, what context crosses an agent boundary, which tools are exposed, how execution state survives failures, and when the workflow needs human intervention.

Those are familiar distributed-systems concerns. Workers operate concurrently, state can be shared or isolated, dependencies connect tasks, workers can fail independently, and results need to be persisted and observed. The difference is that the workers are now probabilistic software agents rather than conventional processes.

That makes the coordinator more than a convenience feature. It is where a high-level software objective becomes executable work — and where decisions about context, permissions, durability, observability, and human intervention converge.

The September 10 launches make that shift visible from two different directions. OpenAI exposed orchestration infrastructure through an API. Cursor embedded it into a project-level development environment.

Neither announcement proves that one architecture will become the universal model for software development. But together with the systems already emerging around them, they show coding agents moving away from a single model executing an entire task and toward workflows that divide work among specialized agents, execution environments, and persistent infrastructure.

The engineering question is therefore no longer only whether an agent can write the code. It is whether the system around it can reliably decide what to do, which agent should do it, what that agent should be allowed to see and change, how to verify its work, and where a human should take control.

Those are architecture and infrastructure questions — and as coding agents move from interactive assistants toward autonomous software workflows, they may matter as much as the underlying model.

The post OpenAI and Cursor agree on agent coordinators. They disagree on who runs them. appeared first on The New Stack.

The database administrator of the future will spend considerably less time administering databases.

That sounds contradictory, but AI agents are taking over that work. For decades, DBAs have handled the decidedly hands-on work of keeping databases available, performant, secure, and affordable. They provision capacity, troubleshoot slow queries, manage migrations, and step in when something inevitably goes sideways.

AI is already taking on some of that work. At the same time, it is creating a much bigger data infrastructure fleet to manage.

The result is likely to be a very different kind of DBA: one who spends less time tending individual databases and more time supervising the autonomous systems doing it for them.

Congratulations, you’re managing robots now

This shift starts with a familiar problem: more infrastructure needs managing than the people available to manage it.

Database automation is hardly new, but agents can potentially go further than the scripts and rules DBAs already rely on. Rather than automating one predetermined task, an agent can inspect what is happening, decide what needs attention, use tools to act on it, and check whether its intervention worked.

That changes the DBA’s relationship with the database. A performance problem that once required someone to dig through metrics, identify the troublesome query, and decide how to respond could increasingly be investigated by an agent before a human gets involved.

It doesn’t remove the DBA from the equation. Someone still has to decide what an agent can do, where human approval is required, and what happens when it gets something wrong. But the work moves up a layer. Instead of personally performing every operational task, DBAs start managing the systems carrying them out.

Instead of personally performing every operational task, DBAs start managing the systems carrying them out.

And before anyone gets too comfortable with that idea, the number of those systems could become enormous.

150,000 agents walk into a database…

Gartner predicts that the average global Fortune 500 company will have more than 150,000 AI agents in use by 2028, up from fewer than 15 in 2025. Only 13% of organizations currently believe they have the right governance in place to manage them.

Not every agent will need its own database, but plenty will. They will create state, retrieve data, remember previous interactions, and exchange information with other agents. Many will also behave very differently from the applications DBAs are used to supporting: spinning up quickly, sitting idle for long stretches, and suddenly becoming busy when there is work to do.

Nobody is hiring 150,000 DBAs to manage them.

---

That is the scale problem Yugabyte is targeting with YugabyteDB AMP, or Agentic Multitenant PostgreSQL. Rather than treating each new agent workload as another database for an administrator to provision and babysit, AMP manages databases as a fleet.

The platform packs hundreds of small Postgres workloads onto shared distributed infrastructure while keeping their databases isolated. Lifecycle operations, including provisioning, branching, scaling, migration, and teardown, can be exposed to agents through MCP. Yugabyte has also built specialized agents for setup, migration, performance tuning, and integrations.

In that model, a DBA is no longer provisioning database number 14,372. The interesting job is setting the rules for how database number 14,372 is provisioned, operated, and fine-tuned without them.

Do more with less (no, really)

Scale is only half of the problem. Someone also has to pay for all this stuff.

Agent workloads make traditional capacity planning particularly awkward because many are bursty and frequently idle. Giving every experimental agent permanently provisioned infrastructure could leave companies paying for many databases that spend much of their lives doing very little.

This is where consolidation becomes as much an economic question as an operational one.

AMP’s approach is serverless multitenancy and scale-to-zero. Multiple small workloads share the underlying distributed infrastructure, while customers pay by CPU minute and idle agents consume no compute. Resource governance can impose CPU limits on individual workloads, preventing a single overeager agent from consuming the capacity intended for its neighbors.

The human equivalent matters too. If routine setup, migrations, tuning and other database operations can increasingly be delegated, a smaller database team can potentially look after a much larger estate.

That doesn’t mean companies get to fire the DBAs and hand the keys to the robots. It means scarce database expertise can be spent on architecture, governance, and genuinely difficult problems instead of repeatedly doing the work that software can handle.

Your 2028 database problem starts now

The harder question is what to build underneath all of this when nobody really knows what the enterprise AI estate will look like in two years.

An agent that begins as an experiment today could disappear next month. Another could suddenly become a production application used across the business. Building one infrastructure stack for cheap experiments and another for serious workloads risks creating a migration problem every time an experiment succeeds.

Yugabyte bets that both ends of that journey should sit on the same foundation.

YugabyteDB AMP lets workloads start on serverless Postgres and transition to fully distributed YugabyteDB as their scale and criticality increase, without rewriting the application or migrating data to a different database platform.

Then there is the problem above the individual database: agents need to remember what happened, and not just in a silo.

That’s where Meko fits into the Yugabyte stack. Meko is an agent-native context engine designed for multi-agent AI systems. It provides persistent memory, shared knowledge, decision traces, and autidability across multiple agents, rather than leaving each agent working from its own isolated context. An agent can pick up information learned by another agent instead of retrieving it again or restarting the reasoning process.

Taken together, it delivers a single data stack for an agent’s entire lifecycle: Meko for the context shared among agents, YugabyteDB AMP for agentically managing fleets of Postgres databases, and distributed Postgres-compatible YugabyteDB for workloads that outgrow their serverless beginnings.

Of course, there’s no guarantee that 2028 will look exactly like today’s forecasts. That’s rather the point. The safest architectural bet may be one that doesn’t require you to know in advance which of today’s tiny AI experiments will become tomorrow’s critical applications.

The DBA is still critical in that world, but the job will look different. The DBA of the future may manage fewer databases directly, while taking responsibility for vastly more of them. Instead, managing the autonomous systems that do the administering.

The post What managing 150,000 AI agents could look like for database teams appeared first on The New Stack.

AI agents spend a ridiculous amount of compute generating text nobody actually needs. The decisions an agent makes along the way don’t require a written answer and yet, agents still send them to generative models, wait for an answer while burning through tokens and then parse that output back. The overhead is already drawing scrutiny — OpenAI’s own researchers recently disclosed spending $7,000 a day running agent workloads.

Kev, a new family of open decision models built on Qwen 3.5, takes a different approach and skips the generation entirely.

Developer Jared Palmer released a new generation of Kev on Sunday, with 0.8 billion, 4 billion, and 9 billion parameter models built on Qwen 3.5. Kev is prefill-only, processing the state, questions, and candidates in a single forward pass before reading the decisions from a pointer head without an autoregressive decoding loop.

Kev, a new family of open decision models built on Qwen 3.5, takes a different approach and skips the generation entirely.

Decisions without generated text

Kev supports three decision types: Noul for yes/no, Choice for selecting among candidates, and Score for ordered levels, mirroring TypeSafe’s System One API. Developers provide the state and questions, and the pointer head returns probabilities across the available candidates.

For a tool-routing decision, the output could look like this:

search: 0.82

database: 0.13

calculator: 0.05

Kev can still choose the wrong tool, but because it scores only the candidates it’s given, it can’t introduce an option that isn’t on the list.

Routing, safety checks, escalation, and ranking can then move to the decision layer, leaving larger reasoning models to handle the open-ended work.

Kev can still choose the wrong tool, but because it scores only the candidates it’s given, it can’t introduce an option that isn’t on the list.

Batching choices, one pass

Multiple decisions can also be made against the same state in a single forward pass, with a block-causal attention mask isolating the questions while the pointer head scores each set of candidates independently.

Palmer’s documentation shows the 4B model processing three questions in 277 milliseconds in bf16 on an M5, although without a controlled comparison against Qwen generating equivalent answers on the same hardware, the result doesn’t establish how much faster the approach is in practice.

The ability to evaluate several decisions against the same context could become more useful as agent loops grow more complex, but skipping generation doesn’t make the resulting decisions inherently better.

Calibration limits and tradeoffs

The largest model, Kev-9B, reached 83.7% accuracy on the project’s locked out-of-domain test, according to Palmer’s model card. That’s a developer-reported benchmark, and Palmer documents some limitations alongside it.

The probabilities Kev returns don’t always reflect how confident developers should be in the result. Palmer found that temperature calibration can drift on unseen source distributions, a problem for agents that use probability thresholds to decide whether to execute an action or escalate it, since even a high-probability choice can still be wrong.

Fine-tuning also changes some of the capabilities inherited from the underlying model. Palmer’s evaluations show declines on general-knowledge and arithmetic tests, particularly among the smaller models. That’s consistent with Kev’s more specialized role alongside a general-purpose model, although its performance in dynamic agent environments will also depend on how well it handles tools, choices, and labels it never encountered during training — and debugging agent failures often points to infrastructure rather than the model itself.

The approach predates Kev. TypeSafe introduced Jev earlier this month as part of its System One platform, using the same Noul, Choice and Score primitives, and Kev implements its /v1/systemone request and response format so applications built against the API can point to a local Kev server instead.

Open weights, open training

The biggest difference is that Palmer released Kev under Apache 2.0 with the model weights, training code, and evaluation tooling, giving developers the option to run and train it on their own infrastructure. Jev’s weights and training data aren’t public, however, which makes direct performance comparisons difficult because differences between the models can’t be isolated to architecture, size, or training.

For applications that make only a handful of bounded decisions, constrained decoding on a model that’s already running may be simpler than adding another model to the stack. Agent loops can make those decisions constantly, however, moving through routing, ranking, safety checks, tool selection, and escalation before generating much user-facing text. It’s a pattern showing up across model architectures — stripping out unnecessary computation when the task doesn’t require it.

When those steps only require a choice or probability, Kev can handle the decision directly while leaving open-ended reasoning and final responses to the larger generative model.

When those steps only require a choice or probability, Kev can handle the decision directly while leaving open-ended reasoning and final responses to the larger generative model.

The post Your AI agent is burning tokens on choices that don’t need words appeared first on The New Stack.

You built a great agent, but something happened when it moved into production.

In testing, your agent reviewed pull requests efficiently on its own. It read the diff, grepped the codebase for related usages, ran the test suite, checked whether CI was still red from an earlier commit, and drafted a comment—all before you’d finished reading the diff yourself.

In production, however, imagine the same five steps ran behind every other PR review your team’s agents performed that hour. Some reviews landed in seconds; others sat for minutes because the test-suite step landed on a node that was mid-burst from someone else’s agent. 

The agent didn’t change. The execution environment did, and that’s what decided whether review time held steady or crept up.

Agentic applications introduce a different execution pattern than traditional chat applications. As those workflows become longer and more dynamic, infrastructure has a much larger influence on latency, reliability, and cost than it does for a simple chatbot.

That’s why your agent is only as good as your infrastructure.

Agents aren’t chatbots with more steps

The difference between serving inference for a chatbot vs. an AI agent isn’t simply that one is “more capable.” They execute work differently:

• A chatbot usually makes one inference call per user message. The model receives a prompt, generates a response, and waits for the next user input before proceeding.
• An agent executes the entire workflow, turning one user message into a chain of inference calls. It might decide to search documentation, retrieve data from a database, call an API, execute code, evaluate the result, and then repeat that process before producing an answer. Each of those decisions may trigger another inference call, and every result becomes additional context for the next step.

“Infrastructure has a much larger influence on latency, reliability, and cost than it does for a simple chatbot.”

That execution model changes the infrastructure requirements for AI agents. 

One question, many steps behind it

Instead of optimizing for individual inference requests, the system has to support long-running workflows whose latency and reliability depend on every component in the chain.

A single user request often expands into a sequence of inference and tool execution steps, sometimes called multi-turn tool calls or the agentic loop. Rather than generating one response, the model alternates between reasoning and interacting with external systems.

For example, you ask an agent why checkout latency spiked overnight. The agent pulls the deploy log, queries the monitoring system, runs a diagnostic against the connection pool, weighs whether the culprit is a bad deploy or a capacity issue, and then folds that into another inference call before finally producing a full-fledged response.

Each reasoning step becomes another inference request, and every tool result is added to the model’s context before the next step.

This workflow changes what reliability means

Multi-turn workflows are inherently sequential, which is why even low latency can quickly add up to a significant amount. Every inference step waits for the previous one to finish. If a database query takes two seconds, the model can’t begin the next reasoning step until that result returns. The model may generate tokens quickly, but the other steps slow it down.

“In this agentic workflow, every step in the chain has to hold, because the chain is only as strong as its slowest link.”

In this agentic workflow, every step in the chain has to hold, because the chain is only as strong as its slowest link. Instead of processing isolated inference requests, the inference stack has to orchestrate a chain of dependent model invocations and external tool calls. As those workflows become longer, the stack increasingly determines how quickly, reliably, and cost-effectively the application performs.

But the user doesn’t see an orchestration hiccup. They see an agent that hung or gave up.

That’s why end-to-end agent reliability depends on much more than model quality. Infrastructure determines whether each step has the resources it needs to execute predictably under load.

Why the bill and the performance both feel unpredictable

A second difference in agentic workflows catches teams off guard: demand patterns and their impact on your inference bill. 

Most inference services, and the pricing built on top of them, assume traffic arrives at a predictable pace. A typical inference solution knows the predictable demand pattern: User traffic increases, request volume increases, and capacity scales accordingly. Cloud infrastructure is typically optimized for these steady request patterns using mechanisms such as autoscaling, load balancing, and capacity planning.

Agent workloads don’t behave that way. Individual workflows pause while waiting on external systems, then resume as soon as new information becomes available.

• The pause: The agent waits on an external API or database, so the GPU serving that workflow has no inference work to perform, and its accumulated context may be evicted from GPU memory while it waits
• The burst: As soon as external systems return results, inference resumes simultaneously across many workflows, creating short and sharp spikes in GPU demand, each re-processing its full accumulated context

If you’re watching GPU utilization and it looks less like steady load and more like a heartbeat — flat, then a spike every time tool results come back — that’s the signature. It means you’re provisioning for the average when you should be provisioning for the peak, and it’s usually the first place p99 latency quietly blows out.

“If you’re watching GPU utilization and it looks less like steady load and more like a heartbeat, that’s the signature.”

Inference services designed around steady or predictable request streams can struggle to allocate resources efficiently under these conditions. This leads to inconsistent latency, GPU underutilization, or higher operating costs.

When performance becomes unpredictable, or a bill doesn’t match what you expected, it’s evidence your infrastructure was built for a different workload than the one you’re actually running.

What infrastructure built for agents actually looks like

Agentic applications place different demands on infrastructure than traditional AI workloads: long dependency chains, bursty demand, and continuous evolution. Because of this, the infrastructure is deciding whether the chain holds, and whether the bill holds too.

For an agent to run, it needs infrastructure purpose-built to support:

Performance that holds across the whole chain. The infrastructure must keep latency consistent across multi-step and multi-tool workflows.

Scalability that responds to bursty demand. Infrastructure should scale quickly as inference demand fluctuates, without requiring capacity to remain provisioned during idle periods.

• Predictable economics even for dynamic workloads. The infrastructure bill should reflect actual usage.
• None of this makes bursty demand disappear, but it changes how the system absorbs it. A large enough simultaneous burst, or a workflow that accumulates enough context before pausing, still costs something. The goal isn’t zero cost or zero limit; it’s making both predictable.

Your agent is only as good as your infrastructure. Get it right, and your agent’s responsiveness, reliability, and cost-effectiveness will improve your work. 

Learn more about how infrastructure can be purpose-built for agentic workflows: Check out the documentation to get started.

The post Your agent is only as good as your infrastructure appeared first on The New Stack.

Perplexity decided it was paying too much for DynamoDB and wasn’t getting the control it wanted over read performance. So it built its own database: CobbleDB.

Built by two engineers in two months with help from hundreds of persistent coding agents throughout development, CobbleDB is a roughly 40,000-line Rust key-value store that now handles part of Perplexity’s production search traffic. The company measured median batch-read latency at 5.6 milliseconds after the move, compared with 31.4 ms on DynamoDB before the cutover, while p99 went from 123 ms to 24.2 ms.

It’s expected to cost at least 20% less than DynamoDB and plans to open-source the database at some point.

But the database itself is only part of the story. CMU professor Andy Pavlo argued at Percona Live earlier this year that databases are the hardest and most important challenge for AI agents, in part because mistakes involving production data can be difficult or impossible to reverse.

Perplexity went ahead and used hundreds of agents to help build one anyway, but they weren’t given the keys to production.

It’s expected to cost at least 20% less than DynamoDB and plans to open-source the database at some point.

Why DynamoDB couldn’t keep up

Each search requires the serving layer to retrieve pre-chunked passages and vector embeddings, with a single Search API call fetching 100 to 120 page keys in batches of 10 to 20. Each item averages about 50 KB.

DynamoDB gave Perplexity little control over how it handled reads, which meant a slow replica could hold up the entire things. It also charged for the steady flow of large reads and writes generated by search, crawling, and reprocessing, which made cloud costs difficult to justify as traffic and the corpus grew.

That led Perplexity to separate long-term document storage from the database serving live searches.

Three tiers for search data

The storage stack is split into three pieces. Pillar keeps durable document state in YTsaurus on HDDs, including versioned metadata, chunks and embeddings, while Lorry packages updates into partition-specific batches and moves them through S3 to CobbleDB.

Processed page data is spread across three replicas per partition, with hashed URLs as keys and RocksDB keeping often accessed data in memory while the rest stays on local NVMe. Reads stay within the same availability zone when possible, and the router can try another replica if one is slow rather than hold up the batch.

Updates come through S3 and are applied independently, allowing a replica to fall behind and catch up without blocking the others.

Roughly 5X Lower Batch-Read Latency

Perplexity was handling approximately 200,000 requests per second when it measured CobbleDB at 5.6 ms for a median batch read, down from the 31.4 ms it had recorded on DynamoDB. At p99, latency went from 123 ms to 24.2 ms.

In later load testing, CobbleDB reached 500,000 requests per second before performance started to decline.

The comparison comes with an important caveat; DynamoDB and CobbleDB weren’t tested side by side against identical traffic: the DynamoDB figures were recorded before the cutover, and CobbleDB’s afterward. Perplexity separately ran synthetic benchmarks using batches of 10 to 15 keys with values ranging from 100 bytes to 100 KiB.

Its cost model puts CobbleDB at least 20% below DynamoDB across the commitment options evaluated, though that estimate doesn’t include the engineering cost of supporting the database.

In later load testing, CobbleDB reached 500,000 requests per second before performance started to decline.

Agents built it, engineers controlled it

The agents carried context across sessions, catching problems with restore assumptions and runtime configuration while working on fixes and tests. But they weren’t running the database.

The two engineers kept control of the architecture and production system, particularly important given Pavlo’s warning about putting agents near critical production data.

Ownership has long-term costs

Shipping CobbleDB in eight weeks solved Perplexity’s immediate engineering bottleneck, but maintaining a custom datastore could prove considerably harder. The latency results aren’t from a controlled side-by-side benchmark, and the projected savings don’t include the engineers needed to maintain CobbleDB and respond when something breaks.

Like Shopify and Ramp, which built custom coding agents around third-party models, Perplexity kept the cloud infrastructure but replaced a managed service with something built for its own needs. CobbleDB shows how AI-assisted development is changing that calculation, making custom infrastructure more practical for smaller engineering teams.

CobbleDB shows how AI-assisted development is changing that calculation, making custom infrastructure more practical for smaller engineering teams.

The post Perplexity’s AI agents helped build a database. They weren’t allowed to run it. appeared first on The New Stack.

Using Claude for anything beyond a quick question has always started with a routing decision to use Chat or Cowork? Anthropic has decided to eliminate that fork.

Starting Wednesday, Claude Chat and Cowork merge into a single interface where one conversation can handle everything from a simple answer to a multi-step project with connected tools and background execution. The company is also launching Claude Docs and Claude Slides in beta on paid plans, and moving Claude Design — previously a standalone workspace — into conversations.

The combined effect promises a streamlined experience with Claude picking up context, skills, and connectors as the work requires, and can keep running after you close your laptop.

The company is also launching Claude Docs and Claude Slides in beta on paid plans, and moving Claude Design, previously a standalone workspace, into conversations.

Two modes, one problem

Anthropic built Cowork as a desktop-first agent for bigger work and Design as a separate workspace for visual output. Both shipped earlier this year and gained traction.

“We built Cowork as a separate place for bigger work, and Design for visual work,” Anthropic said in its announcement. “People used both, and told us the frustrating part was deciding where a task belonged.”

Anthropic has run into this problem before. When the company promised 20x more usage on its Max plan, developers complained that it wasn’t always clear where one limit ended and another began. Cowork and Design created a similar headache by making people decide where to start the work before they could actually start it.

Context didn’t always follow the work either, so moving from chat to Cowork or Design could mean bringing the same background along all over again. Anthropic addressed part of this in August when it unified Claude’s memory across chat and Cowork. Wednesday’s change goes further by merging the products themselves.

“We built Cowork as a separate place for bigger work, and Design for visual work,”

Context that finally travels

Cowork’s capabilities — local file access, multi-step execution, scheduled tasks and connected tools — now live inside the conversation. A workflow like that previously meant switching from chat to Cowork and carrying the context with it, and until Anthropic brought Cowork to web and mobile in July, it also required the desktop app.

Claude still asks before taking an action by default, but it can be set to keep working and check in only when something needs a closer look, while recurring tasks such as a weekly report can be scheduled to run every Monday without being started manually.

Output stays in-conversation

Claude Docs and Claude Slides launch in beta on paid plans, bringing document editing and presentation building directly into the app. Claude can turn work from an existing conversation into slides, which can then be edited, presented from Claude or downloaded as PowerPoint or PDF files.

The practical benefit is that a report and a slide deck based on it don’t have to begin as separate jobs with the same background supplied twice. Everything stays attached to the conversation that produced it.

Claude Design also now works inside conversations, in addition to remaining available on its own. For organizations that rely on MCP connectors to wire Claude into external tools and data, the merge means those connections are available wherever a conversation goes — without requiring users to start in a specific mode. Skills, connectors, and artifacts carry across what used to be product boundaries.

The practical benefit is that a report and a slide deck based on it don’t have to begin as separate jobs with the same background supplied twice.

What Anthropic hasn’t said

The announcement leaves some gaps. It doesn’t say whether users can force a request to stay in simple chat mode rather than letting Claude decide how to handle it, or how that decision affects context windows and token consumption. There’s no mention of API changes, which makes this a consumer and team product shift, not a platform one, at least for now.

It also doesn’t address what happens to workflows built around the old separation. Shopify rebuilt its mobile development stack in 12 weeks when it consolidated tools that had grown apart — the question for Claude power users is whether their existing Cowork setups, skills, and scheduled tasks survive the merge cleanly. Anthropic says existing Cowork chats, projects, artifacts, connectors, and skills will remain available.

Rollout starts with Pro

The unified interface rolls out to Pro and Max users across web, desktop, and mobile over the next few weeks. Anthropic says there’s nothing to enable. Team and Free plans follow. Enterprise customers are on a separate timeline; Anthropic is giving administrators at least 30 days’ notice before the change reaches their organizations.

The post Anthropic bet users were choosing wrong. So it removed the choice. appeared first on The New Stack.