AI Moves From Chat Windows Into Factories and Infrastructure

Agents Enter the Chip Fab

An AI agent can now run more of the atomic-scale simulation behind chipmaking. The harder question is whether that speed survives contact with a real factory.

Our main story today looks at NVIDIA’s push to bring agentic AI deeper into semiconductor fabrication, and what chipmakers need to prove before they trust it with production decisions. On 14 October, NVIDIA introduced cuPotential, an early-access system for agent-run atomic simulations, and expanded its CUDA-X software stack across chip design, process modelling, inspection and testing.

The practical idea is fairly direct. A semiconductor engineer can give an agent a task, such as exploring how materials behave during a manufacturing step. The agent can run simulations through cuPotential, inspect the results and choose what to test next. That could compress a slow, specialist loop in which engineers define each run, wait for it to finish and then decide on another. NVIDIA says early tests produced another two-to-three-times acceleration in workflows that were already optimised for GPUs. That is a useful claim, but it is a vendor result from an early-access product, not evidence of better chips coming off a production line.

The wider stack reaches beyond atomic simulation. NanoVDB, NVIDIA’s sparse-volume data structure for representing complex three-dimensional material and process data, is available as open source. NVIDIA also says a related Lam Research capability for modelling wafer etching could run as much as 30 times faster, with release targeted by the end of 2026. Applied Materials, Cadence, KLA, Lam Research, Siemens and Synopsys are among the companies NVIDIA says are adopting parts of the stack. That list covers much of the software and equipment chain used to design a chip, model how it will be made, inspect the wafer and test the finished result.

There is a good reason for all this compute. Modern fabrication depends on tightly controlled physical and chemical processes, and small variations can affect whether a chip works. A faster simulation can let an engineer explore more candidate settings before an expensive physical run. Inspection software can also search larger volumes of manufacturing data. An agent adds orchestration: it can select tools, launch work and react to intermediate results rather than waiting for a person to operate every step.

That last capability is also where the risk changes. A simulation can be fast and internally consistent while still being a poor representation of a particular process, material or piece of equipment. If an agent can launch a thousand runs, a weak model produces a thousand confidently organised answers. The production test is whether validated simulation reduces development time or lifts manufacturing yield without allowing unreliable automation into process control.

For chipmakers, my read is that integration work can start now around bounded simulation and inspection tasks, where engineers can compare the output with known results. Decisions that alter a live manufacturing process need process-specific validation, traceable inputs and a clear point where the responsible engineer accepts the recommendation. NVIDIA has shown that more computation may be available. It has not supplied independent evidence of lower cost, higher yield or better reliability. Those outcomes will decide whether this becomes a factory tool rather than an impressive acceleration demo.

Measuring CPUs for Agent Work

That takes us from software inside the fab to the hardware bill for running agents at scale.

Arm has proposed a CPU evaluation method built around representative agent workloads, repeatable measurements and whether the complete task actually finishes. The change reflects how different an agent system can look from a conventional benchmark. A model call may run on an accelerator, but the surrounding work still lands on CPUs: coordinating tools, moving data, running application code and operating sandboxes for generated code or untrusted tasks.

A familiar throughput number can miss those costs. Arm’s approach measures use cases that resemble sustained agent work and validates them against end-to-end completion rather than treating one isolated operation as the result. Fujitsu, Meta and OpenAI support the effort, according to Arm. Arm also acknowledges that the method will need to change as agent architectures evolve, which is important when tool use, memory and orchestration patterns are still moving quickly.

The first performance claim needs careful reading. In an Arm-commissioned analysis, Signal65 measured seven workloads and modelled early Arm AGI CPU systems as completing an average 1.99 times as much work per rack as systems using AMD EPYC 9755 processors. The rack result was not a direct measurement of full production racks. Signal65 derived it from rated server power and measured per-chip performance, using early hardware that still needs broader follow-up testing.

For infrastructure buyers, this is a useful attempt to ask a better question: how much completed agent work can a rack sustain once orchestration and sandbox overhead are included? My view is that buyers should ask for the workload scripts, production-hardware results and power assumptions before treating the 1.99-times figure as a purchasing fact. If those details become repeatable across vendors, agent-oriented measurements could reveal costs that conventional CPU benchmarks hide. Until then, the method is a promising proposal from a supplier with an obvious interest in the outcome.

Scam Detection Stays on the Phone

A smaller model on a phone offers a very different answer to the same question of where AI work should happen.

Google DeepMind and Singapore’s GovTech have announced a lightweight, Gemma-based scam detection model designed to analyse conversations locally on ordinary smartphones. The two-stage design starts with a low-power classifier that screens messages. When that classifier sees a suspicious conversation, it passes the relevant context to a fine-tuned model that can assess the exchange and generate a warning in real time.

Doing that analysis on the device changes the privacy equation. A messaging service would not need to send the contents of a private conversation to a cloud classifier simply to decide whether a scam may be unfolding. DeepMind and GovTech say the fine-tuning used anonymised scam reports and intelligence feeds, excluded citizen data and personally identifiable information, and took place inside a GovTech-managed cloud environment. Those controls address the training process; local inference addresses what happens to a user’s messages during detection.

The model aims at conversational manipulation rather than a single bad link or known phrase. That is useful because a scam can develop over several apparently ordinary messages as the attacker builds trust or urgency. A contextual model may be able to recognise that pattern, while the smaller first stage limits battery and processing costs by avoiding a full model run on every exchange.

There is no consumer protection to try yet. The project is intended for integration by messaging platforms and operating-system vendors, and the announcement names no application carrying it. It also gives no accuracy result, false-positive rate, supported handset list, integration partner or public rollout date. A private model that warns too often will be ignored; one that misses unfamiliar tactics offers false reassurance.

For the public, local processing is a credible design advantage, but distribution and measured performance will determine the benefit. I would look for independent tests across languages, scam types and lower-powered phones, along with a clear account of what text the warning system stores. Until a widely used platform integrates it, this remains a thoughtful technical design rather than a service people can rely on.

Election Safeguards Need Context

The limits of checking one message at a time are showing up in a more public setting as well.

Anthropic says Claude will begin incorporating official United States voting information from Democracy Works later in October, and will display current official results around election night. It is also strengthening classifiers intended to detect coordinated election abuse. The two changes address different problems: giving a user timely, sourced civic information, and recognising misuse that only becomes visible across several actions.

Anthropic examined a random sample of 250,000 United States consumer conversations on Claude.ai from 21 to 27 September. It reported that 5.75 per cent touched politics or public policy, while 0.51 per cent concerned elections or voting. Those figures suggest election questions are a small share of overall use, but the cost of a wrong answer or coordinated manipulation can be high. Bringing official information into the product may reduce the gap between a model’s stored knowledge and dates, rules or results that change during an election. The feature is specific to the United States.

The more revealing finding came from pressure testing by the Institute for Strategic Dialogue and the McCain Institute. Claude usually refused a single overtly harmful request, but could miss a malicious campaign broken into steps that looked benign on their own. One prompt might ask for plausible content, another for targeting ideas and another for distribution. Judging each exchange in isolation can allow the whole operation to slip through.

Anthropic says it has added classifiers for multi-step misuse and banned accounts linked to fake-news and advertising-revenue operations. Those enforcement details are company disclosures, and Anthropic has not published independent detection or false-positive results for the new classifiers. Looking across account behaviour may catch more coordinated abuse, but it also makes calibration and review more important because ordinary research can involve several related prompts.

My takeaway for platforms and campaigns is that prompt-level refusal is now only one layer of election safety. Effective controls have to consider sequences, tools and account behaviour while still separating genuine civic use from manipulation. Official data can improve the answer a voter sees. It cannot close a safeguard gap that exists in how a longer operation is assembled.

A Timetable for Quantum-Safe Migration

Some infrastructure risks arrive with an incident. Cryptography gives organisations the awkward job of preparing before the date is knowable.

Singapore’s Cyber Security Agency has issued a quantum-safe migration advisory that calls for exposed organisations to establish a migration plan by the end of 2027. It sets a 2031 migration target for critical information infrastructure and encourages other organisations exposed to quantum risk to complete migration by 2035. The dates apply in Singapore, but they give security and procurement leaders elsewhere a concrete reference for work that can otherwise remain permanently parked in the future.

The concern is that a sufficiently capable quantum computer could break widely used public-key cryptography. Nobody knows when a cryptographically relevant machine will arrive. Long-lived confidential data creates an earlier problem: an attacker could collect encrypted material now and attempt to decrypt it later. Systems that remain installed for many years can also outlast the practical window for a calm replacement.

The advisory therefore prioritises long-lived sensitive data, internet-facing systems and equipment that will be difficult to update. It asks organisations to assign accountable owners, examine vendor roadmaps and prepare for the performance effects of larger keys and extra computation. It also recommends cryptographic agility, meaning systems should be able to replace an algorithm without a large redesign, rather than hard-coding one new choice and assuming the standards will never move again.

For an organisation, the useful work now is an inventory: identify which applications, devices and external services use vulnerable cryptography, what data needs protection for years, and whether suppliers have credible upgrade plans. That evidence can shape procurement and testing before a migration becomes urgent.

I would resist treating the 2027 planning milestone as a deadline to swap every working system. A rushed replacement can introduce compatibility and performance problems while standards and implementations are still settling. An inventory, named owner and tested upgrade path are the sensible immediate outcome. Singapore has supplied dates. Each organisation still has to discover where its cryptography lives and how difficult it will be to change.

Industrial Systems Left Online

Here in Australia, a shorter alert carries an immediate job for anyone operating connected industrial equipment.

Australia’s cyber security authority has issued a high alert after learning of overseas incidents affecting commercial refrigeration systems. It says it has not observed active targeting in Australia, and the alert does not name a vulnerability, product, threat actor or Australian victim. That leaves the overseas events sparsely described, but the recommended checks are concrete.

Operators are being advised to remove direct internet exposure, patch vulnerabilities, strengthen authentication and access controls, segment operational networks, and review logs for automated activity. Commercial refrigeration is the example behind the alert, although the same exposure pattern can affect cooling systems and other operational technology. These devices often have long service lives, specialised maintenance arrangements and software that is harder to update than an office laptop. Remote access may also have been enabled for a supplier and then left in place.

The absence of a reported Australian campaign is not a reason to wait. My assessment is that operators should use the alert to verify which controllers and edge devices are reachable from the internet, who can enter through a remote-access path, and whether logs would show repeated automated attempts. That is bounded work with value even if the overseas incidents never develop into a local campaign. The uncertainty sits in the cause and scale of those incidents; the known weakness is industrial equipment remaining exposed when it does not need to be.

Designing a Manufacturable Nanostack

Back at the chip frontier, one research project starts with a striking transistor design and a stubborn manufacturing problem.

IBM and Siemens have begun joint research into design automation, process simulation, lithography optimisation and manufacturing software for IBM’s three-dimensional nanostack transistor architecture. IBM describes its current seven-angstrom research design as vertically stacking and staggering nanosheet transistors. It says nearly 100 billion transistors could fit in an area about the size of a fingernail.

The collaboration will build virtual models intended to test performance, optimise designs and find fabrication problems before physical chips are made. Lithography, which transfers tiny patterns onto a wafer, becomes increasingly difficult as structures shrink and move into three dimensions. A design can work in a research demonstration yet remain unsuitable for high-volume production if engineers cannot manufacture it repeatedly within tight tolerances. Virtual modelling gives them more chances to find those constraints before committing to costly physical experiments.

IBM says it has demonstrated that the architecture is viable, while acknowledging that further advances are required before manufacturing and production at scale. There is no production schedule, foundry commitment, independent performance result or commercial product roadmap. That makes this research, not the preview of a processor people will soon buy.

The practical implication for chip companies is that design software and manufacturing simulation are becoming part of the invention itself. My read is that a novel transistor structure has limited commercial value until engineers can model, inspect and produce it reliably. IBM brings the device research, while Siemens brings tools that may help connect the design to a workable process. If the collaboration succeeds, the valuable result will be repeatability, not the transistor count in the announcement.

What Changes for You

For developers shipping software, one new GitHub control is ready for a closer look, within a fairly narrow preview.

GitHub has released workflow dependency lockfiles in public preview for GitHub Enterprise Cloud and Enterprise Cloud with data residency. An actions.lock file records the exact commits for actions, their transitive dependencies and reusable workflows. Developers can keep readable tags or branch references in the workflow file, while GitHub Actions executes the commit recorded in the lockfile.

Once a workflow is onboarded, its dependencies have to appear in that file. If an upstream maintainer later moves a tag, the reviewed workflow does not silently begin running different code. Dependabot can propose an update to the corresponding lockfile entry, giving a developer a visible change to review. This is particularly relevant to release and deployment workflows, where a changed third-party action may gain access to packages, credentials or production infrastructure.

The limitation is important: a lockfile proves which commit will run; it does not prove that the code in that commit is safe. Teams still need to review the dependency and the update. The preview is also restricted to eligible enterprise plans, with no general-availability date.

For developers who have access, I would trial it first on release and deployment workflows. It reduces the chance that a readable upstream reference changes underneath an approved pipeline, without forcing every workflow line to become an opaque commit hash. What becomes easier is controlling change. Deciding whether the pinned code deserves trust remains the developer’s job.