Gemini 4 Argon Arrives, and Agent Infrastructure Opens Up

Gemini 4 Argon Opens Up

A frontier model built for sustained work is now broadly available, but its introductory price has an expiry date and its strongest results still belong to Google.

Our main story is Gemini 4 Argon, and what its release means for developers considering longer, more involved agent workflows. Google made the model globally available on 13 October through the paid Gemini API and its enterprise products. Consumers can also reach it through the Gemini app and AI Mode in Search, although only with a Google AI Pro or Ultra subscription. For developers, this is paid-tier access rather than a free experiment.

The headline technical detail is a unified input-and-output limit of one million tokens. That means the allowance covers the material sent to the model and what it generates, rather than advertising a huge context window while treating the output separately. Google has also introduced a continuation protocol for work that runs for a long time. In practical terms, the model is being offered for jobs that may involve a large codebase, a substantial document set or a sequence of tool calls that cannot be completed in one quick response. The continuation mechanism matters because a long context limit alone doesn't make an agent durable. The application still needs a reliable way to resume work, preserve state and recognise what has already been done.

That combination changes the engineering question. A large context gives the model room to see more of the task, while continuation gives the surrounding application a way to carry the work across boundaries. Neither guarantees that the model will use all that material well. An agent can still bring forward irrelevant history, miss an earlier constraint or resume from the wrong state. A serious evaluation should therefore track whether the finished work is correct, how many continuations it needed, what context was carried forward and how much output it generated. Those details reveal whether Argon is completing longer jobs efficiently or merely keeping them alive for longer. They also help separate a model-quality problem from a fault in the application's state handling.

Pricing needs a careful look before anyone designs around that scale. Until 30 November, Google lists the API at two US dollars per million input tokens and ten dollars per million output tokens. Standard pricing is then due to double to four dollars for input and twenty dollars for output. A short evaluation may look inexpensive at the introductory rate. An agent that repeatedly carries large histories, generates lengthy results or runs across many users could produce a different bill after the increase. The sensible comparison is the cost of completing a real task, not the price of one isolated model call.

Google reports leading benchmark results and gains in its own engineering work. Those figures are useful as a description of what the company has measured, but they aren't yet independent evidence of performance across representative production systems. Long-running work exposes weaknesses that benchmarks can miss: losing track of constraints, repeating tool actions, recovering badly from an error or consuming more tokens than expected. Developers now have enough access to test those behaviours directly.

My read is that Argon's immediate value is practical access to a model designed for sustained, multi-step work. The trade-off is equally concrete: it sits inside a paid, Google-centred toolchain, and the standard price is already known to be higher than the launch price. Run it against the awkward tasks your software actually performs, include the December pricing in the calculation, and treat Google's performance numbers as a starting point rather than the result.

Workday Lets Outside Agents In

That gives us the model layer. The harder enterprise question is what an agent is allowed to touch once it starts doing useful work.

Workday has made a set of tools generally available that lets external applications and AI agents operate against its HR and finance platform. The release includes Agent Harness, Agent-Ready Tools, Custom Agents, Developer Agent and Data Cloud. Agent-Ready Tools expose approved actions through the Model Context Protocol, or MCP, while Live Data Query offers SQL access to current Workday data under the business rules already configured in the platform.

That design aims to avoid a familiar enterprise shortcut: copying sensitive operational data into a separate store that has weaker permissions and a new audit problem. An agent can instead work through Workday's roles, approval processes and audit trails. Customers aren't locked to one model family, and agents built with LangChain can be deployed. Support for Google's Agent Development Kit is narrower for now and remains limited to design partners.

The control point stays inside Workday. An external agent asks for an approved action or queries current data, and the platform applies the organisation's existing rules around that work. That can keep an approval and its audit record close to the HR or finance process it affects. It also means the quality of the boundary depends on the roles and approvals the customer has configured. An audit trail can show what an agent did; it doesn't make an overly broad permission sensible.

Some of the more ambitious safeguards are also still on the roadmap. Agent Context Service is planned for early access late in 2026, and Grounded Reasoning is planned for early 2027. They shouldn't be treated as protections in the product that customers can deploy today. Workday also hasn't provided independent evidence that every combination of third-party model, customer role design and complex approval flow will enforce policy consistently.

For organisations, the useful shift is that agent governance is moving into the system of record. That can reduce duplicated security work and make approvals easier to trace. It also increases dependence on the platform that owns the permissions and audit history. A well-configured Workday environment may give an external agent a controlled path to useful work; a poorly designed role model will still be a poorly designed role model, only moving faster.

One Agent Kit, Five Languages

There is also a quieter change for developers who don't want a Python service bolted onto every application.

Google's Agent Development Kit now has native implementations for Python, Go, TypeScript, Java and Kotlin. They share an architectural approach, and each implementation includes an MCP client as well as support for Agent2Agent communication with remote agents over HTTP. That makes it more realistic to place an agent component where the rest of the application already lives: Go in a backend service, TypeScript in a web stack, Java or Kotlin on the JVM, or Kotlin in an Android application.

The interoperability piece is more important than the language count on its own. MCP gives an agent a common way to reach tools, while Agent2Agent, usually shortened to A2A, lets separately running agents communicate. A mixed system can therefore keep components in different languages without requiring all of them to share one runtime. That removes one reason teams have been introducing a Python orchestration service solely to connect models and tools.

Shared protocols don't make the implementations interchangeable. They give agents a common route to tools and remote peers, but the available adapters, cloud integrations and evaluation support can still differ by language. A developer can keep a service in its natural stack without assuming that an example built against the Python reference will transfer feature for feature. In a mixed-language system, each component still needs testing against the facilities its own implementation provides.

The five implementations aren't equivalent, though. Python remains the reference implementation and has the widest set of Google Cloud integrations and model adapters. Kotlin can run an agent loop locally on Android, which opens some interesting device-side possibilities, but its ADK 2.0 graph workflows are still described as experimental. Google does not claim complete feature parity or equal production maturity across the languages.

For a developer choosing a stack, the language barrier is lower, but the maturity decision hasn't disappeared. Existing skills and deployment systems can now carry more weight in that choice. Before committing, check the particular integrations, evaluation tools and workflow features the application needs, because a shared architecture doesn't guarantee that the Go, TypeScript or Kotlin path behaves exactly like Python in production.

Intel Bets on Memory for Inference

At the hardware layer, Intel is trying a different pitch from the usual race for the largest compute number.

The company has disclosed specifications for its GPU D-series inference accelerator, previously known as Crescent Island, and says customer sampling is under way. The Xe3P-based design can provide up to 480 gigabytes of LPDDR5X memory, 1.5 terabytes per second of memory bandwidth and 1.3 petaflops of FP8 compute within a 350-watt power envelope. Intel's own PCIe card carries 160 gigabytes; the larger 480-gigabyte configuration is available to partners building their own cards.

Intel says one card can host models with up to 300 billion parameters, while a system with eight GPUs can go beyond one trillion parameters. Hosting a model is not the same as serving it quickly, so those capacity claims don't answer questions about tokens per second, latency under concurrent load or the performance of the software stack. There are no independent results yet, and Intel hasn't announced broad availability or pricing. This remains pre-release hardware in customer sampling.

The deployment shape is the interesting part. A 350-watt, air-cooled PCIe accelerator could fit into more conventional servers than hardware that demands specialised liquid-cooled racks. For an organisation expanding inference capacity in an existing data centre, avoiding a rack-level cooling replacement can be as relevant as raw accelerator speed. High memory capacity may also reduce the need to split a large model across more cards, although measured throughput and total system cost will decide whether that advantage survives outside a specification sheet.

Intel is competing on memory and compatibility rather than claiming the peak-compute crown. That could be a useful trade for buyers with air-cooled infrastructure, but only if partner cards appear at sensible prices and the software can keep the hardware busy. Until availability, pricing and independent tests arrive, this is a promising deployment option rather than a purchasing decision.

Patching Ivanti Is Only Step One

Now for a security issue where a successful update can still leave an operator with the wrong answer.

CISA has added CVE-2026-104935 to its Known Exploited Vulnerabilities catalogue after confirmed attacks against Ivanti Connect Secure gateways. The authentication bypass allows an unauthenticated attacker to execute commands. CISA says attackers have used it to steal credentials and exfiltrate data, so this is observed activity rather than a theoretical path described in a lab.

The affected versions include 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier. Ivanti has published fixed releases for each affected branch and gives the flaw a severity score of 8.6. Operators on the 22.8 branch also have a longer-term decision approaching because that branch reaches end of life on 31 January 2027. That deadline doesn't change the immediate patching need, but it does mean an organisation staying on that branch has a migration decision to make after the incident work is under control.

The uncomfortable detail is that Ivanti's Integrity Checker Tool may not detect exploitation. Attacker commands can run in memory, leaving the appliance able to pass a check that an operator might otherwise interpret as evidence of a clean system. Updating closes the known vulnerability, but it doesn't establish that credentials weren't stolen or that data wasn't accessed before the patch.

The order of work matters. Apply Ivanti's fixed release to close the exposed path, then use network and memory evidence to assess a suspected compromise. A clean integrity result can't replace that second step because the tool may never see commands that ran only in memory. If the investigation finds signs of credential theft, the response extends beyond the gateway itself.

Internet-facing gateways sit close to identity, remote access and high-value network paths. The number of compromised organisations, and how long attackers were exploiting the flaw before disclosure, remain unclear. The key judgement is simple: treat the patch as containment of the entry point, not a forensic clean bill of health.

A Proposal to Contain Cyber-Capable AI

The Ivanti case is a current incident. A group of scientists is asking how the industry should handle AI systems that could make future cyber incidents harder to contain.

An open letter signed by about 350 scientists from more than 30 countries calls for high-assurance containment of cyber-capable AI. Its recommendations include initially air-gapping capable models from external networks, putting containment under independent oversight, and creating an international body to record containment failures and security incidents. The record would eventually be published, allowing organisations to learn from failures beyond their own walls.

Air-gapping means physically or logically isolating a system from external networks. Applied to a cyber-capable model, that could reduce the chance that the model reaches targets or tools outside a controlled environment while it is being evaluated. The hard part is operational. Useful testing often needs software, data and controlled interactions, so the isolation boundary, the people allowed to cross it and the evidence collected around each test would all affect whether the protection works.

The proposed incident body could address another weakness: private failures produce very little shared learning. Aviation and cybersecurity have shown the value of structured incident records, but an AI system would need agreed reporting thresholds, protection for sensitive details and enough participation to reveal recurring patterns. None of that authority exists yet. No government has committed to creating the body, and its membership, powers and reporting rules remain unspecified.

For frontier-model laboratories, the letter adds pressure to document isolation controls and explain what happens when containment fails. My view is that a shared record could improve engineering practice, provided it captures useful evidence rather than vague assurances. Without agreed authority and participation, though, it remains an expert appeal rather than an international safety system.

Security Hardware Moves Inside the Server

There is another early-stage security effort taking shape, this time much closer to the silicon.

Marvell, Microsoft and Oracle have formed an Open Compute Project working group to define an open specification for hardware security modules integrated into servers. An HSM is specialised hardware that protects cryptographic keys and performs sensitive cryptographic operations. These devices are often network-attached. The proposed design would instead put a silicon-based, attested security boundary into the server, targeting key caching, cryptographic operations and workload-integrity attestation.

The group says the design will align with NIST FIPS 140-3 Level 3. That is the working group's stated target, but it has not delivered a completed standard or a generally available compliant product. An initial draft is targeted around the 2026 Open Compute Project Global Summit, with version 1.0 to follow.

If a common specification gains support, cloud operators could keep keys closer to the workload while still verifying the hardware boundary. That may reduce some latency and simplify parts of confidential-computing and AI infrastructure. It could also let customers compare implementations across suppliers instead of accepting a security design tied to one vendor. Those benefits are still claims around an unfinished specification; they haven't been independently demonstrated in deployed systems.

Nothing changes for current data-centre deployments yet. The useful test will be whether other hardware and cloud providers adopt the specification, interoperable products appear, and certification evidence matches the promised design. Open hardware security can make trust easier to inspect across vendors, but only broad adoption will stop this becoming another supplier-specific interface with an open label.

What Changes for You

One practical permission change is ready to use now, and it is worth checking anywhere software creates repositories on your behalf.

GitHub has introduced finer-grained permissions for GitHub Apps and fine-grained personal access tokens. A new repository_creation:write permission allows an app or token to create a repository without also receiving the power to delete or transfer repositories. A separate installation_repositories:write permission lets automation control which repositories an app installation can access. GitHub Apps also gain offline_access support, providing a staged route back to short-lived, rotating user tokens.

For developers and platform administrators, the immediate difference is a smaller blast radius for provisioning automation. An internal developer portal, project bootstrapper or integration may no longer need broad repository-administration access simply because it creates repositories. Existing grants deserve a review: if an app received administration or a classic repository scope to work around the old permission model, a purpose-built permission may now cover the job.

Most of these changes are due in GitHub Enterprise Server 3.24, while offline_access is available in 3.23. That version boundary is the main limitation for self-hosted installations. The permissions also improve only the GitHub side of the workflow; they don't correct excessive access in cloud credentials, CI systems or other tools connected to the same automation. Still, reducing repository authority from delete-and-transfer power to create-only access is a concrete security improvement, and one administrators can apply without redesigning the provisioning service.