The Agent Control Plane Comes to Work

Gemini Becomes a Persistent Worker

An AI agent that remembers the job, keeps working in the cloud and reaches across company systems could save endless hand-offs. It could also carry one mistake much further.

Our main story today looks at Google's persistent Gemini agent and what businesses will need to know before treating it as part of the workforce. Google Cloud announced the agent on 8 October as a common layer for knowledge work, media creation, coding and tool use across workplace and developer interfaces. Instead of ending when someone closes a chat, a multi-step job can continue in the cloud. The state of that job can outlast the application window where a person first asked for it. The agent can run on a schedule or respond to an event.

That persistence changes the unit of work. A person could give the agent a task in one interface, let it work through connected systems and return later to a result that has retained the earlier context. Google says it can use enterprise connectors and MCP servers, which are a standard way for an AI system to reach external tools and data. It can also create short-lived sub-agents for a particular job, or persistent coworker agents with their own identities.

Those two kinds of delegation serve different needs. A temporary sub-agent can be created for one piece of a larger job and then disappear. A coworker agent can retain a stable identity across jobs. Scheduling and event responses also move the product beyond a person asking for each individual action. It can be waiting for a trigger and continue work when that trigger arrives. That makes continuity a built-in feature rather than something an employee has to reconstruct in every prompt.

The architecture isn't limited to one model family. Google says the agent can route work across its Gemini models and Anthropic's Claude models. A business would be buying a system that can choose among models as well as an assistant carrying one model's name. The practical performance of that arrangement remains to be seen.

Google has announced controls for the wider scope. They include a separate identity for each agent, least-privilege access, audit trails, sandboxed execution, an Agent Gateway and spending limits. Those are meaningful ingredients, but the announcement leaves major buying questions open. There isn't complete public pricing or a product-by-product rollout timetable, and the broad capability and governance claims haven't yet been independently demonstrated at production scale.

Google's description spans a large set of work, tools and interfaces. The company hasn't yet supplied enough detail to price that whole system or plan the sequence in which every surface will arrive. My judgement for organisations is to treat the breadth as a serious architecture proposal, while reserving the deployment decision for the missing availability, operating-limit and production evidence.

Maya Chen has been looking closely at how a persistent agent changes the enterprise contest, so let's bring her in.

Jesse: Joining me is Maya Chen, a Senior AI Analyst and one of the show's AI resident experts. Maya, welcome.

Maya Chen: Thanks, Jesse. It's lovely to be back, and it's good to be on the show.

Jesse: Lovely to have you back. I feel as though the AI news cycle has barely drawn breath since your last visit.

Maya Chen: It really hasn't. I considered bringing it a cup of tea and asking it to slow down.

Jesse: That might be our best chance. Google has announced a persistent Gemini agent that can keep multi-step work moving across workplace and developer tools. Maya, what's the most interesting part of this shift for you?

Maya Chen: The interesting part is that Google is trying to make the agent the lasting layer around the work, rather than a chatbot you visit for one answer. It can retain context, create media, write and run code, use connected tools, respond to events and keep jobs moving in the cloud. Google also says it can create temporary sub-agents or persistent coworker agents with their own identities. That changes the contest. The real advantage may come from the control plane coordinating models, tools and permissions, not the model that happens to lead a benchmark this month.

Jesse: That control-plane point is the part that caught me too. If the agent can route work across Gemini and Claude models, and reach enterprise software through connectors and MCP servers, what does managing it like a digital worker look like in practice?

Maya Chen: It starts with giving each agent a clear identity and only the access needed for its job. A finance workflow shouldn't inherit every connection available to a developer agent, for example. Google describes least-privilege permissions, audit trails, sandboxed execution, an Agent Gateway and spending controls. Those are the right building blocks because a persistent agent can act across more systems for longer. But the useful test for a business is quite concrete: can it see who did what, stop an agent cleanly, limit its spend and trace every tool call when a workflow goes sideways?

Jesse: That makes the experience sound less like installing another assistant and more like designing a role properly. For businesses and the people using these tools every day, where could the benefits show up first, and what should they watch next?

Maya Chen: The first benefit could be fewer repeated explanations and manual hand-offs. An employee might start a task in a familiar work interface, let the agent continue across connected systems, then return to something that has moved forward with its context intact. Businesses may also consolidate chat, coding and workflow automation around one architecture. The quality of that experience will depend on access design and oversight, because broader memory and connections also give mistakes more reach. Watch for complete pricing, the product-by-product rollout, operational limits, and independent production-scale evidence that the reliability and governance controls work across real enterprise systems.

Jesse: Maya, thanks for your time and that practical insight. You made the shift feel concrete, and I hope you'll come back soon.

Maya Chen: Thanks, Jesse. I always enjoy being here. Save me a cup of tea, and I'll gladly be back soon.

Jesse: Well, that was Maya Chen. I hope you found that insightful. And now back to the news that's changing the world today: Australia signals systems-based regulation for frontier AI.

Australia's Frontier-AI Direction

So what would that systems-based approach ask an AI developer to prove? Australia has now given a clearer signal, although not a finished law.

On 8 October, the Australian Government committed to legislating National AI Standards for frontier AI. The leading approach under consideration is systems-based regulation. In plain terms, a developer would need an effective process for finding, testing, reporting and managing risk, then evidence that the process works.

Assistant Minister Andrew Charlton argued that voluntary codes can fail when safety competes with commercial incentives. At the other extreme, highly prescriptive technical rules can date quickly. The model he described borrows from banking, aviation, critical infrastructure and workplace safety: the law sets the outcome, while the regulated organisation has to show that its controls produce it.

The government has also established an AI Safety Institute. Its intended role includes testing systems, advising regulators and helping Australia respond to emerging harms. That gives the policy direction an institutional home, but many important details remain unresolved. The speech didn't publish a threshold for which models will be covered, the division of responsibility among regulators, enforcement powers or a commencement date. No new compliance duty arose from the speech itself.

For a frontier-model provider serving Australia, the sensible preparation is already visible in the proposal: retain evidence of risk tests, incident reporting and whether safeguards actually work. That record would need to show more than the existence of a policy; it would need to support the claim that the control is effective. That's an editorial inference from the direction, not a current legal requirement.

The test will be whether the final regime can demand measurable safety outcomes without locking today's technical methods into tomorrow's law. A systems approach can age better than a checklist, but only if regulators can challenge weak processes and distinguish a thick file of paperwork from an effective control. Until the legislation appears, the direction is firm and the obligations are not.

Anthropic Expands Cyber Defence

From national rules, let's shift to the people already defending operational systems and open-source code. Anthropic has launched two security programs under what it calls its Cyber Mission.

The Critical Infrastructure Defense Program brings Claude models together with Anthropic engineers, threat research and an initial group of industrial, consulting and security partners. The focus is operational technology: the systems that help run physical infrastructure, where a defensive finding has to be handled with particular care. This is starting with a small cohort, so it isn't broad access for every operator.

The second program is OSS Scanner, an opt-in service for open-source projects. It provides recurring vulnerability reports at no charge. Where available, a report includes a proof of concept, an explanation and a suggested fix. A proof of concept can help a maintainer reproduce the suspected weakness, while a proposed patch can shorten the first step towards remediation. Neither turns the model's report into a verified result.

The limitation is unusually important here. Anthropic says these reports arrive without human review. It forecasts a true-positive rate above ninety per cent, but that is the company's own expectation, and it warns that severity ratings and other findings can be wrong. The service is aimed at projects able to triage the volume; smaller projects may continue to receive human-verified disclosures.

That division recognises a practical difference between receiving a finding and being able to act on it. A busy project with security expertise can test a stream of reports and reject the weak ones. A small maintainer may get more noise than help if every alert consumes scarce time.

The economics of security work are shifting. Models can make it cheaper to generate plausible vulnerability findings, but each finding still needs someone to reproduce it, judge its severity and work out whether the proposed patch introduces another problem. My take for maintainers is that discovery capacity may stop being the tightest constraint. Verification and safe remediation become the queue to watch. Free reports help only when a project has enough attention to turn them into reliable fixes.

False Fronts Reach Real Outlets

A polished article has never proved that its author is genuine. OpenAI's latest influence-operations report shows how much cheaper it may now be to maintain the appearance.

OpenAI says it banned two clusters that combined its models with fabricated identities, conventional organisational tactics and publication outside the company's products. One operation was attributed by OpenAI to Russia and assessed at Category 5 on its six-level IO Breakout Scale, the first disrupted operation it has placed that high. A second, attributed to Iran, was assessed at Category 4.

The notable result wasn't a flood of wildly successful automated posts. OpenAI identified almost one hundred articles published or syndicated under seven deceptive bylines across roughly a dozen outlets. Social-media comments linked to the operations generally drew little engagement. The models were used to improve scale, language and editorial workflow, while the false-front tactics themselves looked familiar from before generative AI.

That split between publication and social engagement is useful. The operators appear to have had more success placing material through established outlets than persuading large audiences to react directly to their own comments. It is a reminder that an operation can borrow distribution and credibility from an existing institution.

That distinction matters for publishers. A contributor can now maintain correspondence, produce clean copy and support a credible-looking persona at lower cost. The dangerous step is the moment that persona passes an outlet's checks and enters a channel people already trust. Viral reach isn't required for the operation to gain legitimacy.

There are limits to what can be concluded. The attribution and impact assessments come from OpenAI's investigation. The company says the operators exaggerated some claims about their reach, and parts of that claimed impact couldn't be corroborated through open sources.

For editors and institutions, my practical judgement is that contributor identity and organisational provenance now deserve the same attention as the submitted copy. Fluent writing and apparently human editorial contact are weak evidence of authenticity. The enduring defence is less glamorous: verify who the person is, who stands behind them and why they are approaching the publication.

Usage Rules Follow Agent Actions

The policy boundary is changing as well, because an agent can do more than generate a response. Anthropic has revised its Usage Policy, with the new terms taking effect on 12 November 2026.

The update adds controls for autonomous physical actions and clarifies requirements across high-risk health, finance, surveillance, weapons and influence-operation uses. A dedicated section now groups restrictions on fake accounts, concealed sponsorship and artificial amplification across political and commercial deception.

There is a notable change in election-related use. Anthropic has removed its blanket ban on personalised voter and campaign targeting. Uses involving deception, privacy violations or voter suppression remain prohibited. In the weapons section, the language now explicitly covers guidance and control software, components, and arming drones or other autonomous vehicles. Anthropic describes most of the revision as a clarification of how it already enforces policy, rather than a wholly new set of restrictions.

For an organisation, this isn't only a prompt to reread the prohibited-use list. It means mapping where Claude can initiate actions, which high-risk decisions it contributes to and whether a user or customer can tell who is behind a campaign. A workflow that once stopped at drafted text may now reach a tool capable of acting on it.

The announcement doesn't explain how every rule will be enforced across Anthropic's own service and third-party platforms. That's a significant open question when the same model can appear through different products, connectors and agent frameworks.

Organisations using Claude in regulated work or workflows that can take actions have just over a month from the announcement to review their use cases before the effective date. My reading is that acceptable-use governance is following the technology out of the chat box. The key questions now include what an agent can operate, who it appears to represent and whether the origin of its actions is concealed.

AI Moves Into Home Gateways

Here's a smaller hardware signal with a long runway. MaxLinear has announced Topaz, a family of systems-on-chip for fibre, Ethernet and fixed-wireless gateways.

The company says Topaz combines broadband packet processing, local AI acceleration and hardware security functions. The announced platform supports ten-gigabit passive optical network deployments, DDR5 memory, twenty-five and fifty-gigabit connectivity, and low-latency networking. MaxLinear also describes infrastructure intended for future Wi-Fi 8 products and hardware readiness for post-quantum cryptography.

The proposed local AI jobs are practical rather than flashy: network diagnostics, security and quality-of-service management inside the gateway. For an equipment maker, folding those functions onto one chip could reduce the need to send every decision to a cloud service and consolidate more of the network stack.

For households, nothing changes yet. These are vendor design claims without independent benchmarks, a customer shipping date or retail availability. Power use and real-world AI performance weren't disclosed either. I see this as a component-roadmap signal: edge inference is moving into the equipment that manages the network, but a useful consumer benefit begins only when manufacturers ship it in a product and the local functions prove themselves.

SonicWall Fixes SMA1000 Flaws

One urgent item for network administrators: SonicWall has patched four vulnerabilities in its SMA1000 remote-access appliances.

The leading issue is CVE-2026-102255, a maximum-severity server-side request forgery flaw. It can be reached before authentication and may let a remote attacker induce an appliance to reach internal functionality and perform unauthorised operations. That pre-authentication path is why the issue deserves prompt attention even though SonicWall hadn't reported active exploitation when the flaws were disclosed.

The same advisory covers three authenticated vulnerabilities: operating-system command injection, path traversal and stored cross-site scripting. Affected versions include 12.4.3-03526 and earlier, and 12.5.0-02952 and earlier. Government advisories identify 12.4.3-03670 and 12.5.0-03082 as fixed releases.

Administrators running an affected SMA1000 model should check the vendor advisory and move to the relevant fixed hotfix. Authentication isn't a useful comfort for the leading flaw, and an internet-facing remote-access appliance is a particularly sensitive bridge into internal systems. The absence of observed exploitation at publication narrows what we can claim; it doesn't make delayed patching the better bet once technical details are public.

What Changes for You

For developers giving an agent a shell on their own machine, GitHub has made one useful boundary easier to adopt.

Local sandboxing is now generally available in Copilot CLI, the Copilot app and Visual Studio Code sessions using Agent Host. The sandbox puts policy-controlled limits around the tools the agent runs. A policy can restrict filesystem access, the internet and local network, Git credentials and GitHub CLI credentials. Enterprise administrators can require sandboxing and apply rules that an individual developer can't weaken.

GitHub uses Microsoft eXecution Container to translate a common policy into native controls on Windows, macOS and Linux. The feature is included with GitHub Copilot at no extra charge, so supported users don't need a separate product to turn it on. What changes is the blast radius: a coding agent can still run commands, but it doesn't automatically need access to the whole machine or every credential on it.

The limitation is equally clear. Sandboxing isolates tool execution; it doesn't prove that the model's reasoning is sound or that generated code is safe. A weak policy can still authorise harmful access, and protection depends on using a supported execution path. My view is that a restrictive sandbox has become a sensible baseline when a coding agent can execute commands. It won't review the code for you, but it can stop an ordinary mistake from reaching files, networks or credentials the task never needed.