The phone chip built for agents that stay with you

Agents Move Onto the Phone

The next AI agent may not live in a browser tab. It may sit on your phone, stay close to your personal data and keep working without sending every decision to the cloud.

Our main story today is Qualcomm’s new flagship phone chips, and what happens when persistent AI moves onto the most personal computer most of us own. On 22 September, Qualcomm launched the Snapdragon 8 Elite Extreme Gen 6 and the Snapdragon 8 Elite Gen 6. They’re two separate platforms for premium Android phones, both made on a 2-nanometre process and built around Qualcomm’s Oryon CPU, Adreno GPU and Hexagon neural processor.

That neural processor is the part designed to run AI workloads efficiently on the device. Qualcomm is pitching both platforms for what it calls agentic AI: software that can interpret a request, use tools and take a series of actions, rather than answer one prompt and stop. Motorola, OnePlus, OPPO, vivo and Xiaomi are among the brands Qualcomm says will use the platforms in forthcoming phones. We don’t yet have firm release dates for individual devices.

There’s a practical reason to move more of this work off the cloud. A local agent can respond without waiting for a round trip to a data centre, and some personal information may stay on the phone rather than being uploaded for every task. The advantage should be most noticeable when an agent needs several small model decisions to complete one request, because network delay can accumulate at every step. It can also keep useful context close to the apps, messages, photos and settings that make a phone assistant genuinely personal. Those are potential benefits, though, not measured outcomes from shipping handsets. The phone maker’s software, not only the silicon, determines the speed, battery cost and privacy of each implementation.

Permissions become the harder part. A conventional assistant might need access to a microphone or calendar for one action. A persistent agent could combine several permissions and act across services over time. Local processing reduces some data transfers, but it doesn’t answer who can inspect the context, how long it stays, or whether an action needs fresh approval. A faster neural processor can make the agent more capable; it can’t make those product decisions on the manufacturer’s behalf.

Qualcomm’s performance and agentic-AI improvements are its own claims for now. Independent testing still needs to show how the two chips behave in real phones, especially under sustained workloads where heat and power use count. We also need to see whether the Extreme model delivers a meaningful experience beyond the standard Elite version, rather than a spec-sheet difference.

For phone buyers, my read is to judge the finished agent and its controls, not the AI label on the chip. On-device capability can make mobile AI faster and keep more processing local, which is useful. But the best implementation makes access visible, limits it cleanly and lets you understand why the agent acted. The hardware creates room for that experience. Phone makers now have to prove they can build it responsibly.

CloudWatch Opens the Agent Trace

That puts more intelligence at the edge; the next challenge is seeing what an agent actually did once it’s running in production.

AWS made CloudWatch Omni generally available on 23 September. It’s an OpenTelemetry-based observability service for conventional applications and AI agents, spanning multiple accounts, regions and supported clouds. OpenTelemetry is the widely used set of standards and tools for collecting traces, metrics and logs, so this isn’t a monitoring format that starts and ends inside one AWS product.

For an agent, a useful trace needs more than a record that a request succeeded or failed. Omni can inspect prompts, model calls and tool invocations, then map the dependencies around them. AWS lists support for frameworks including LangGraph, CrewAI, the OpenAI Agents SDK, Vercel AI SDK and Strands. That gives an engineer a path through the chain of decisions: what the user asked, which model was called, which tool the agent selected and where the result went wrong.

The managed service initially runs only in AWS regions in Northern Virginia, Oregon and Ireland. AWS also offers a local extension for VS Code, Cursor and Kiro that can be used without an AWS account. That local option is notable for developers investigating a problem before deciding whether the managed service belongs in their production stack.

AWS says Omni can assist with root-cause analysis and proposed fixes, but there’s no independent evidence here showing how accurate that help is during real incidents. The trace itself is the more dependable value. Models can produce plausible explanations for failures, while the recorded sequence of prompts, calls and tool use gives an operator evidence to test.

For organisations running agents, this makes observability look less like a specialist add-on and more like normal production plumbing. My view is that the immediate win isn’t automated diagnosis. It’s giving developers and operators one place to reconstruct an agent’s behaviour instead of treating the model as an opaque box. That should make failures easier to reproduce and governance decisions easier to support with records, provided teams are comfortable with where sensitive prompt and tool data is collected.

Malware Lets Models Vote

There’s a darker version of delegated decision-making, and Cisco Talos has found it packaged inside a Windows implant.

The malware is called CLOSEDQUORUM. Talos says it can query four commercial language-model services, gather their responses and use the combined decision to choose its next post-compromise action. The models are DeepSeek, Qwen, Mistral and Google Gemini, contacted sequentially. Available actions include attempts to harvest credentials and cryptocurrency wallets.

The unusual part is where the tactical decision sits. Conventional malware often receives commands from infrastructure controlled by an attacker. CLOSEDQUORUM can ask ordinary hosted models what action fits the machine it has compromised, then execute the selected option without waiting for a person to remain connected. In effect, the implant carries the mechanism for acting while outsourcing part of the judgement.

That doesn’t mean four models independently discovered an attack or that the services were designed for this use. The implant supplies the prompts, constrains the available actions and counts the models’ votes. The attacker still chose the goal and built the surrounding machinery. The change is that hosted AI can reduce how often that attacker needs to issue live commands, potentially making a familiar intrusion pattern less dependent on a conventional command server.

There’s an important limit to the finding. Talos linked the developer to activity on criminal forums, but it hasn’t confirmed that CLOSEDQUORUM has been deployed in the wild. This is evidence of a working architecture, not evidence that the technique is already widespread. Prevalence remains unknown.

For security teams, the useful conclusion is narrower than the phrase autonomous malware might suggest. Outbound traffic to a model API can be part of an implant’s control loop as well as legitimate business use. Organisations that already allow those services may need enough endpoint and network context to distinguish an approved agent from an unexpected process making model calls. Blocking every AI endpoint would be a blunt response and may not suit the organisation. Correlating the request with the process, credentials and subsequent actions is more informative.

My assessment is that defenders should treat this as a new control-channel pattern to test for, not proof of an immediate wave. The architecture is credible, the sample exists, and its dependence on commercial APIs gives defenders signals they can examine. The unanswered question is whether attackers can make it reliable and quiet enough to use at scale.

AI Assistants Enter Search Choice

From hidden model calls to a very visible choice: UK regulators are considering whether an AI assistant can become your default way into search.

On 23 September, the UK Competition and Markets Authority strengthened proposed requirements for Google on Android and Chrome. The proposal would put eligible search services, including AI assistants, on a choice screen shown on first use, with another prompt each year. If adopted, a qualifying assistant could compete for default-search status without relying on a user to install it separately and dig through settings.

The inclusion of AI assistants is the significant change. Search competition used to mean choosing among services that returned lists of links. Answer engines can synthesise a response, retain context and become the interface through which a person reaches information. Treating them as eligible search choices recognises that they’re competing for the same starting position, even though the experience and incentives can be quite different.

Eligibility wouldn’t be automatic. The CMA says assistants would need to meet technical and security criteria. Services listed on the screen would also have to attribute publisher content clearly. That attribution condition goes to the central trade-off: an assistant may make discovery quicker for a user while reducing the visibility and traffic a publisher receives for producing the source material. More choice at setup doesn’t resolve that relationship by itself.

Nothing changes on UK devices yet. Consultation closes on 9 October, and the CMA expects a final decision by the end of 2026. The details may change during that process, and any resulting measure would apply within the regulator’s UK jurisdiction.

For the public, the likely benefit is a more meaningful default choice than selecting between near-identical search boxes. My analysis is that the quality of the eligibility rules will matter more than the number of logos on the screen. Security standards need to filter out unsafe options, while clear attribution needs to remain useful after an assistant has condensed several sources into one response. If those conditions hold, default access could become easier without making the source of an answer harder to see.

Muse Flaw Amplifies Local Access

A patch from Meta shows how a small opening on one computer can become much larger when it reaches a connected agent.

A researcher demonstrated that an unprivileged process already running under a Mac user’s account could redirect dictation traffic used by Meta’s Muse personal agent. The proof of concept changed an undocumented dictation-endpoint setting. That allowed it to capture spoken prompts and authentication material, inject prompts, and potentially use permissions the person had already granted to Muse.

The prerequisite matters. This flaw didn’t let a remote attacker compromise a clean Mac by itself. The attacker first needed local code execution, or needed the user to run a command. That makes it a privilege-amplification problem: malware with limited local access could reach through the agent into a wider set of connected services and actions. The danger came from the combination of a local weakness and an assistant trusted to do more.

Meta told Ars Technica it issued a hot-fix roughly 12 hours after the researcher published the details. There’s no public evidence in the briefing that the flaw was exploited in the wild. The quick response reduced the exposure, and the demonstrated route depended on a fairly specific foothold.

Still, the design lesson travels beyond Muse. Security reviews often assess a desktop component by what that component can reach directly. A personal agent changes the calculation because its tokens and delegated permissions may bridge several connected services. A process doesn’t need to defeat the security of each connected system if it can take over an agent that already has approved access.

For people using connected assistants, my practical reading is that prompt injection isn’t only something that arrives through a hostile webpage or document. A compromised local input path can become an instruction path too. For developers, the harder job is keeping authentication material away from redirectable local channels and making sensitive actions require controls that survive a stolen session. Meta’s fast patch handled this reported flaw; the wider permission design remains the part every agent maker has to get right.

Qualcomm Buys Into Robot Motion

Qualcomm’s other move this week reaches beyond phones and into the software that helps robots turn a plan into motion.

The company has agreed to acquire PickNik, the robotics software business that stewards MoveIt. MoveIt is an open-source framework for manipulation: the planning and control work that turns a plan into a robot’s movement. Qualcomm says MoveIt 1 and MoveIt 2 will remain open-source, community-driven and available across third-party hardware. The deal is still subject to customary closing conditions.

Qualcomm plans closer integration between MoveIt and its Dragonwing and Arduino robotics platforms. The technical opportunity is a shorter path from models that interpret a scene or instruction to motion planning and real-time control on Qualcomm hardware. That could remove some integration work for developers building physical AI systems, although the promised roadmap isn’t delivered software yet.

The open-source commitment is therefore the detail to watch. MoveIt’s usefulness comes partly from being able to work across different robot arms, sensors and compute platforms. Investment from a large chip company could improve tooling and maintenance, while tighter platform integration could make one hardware path more attractive. Those outcomes can coexist, giving developers good reason to look for evidence that hardware-neutral governance stays strong after the transaction closes.

My take for robotics builders is cautiously positive: more engineering support could make a difficult stack easier to assemble. The long-term value depends on whether improvements land in the shared framework, not only in a polished route onto Qualcomm hardware.

Grok Stretches the Coding Run

For developers choosing a model rather than a chip, SpaceXAI has added another long-context option to the bench.

Grok 4.7 was released on 21 September through the API, Grok Build, Cursor and third-party coding harnesses. SpaceXAI positions it as a larger model trained for longer coding and professional tasks. The API accepts text and image input, returns text, and offers a 500,000-token context window. That’s enough capacity to hold a substantial amount of code and working material, although context capacity alone doesn’t show that a model will use every part reliably.

The published price below 200,000 prompt tokens starts at US$2 per million input tokens and US$6 per million output tokens. Once the prompt crosses that threshold, both rates double. That tiering matters for agent runs because a long task can repeatedly resend growing context, call tools and generate large outputs. The headline input rate may describe only a fraction of the final bill.

SpaceXAI reports stronger performance on long tasks and safer refusal behaviour, but those results come from the company’s own evaluations. Independent evidence on reliability, latency and safeguards isn’t available yet. Developers evaluating it will need to look beyond whether it solves one challenge and measure whether it stays coherent across the complete job, recovers from tool errors and finishes within a predictable cost.

That’s the useful competitive test now. My view is that a half-million-token window earns Grok 4.7 a place in comparisons for extended coding and knowledge work, but not an automatic win. For a working developer, completion rate and total run cost are more revealing than a short benchmark score. The model is accessible now; the evidence needed to judge those longer runs still has to be built.

What Changes for You

One control is available to developers right now, and it addresses the uncomfortable amount of access a local coding agent can accumulate.

GitHub released local sandboxing in public preview for repository sessions in the Copilot app on 23 September. You can set restrictions for filesystem, network and credential access on a project-by-project basis. That means a developer can reduce what an unintended agent command can touch while keeping the repository on the local machine, rather than moving the work into a remote environment.

The control fails closed if the operating system can’t enforce the requested policy. That’s a useful property: the session shouldn’t quietly continue with broader access than the developer selected. There are several limits to account for, though. Sandboxing is off by default, it applies only to new or restarted sessions, and the preview doesn’t cover cloud sandboxes or remote hosts. Copilot CLI settings are separate as well, so enabling the app control doesn’t establish one policy across every Copilot workflow.

For anyone using the Copilot app on local code, this makes per-project containment newly practical. My recommendation is to treat it as a worthwhile preview guardrail, especially for repositories that don’t need open network or credential access, while remembering that it isn’t a complete security boundary. Its value depends on enabling it, choosing sensible restrictions and checking the other environments where the same agent tooling runs.