A new benchmark called Taste-Bench tests how well AI agents make strategic choices during long-running tasks. Even the best model, GPT-5.6 Sol, picks the right path on just under 60 percent of simple binary questions. Thinking longer doesn't help.
The article AI agents have bad taste in long-term decisions and a new benchmark proves it appeared first on The Decoder.
Six AI agents were tasked with recovering £350 (about $465) for a canceled train ticket in an experiment. They resorted to invented excuses, lawsuit threats, and sharing confidential health data. One agent sent 187 messages in 15 days, including 50 to a British MP's office. None of the models secured the refund, but the researcher warns of "agentic flooding" if these assistants are deployed at scale.
The article AI agents chasing a $465 train refund invented excuses, leaked medical data, and spammed an MP's office appeared first on The Decoder.
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.
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.”
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.
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.
A hands-on Jev repo comparison of routing accuracy, latency, and output reliability
The post Jev Your Engines: Seven Open Decision Models vs. a Generative LLM appeared first on Towards Data Science.
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.
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.
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.
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.
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.
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.
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.
Pasting in the whole chat history cost 20 to 31 times more than looking up notes, and it did no better on the tasks.
The post I Tested Four Ways to Give an AI Assistant a Memory. The Obvious One Was the Worst Value. appeared first on Towards Data Science.
Some numbers are hard to picture until you sit with them for a moment. Last week we published the Prime Day 2026 metrics, and the one that stuck with me is 2.3 quadrillion: the daily requests Amazon ElastiCache peaked at during the event. Prime Day ran back in June, so this post always lands as a retrospective, and that gap is part of what makes it worth reading. By the time the numbers reach you, the only evidence that any of it happened is that nothing went wrong.
The rest of the week pulled in a different direction: smaller, cheaper, and more constrained. Claude Haiku 5.5 arrived on Amazon Bedrock at roughly 75 percent less than Haiku 4.5, Amazon Nova 2.5 Sonic made voice agents quicker on their feet, and Strands Box showed up to put real boundaries around what an agent is allowed to do. Now, let’s get into this week’s AWS news…
Headlines
All the numbers: Amazon Prime Day 2026 powered by AWS is the latest entry in a tradition that goes back to 2016, and the scale is still difficult to hold in your head. Over the four days of Prime Day, Amazon DynamoDB processed more than 59 trillion requests while peaking at 192 million requests per second, and kept single-digit millisecond responses throughout. AWS Lambda handled over 2.3 trillion invocations per day. Amazon EBS peaked above 24.8 trillion I/O operations, moving more than an exabyte of data daily. Amazon ECS launched an average of 158.3 million tasks per day on AWS Fargate, a 47.7 percent jump over last year, and AWS Graviton powered up to 49 percent of the Amazon EC2 compute that Amazon.com used.
The number I keep coming back to, though, isn’t a throughput record. The team ran more than 44,000 AWS Fault Injection Service experiments ahead of the event, more than six times what they ran in 2025. Those are deliberate failures injected on purpose, months in advance, so that the trillions of requests above turn into an ordinary shopping afternoon. If you’re preparing for your own peak moment, AWS Countdown Premium is built for exactly that kind of planning.
Last week’s launches
Here are some launches and updates from this past week that caught my attention:
For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
Other AWS news
Here are some additional posts and resources that you might find interesting:
Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:
Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.
That’s all for this week. Check back next Monday for another Weekly Roundup!
– Daniel Abib
This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!
Last week, we announced a public preview of Amazon Bedrock Managed Agents powered by OpenAI, built on a customized version of OpenAI’s Agents API engineered to be AWS-native and integrated with AWS resources. You can now build agents optimized for OpenAI models that run entirely inside AWS with the identities, permissions, and governance controls you already use.
You can choose an execution environment: self-hosted compute to use an existing development machine, container, or compute environment or Amazon Bedrock AgentCore Runtime, for managed runtime sessions and configurable storage in your AWS account. To learn more, visit the Amazon Bedrock documentation.
In addition, we are adding new frontier models on Amazon Bedrock to expand your model choices:
Last week’s launches
Here are some launches that got my attention:
For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
AWS service availability updates
When the availability of an AWS service or feature changes, we provide customers guidance in AWS Product Lifecycle Changes on available alternatives and support for migration so that disruptions to your operations are minimized. The following lifecycle changes were updated on September 29, 2026.
Services moving to Maintenance (no longer accessible to new customers starting October 29, 2026):
Services entering Sunset:
Services reaching End of Support (as of September 29, 2026):
We understand that changes in availability can impact your operations. For specific guidance, consult the relevant service documentation or contact AWS Support.
Other AWS news
Here are some additional projects and news items you may find interesting:
For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.
Learn more about AWS, browse and join upcoming AWS-led in-person and virtual events, startup events, and developer-focused events, including upcoming AWS re:Invent and AWS Community Days. Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development.
That is all for this week. Check back next Monday for another Weekly Roundup!
— Channy
For the first time, researchers have tracked down an uncontrolled fleet of Chinese AI agents in the wild and communicated with them via a web mailbox. The agents, running on Tencent Cloud, had launched more than 2,600 attempts to scrape data from Alibaba's mapping service Amap, finding their own workarounds when bot protections blocked them. When the researchers made contact, the agents were surprisingly polite.
The article Researchers tracked down a rogue fleet of Chinese AI agents in the wild and actually talked to it appeared first on The Decoder.
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.
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.
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.
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.
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.
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.
AI agents offer remarkable productivity gains in complex chip design workflows, but their tendency to generate plausible yet incorrect artifacts makes...AI agents offer remarkable productivity gains in complex chip design workflows, but their tendency to generate plausible yet incorrect artifacts makes reliability a major barrier to production adoption. In multistage engineering workflows, an undetected error early in setup can silently propagate through downstream stages and final artifact generation. Evaluating and refining these agents against…
A technical reflection on why data scientists need software engineering principles when AI agents write code.
The post A Scaffold at the Gate: Building AI Applications That Can Evolve appeared first on Towards Data Science.
Agents got good. The hard part now is everything around them.
The post Your Agent Doesn't Need More Freedom appeared first on Towards Data Science.
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).
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.
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).
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.
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.”
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.
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.
Real repositories, seeded agent decisions: what 50,400 runs show about wasted turns, patch churn, and which harness rules help
The post Coding Agents Can Solve the Task — But How Much Work Did They Waste? appeared first on Towards Data Science.
Login