Software development is rarely a one-person job. A request or an idea may begin with a product manager or another employee, before moving through developers, designers, reviewers, and other stakeholders on its way to becoming working code.

Salesforce now wants to put an AI coding agent directly into that workflow to reduce the number of handoffs and additional time involved in moving a software project from an idea to a finished product.

The CRM software provider has released Slack Code, a new service built around dedicated channels inside Slack where a coding agent can be asked to take on a software development task while the stakeholders involved follow its progress, provide context and intervene as needed.

When a user tags a supported coding agent, such as Anthropic’s Claude, Cognition’s Devin, GitHub Copilot, ChatGPT, or a Vercel agent, from any Slack conversation, the new service automatically creates a project-specific code channel for the task, including relevant team members, Katie Steigman, VP of product management at Slack, said in a short video presentation.

The channel can retain relevant context from the conversation and give participants separate views for the agent’s conversation, its plan, code diffs, and the option to review the changes the agent makes, provide feedback and steer, pause or stop the agent if needed, Steigman added.

Once the task is complete, the agent can package the work for human sign-off and, depending on the workflow and agent, open a pull request as well, Steigman further said, adding that the code channel then archives automatically, while retaining the history as a searchable record.

That proposed workflow, according to Salesforce, is differentiated from the traditional one-person, one-agent approach to AI coding, where an employee or product manager flags an issue or idea in a collaboration tool like Slack, raises a ticket in a project management tool such as Jira, and then hands it over to a developer who works with a coding agent in an IDE, terminal, or another interface.

Salesforce’s bet is that allowing the stakeholders involved in a project to work alongside the same agent and intervene while it carries out a task can reduce the handoffs involved in moving the resulting code through subsequent stages of the development process.

Productivity benefits in software development

For enterprise teams, Salesforce’s proposed workflow model via Slack Code can offer productivity benefits, analysts say.

“The model around Slack Code could mean faster fixes, better cross-functional input, and fewer costly handoffs between technical and non-technical staff,” said Manoj Chandra Jha, principal analyst at Nord-IQ Research.

Primarily because putting all the stakeholders involved in a task alongside the same AI agent could help teams catch incorrect assumptions early, before they surface later in the review process and require work to be redone, which adds costs and time, echoed Amit Kumar Jena, AI development manager at IT consulting firm Kanerika.

The same model could also broaden who gets to initiate software development work, Jena said, allowing, for example, a product manager who spots a bug to tag an agent and watch it produce a first pass instead of filing a ticket and waiting for the task to be picked up.

Beyond the productivity gains, making an agent’s prompts, plans and corrections visible could also help teams learn faster from its work, according to Advait Patel, senior site reliability engineer at Broadcom, particularly by giving other engineers and stakeholders more insight into how the agent was directed rather than limiting their view to the final code diff.

“Stakeholders watching how a good prompt gets constructed and corrected is genuinely useful, and right now none of that is observable,” Patel said.

That same shared context, which is archived as a searchable record after a project is completed, according to Patel, could also come in handy when teams need to revisit or investigate an older code change.

Typically, in traditional workflows, the reasoning behind an agent’s work, including what it was asked to do and the plan it followed, may remain in a developer’s terminal session or across different tools, leaving engineers to reconstruct that context from the final code diff alone.

The trade-offs of making AI coding more visible

However, putting an agent’s work in a shared, always-visible channel could also introduce new trade-offs.

“Coding is deep work, and Slack is the interruption machine. Putting them on the same surface is not automatically a win,” Patel said, warning that allowing multiple stakeholders to intervene could also create competing suggestions and midstream changes, potentially slowing a task while forcing the agent to repeatedly adjust to new instructions.

The senior SRE also questioned whether developers would be willing to expose the messier parts of working with an AI agent, including false starts and ineffective prompts: “If developers carry out the messy part privately and paste the clean result into the channel, it defeats the whole purpose. The transparency you get is the performance, not the process.”

There are also concerns around scaling Salesforce’s approach to an extent.

Since Slack Code, according to Patel, creates a new channel for each coding task, that could leave large enterprises managing hundreds of additional channels and create a notification problem that has yet to be addressed.

Those practical concerns and developers’ resistance around making their coding activity visible could also shape how enterprises ultimately adopt Slack Code.

Rather than replacing private developer-agent sessions altogether, Patel expects a hybrid approach in which shared channels are used for work that benefits from cross-functional input, while more focused engineering tasks continue to be handled privately.

“The private loop stays dominant for anything hard. Refactors, debugging, performance work, anything touching a system, you have to hold in your head. Multiplayer fits small, well-scoped, visual or cross-functional work. A copy change, an internal tool, a prototype, a bug, a product manager can describe precisely,” Patel said.

Focus on security and access critical for adoption

The question of which tasks belong in Slack is only one part of the enterprise adoption equation, however. Security and access controls will also be critical factors, analysts pointed out.

While Jena said enterprises will need to determine what information an agent can access inside a live channel and whether that access is limited to a specific task, Patel cautioned that Slack channel membership should not automatically translate into permissions to access or modify an underlying code repository.

Otherwise, adding someone to a channel could effectively become a way to grant code access, creating a potential privilege-escalation risk, Patel noted.

For now, Salesforce said that agents operate within Slack’s existing permissions, security model and administrative controls. The service also comes with APIs that enterprises can use to tailor agent behavior and automate parts of the workflow, including account provisioning and authentication.

Malicious versions of three Rust packages, including the widely used arrayref, were published to the crates.io registry on August 20, carrying a backdoor that executed automatically when affected projects were compiled.

Security researchers at Wiz said the attack also shares infrastructure with recent supply-chain campaigns attributed to North Korean threat actors.

The compromised releases were “arrayref@0.3.10”, “internment@0.8.7,” and “append-only-vec@0.1.9.” All three introduced a dependency on “proc-macro1,” a typosquat of the legitimate and widely downloaded “proc-macro2” crate.

The malicious dependency contained a build script that downloaded and executed a second-stage payload during compilation, Wiz researchers said in a blog post. “The second stage payload is selected based on the platform, with support for x86_64 versions of Linux, Windows, and macOS, in addition to aarch64 macOS,“ they added.

A StepSecurity analysis noted that arrayref has 245 million all-time downloads, with 53.7 million of them happening in the last 90 days. The cybersecurity outfit estimated per-crate exposure windows at 86, 90, and 107 minutes, respectively, before all of them were deleted along with other associated crates.

The attack was first reported to RustSec and security@rust-lang.org by researcher jhobern, but only the arrayref compromise was known at the time.

The malicious code ran at build time

The attack did not require developers to execute suspicious code or even call a function from arrayref. “Because Rust build scripts run at compile time, simply building any project whose lockfile resolved arrayref 0.3.10 was enough to detonate the payload. The crate’s code never needs to be called,” StepSecurity researchers said.

When the affected package was built, the “Cargo.toml” configuration file added proc-macro1 as a dependency. This dependency then reconstructed a command-and-control (C2) URL from Base64 fragments, disabled TLS certificate validation, downloaded a platform-specific payload, and executed it as part of the normal build process.

Wiz found the payload collecting host, username, and operating-system information, enumerating installed applications and inspecting Chrome, Brave, and Edge profiles for saved-login and extension information.

It could also establish persistence through Windows Registry Run keys, macOS LaunchAgents or Linux systemd user services, and accept commands to reconfigure itself, terminate, or download and execute scripts.

The payload supported Linux, Windows, and macOS, including Apple Silicon Macs. It featured a fallback domain-generation mechanism that could generate 10 .com domains every five days if the primary C2 became unavailable.

Links to North Korean campaigns

Wiz said the payload’s infrastructure “substantially overlaps” with operations attributed to recent DPRK actors.

The strongest link is the C2 request path, it said. The backdoor communicates with an endpoint also used in the Mastra campaign, which Microsoft attributed to the DPRK-linked Sapphire Sleet. The IP infrastructure used in the arrayref campaign also shares an SSL certificate issuer with the infrastructure associated with that operation.

Another connection was found with the Axios npm supply-chain campaign. Wiz said a victim reported C2 traffic involving an IP address that also appeared in Google Cloud Threat Intelligence’s analysis of the Axios attack, which Mandiant has linked to North Korea.

Wiz recommended that organizations search “Cargo.lock” files and local Cargo caches for the compromised versions and attacker-controlled packages. It also said that any developer workstation or CI runner that actually built an affected project should be treated as compromised, with accessible credentials, tokens, and keys rotated and artifacts rebuilt from clean sources.

The article originally appeared on CSO.

The reported $10 billion deal between Anthropic and AI cloud startup Volta is more than just another big-number headline in the AI infrastructure race. It’s a sign of where cloud computing is headed. When a frontier AI company needs massive amounts of specialized compute, and a relatively young cloud provider claims it can deliver that capacity, billions of dollars shift hands before most enterprises even figure out their actual AI infrastructure requirements.

The Anthropic-Volta deal is notable for its size, duration, and specialized AI hardware involved. But it’s also a signal, and that’s the real story. We are watching the rise of neoclouds, a new class of cloud providers built less for generalized enterprise hosting and more for focused, high-performance infrastructure for AI training, inference, model serving, GPU clusters, and related workloads. The hyperscalers are still growing, and recent revenue announcements from Amazon, Microsoft, and Google show that the Big Three remain very much in control of the broader cloud market. However, AI has created enough demand, specialization, and scarcity to open a lane for a new group of infrastructure providers.

Huge deals in the neocloud market

Large commitments have long shaped the cloud market. Enterprises signed multiyear spending agreements with hyperscalers. SaaS companies prepaid for capacity. Startups took cloud credits and grew into large consumption accounts. What’s different now is the scale and urgency of AI infrastructure deals. These are not ordinary enterprise hosting contracts. They are multibillion-dollar bets between companies that both need the deal to validate their futures.

For the AI model company, the contract is about access to compute. Without processors, power, networking, cooling, and memory, there is no competitive frontier model strategy. For the neocloud provider, the contract is about credibility. A $10 billion commitment from a major AI player signals to investors, chip suppliers, data center partners, and future customers that the provider is not just another GPU reseller with a website. It becomes part of the AI supply chain.

This is one reason neoclouds are emerging so quickly. They are being financed, validated, and scaled by demand that did not exist in this form even a few years ago. Many of these providers will serve small and midsize businesses that cannot get meaningful GPU access from the hyperscalers, or they do not want to navigate the complexity of massive cloud platforms. At the same time, they will also serve the largest AI companies in the world. That range is unusual. The same class of provider may offer on-demand inference capacity to a startup on Monday and negotiate a multibillion-dollar training infrastructure agreement with a model company on Tuesday.

Scarcity as a business model

The rise of neoclouds is not only about clever positioning. It is also driven by scarcity. Enterprises and AI companies cannot always buy the processors they need, even when they’re within budget. Advanced GPUs and AI accelerators are constrained by supply chains, manufacturing capacity, allocation decisions, and the simple fact that everyone wants the same hardware at the same time.

Memory is another bottleneck. Shortages of DRAM and high-bandwidth memory are central constraints. A model training cluster is not just a pile of GPUs. It requires memory, networking, storage, power infrastructure, cooling systems, and operational expertise. If any of those components become constrained, the entire infrastructure plan slows down.

Neoclouds can step into this gap by aggregating access to scarce resources and turning them into consumable infrastructure. In many cases, customers are not buying compute because it’s cheaper than owning it. They buy compute because they cannot get the hardware any other way or because they cannot build the operating model fast enough. This is on-demand infrastructure, but with a narrower, more urgent purpose than traditional public cloud consumption.

That demand creates a specific niche. Neoclouds will focus on serving the training and inference needs of companies that require specialized AI infrastructure but do not want (or cannot manage) the capital expenditure and operational complexity of owning it. Some will specialize in training clusters. Others will focus on low-latency inference. Some will build around specific chip architectures or data center geographies. The winners will not just have GPUs. They will have reliable capacity, predictable economics, strong networking, useful software layers, and a clear understanding of AI workload operations.

The hyperscalers won’t be toppled

It would be a mistake to think neoclouds will replace Amazon Web Services, Microsoft Azure, or Google Cloud. That’s not happening. The hyperscalers also benefit from the AI boom, and they have enormous advantages in enterprise relationships, global infrastructure, platform services, security, compliance, and ecosystems. Their revenue growth shows that enterprises are still buying cloud services from them at massive scale.

However, demand for AI infrastructure is expanding faster than any single class of provider can absorb. Hyperscalers will capture a large share of this market, but not all of it. Neoclouds will continue emerging because the market needs more capacity, specialization, and options. Over the next two to three years, I expect many of these neocloud providers to inflect sharply. Revenue will rise quickly for those that secure hardware, power, and customers. Some will become acquisition targets. Some will fail because they overcommit, underdeliver, or discover that running AI infrastructure at scale is harder than raising the money to build it.

The most interesting outcome is not a world where neoclouds beat hyperscalers. It is a world where enterprises use both. General-purpose workloads, data platforms, application modernization, and enterprise integration may remain with the big cloud providers. Specialized training and inference workloads may move to neoclouds when economics, availability, or performance make sense.

Learn from cloud mistakes

This is where the gold rush becomes dangerous. Many enterprises are making strategic decisions about where AI training and inference will run before they understand their own requirements. This is a recipe for disaster.

Ten to 15 years ago, enterprises rushed into public cloud because they believed speed mattered more than architecture. They lifted and shifted applications as quickly as possible, signed commitments, and celebrated migration numbers. Then they spent the next decade dealing with cost overruns, poor workload placement, security gaps, operational confusion, and technical debt. In 2026, many organizations are still repairing the damage from cloud decisions made in a hurry.

The AI infrastructure push is even more extreme. Mistakes will not merely cost two or three times more than expected. In some cases, they could cost 10 to 20 times more than a properly designed equivalent solution. For a Global 2000 company, it can become a board-level issue. In the worst cases, it can become a bankruptcy-level decision, especially when companies lock themselves into capacity levels, architecture, or operating models that do not align with real business demand.

Enterprises need to slow down. Don’t press the “Buy” button until you understand what the infrastructure is for. Are you training foundation models, fine-tuning existing models, running retrieval-augmented generation, hosting inference for internal applications, or experimenting with AI features that may never reach production? These are different problems. They require different infrastructure, economics, and risk models.

The most important question is whether the workload needs AI at all. Many applications are being pushed into AI because executives want AI attached to everything. That is not strategy. That’s branding. Traditional analytics, rules engines, search systems, automation platforms, and better application design may solve many of these problems without expensive AI infrastructure.

Neoclouds will be an important part of the next cloud era. They will provide the capacity the market desperately needs, and some will become durable infrastructure companies. But enterprises should not confuse availability with suitability. Just because someone can sell you GPUs does not mean you should buy them. The smart move is to define requirements first, model the economics second, and select providers third. Anything else is just another land grab, and we already know how that ends.

Python can’t stop, won’t stop evolving. Python 3.15, due in fall 2026 but available now in its first release candidate, abounds with useful new features worth trying out: lazy imports, a new profiling technology, immutable dictionaries, and its ever-evolving JIT (just-in-time) compiler.

Top picks for Python readers on InfoWorld

Speed boost your Python programs with new lazy imports
Don’t let a fat Python import be a bottleneck for the rest of your program. Lazy imports let you defer executing a module until the time it’s actually used. Best of all, you can use lazy imports with no changes to existing code.

Hands-on with the new sampling profiler in Python 3.15
It’s like X-ray goggles for your code! Tachyon, the new profiling system for Python, lets you see what your program is doing without having to instrument it, rewrite it, or even pause it and restart it.

Get started with Python’s new frozendict type
Python users have been clamoring for an immutable dictionary type, and now they’ve got one — built right into the language. Ever wanted to use a dictionary as a key for another dictionary’s value, or seal a dictionary against modification? Here’s your solution.

Get started with Python’s new native JIT
We all want faster Python, but nobody wants to rewrite their code. Python’s new built-in JIT is paving the way to automatically faster Python, and you can get started with it right now.

More good reads and Python updates elsewhere

Run Numba in the browser with WebAssembly
Numba speeds up computation in Python by compiling to native code, making it a tricky candidate for porting to an in-the-browser experience. Nevertheless, a new project from QuantStack, called JupyterLite, not only brings Numba into the browser but adds performance boosts too.

Mojo is now open source
The one-time Python challenger for the scientific computing space has shaped up to be a “Rust lite” language. And now it’s freely available under an Apache 2 license for your tinkering and forking pleasure.

Scaling NumPy on free-threaded Python
As Python’s free-threaded build gains traction, developers of libraries such as NumPy are working to squeeze maximum oomph from Python’s newfound parallelism. Learn how hidden bottlenecks in NumPy kept it from scaling, and what it took to break that stranglehold.

How a common string method in Python turned out to have a security vulnerability
When does converting a string into lowercase expose you to danger? When a corner case in how the operation is processed can deliver inconsistent results. Read about how this tiny but troubling problem was detected and fixed.

Rust is slated to play a huge part in Ubuntu’s future. As a language that allows programmers more control over resource use and performance as well as removing many classes of memory safety issues, it’s an especially good choice for building security-sensitive software.

But modernizing huge amounts of the legacy C code that currently powers the Linux operating system has been, and continues to be, a major challenge.

“Rewrites have long been expensive and risky, and do not often materialize obvious improvements. Established codebases often contain years of bug fixes, compatibility decisions, operational knowledge, and hard-won performance optimizations,” Jon Seager, VP engineering at Canonical wrote In a blog post on Wednesday. “If we want more systems software to benefit from memory safety, we need better ways to reduce the cost and risk of migration.”

To that end, Canonical, along with UK Research and Innovation, is funding a three year PhD project to create a platform that will translate hundreds of thousands of lines of C code into Rust. The project will be led by Professor Meng Wang, with Seager and Dr. Cristina David as co-supervisors of PhD student Alex Wood.

It’s not as easy as it may sound, Seager wrote. “Traditional source-to-source translators can process substantial amounts of code, but often preserve the structure of the C too literally. The result may compile as Rust, but still rely heavily on unsafe operations, retain awkward C idioms and require significant manual work before it resembles code a Rust maintainer would choose to own.”

On the other hand, a large language model (LLM) can create “convincing, idiomatic Rust” but struggles with “repository-scale context,” Seager said. And, he added, “more importantly, plausible-looking output is not evidence that the translated program behaves like its source.”

Thus, the project will combine the two techniques, machine learning and conventional program analysis, to build the system.

Its proposed architecture consists of four components: scheduling, which will split a repository into chunks containing sufficient context to give the translation mechanism understanding of types, dependencies, and behavior; translation using models trained against a library of known C-to-Rust translations; validation to check that the translation behaves like its C source; and debugging and repair to analyze and correct issues.

“Here,” Seager wrote, “the language model is only one component in the system. Generated code should be treated as untrusted until there is evidence that it preserves the desired behavior.”

Two Ubuntu security components, AppArmor and snap-confine, will be targeted as case studies. “This is not a commitment to replace AppArmor or snap-confine with what is generated,” Seager noted, but “rather that we have a vested interest in the software and are keen to see the results.”

The project’s “most optimistic outcome,” Seager said, “would be a system capable of translating substantial C repositories into Rust with strong evidence of behavioral equivalence and relatively little manual intervention. The research could also produce better methods for decomposing repositories, stronger validation techniques, reusable translation datasets, improved program-repair tools, and a more precise understanding of where automated migration stops being reliable.”

TrueFoundry has launched TrueForge, an open-source agent harness that lets developers build and run AI agents using models from different providers, positioning it as an alternative to Anthropic’s Claude Managed Agents.

The San Francisco-based enterprise AI infrastructure startup was founded in 2021 by a team that included former Meta engineers. It initially focused on software for deploying machine-learning models before expanding into generative AI infrastructure.

An agent harness is the software layer that manages how an AI agent interacts with the underlying model and external tools. Anthropic’s Claude Managed Agents provide this functionality as a hosted service for long-running agent workloads on the Claude Platform.

TrueForge can run on an enterprise’s own infrastructure and supports OpenAI and Anthropic models as well as more than 20 additional models, according to TrueFoundry. Developers can bring their own Model Context Protocol (MCP) servers and API keys. The company is also offering a hosted version with usage-based pricing.

TrueFoundry says TrueForge can reduce total agent operating costs by 50%, although its published benchmark shows different savings depending on the model and harness being compared.

In a 14-task DevRev Enterprise-Bench test, TrueFoundry said TrueForge and Claude Managed Agents each completed about 11 tasks using Anthropic’s Opus 4.8 model. TrueForge averaged $8.50 per run, compared with $11.80 for Claude Managed Agents, about 30% less.

 The difference widened when TrueForge used GLM-5.2. TrueFoundry said that configuration averaged $2.90 per run while completing about the same number of tasks as Claude Managed Agents running Opus 4.8, representing a roughly 75% reduction.

The benchmark was conducted by TrueFoundry, so the results have yet to be independently validated across larger production workloads.

More control, but more responsibility

Separating the agent runtime from the model provider can give enterprises more freedom to change models while retaining control of the surrounding agent infrastructure, according to Pareekh Jain, CEO of Pareekh Consulting.

“TrueForge gives enterprises more control and less vendor lock-in,” Jain said.

Companies could, for example, route simpler tasks to cheaper or open-source models while reserving more expensive models for workloads that require them, he said. That could let teams switch models without rebuilding the surrounding tool integrations and governance setup.

The separation could be particularly useful for companies in regulated industries, according to Lian Jye Su, chief analyst at Omdia, because it allows them to integrate their own controls for budgets, access, and observability rather than relying entirely on those provided by the model vendor.

The trade-off is that enterprises have to run more of the stack themselves. Su said that includes maintaining the runtime and ensuring the environment meets regulatory requirements.

Where self-hosting could pay off

Whether self-hosting is cheaper will depend heavily on how the agents are used, Jain said. Costs can rise as agents use larger contexts or repeatedly call models and tools, while self-hosting also brings infrastructure and monitoring expenses.

Su said token consumption is likely to account for the largest share of agent operating costs. Self-hosting could therefore become more attractive when companies can use lower-cost open-weight models and already have the infrastructure and engineering expertise to operate agent workloads, he added.

Jain said self-hosting is more likely to pay off for high-volume agents used continuously, where enterprises have greater scope to route workloads across models and make better use of their infrastructure.

For smaller or unpredictable workloads, managed services could remain cheaper because the provider absorbs much of the infrastructure and operational overhead, he said.

Agent harnesses as an infrastructure layer?

Agent harnesses could eventually develop into an infrastructure layer of their own.

Su said that is possible, but the technology has not yet reached the level of standardization needed for the harness to become a fully independent, model-agnostic layer. The industry would need greater agreement on how runtimes handle context, model routing and tool use, as well as broader security and safety requirements.

Jain similarly expects agent harnesses to emerge as an infrastructure category, although he does not expect the market to converge in the same way Kubernetes did around containers. Competing vendors are likely to add capabilities beyond the runtime itself as they seek to differentiate their platforms, he said. Standards such as MCP could nevertheless make models and tools more portable between those platforms, Jain added.

AI coding assistants are supposed to reduce the work required to turn a developer’s intent into working software. But some users of Anthropic’s Opus 4.8 and Opus 5 models say they are having to spend additional time, prompts, and tokens correcting the models’ language, sometimes even routing their output through cheaper AI models to make it usable.

In a detailed GitHub issue, Peter Bower, founder and CEO of London-based tech startup SpaceCell, said that Opus 4.8’s tendency to use confusing or invented terminology was creating extra work in software development workflows, particularly when generating code documentation.

That was despite being explicitly and repeatedly prompted to avoid certain terms and use specified alternatives, Bower wrote, adding that the model continued to introduce the unwanted terms, forcing repeated cleanup passes, including through cheaper Sonnet or Haiku models, to make the documentation “sane and presentable.”

Those additional passes, he further said, were pushing token costs up to two times higher than they otherwise would have been.

Bower’s issue, which was posted last month, has since received nearly 265 acknowledgements, which could indicate that several other users have faced an issue with Opus 4.8’s language coherence one way or the other.

Some even commented on having faced a similar issue. Bower himself also references a ClaudeAI subreddit in his issue, which points to Opus 4.8’s language incoherence. That, too, received a significant number of upvotes, which are Reddit’s equivalent of a thumbs-up that is often used on social media to indicate approval or support for a post or comment.

Another subreddit thread points to a similar issue with the Opus 5, with users reporting the model’s tendency to produce confusing, hard-to-parse output, and it received nearly twice as many upvotes.

Why unclear AI output could slow software development

For enterprise development teams, the persistent nature of the reported issue with the Opus models could result in significant productivity drag, analysts say.

“Repeated correction cycles can erode productivity when developers spend enough time reviewing, redirecting and repairing AI output. That offsets the time saved by generating code via a coding assistant or any other tasks,” said Abhishek Satapathy, principal analyst at Avasant.

That erosion in productivity, according to Advait Patel, senior site reliability engineer (SRE) at Broadcom, is also linked to the operational aspects of the software development lifecycle (SDLC) as unclear AI-generated prose could affect design documentation, runbooks, architecture decision records (ADRs) and incident writeups.

“A runbook written in a style that engineers find difficult or unpleasant to read, for example, could become a problem during an incident, when teams need to quickly understand and act on the information in front of them,” Patel said.

Code review, Patel added, presents another potential problem due to unclear prose: “Overly padded or confusing pull request descriptions are likely to be skimmed rather than carefully reviewed, increasing the risk of important details or potential defects being missed.”

Unclear output could have repercussions on cost

The implications of unclear prose extend to costs as well.

That is because the price enterprises pay for an AI coding tool does not necessarily reflect the cost of getting usable output from it, said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

If developers have to make repeated passes to correct, rewrite, or review a response, or route it through another model, then those additional steps become part of the overall cost of completing the task, including human review time, Chopra added.

And most enterprises, according to Patel, often don’t realize this calculus because all of this “is packed into a single line item” in their coding agent bill.

That hidden cost could also have implications for Anthropic’s ability to retain developers.

“Switching coding assistants or underlying models have become relatively easy for development teams, particularly as coding platforms increasingly support models from multiple providers, though enterprises are likely to encounter sunk cost in config, hooks and MCP setup. But the code doesn’t move, the repos don’t move, and thus no migration plan is needed,” Patel said.

“That’s a genuine commercial risk for any model vendor. Low switching cost means goodwill is your only lock-in, and readability complaints erode goodwill fast because people hit them daily,” Patel noted.

Prompt workarounds may not be enough

However, Anthropic has not yet responded to Bower’s GitHub issue, which also outlines the changes he believes the company should make to address the problem.

The startup founder has called for Anthropic to tweak the model’s default writing style to be closer to “a technical white paper or a good Stack Overflow answer”, which is “plain, declarative and direct”.

He also called for the model to be less verbose while strongly adhering to instructions set in CLAUDE.md and repeated during a conversation, arguing that those instructions should persist rather than gradually being overridden by the model’s default communication style.

In the meantime, Patel, who said he has faced similar model drift at work, particularly while working with repositories involving a Jenkins, Python, Terraform, GKE, and Helm stack, pointed to a fix he and his team use when generating documentation and pull request summaries.

Rather than broadly asking Claude to be concise, his team uses explicit rules in project configuration to ban specific phrasings, because asking for conciseness can sometimes make the output shorter but more cryptic, Patel said.

However, Patel cautioned that relying simply on prompt-level workarounds may not be enough for enterprises because model behavior can change over time.

“Model behavior is a moving target,” Patel said. “A version bump can change output register without you deploying anything, and nothing in your pipeline alerts on it.”

That means CIOs and engineering leaders should treat changes in model behavior as something that needs to be tested and monitored continuously.

“Pin model versions for anything in a pipeline instead of tracking latest. Keep a small eval set of your own real tasks and rerun it on every model change. Track rejection and rework rate, that’s your early warning. And don’t let thirty teams each invent their own undocumented prompt workarounds,” Patel advised.

I run 49 scheduled AI agents on one laptop. Another 24 sit beside them, deliberately switched off.

That distinction matters more than it sounds. After eighteen months, I have stopped being surprised by model errors. Models misunderstand requests and occasionally produce confident nonsense. I expect that. I test for it.

What still catches me is how rarely those errors cause an outage. No serious failure in my fleet has started with a bad model answer. They start lower in the stack: a job never loaded, a shell command that existed only in my terminal, a credential expired between runs, a timeout guard built on a utility the operating system does not ship.

The agent did not go rogue. Unix happened.

Most agent-fleet guidance is written forward from a proposed architecture: a router, specialist agents, tools and memory, clean arrows between boxes. I have drawn those diagrams myself. But every design rule I actually use came backward from an incident, after the arrows stopped moving and the dashboard still looked green.

Three failures from one week explain the gap.

What actually broke, and why none of it was the model

The first failure looked correct everywhere I checked. The job existed on disk, its configuration was valid, a symlink pointed into the expected directory, and the script ran when I invoked it by hand.

It had never been registered with the scheduler. I had written the definition, moved it into place, confirmed the file was where it belonged and never once asked the scheduler whether it had picked it up.

For several days it did nothing, and produced no error, because no process existed to fail. I had inspected the desired state and mistaken it for the actual one.

That sounds embarrassingly basic. It is also a small version of a familiar systems problem. Richard Cook’s paper on how complex systems fail argues that incidents are usually attributed to a nearby, obvious cause even though failure emerges from several normally tolerated conditions. My nearby cause was an unloaded job. The conditions around it mattered more: manual execution passed, the file tree looked right, no freshness alarm existed and my review stopped at configuration.

I now treat a scheduler definition as a claim about behavior, not evidence of it. The evidence is the live registry, the last start time, the last successful completion and a fresh artifact produced through the scheduled path.

A file can tell me what should run. It cannot tell me what is running.

The second failure began with an agent command I use dozens of times a day. I had shortened the executable and its arguments to an alias. In my terminal, the short name worked. Inside a non-interactive script, it did not exist.

The failed command should have made this obvious. Instead the wrapper continued, ran a harmless bookkeeping line and returned that line’s status. The scheduler recorded exit code 0. The agent had not run, and the wrapper announced success.

There were two bugs, not one. I had relied on an interactive-shell convenience in production code, and I had allowed a later command to erase the failure signal. The first stopped the work. The second stopped me from knowing, and that one cost far more. A job that dies loudly gets fixed the same morning. A job that dies quietly gets fixed whenever somebody happens to go looking for output that was never there. In my case that was four days, and only because I wanted to read the report, not because anything told me to.

Shell portability is old work. The current POSIX operating-system specification still has to spell out command execution and environment behavior in exhaustive detail, because those assumptions really do change between an interactive shell and a script. This is settled ground. Agent projects just make it easy to walk back onto. The model call feels like the sophisticated part, so the three-line wrapper around it escapes the scrutiny I would give ordinary production code.

My fix was not clever. Scheduled scripts now call absolute paths, or resolve and validate them at startup, and run with a deliberately small environment. They fail on an unset variable. Most importantly they verify the intended effect before reporting success. Exit code 0 is necessary. It is not proof that work happened.

The third failure was a timeout guard. An agent could occasionally stall on a tool call, so I wrapped it with a 40-minute limit and moved on.

The guard depended on a command common on Linux but not installed by default on macOS. My wrapper treated the missing utility like a non-event and continued through its fallback path. For a week, I believed every run had a hard ceiling. None did. Nothing hung during that week, which is the part I keep turning over. The protection was absent and the system looked fine, because the condition it existed for simply did not arise. I got no signal at all — I got lucky, and luck reads exactly like working code right up until it doesn’t.

This bothered me more than a stalled job would have. A broken feature reveals itself when someone uses it. A broken safety mechanism stays invisible until the moment the system is already in trouble.

So I added a rule: every guardrail has to fail its own startup test. The timeout now proves itself against a process I deliberately hang, which is how I found the missing utility in the first place – it took one afternoon and I should have done it a year earlier. Locks, credential checks and circuit breakers get the same treatment. If I cannot force a protection to fire on demand, I do not get to count it as protection.

That instinct is not just mine. A 2025 USENIX OSDI paper on silent semantic failures argues the same thing at far larger scale: process survival and surface-level success are weak substitutes for checking the behavior a system promised. My fleet is tiny next to the systems in that paper. The lesson transfers anyway. I need an oracle for the guardrail, not just an absence of errors.

A good agent says unknown

The most important failure was quieter.

One agent summarizes a small set of email inputs. During a scheduled run its token expired. It could have returned “zero new items,” which would have matched the empty response in front of it and been, operationally, a lie. It had not seen an empty inbox. It had failed to see the inbox.

Instead, the run reported unknown, named the inaccessible source and refused to produce a summary. It then carried on with the parts of the job it could still do, and said which those were. The report that morning was shorter than usual and honest about why. That took me ten seconds to read. Reconstructing the same fact from a confident zero would have taken a week.

That is what I now want from every agent in the fleet. A good agent reports unknown. A bad one reports zero.

The difference is not philosophical. Zero is a measurement. Unknown is a statement about whether measurement was possible. Collapse them and the fleet looks healthiest when it is blind.

Observability guidance usually begins with logs, metrics and traces. The OpenTelemetry observability primer gives the conventional framing: a properly instrumented application emits enough signals to answer questions about its behavior. That is necessary, but agent fleets need another layer. I also need evidence about the boundaries of observation: which sources were reachable, which credentials were valid, how fresh each input was and which expected jobs emitted nothing at all.

A trace explains what a process did. It cannot explain a process that never ran, unless something outside it was watching for the absence.

I now model each scheduled run with more than success and failure. A run can have succeeded, failed, arrived late, been skipped by policy or be unknown because an input could not be observed. That last state is the awkward one, and it is the one that earns its keep. Every expected run has a freshness deadline. Every important data source has an availability result separate from its item count. A heartbeat is accepted only after the job produces the artifact the schedule exists to produce.

This creates more yellow on the dashboard. Good. I would rather investigate an honest yellow than trust a fabricated green. The fleet is not less reliable than it was before I started tracking this. It is exactly as reliable as it always was, and I can finally see it.

Read the running state

None of this is new computer science, which is exactly why it is easy to miss. Agent systems arrive wrapped in new language — planners, tool use, memory, reflection — but they still depend on schedulers, shells, paths, credentials, clocks and exit codes. The new layer does not repeal the old ones. It gives the old ones more ways to fail quietly.

I still evaluate model quality. I still test prompts, tool selection and output grounding. But the questions I ask first are less fashionable. Did the scheduler load the job? Did it start when expected? Did the wrapper invoke the binary I thought it did? Did the safety check prove itself?

The rule I wrote down, and then broke anyway, is simple: Never infer a system’s current behavior from a configuration file. Read the running state.

That is also why 24 agents are switched off rather than deleted. Each one was useful enough to build and not useful enough to keep watching. Every agent I add is another scheduled job that can quietly stop, another credential that can lapse, another silence I have to notice. The cost of a fleet is not the tokens. It is the number of things that can fail without telling you.

The architecture diagram tells me what I intended to build. The running state tells me what I actually have. Only one of them gets to wake me up at 3 a.m.

Microsoft’s open sourcing of .NET not only has sped up the development of the platform, but also has allowed new languages and features to be built on top of the .NET runtime and compilers. At the same time, the extensibility features of Visual Studio Code make it easy for developers to provide the tooling we need to use those new platform capabilities.

One of the more interesting new projects to build on .NET is a Go-like language, G#, that targets both systems programming and mobile applications, with the intent of delivering small, secure, applications and libraries that can be used in other .NET applications. G# is a way to take the lessons learned in Go, Kotlin, and Swift and deliver code that works with .NET assemblies and libraries, taking advantage of NuGet and other similar repository services to build on top of the mature .NET platform. It’s being developed on GitHub, with an impressively rapid release cycle.

Getting started with G#

Getting started with G# is easy. You’ll need a supported version of .NET and the appropriate SDKs for your target operating systems. G# will produce code that’s compatible with .NET 8 through .NET 10, though .NET 10 is preferred. The G# SDK and templates are available from NuGet, which ensures that you can install and run G# from the .NET CLI.

The quickest way to get started is to install the G# templates and then use these to create a console application that you can then open in your choice of development tool and start extending. The structure of a basic application is quite simple, with a project file, the program .gs file, and a NuGet configuration to manage packages and libraries, with support for local SDKs (useful if you’re building G# from source). Building and running the default console template is quick, delivering output in a little over four seconds on an Arm-based Windows PC, which bodes well for building and debugging larger applications.

The installed templates give you options for several different classes of application and library beyond the basic console implementation. Additionally, there’s a Visual Studio Code extension for G# that can be downloaded from the Visual Studio Marketplace, which should speed up development as it includes the appropriate language server bits. The documentation includes a command-line option for installing the extension, which avoids having to search for the necessary files and gets you ready to start coding with G# next time you open VS Code.

Alternatively, you can use the G# language’s own gsc compiler directly, rather than it being called by MSBuild from the .NET CLI. This approach is useful when you want to output code that targets a specific .NET version or compiles as an assembly for use with other .NET languages. This approach avoids using interpreted code and lets you go straight to delivering pre-compiled binaries.

Inside the G# language

The G# language itself is straightforward. Code is structured in packages, with executable sections defined as funcs. By default, G# uses the .NET System namespace, so you can use familiar constructs without having to learn different ways to do the usual things. If you don’t want to bring in System by default, you can disable imports as part of the compiler configuration.

Each function can take parameters and return values, with types declared as part of the parameter list. The parameter list can end with type declarations for any returns, so you can ensure that you’re returning the expected data. Most types include lengths, for example int64, though there are aliases for familiar types as used in other languages. Strings allow you to add alignments and formatting information. In addition to functions, you can define structs and classes to help handle variables, with structs handling values and classes handling references. Similarly, data structs and classes let you treat variables as data, applying copies and assigning values.

Much of the language structure will be familiar, especially if you’re used to working with languages like Go. There are some interesting shortcuts, using features like if let to check for nulls when parsing function parameters. You can use if let alongside G#’s exception handling to manage more complex program flows. Other features include using for in to iterate through collections, allowing you to deliver and use arbitrary length arrays with a function, without having to determine lengths before running operations.

Using G# in distributed systems

G# is designed to support asynchronous programming, which is essential for working with distributed applications. It uses the familiar async and await constructs, though here it’s an async func. Interestingly, there’s the option to wrap a set of asynchronous operations in a scope, which allows you to run a series of operations and manage failures, keeping the results of successful operations for use elsewhere in your application. This lets you tie together parent and child operations so that the parent always returns after the child. You can use an async sequence to work with streams, but if you prefer, there’s also support for Go-like channels if you use the Go extensions package.

This last option provides alternative asynchronous operations, including fire-and-forget go calls, which allow you to trigger external functions concurrently without needing to wait for a response. Your main function will carry on operating, without needing a success or failure. There’s an interesting option here of mixing and matching .NET style asynchronous programming with Go’s fire-and-forget concurrency, as well as its built-in publish-and-subscribe channels.

Bringing together .NET and Go

The more you drill down into the language structure of G#, the more you can see it as a hybrid of the .NET approach (which comes from it being part of the family of Pascal and similar languages) and Go (with its structured C language heritage). That makes G# a very flexible tool, and one that could work very well with .NET-based Kubernetes applications.

Another key feature is the ability to interoperate with the rest of the .NET ecosystem, importing namespaces and using methods in functions. Imported packages can be given aliases to simplify calls, with G# supporting .NET types and collections alongside its own constructs. There’s even support for events and delegates, as well as for working with unmanaged code via DLL and library imports.

Usefully, the project documentation includes tables comparing G# with Go and C#, helping you transition between different ways of working by showing direct comparisons with familiar features. If you’re currently working in .NET, it’s worth keeping the C# comparison open while you’re writing your first G# applications.

What G# is good for

One interesting option for G# is as an educational language. It’s small and predictable, which makes it suitable for the classroom, simplifying both teaching and marking assignments. You can then use G# as an on-ramp into the wider .NET ecosystem, or to move from mobile development with Swift or Kotlin to C# and other .NET languages, using the two together as you develop more enterprise development skills.

Having a smaller surface than other .NET languages makes G# an interesting candidate for working with WebAssembly and with microVMs in Hyperlight. By writing code that works in a more constrained environment than C# but still compiles to .NET running on WebAssembly, there’s the prospect of using G# to deliver fast modules for use in Kubernetes and other distributed programming environments, where fast-loading serverless components provide the response times needed by both applications and users.

For now, don’t expect to see G# supporting all the language constructs used by C# or VB.NET. It’s still very early days for what is intended to be a smaller language, and not all the intended features are available. That shouldn’t stop you trying it out, especially if you’re coming from an iOS or Android development background and you want to bring your code to Windows and Azure. The similarities of G# to this class of programming language should make it easier both to embrace the new platform and to port your existing code.

Building an AI agent that looks impressive in a demo is now a weekend project. Building one that an enterprise will actually let touch its CRM, its data warehouse, and its customers is a different discipline entirely — and almost none of the challenges associated with shipping an agent live in the model. The challenge is infrastructure around the model, including who it is allowed to be, what it is allowed to see, what it is allowed to do, how it keeps its place across hours of work, and whether anyone trusts the result. These are system problems, not prompting problems.

In this article, I will introduce the five obstacles that reliably stall enterprise agent projects, and the architectural patterns that solve them. The examples come from a production system: an agent platform called Jean-Paul that runs on SnapLogic’s integration fabric and the Model Context Protocol (MCP). But the lessons are meant to apply broadly. If you are building in this space, you will hit all five walls regardless of your stack.

The authentication wall

While demo agents authenticate with a single god-mode API key, enterprise agents cannot, because security teams need to understand who the agent is acting on behalf of and what it is allowed to access.

MCP gives you the right primitive to answer this. In the protocol, the agent is always the client, and every capability it has is exposed by an MCP server. That separation matters because it decouples what the model can do from what the model is. The agent never holds raw credentials to Salesforce or BigQuery. It holds a connection to a server that fronts those systems, and that server is where identity and authorization get enforced.

The key control point is when an agent’s tool access is assembled. In a well-designed system, this serves as a single enforcement point for each session: access starts at zero, and only the tools permitted by the user’s role are granted. The agent determines server access through group-based permissions, with each user’s available servers defined by the union of grants across their assigned groups. Users without group membership receive no access by default. A second control layer filters individual tools, removing unauthorized capabilities from the model’s context before the session starts. This strengthens security and improves efficiency, as models perform better when selecting from a smaller, role-appropriate toolset.

The hard part is identity propagation. The agent must never be allowed to self-assert its identity. Instead, trusted infrastructure injects the human’s canonical user ID as a transport header that the agent cannot forge, and privileged servers re-check authorization against that header on every call, ensuring that access to a server is necessary but never sufficient. This is also where the integration platform earns its place as the system security layer. The vendor serves as the trust layer, securing credentials, enforcing authorization policies, and propagating user identity so downstream actions execute with the user’s permissions rather than a shared service identity. In practice, most deployments begin with a governed shared service identity at the agent’s MCP boundary and move toward per-user impersonation as the integration layer matures, but the boundary is in the right place from day one.

Data scale and context window limits

The second wall is physical. Enterprise data dwarfs any context window. You cannot paste a two-thousand-table warehouse schema into a prompt, and an agent that tries will exhaust its context before it answers anything.

Bigger models help, but do not solve it. A million-token context buys headroom, not infinity. The real answer is architectural: never preload, always fetch on demand. MCP is well-suited to this because the tools return only the requested slice.

The pattern that makes it scale is an index-and-leaf design. A one-time discovery pass introspects a system and writes a queryable metadata index — one entry per table, object, or routine — into a context library. At query time, the agent browses the index (cheap, a line per object), fetches the full schema for only the handful of objects in play, and then queries the live data. The context window holds index lines plus a few schemas, never the warehouse. The addressable surface is bounded by the database, not by the model.

Two more techniques help to carry the load. First, work that exceeds a single context is fanned out: a job over 10,000 records is split across many bounded-context sub-processes or a batch API and reassembled, rather than forced through one window. Second, large files are handled out-of-band, generated by code through ordinary libraries, written to disk, and delivered as a hosted URL, so the bytes never enter the model’s context at all. To be precise, the conversation-level mechanics of context compaction and prompt caching come from the model runtime, not the application. The platform’s job is to instrument them for cost accounting and to architect the workload so the window is rarely the binding constraint.

The action safety problem

Reading data is reversible. Taking action is not. This is where most teams either over-restrict the agent into uselessness or quietly accept unacceptable risk. The key point is that you cannot enforce safety in the prompt. “Please ask before deleting anything” is a suggestion a sufficiently confused model can be argued out of. Safety has to live in a deterministic infrastructure that the model cannot reason its way past.

A permission prompt that protects a human at a terminal is unusable in a Slack bot; something deterministic must replace it. An agent should layer four such gates. A visibility layer means the agent can’t invoke what it can’t see. A hard deny list embedded in the image and enforced regardless of interactive permissions creates a model-agnostic blacklist: no reading secrets, no destructive shell commands, and no editing the very files that define its own guardrails. An invocation policy cascade resolves each tool call to allow or deny by scope and specificity. And a set of independent preconditions can require, for instance, that the agent has read the relevant schema before it is allowed to write.

The human-in-the-loop gate is the clearest illustration of enforcement at the tool layer. A pre-execution hook intercepts a sensitive call before it runs, writes a pending-approval row, posts an interactive card to the user’s Slack or Teams channel, and then blocks — polling a database latch until a human clicks Approve or Reject. The tool call is physically suspended until the hook’s exit code returns the verdict. The model is not being asked nicely to wait. It is gated. This same mechanism enforces softer policies as hard rules: an agent can be made unable to publish a document until it has demonstrably read the brand guidelines, by requiring a prior read of that file as a precondition for the publish tool.

These gates are tuned to fail open on their own internal errors (an availability choice that keeps a hook bug from bricking the whole agent) while failing closed against the loss of their policy store. Where you set that dial is a real decision, and pretending the gates are infallible is exactly the kind of overclaim that erodes the trust the gates are meant to build.

Multi-step orchestration and state management

Real enterprise work is multi-step, multi-turn, and long-running. Chat channels are effectively stateless. A new message in Slack carries little reliable context about whether it represents a new request or a continuation of prior work. An agent that treats every message as a fresh start is amnesiac.

A solution to this can be smart routing: put a small, fast, cheap model in front of the expensive agent purely as a dispatcher. For a fraction of a cent per message, it decides whether an incoming message should resume an existing session or start a new one, and which prior session is the relevant one, converting stateless chat into resumable, stateful work. A concurrency guard prevents two processes from writing to the same session at once. A useful discipline when building this is to be conservative. When the router is unsure, start fresh, because a clean context is cheaper to recover from than a corrupted one.

Complexity is managed by delegation. The agent runtime lets the main agent spawn sub-agents with isolated contexts. The platform’s contribution is not the isolation itself but the judgment of when to delegate, which is encoded in the platform’s skills. This keeps the coordinating agent’s context focused on the plan while bulk or parallelizable work happens in separate windows.

Those skills are the agent’s standard operating procedures. A skill is a versioned, reviewable document that encodes a repeatable procedure. It tells the agent what references to review, which tools it can use, how the output should be structured, and how to verify its own work before returning a result. Skills load progressively (only a short description is always in context; the full procedure is read when triggered), and they move through a submit-review-approve life cycle. This is what turns agent behavior from improvisation into something repeatable and auditable. Underneath, a durable substrate ties the pieces together: a session identifier is the join key across the model’s transcript and the orchestration ledger, and an unfinished job left marked “running” after a crash becomes a recovery queue that the system drains on restart.

Organizational trust and adoption

The last wall is the tallest, and not technical. Industry surveys indicate that the large majority of generative AI pilots deliver no measurable return and only a small fraction at scale. People will not delegate real work to a black box, and leadership will not sanction one.

Explainability has to be a built-in primitive, and not a debugging afterthought. Every tool call an agent performs (its name, the system hit, its inputs, its response, success or failure) should be logged. Your agent must do this and then close the loop in the conversation itself: when a session ends, a hook automatically posts a “here’s what I did, and here are the sources” summary back into the same thread, with a deep link to the full transcript, and configuration changes are captured in a separate before-and-after audit. Attribution must be mechanical rather than a matter of trust. Output honesty — the agent not inventing a number — must be enforced by explicit guardrails in the system prompt plus the after-the-fact audit trail, not by an automatic citation-checker that blocks unsourced claims. The audit log is what lets you verify, which is the point.

Two softer factors matter more than engineers like to admit. First, a distinct agent personality measurably drives engagement — provided the persona governs how the agent communicates and never what it communicates, with factual honesty fenced off as non-negotiable. Second, adoption hinges on a single, low-friction surface: people talk to the agent in the tools they already use, while one dashboard unifies history, skills, hosted deliverables, personalization, cost, and governance. Each tool is labeled by its risk, so personalization itself communicates consequence.

The deepest issue is structural, and it predates AI. Eric von Hippel’s decades of research on user-driven innovation describes sticky information — knowledge about how work actually gets done that does not survive translation into a requirements document. Most enterprise AI stalls because the people who hold that context are not the people allowed to build. The durable pattern is to invert that: let the people with the context author the workflows, governed end-to-end. AI is the means; governance is the foundation, not a wrapper bolted on afterward.

The hard part

None of these obstacles is a model capability problem, so simply throwing a bigger model at them does not help. They are problems of authorization, scale, safety, state, and trust, and each is solved the same way: keep control in deterministic infrastructure around the model, bind every action to a real human identity through an integration layer that holds the credentials, make everything auditable by default, and put authoring in the hands of the people who understand the work. The model is the easy part. The enterprise is the hard part.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

AI coding tools are increasingly becoming the place where developers write and modify software. SpaceX-owned Cursor now wants to bring code hosting into that same environment, potentially challenging GitHub’s position as the center of the software development lifecycle (SDLC).

The company, earlier this week, launched Origin, an early-beta code-hosting platform that brings repositories, pull requests, and code browsing into its AI coding environment, on the same day that Microsoft-owned GitHub faced an outage for nearly eight hours, disrupting several of its services, including Actions, API requests, Git operations, and Copilot.

The move puts Cursor and GitHub on opposite sides of the same software development stack. GitHub built its position as the code-hosting and collaboration platform before expanding into CI/CD, security, project management, and AI-assisted development. Cursor is moving in the opposite direction, starting with an AI coding environment and adding code hosting around it.

In essence, that means Origin wants to change the traditional software development model, where developers typically use GitHub as their codebase and collaboration layer while relying on separate tools for coding, AI assistance, and other parts of the development lifecycle.

The rationale is that Origin’s model could reduce the number of tools involved in writing, reviewing, and managing code by bringing those workflows closer to the AI agents that are increasingly taking on software development tasks.

For enterprises and their CIOs, however, the question is whether Origin’s tighter integration with AI agents makes the code-hosting layer compelling enough to justify moving core development workflows away from a mature platform with a broader ecosystem and established enterprise controls, and eventually rethink where their canonical codebase should live.

Origin has a long way to go on enterprise controls

As of today, analysts say GitHub remains the safer enterprise choice.

Primarily because Origin is still in early beta and doesn’t match GitHub’s depth in enterprise controls, compliance, audit, and third-party integrations, said Manoj Chandra Jha, principal analyst at Nord-IQ Research.

Specifically, it lacks enterprise controls and security capabilities, such as branch protection and rulesets, CODEOWNERS, required reviewers, signed commits, SSO, SCIM, granular roles, IP allowlisting, audit logs you can ship to a SIEM, secret scanning with push protection, dependency alerts, SBOM, package registries, and GitHub’s broader CI/CD ecosystem, echoed Advait Patel, senior site reliability engineer (SRE) at Broadcom.

This is despite Origin’s integrations with Depot and Buildkite to support CI, Patel said, adding that “trusting a third party for CI” could introduce additional trust and operational considerations.

Another challenge for enterprises, when moving to Origin, would be reproducing the depth of GitHub’s Actions ecosystem, self-hosted runners, and integrations such as OpenID Connect (OIDC) for connecting CI workflows to cloud accounts, Patel further pointed out.

Beyond these capabilities, the senior SRE cautioned that CIOs would also need to consider compliance and operational safeguards, including certifications such as ISO 27001, data-residency options, clear terms on whether hosted code can be used to train AI models, and FedRAMP support for public-sector customers.

Those considerations, Patel added, should also extend to requirements around backup and restore guarantees, recovery point and recovery time objectives (RPO and RTO), a published SLA, an established incident history, and a documented way to export code in bulk.

That option to export code, according to Jha, is particularly important because Origin’s tight integration between AI coding and code hosting could also create a new form of vendor lock-in, where a single AI vendor ends up controlling the entire development loop, from writing and modifying code to hosting and managing it.

Origin could add another layer before it removes one

There are other reasons to consider GitHub over Origin despite its promise of less tool switching to deliver a simpler, tighter development workflow.

For its initial release, Origin still relies on GitHub for parts of the development workflow, meaning enterprises adopting it would not necessarily replace GitHub outright but might end up running two systems in parallel.

That could limit some of the tool-consolidation benefits Origin is designed to offer while adding another layer of integration and management for engineering teams, Patel pointed out.

And that distinction may become an important factor in Origin’s enterprise adoption, echoed Jha.

Rather than treating Origin as a replacement for GitHub, CIOs should keep GitHub as the system of record while testing Origin on lower-risk repositories and expanding its use only as its enterprise capabilities mature, he advised.

That approach, however, could change if GitHub responds by building tighter AI-agent workflows of its own, Jha added.

Regular readers will probably have figured out that I’m generally an optimist. I think things are always getting better, and the future of the human race looks pretty good. Technology has taken us from grinding poverty to a pretty good life here on Planet Earth. 

I also believe that life has gotten immensely better for software developers just in the last year. We’ve seen AI agents suddenly and stunningly write real, working code from prompts alone. We tell the AI what we want, and it does it. I think it is fantastic. I’ve used coding agents to build complete, working websites in a weekend.

But I meet a lot of skeptics. Some see the agents doing their thing and love to point out the flaws, mistakes, and bugs that the agents produce. They love to mention that AI agents are not compilers and that they aren’t deterministic — the same prompt will produce different results every time.

Oops, sorry

Well, okay. But you know what else makes coding mistakes, writes bugs, and never writes the same code twice when prompted? Humans. Us. Yep, we do those very things. All the time.

Not only that, but we have a large infrastructure of tooling to account for our flaws. We have source version control so we can unroll our mistakes and misadventures. We have pull requests and code reviews to prevent our flaws from getting into the codebase. We have whole teams of people — quality assurance engineers — who make sure that what we wrote does what it is supposed to do.

We built these tools and this structure all for the purpose of catching errors and for keeping control over the errant ways of humans. And yet, somehow, the fact that AI agents make mistakes is supposed to stop us from using them. Huh.

Since the beginning of software development, we’ve been dealing with flaws in the whole system. Many flaws. In fact, it’s a rare commit of any substance that doesn’t have flaws in it. There are bugs everywhere. We hunt them down, log them, track them, and fix them. Our fixes introduce new bugs. We are, after all, flawed beings. 

Neither humans nor coding agents produce deterministic results. But remember, they both produce code — which is deterministic. When humans write code, they read the specification, formulate a plan, and write the code. An agent does the same thing. And in both cases, the code produced is the thing that defines the system. How that code gets produced shouldn’t make a difference.

Hire that developer

So, I have no idea why anyone would hesitate to add a new “team member” that, while writing flaws, at least writes them 100 times faster than we humans can. And not only that, they can find the flaws 100 times faster as well. Agents are so good at finding flaws that Microsoft has started using Anthropic’s Claude Mythos model to help harden Windows and Azure against vulnerabilities — finding in minutes flaws that human security teams would take weeks to find.

If you could find a human that was half as capable at coding or finding bugs as today’s frontier models, you’d hire her in a heartbeat. 

And with models rapidly improving, not hiring that coding agent is a foolish omission.

While some organizations are still getting started with their AI strategies, others are in pilot purgatory, with few experiments or proofs of concept (POCs) reaching production. Only 25% of organizations have moved 40% or more of their AI experiments into production, according to The State of AI in the Enterprise.

We discussed delivering AI proofs of concept that matter at a recent Coffee With Digital Trailblazers on LinkedIn Live. One key reason POCs stumble is when they don’t align well with the AI business strategy or have defined business outcomes. Two other problems: There isn’t a sufficient AI change management program, or employees aren’t involved in the development process.  

But there’s also a significant technology issue: The architecture used for training AI models and developing AI agents can be very different than what’s used for AI inference, running a trained model to generate outputs in production. Training and inference have very different performance, scalability, compliance, and security requirements, and it’s wrong to assume that AI inference is a scaled-up or scaled-down version of the training architecture.

“The industry focus is rapidly shifting from training frontier models to optimizing AI inference in production environments,” says Pascal Jaillon, senior vice president of product at OVHcloud US. “Enterprises are realizing that long-term AI success depends less on raw model size and more on balancing latency, scalability, security, and infrastructure economics across distributed environments. As inference workloads scale, organizations are increasingly evaluating alternatives to traditional hyperscaler-only strategies to improve cost efficiency, data sovereignty, and operational flexibility.”

Optimizing the AI inference environment must also account for operating conditions, compliance requirements, and cost trade-offs. Rick Ross, distinguished technologist at EY, says, “For CIOs, localized inference is a deliberate architectural choice reserved for latency-sensitive applications like robotics, or where regulation mandates.”

Waiting for a successful AI experiment or POC before considering its inference architecture can be a mistake. It may drive unanticipated rework, or add complexities that require restarting the development process. Here are five best practices for developing effective AI inference architecture, infrastructure, and operations.

1. Architect for integration and performance

Training architectures are designed for throughput and flexible data requirements, while inference requires low latency, high reliability, and autonomous operation. Inference environments for AI agents must also consider how workflows will be orchestrated with Model Context Protocol (MCP) servers and agent-to-agent (A2A) integrations. 

“IT teams should modernize the integration and orchestration layers first, ensuring they can support event-driven, low-latency, and high-reliability interfaces before AI systems are deployed at scale,” says Riki Efraim-Lederman, division president of Amdocs Studios at Amdocs. “Many legacy environments appear functional because humans are compensating for gaps behind the scenes, but once AI systems begin acting autonomously, that safety net disappears and those weaknesses surface quickly.”

As organizations deploy more AI agents and usage increases, devops teams must consider latency requirements for different use cases and peak-load performance requirements.

“IT teams underestimate how quickly complexity compounds from unpredictable burst traffic, sensitive data pipelines, and AI agents executing across opaque APIs and tool chains,” says Sridhar Iyer, senior director of AI/ML at Versa. “AI inference increasingly requires a distributed architecture, shifting workloads dynamically across cloud, on-prem, and edge locations based on latency, sovereignty, and cost.”

Training environments often require flexibility for accessing multiple large-scale data sources to test and optimize AI models. This contrasts with inference environments, which often connect to fewer runtime data sources and where availability and latency are key design considerations.

“Inference at the edge or across distributed environments only works when the database matches that architecture: local, consistent, and highly available,” says Phillip Merrick, CEO and cofounder at pgEdge. “IT teams tend to treat the infrastructure decision and the data decision as separate workstreams, but they are not, and they are the same decision.”

2. Secure the AI’s data and actions

In training environments, IT can firewall outside access, mask sensitive data, and confine actions to testing environments. A secure-by-design strategy is needed for inference environments where AI agents access real-time data, automate actions across production SaaS platforms, and require dynamic security evaluations around decision-making authorities.

“Inference is the moment a model moves from experimentation into live operations, touching real data, real services, and real business workflows,” says Gal Ordo, cofounder and CPO at Native. “At that point, the critical questions are what the model is allowed to access, what actions it can trigger, and what conditions must always hold while it’s running. Make boundaries explicit from the start, so inference operates inside a controlled, deterministic environment.”

Since AI’s decisions are non-deterministic, observability, auditing, and monitoring are key to avoiding rogue agents, flagging model drift, and alerting early to unexpected usage patterns.

“IT departments need to treat AI inference as another workload with unusual identity, data, and cost characteristics,” says Mike Toole, director of security and IT at Blumira. “It’s critical to choose where it runs based on the sensitivity of what’s going into the prompt and apply the same access controls, logging, and review you’d apply to any SaaS that touches production data.”

3. Separate training and inference requirements

Training environments may require GPU chips and other high-performance architectures. For inference, infrastructure needs to focus on compliance, latency, cost, and other non-functional requirements. The differing requirements often result in distinct infrastructures.

“As compute becomes more distributed, CPU is a critical component in inference workloads, and with agents exploding, compute is where they live,” says Michael Reid, CEO at Megaport. “At the same time, inference acts as a north-south traffic multiplier, significantly increasing data transfer demands and putting greater pressure on networking capacity. Fully optimizing for AI inference therefore requires a unified environment where compute, network, and storage work in lockstep.”

Web systems optimized performance by including a caching layer. In AI inference architectures, caching also reduces redundant computation and the associated GPU cost,

”Every request that reprocesses the same inputs from scratch burns GPU cycles at full cost,” says Junchen Jiang, cofounder and CEO at Tensormesh. “Key value caching eliminates that redundancy, cutting latency and GPU spend dramatically. IT teams that build caching into their inference architecture from the start will be able to scale without the runaway infrastructure bills.”

Large enterprises will need to consider hybrid infrastructure based on compliance and performance requirements. For example, AI agents and applications that involve human safety will need to evaluate edge and on-prem infrastructure, while back-office operations may run entirely on public clouds.

“The biggest mistake companies make with AI inference is treating it like a model decision when it’s really an operating model decision,” says Andrea Malagodi, CIO at Sonar. “Where inference runs, whether it be in the cloud, on-prem, or at the edge, directly affects latency, cost, data exposure, and resilience.”

4. Design for flexible and resilient operations

Inference architectures are not built once and then scaled up and down, the way web applications are. Architects should plan for models, infrastructure, security, and data management to all change as technology, compliance, and pricing evolve.  

“AI inference is rapidly becoming a core production workload that demands consistent, automated operations across hybrid cloud environments and a clear chain of trust from model to deployment,” says Tushar Katarki, head of product, Gen AI Foundation Model Platforms at Red Hat. “Open source and open standards are essential here; they give enterprises the transparency to secure their AI stack and the flexibility to run inference wherever their business demands.”

One source of change is the AI model capabilities, performance, and costs. Ayaz Ahmed Khan, senior director of engineering at Cloudways, says, “Models are improving at breakneck speeds, and as soon as the model is changed, the prompts and guardrails have to be thoroughly evaluated, reviewed, and modified.”

Another concern is tracking usage and interactions with SaaS platforms, data sources, and other AI agents. Shannon Weyrick, CTO and cofounder at NetBox Labs, says, “IT teams should route AI traffic through a single control point that provides visibility into which models are in use, what data is leaving the organization, and how costs are accumulating, because you can’t secure or manage what you can’t see.”

Matt Waxman, chief product officer at Precisely, says that the most underestimated challenge in enterprise AI inference isn’t the model, but the data behind it. “Prompts and retrieval pipelines pull from dozens of sources with inconsistent semantics, missing lineage, and no governance layer, and the model has no way to know. In an agentic world, where AI systems act autonomously and at scale, that foundation becomes even more critical,” says Waxman.

David Mytton, CEO and founder at Arcjet, shares a practical issue his company encountered with production inference. “Every model wants to become its own API with different request shapes, health checks, metadata, readiness behavior, error formats, and response fields. That does not scale once you have multiple models or back ends,” Mytton says. Arcjet built an abstraction using the Open Inference Protocol on top of their AI security models to provide inference services with a standardized shape for liveness, readiness, metadata, versioned model routes, and tensor-style inputs and outputs.

5. Optimize for costs and changing AI models

Organizations moving from dozens to thousands of AI agents will need to advance their finops programs to account for how AI model selection and optimization affect costs.

“As teams move from single-agent prototypes to multi-agent pipelines, inference costs don’t just grow linearly. A multi-agent system can burn 15 times as many tokens as a single chat interaction,” says Andrew Marshall, vice president of product marketing at Yugabyte. “That multiplier is a data problem, not a model one, based on how much context gets passed between agents, how much is retrieved redundantly, and how much state has to be reconstructed from scratch on every call.”

In addition to changing AI models, architects should consider that frontier models used during training may help develop smaller, more efficient models that are then used for inference.

Jason Rolles, CEO and managing director at BlueOptima, says, “LLMs are fast evolving into two broad categories: frontier, cloud-scale models that will likely remain the preserve of hyperscalers, and smaller, highly distilled specialist models deployed at the enterprise edge.” This gives enterprises the option to route low-level, low-ambiguity tasks to smaller models, while tapping frontier models for decisions that require reasoning and accuracy, saving overall costs.

Andrew Filev, CEO and founder at Zencoder, says, “Once agents became useful, usage jumped 10x, contexts ballooned, and enterprises started paying frontier-model prices on every token. Many now burn through annual AI budgets in months, and most of that spend comes from running a flagship model on every step, including simple tasks.”

To increase the number of production AI models and agents, enterprises will need a solid plan for building resilient, scalable inference architectures. But as usage, compliance, technology, and pricing change, plan to reevaluate and evolve the architecture.

Diffusion models are becoming sophisticated enough that they can reproduce an image even when they don’t have access to the original.

In a series of ‘what if’ scenarios, researchers associated with MIT’s Computer Science & Artificial Intelligence Laboratory (CSAIL) swapped out different training datasets to test the impact on image outputs when original image data was completely removed.

It turns out that, at sufficient scale, nothing changed.

The researchers call the phenomenon “attribution decay”: The more data a diffusion model is trained on, and the larger it gets, the less individual inputs matter.

“If you take away a piece of data and the output of the model doesn’t change, then that piece of data didn’t affect the output,” Zheng Dai, lead author on the work, explained in an MIT blog post.

These findings could have significant ramifications when it comes to resolving growing concerns about intellectual property (IP) and copyright infringement.

Models can recreate images even if they’ve never ‘seen’ them

Modern generative diffusion models essentially replicate statistical patterns in large training datasets to create realistic reproductions. These powerful tools have achieved “remarkable results” in a wide array of applications, the researchers noted, notably image, video, and audio generation.

But they are increasingly under scrutiny by creatives, companies, and policymakers, who all want a way to assign responsibility for generated outputs. Models sit at the center of lawsuits, licensing deals, and proposed regulations around the world.

For instance, Stability AI (maker of Stable Diffusion) and Midjourney are embroiled in an ongoing class action lawsuit filed by several artists in federal court in California. The claimants argue that the popular image, video, and audio-creating models are scraping billions of their copyrighted images without their consent.

Getty Images also brought claims against Stability AI, but they were struck down by the High Court of Justice Business and Property Courts of England and Wales, although Getty did partly win trademark claims because some AI-generated images closely resembled its work.

Attributability, the MIT CSAIL researchers noted, would increase understanding of “machine unlearning,” data poisoning, model interoperability, fairness, and privacy, while also addressing ethical, legal, financial, and regulatory issues.

“Developing a method to attribute generated outputs to influential training data would greatly advance our understanding of and ability to regulate these models,” the researchers wrote.

In their experiments, they used ablation, which is essentially testing what happens when certain elements are removed by looking at what a model might have produced if it had never “seen” a particular image.

Typically, ablation is difficult because models need to be retrained after data is pulled out. But the MIT CSAIL researchers applied the method to a “diffusion ensemble” architecture of many different components trained on different pieces of data. These components could be swapped out to determine how much of an impact, if any, each one had.

“Our analysis is based on observing changes in model behavior, or lack thereof, upon omitting a part of the training set,” the researchers explained.

To do so, they trained 24 ensembles on datasets containing anywhere from 256 to 160,000-plus images. These were pulled from seven publicly accessible image datasets, including ArtBench (artwork), CIFAR-10 (generic colored images), Fashion-MNIST (clothing and accessories), CelebA (celebrity faces), and MetFaces (human faces).

In one example, they presented an image of a famous oil painting generated by a model trained on public domain artwork from 744 artists. It was shown side-by-side with hundreds of seemingly identical images that the model had generated, even when specific artists had been removed from training data.

The original was re-imagined in every possible variation, and the researchers quantified attributability by measuring the largest change they could induce by omitting training data. The radius became smaller as datasets became bigger, holding true across different measurements including pixel-by-pixel or semantic meaning.

In other words, single artworks by specific artists, or photographs of certain people, could be entirely removed from datasets, and the model could still reproduce that image or style. Essentially, tangible connections are lost, and linking to specific data points responsible for generated samples is “practically impossible,” or can even vanish, the researchers explained.

Their method is novel, they said, because prior work has focused on removing large swathes of data rather than targeting smaller pieces, what they called “leave-one-out style attribution.”

The impact on attributability

Because the experiment shows that, as Dai put it, it “doesn’t make much sense” to attribute a given output to a given piece of data, creatives and others may not be able to provide an audit trail tracing back to their original work.

Co-author David Gifford, an MIT professor and CSAIL principal investigator, said the findings have a direct bearing on legal questions around whether model outputs are actually derivative works.

“One way to think about this is that these models are creative,” he said. “They are not simply copying what they are fed, but creating brand new outputs.”

So if outputs can’t be correlated to individual pieces of training data, questions can be raised around fair use and whether, in fact, model-generated outputs are themselves copyrightable as “novel works,” Gifford said.

It could also shift the conversation about how original creators are compensated when what comes out of a model seems a direct recreation of their work, but can’t be traced back to anything on the internet.

Ultimately, producing outputs that are guaranteed to be unattributable is an “obligation for the industry, rather than a loophole,” he said. AI builders “need to revise their models to take advantage of the advances in this work, so they can show they’re not creating derivatives of individual people or items.”

This article originally appeared on Computerworld.

Open-weight AI models are a big deal, as Nvidia and more than 200 other companies and organizations attested in their “Open Weights and American AI Leadership” letter in July. The question is who will pay for them.

Why are they a big deal? Well, former Red Hat CEO Jim Whitehurst will tell you that “open weights can play the same catalytic role [as open source]” to drive innovation in AI. This isn’t to suggest that open source, or open weights, will “win” in some absolute sense. Linux, for example, has become essential to the fabric of enterprise computing, but there are still plenty of Windows servers running. So open-weight models like Kimi or Nemotron aren’t going to topple Anthropic or OpenAI anytime soon. However, according to Whitehurst, they can “create a broader competitive landscape where innovation happens faster, and the power of AI is broadly shared.”

Again, only if we can figure out how to pay for them.

Betting on self-interest

That was the concern I expressed to Whitehurst, much more politely than when he became Red Hat CEO back in 2007, and it’s something the industry must confront. Or maybe not. Open source, for example, has always depended on widespread, ever-evolving corporate self-interest to thrive. At any given time, one company might decide it no longer had anything to gain from contributing to, say, Linux, but at the same time, another company would discover reasons it should start contributing.

Self-interest, it turns out, is one heckuva drug.

I wrote in 2016 that “there’s no money in open source.” That’s still true in 2026, both for open source and open weights. In open weights, the smart money isn’t that any particular company will keep funneling copious quantities of cash into training new, soon-to-be-given-away models. It’s never wise to bet on any particular vendor’s goodwill. Instead, the bet is on the perpetuity of the overall supply of open-weight contributions. Why? Because Meta, Alibaba, DeepSeek, Nvidia, and inference companies all have different businesses that become more valuable when the model layer becomes cheaper and more interchangeable. If Meta becomes more closed, Alibaba still wants cloud consumption. If Alibaba holds back, DeepSeek or Moonshot may want global attention. Nvidia wants chip demand.

These asymmetric incentives make the system resilient, even when the costs to individual contributors may be high.

Take Meta. It’s great to see Meta CEO Mark Zuckerberg championing open source and open weights in AI manifestos, following the release of open-weight models like Llama. In 2024, Zuckerberg offered an unusually candid explanation for opening Llama. First, Meta didn’t want to depend on another company’s AI platform the way it depends on Apple’s mobile platform. Second, he reasoned that a large Llama ecosystem would produce silicon support, inference optimizations, tools, and integrations that Meta couldn’t build alone. Finally, Meta could pursue these other benefits knowing that opening Llama was unlikely to cannibalize its primary business, advertising.

Will Meta always have sufficient self-interest to release open weights to the world? Probably? The company now says it expects to train a combination of open and closed models. Fine. Even if Meta becomes more selective, there’s Alibaba, whose open Qwen releases create demand for proprietary models and cloud compute, and Z.AI (formerly Zhipu), which can release GLM-5.2 under an MIT license while charging for API access.

The incentives differ, which is, of course, the point.

Hence, as much as we may laud Meta for its open-weight contributions today, the reality is we don’t need it to keep contributing forever. We just need at least one ambitious model builder in each model generation to decide that distribution is worth more than exclusivity.

The market leader generally has the strongest reason to protect scarcity. A challenger, by contrast, tends to look to open source (or open weights) to catch up and shift the playing field in their favor. Should today’s underdog become tomorrow’s leader and pull back from openness, someone else inherits the incentive. Competition drives contribution, as it were.

Good enough is enough

Nor do open models have to beat every closed model to matter. As of March, Stanford found the best closed model was ahead of the best open model by 3.3%, while Epoch AI estimates that open models have trailed the closed frontier by roughly four months during 2026.

Four months may feel like an eternity to the labs racing at the frontier, but it’s largely irrelevant to an enterprise trying to summarize documents, classify support requests, extract data, or run a routine agent. The model doesn’t need to be the best in the world. It needs to clear the company’s evaluations at the right price, latency, and level of control. As I wrote recently, we just need the Fireworks-esque companies of the world to more finely tune those open-weight models to enterprise use cases, making “good enough” open weights arguably “better than” closed frontier models, at least for particular use cases.

Vercel’s AI Gateway offers a glimpse of how that market is developing. In July, open-weight models ran 36% of its tokens while capturing 8.6% of spending. DeepSeek became the gateway’s second-largest lab by token volume, while Anthropic collected 65% of spending on 30% of tokens. One provider’s traffic isn’t the whole market, of course, but the pattern makes sense: Open models absorb an increasing share of high-volume work, while closed frontier models retain the premium workloads, which is similar to what we’ve seen happen in other markets, like databases.

‘Open core’ comes to open weights

Of course, weights alone aren’t a product. Someone still has to make them fast and reliable, serve them efficiently, help customers evaluate and adapt them, and make a newly released model available in production on day one. That’s the ecosystem Whitehurst is calling for.

It’s also where the tension will grow. A model creator wants inference providers to broaden adoption, optimize performance, and create demand. It may become less enthusiastic once those providers start capturing meaningful revenue. Open source history suggests that once downstream companies start making serious money from someone else’s work, the original creator tends to doubt it’s reaping a fair return on its investment. We saw this with databases and cloud providers, as vendors changed licenses to defend against cloud competitors. We’re starting to see the same dynamic with model weights, perhaps ushering in the latest instantiation of so-called open core models.

Moonshot’s Kimi K3 license, for example, says a model-as-a-service provider with more than $20 million in annual revenue must negotiate a separate agreement. MiniMax M3 similarly requires prior authorization once products or services built on the model exceed $20 million in annual revenue. By contrast, DeepSeek V4 and GLM 5.2 use permissive MIT licenses.

Restrictive licensing isn’t inevitable. The market is splitting between models designed to commoditize the entire model layer and models designed to win adoption while preserving tollbooths around the most valuable commercial uses. The weights may remain downloadable even as the right to build a large business with them becomes less open.

Bet on the supply, not the supplier

So, what’s an enterprise to do? As I argued recently, enterprises shouldn’t bet the company on any one model, open or closed. They should build evaluations that reflect their actual work, preserve the ability to move their data and tuning, keep application logic from becoming needlessly dependent on one provider, and read the license before confusing downloadable with unrestricted.

After all, technical portability without legal portability isn’t really portability. It’s lock-in.

We can reasonably bet on more and better open-weight models. We just shouldn’t bet on Meta, Alibaba, DeepSeek, or anyone else remaining permanently committed to openness. Nor do we need to. If open source history is any guide, open weights will endure because somebody will always profit by breaking rank with their closed-model cousins. Even so, it’s worth paying attention to ensure that “open weights” doesn’t come to mean quasi-open or pseudo-open, which happened in open source. But there again, there’s always reason for someone to go fully open as it seeks to outflank competitors. Competition is openness’ best friend.

DuckDB, the analytics database with high-end features in a single easily deployed binary, is due to release a major update, version 2.0, this fall.

In a blog post on the DuckDB site, the project’s maintainers outlined several key features that motivated a major version bump. The single biggest is a client/server mode, allowing DuckDB to function both as a compact, in-process database for a single client (its original use case), and as a service for multiple clients. The previously released quack extension for DuckDB made this possible on an experimental basis; now quack is being promoted to a stable release with DuckDB 2.0. The quack extension also makes it easier to remotely query other supported databases such as PostgreSQL and MySQL.

Many of the other major changes in DuckDB 2.0 are internal, but with big implications for end users. The data engine beneath DuckDB now works asynchronously, allowing the I/O layer and the query processing layer to scale separately and make better use of parallelism. This, plus other internal changes, means faster queries overall, with the speedups ranging up to 40 times faster depending on the kind of workoad involved. A new storage format for the database means databases with large indexes and “wide” tables (many columns) can be opened and read faster. A completely written SQL parser allows extensions to extend SQL syntax and delivers more detailed error messages.

DuckDB already has a fair number of third-party extensions written for it, but extensions have had to be written against an unstable C++ API. Each new DuckDB release required extensions to be recompiled for that release. With DuckDB 2.0, a stable C API now supports a broad feature set for extensions to use. It also allows extensions to be compiled from a single header file, and they won’t need recompiling to work with new releases. A work-in-progress effort allows you to register your own DuckDB extension repository, rather than require an extension to be distributed from the community repo.

Previews of DuckDB 2.0 are now available in an unstable, nightly release version. No date has yet been set for a release candidate or final release, although the goal is to release it sometime this coming fall.

The public cloud market is experiencing an extraordinary financial moment, with Amazon Web Services, Microsoft Azure, and Google Cloud all benefiting from the explosive demand for AI infrastructure and services. AWS continues to turn its infrastructure dominance into new AI-driven revenue streams, including managed AI platforms, custom chips, and large-scale compute services. Microsoft has made Azure the center of its enterprise AI strategy, integrating cloud infrastructure, models, developer tools, and business applications into a highly effective revenue engine. Google Cloud, long considered the third-place hyperscaler, has gained new momentum as enterprises seek AI infrastructure, data platforms, and model services that leverage Google’s deep technical history in machine learning.

The Big Three hyperscalers sit directly in front of what may become the largest enterprise tech spending wave since the initial public cloud rush. Enterprises want GPUs, AI accelerators, managed model services, vector databases, inference platforms, training environments, data pipelines, and the operational plumbing required to run AI at scale. The providers have the capital, data centers, chips, engineering talent, partnerships, and enterprise sales channels to fulfill those needs. Customers are willing to spend heavily, and the hyperscalers will gladly meet that demand.

But what happens to the traditional cloud services when providers become overwhelmingly focused on the newest and most profitable segment of the market? We’ve seen many times that when one part of the business excites customers, boosts investor confidence, and creates new high-margin opportunities, that part will receive the people, capital, executive attention, and marketing budget, often at the expense of other parts of the business.

The core cloud services

Most public cloud activities are not highlighted in keynote demos or in exciting press stories. Storage, compute, networking, databases, identity management, backup, messaging, monitoring, logging, load balancing, security services, governance, and disaster recovery constitute the bulk of everyday public cloud use. These services process transactions, run applications, store records, move data, authenticate users, support analytics, and keep the business operating. They justified the original migration to the public cloud.

Many organizations moved workloads to the public cloud because it was supposed to improve faster than their data centers. The cloud offered access to new technology, but more important, it also offered infrastructure that was more elastic, reliable, easier to operate, faster to provision, and continually improved by providers at an unmatched scale.

However, that promise requires ongoing investment. Compute needs better price-performance. Storage needs better durability, performance, and economics. Databases need stronger resilience, simpler operations, and more predictable scaling. Networks need to be easier to secure and less fragile. Management tools need to reduce complexity rather than add another layer of abstraction.

If those improvements slow down, the original cloud bargain begins to weaken.

Adding AI to everything

One of the more predictable patterns in technology is that every existing product eventually gets wrapped in the latest trend. Today, that trend is AI. A database gets a natural-language assistant. A storage platform gets intelligent search. A monitoring service gets automated incident summaries. A management console gets a chatbot that recommends configurations.

Some of these features will be useful. I am not arguing against intelligent automation. If a feature helps engineers find problems faster, improves security, fixes performance issues, or reduces operational toil, then it has value. But bolting AI onto a service is not the same as improving the service itself. A database does not become more reliable just because it can explain a query in plain English. A storage system does not become more cost-effective just because it has smarter metadata tagging. A monitoring platform does not become operationally excellent just because it can summarize alerts in conversational language.

The core still matters: performance, availability, recovery, security, cost controls, service limits, documentation, support quality. These are not legacy concerns. They form the foundation of enterprise computing. If providers confuse AI decoration with real modernization, enterprise customers will eventually notice the difference.

Neglect shows up slowly

Traditional infrastructure services rarely fail because someone announces they are no longer important. They decline quietly. Road maps become less ambitious. Meaningful updates arrive less often. Long-standing bugs remain unresolved. Documentation falls behind reality. Support organizations become less prepared to handle complex cases. Regional capacity issues become more common. Service limits no longer align with how customers actually use the platform.

Then come outages, performance surprises, and quality-control issues. No public cloud provider can eliminate outages entirely. These platforms are too large and too complex for perfection. But there is a major difference between the unavoidable failure modes of complex systems and a pattern of underinvestment in foundational services.

Mature cloud services require constant care. In some ways, they deserve more investment than new services because they serve more customers, have more dependencies, and rely on more hidden assumptions. A seemingly minor regression in a core service can affect thousands of workloads. A poorly communicated change to networking, identity, storage, or database behavior can create cascading problems for enterprise customers.

This is the part of the cloud market that does not receive enough attention. The shiny new services create the buzz, but the mature services carry much of the operational risk.

Influencing the road map

Yes, some organizations will deploy large-scale AI workloads over the next two to five years, but most will move more slowly. They will experiment. Some will use AI embedded in software-as-a-service platforms. Some will build narrow, governed use cases. But many will continue to spend most of their cloud budgets on traditional infrastructure. These customers need to be more demanding. They should ask direct questions about the services they already use. What is being done to improve reliability? To reduce complexity? How is the vendor improving database performance, storage economics, network resilience, observability, identity, and support quality?

More important, customers should compare what providers say with what they actually ship. Road maps are easy to present, but release histories are more revealing. If a critical service has not seen meaningful improvements in a long time, that should be part of the enterprise risk conversation.

Enterprises should stop assuming that all cloud services are improving at the same pace. They should review dependencies, validate architectural decisions, examine failure scenarios, and understand their alternatives. A workload that made sense on a particular platform five years ago may no longer be the best fit if the service behind it has stagnated.

Cloud buyers also need to use their commercial leverage. Providers listen when large customers make road-map demands part of renewal discussions. If enterprises want traditional infrastructure to remain strong, they need to say so—clearly and repeatedly.

The boring stuff still matters most

The hyperscalers are not wrong to pursue the fastest-growing opportunity in the market. Any rational company would do the same. But enterprise customers made long-term commitments to these platforms based on a broader promise that public cloud would continue to improve the core infrastructure services businesses rely on every day. The technology press may be fascinated by the latest capabilities, but most enterprises still run on the boring stuff that keeps the lights on.

Yes, the current AI cloud boom is impressive. But enterprise IT leaders should focus on what matters most. Watch the road maps. Watch the release notes. Watch outage patterns. Watch support quality. Watch whether core services are truly improving or merely being dressed up with fashionable features. Traditional cloud infrastructure is not legacy. It is the foundation. If providers neglect it to chase the newest revenue wave, customers may eventually decide that the public cloud is no longer holding up its end of the bargain.

There is an important distinction between using AI to generate UI code during development and letting AI generate executable UI at run time.

If a developer uses ChatGPT, GitHub Copilot, Cursor, or another AI coding assistant to generate a component, template, stylesheet, test, or even an entire feature, that can be a productive workflow. The generated code still enters the normal software development process. A developer can review it, edit it, test it, commit it, and maintain it like any other source code.

That is not the problem this article is about.

The risk begins when a live application asks a model to generate HTML, JavaScript, styles, or event handlers in response to an end user’s request and then renders that output directly inside the running product. In that scenario, AI is no longer just helping a developer write code. It is participating in the run-time behavior of the application.

This article is for developers and front-end architects building AI-driven applications where the interface adapts based on user intent. These systems may render charts, tables, forms, summaries, confirmation flows, or workflow steps dynamically. The goal is not to discourage the use of AI-generated, executable UIs in production. The goal is to use AI-generated, executable UIs in production safely, with the proper checks. 

This is not a hypothetical concern. Developer platforms are already exploring generative UI patterns where model output, tool calls, or structured responses determine which components appear in an application. The pattern is still early, but the direction is clear: AI responses are moving from plain text into task-specific interface composition. That makes the front-end boundary more important, not less.

A useful example is a cloud cost dashboard.

Imagine a user asks:

Why did our cloud bill spike this week, and what can I do about it?

A plain-text response may explain that compute usage increased, storage costs rose, and one service had unusual traffic. That answer may be technically correct, but it is not the best interface for the task. The user probably needs a cost comparison chart, a service breakdown, a list of anomalies, links to affected resources, and a set of safe remediation actions.

This is where generative UI becomes valuable. The application can assemble an interface around the user’s information needs and the actual task to be performed, instead of forcing every answer through a chat transcript.

But the architecture matters.

Generative UI will not fail because AI cannot draw charts or suggest buttons. It will fail because teams let models own behavior they should only be allowed to describe.

The model may propose intent, but the application must own execution.

The promise and risk of generative UI

As AI applications move beyond chat boxes, developers are starting to build interfaces that adapt to what the user is trying to do. That is the right direction. A user investigating a spike in the cloud bill should not have to read a long paragraph and then manually navigate to five different dashboards. The application can present the monthly comparison, identify the services that changed most, surface the suspicious resources, and offer next steps in one task-specific view.

That is the promise of generative UI: interfaces assembled dynamically around the user’s task.

But there is a dangerous shortcut behind that promise. If the model generates arbitrary HTML, JavaScript, styles, and event handlers at run time, the application gives up one of the most important boundaries in front-end architecture: control over what the interface can do.

A production application should not let a model invent executable UI during a user session. It should let the model describe interface intent, then render that intent through trusted application components.

The wrong pattern: AI-generated UI code at run time

The most obvious version of generative UI is also the most fragile. A developer building an AI-powered product asks the model to produce some HTML, injects the output into the page, and treats the result as an adaptive interface.

For example, the model might return something like this:

  
Cloud spend increased by 38%
  
The biggest increase came from compute usage in us-east-1.
  
    Shut down unused instances
  

This looks useful at first glance, but it creates several problems at once.

The model has generated markup, assumed a visual structure, and attached executable behavior. It has decided that shutting down instances should be available. It has assumed a function named shutdownInstances exists. It may also have bypassed the design system, accessibility rules, analytics conventions, authorization checks, approval workflows, and the application’s normal state model.

This is very different from an AI coding assistant generating a component that a developer reviews before shipping. In this case, the model output is entering the live application at run time. The user sees it immediately, and the application may execute behavior based on it immediately.

Even if this works in a demo, it is not a maintainable front-end architecture.

Generated HTML bypasses the component system. Generated JavaScript expands the application’s attack surface. Generated event handlers make behavior harder to test. Generated UI state can drift away from real application state. Generated forms can ask for fields the product does not support. Generated buttons can imply actions the user is not allowed to perform.

The issue is not that models are useless at shaping interfaces. The issue is that an executable UI is the wrong run-time output boundary.

In a production system, the model should not create the interface directly. It should describe the kind of interface the application should assemble.

The better pattern: structured UI intent

A safer approach is to define a controlled vocabulary of UI blocks the model is allowed to request. The application validates the model response, rejects anything it does not understand, and maps valid blocks to trusted components.

Instead of returning HTML, the model returns structured data:

{
  "blocks": [
    {
      "type": "cost-summary",
      "props": {
        "period": "current-week",
        "comparisonPeriod": "previous-week"
      }
    },
    {
      "type": "service-cost-breakdown",
      "props": {
        "period": "current-week"
      }
    },
    {
      "type": "anomaly-list",
      "props": {
        "severity": "high"
      }
    },
    {
      "type": "remediation-options",
      "props": {
        "category": "compute"
      }
    }
  ]
}

This response is still dynamic. The model can decide that the user needs a cost summary, a service breakdown, a list of anomalies, and remediation options. But it is no longer inventing arbitrary UI. It is choosing from capabilities the application already understands.

In TypeScript, that vocabulary might look like this:

type UIBlock =
  | {
      type: 'cost-summary';
      props: {
        period: 'current-week' | 'current-month';
        comparisonPeriod: 'previous-week' | 'previous-month';
      };
    }
  | {
      type: 'service-cost-breakdown';
      props: {
        period: 'current-week' | 'current-month';
      };
    }
  | {
      type: 'anomaly-list';
      props: {
        severity: 'medium' | 'high';
      };
    }
  | {
      type: 'remediation-options';
      props: {
        category: 'compute' | 'storage' | 'network';
      };
    }
  | {
      type: 'confirmation';
      props: {
        message: string;
        actionId: string;
      };
    };

This type defines the interface contract. The model can request a cost summary, a service breakdown, an anomaly list, remediation options, or a confirmation prompt. It cannot invent a new component type, add random props, attach JavaScript, or decide how the component behaves internally.

The model chooses from a vocabulary. The application owns the vocabulary.

Render through a component registry

Once the model response has been converted into structured UI intent, the application can render it through a component registry.

const componentRegistry = {
  'cost-summary': CostSummary,
  'service-cost-breakdown': ServiceCostBreakdown,
  'anomaly-list': AnomalyList,
  'remediation-options': RemediationOptions,
  'confirmation': Confirmation
};

function renderBlock(block: UIBlock) {
  const Component = componentRegistry[block.type];

  if (!Component) {
    return null;
  }
  return ;
}

This example is intentionally simple, but the architectural shift is significant.

The model does not decide how the cost summary is implemented. It does not decide how billing data is loaded, how errors appear, how loading states work, how accessibility is handled, or how analytics are recorded. Those responsibilities remain inside the application.

That matters because a mature component system is not just a visual toolkit. It is where front-end teams encode product consistency, interaction rules, performance decisions, accessibility behavior, telemetry, and testing strategy.

Generative UI should not bypass that system. It should compose from it.

A component registry gives the model flexibility without giving it authority. The model can influence which trusted components appear. It cannot create new executable behavior outside the application’s control.

Validate model output at run time

TypeScript helps developers define the expected shape of the UI contract, but TypeScript does not validate model output at run time. A model response is external data. It should be treated the same way we treat data from a network request, file upload, webhook, or third-party API.

It is untrusted until validated.

The validation layer is where the application turns probabilistic model output into something deterministic enough to render. Whether a team uses JSON Schema, Zod, Valibot, or another validation library, the application should receive the model response as unknown data and validate it before anything reaches the screen. That validation step should reject unknown component types, malformed props, unsupported actions, and any structure the application does not explicitly understand. Only after the response passes that boundary should it be rendered through the component registry.

With a schema library, the validation boundary might look like this:

const CostSummarySchema = z.object({
  type: z.literal('cost-summary'),
  props: z.object({
    period: z.enum(['current-week', 'current-month']),
    comparisonPeriod: z.enum(['previous-week', 'previous-month'])
  })
});

const AnomalyListSchema = z.object({
  type: z.literal('anomaly-list'),
  props: z.object({
    severity: z.enum(['medium', 'high'])
  })
});

const UIBlockSchema = z.discriminatedUnion('type', [
  CostSummarySchema,
  AnomalyListSchema
]);

function parseUIResponse(response: unknown): UIBlock[] {
  const result = z.array(UIBlockSchema).safeParse(response);

  if (!result.success) {
    return [];
  }

  return result.data;
}

In a real application, the schema would likely cover layout rules, component limits, allowed nesting, action references, and versioning. The point is not the specific library. The point is the boundary.

The model does not get to decide whether its output is safe. The application does.

A fallback path is also essential. If validation fails, the application should not attempt to improvise. It should show a safe fallback, ask the user to rephrase, or return a conventional text response. AI-driven interfaces need graceful failure. A malformed UI description should never become a broken or unsafe screen.

Separate rendering from actions

The most important boundary in generative UI is not rendering. It is execution.

A dynamic interface may include buttons, forms, confirmations, or workflow steps. Those controls may request real operations: shut down an instance, resize a database, open a support ticket, approve a deployment, update a policy, or change account settings.

The model should not execute those actions. It should not decide that an operation is allowed simply because the user asked for it. Instead, action execution should flow through an application-owned action registry.

For example, a model may request a confirmation component:

{
  "type": "confirmation",
  "props": {
    "message": "Do you want to open a remediation task for the unused compute instances?",
    "actionId": "create-remediation-task"
  }
}

But the action itself should be defined and executed by the application:

type UIAction =
  | {
      type: 'create-remediation-task';
      resourceIds: string[];
    }
  | {
      type: 'open-support-ticket';
      category: 'billing' | 'performance' | 'security';
    };

const actionRegistry = {
  'create-remediation-task': createRemediationTask,
  'open-support-ticket': openSupportTicket
};

async function executeAction(action: UIAction, user: CurrentUser) {
  if (!isActionAllowed(action, user)) {
    throw new Error('Action not allowed');
  }
  return actionRegistry[action.type](action);
}

Before an operation runs, the application has to make deterministic decisions that the model should not control. The action must exist in the application’s registry, the current user must be authorized to perform it, the target resources must belong to a context the user can access, and the operation must still be valid in the current state. Some actions may require confirmation, auditing, approval routing, or a final server-side permission check before anything changes.

These questions cannot be delegated to the model. They belong to the application and, ultimately, to the back-end systems that enforce the business rules.

The model can help generate the path. It cannot become the authority.

State still belongs to the application

Generative UI also creates a subtle state-management problem.

In a traditional application, the front end knows where state lives. Billing data, user permissions, resource metadata, anomaly status, remediation tasks, and workflow progress are loaded, cached, invalidated, and updated through known application paths.

An AI-driven interface can blur that boundary. The model may summarize state, infer state, remember conversation context, or describe a screen based on previous messages. If teams are not careful, the generated interface becomes a second hidden state system.

That is dangerous.

The UI may say a compute instance is unused even though its status has changed. It may show a remediation option based on stale billing data. It may produce a confirmation message that no longer matches the current workflow. It may remember something from the conversation that the application itself has not verified.

The application must always remain the authority on state. 

The model can help decide which components to display, but those components should read real state from the application and its APIs. A CostSummary component should fetch or receive billing data through the same trusted path as any other part of the product. A remediation action should update state through the normal application flow. A confirmation component should not become the source of truth for whether an operation is possible.

Generative UI should be a projection of application state, not the owner of it.

This distinction becomes even more important in agentic applications, where interfaces may change over several turns of conversation. A user may ask a question, inspect a result, request an action, change their mind, and return later. The application needs a reliable model for what happened, what is pending, what failed, and what still requires human approval.

That cannot live only in the model’s context window.

Design for controlled composition

The future of generative UI is not arbitrary run-time code generation. It is controlled composition.

The model should be able to assemble experiences from trusted capabilities: components, layouts, actions, validation rules, and state transitions that the application exposes intentionally.

That gives developers the best of both worlds.

The interface can adapt to the user’s goal, but the system remains testable. The model can choose the right UI blocks, but the design system stays intact. The user can move through dynamic workflows, but permissions and business rules remain deterministic. The application can feel intelligent without becoming unpredictable.

This is also a better mental model for front-end teams. Generative UI is not a replacement for front-end architecture. It increases the need for front-end architecture.

Teams still need component systems. They still need run-time validation. They still need state ownership. They still need accessibility standards. They still need action boundaries. They still need server-side authorization. AI does not remove these concerns. It makes weak boundaries easier to expose.

In this model, the user expresses intent and the model responds with structured UI intent. The application validates that response, renders it through a component registry, and routes any requested behavior through an action registry. Application state remains the source of truth, while the server remains responsible for final authorization.

That is the boundary production systems need.

AI can help developers generate complete features during development. That code can and should go through review, testing, and normal delivery. But when AI participates in a running application, the run-time contract needs to be much narrower. The live model should describe what the user interface should express, not generate unchecked code that the product executes.

The better approach is to give AI a component system.

Let the model compose. Let the application control. Let the user experience become more dynamic without sacrificing the architecture that makes software reliable.

GitHub has restored services after a nearly eight-hour outage disrupted several of its core developer tools, including Actions, pull requests, APIs, Git operations, Webhooks, and Copilot, impacting software development workflows across its platform.

“This incident has been resolved. Thank you for your patience and understanding as we addressed this issue,” the company wrote on its status page.

The disruption was first reported at 1:40 PM UTC on August 17, with GitHub initially flagging degraded performance across parts of its platform. Within minutes, the disruption had spread to API Requests, Actions, Webhooks, Issues, and pull requests (PRs).

At the height of the incident, GitHub reported an error rate of about 20% across its web experience and API traffic. Archive downloads and raw repository content downloads were seeing an error rate of approximately 50%, while SAML and OIDC authentication, SCIM, and Team Sync were also affected.

GitHub’s AI coding assistant, Copilot, also experienced degraded availability beginning at 2:31 PM UTC. The company later said that some Copilot authentication problems persisted even after other parts of the platform had recovered.

Recovery was not linear

Finally, at 4:36 PM UTC, the company said that it had identified the problematic component and had taken corrective actions.

However, the recovery of services was not linear.

Git Operations experienced another period of degraded performance, while API Requests briefly returned to a degraded state. GitHub subsequently said it had mitigated the Git Operations issue and restored normal API operation by 7:01 PM UTC.

Still, other services remained affected with problems centered largely on authentication. GitHub said it had partially disabled authentication-token retries after observing sporadic authentication failures and later reported that Copilot authentication issues were still affecting some applications.

“We are continuing to investigate sporadic authentication failures. We have partially disabled authentication token retries and have seen improvement, and we are monitoring impact before fully applying this mitigation,” the company wrote.

It finally fixed these issues at 8:45 PM UTC and marked the incident resolved at 9:15 PM UTC, nearly 8 hours after it was first reported.

Downtime significant for enterprise teams

While the incident didn’t amount to a complete shutdown of GitHub, the number and nature of services impacted are significant for enterprise development teams as the company increasingly serves as more than a repository for source code.

Development teams use its APIs, Actions workflows, PRs, and integrations as connected parts of their software delivery processes, and a disruption to several of those components simultaneously can therefore affect workflows even when basic repository access remains available.

GitHub has yet to identify the “problematic component” that caused the failure or why its failure took out so many services together.

Until the company’s post-incident analysis is available, it is unclear whether the outage was caused by an infrastructure failure, a software change, an authentication problem, or another issue like an attack.

For now, GitHub’s status page says that a “detailed root cause analysis will be shared as soon as it is available.”

Promoting the use of coding agents with its cloud-based document database, MongoDB has unveiled the MongoDB Atlas Managed MCP Server. Fully hosted and managed, the MongoDB Atlas Managed MCP Server connects coding agents to MongoDB Atlas without requiring customers to run additional infrastructure.

Developers can easily add MongoDB Atlas to Claude Code, Codex, Grok Build, and Devin, said MongoDB, which announced the availability of the Managed MCP Server on August 13. With the Managed MCP Server, MongoDB brings live operational data to the agentic coding stack, the company said.

The MongoDB Atlas Managed MCP Server is remote and fully hosted, running as a service inside MongoDB Atlas, so there is nothing for a team to install, operate, or upgrade, MongoDB said. Teams connect using the same credentials and access controls they already use with Atlas, so administrators can govern how agents access operational data from one place.

The MongoDB MCP Server remains available for users who want to deploy a MongoDB MCP server locally or host one themselves. The MongoDB MCP Server works with any MongoDB deployment, including MongoDB Atlas, MongoDB Atlas Local, MongoDB Community Edition, and MongoDB Enterprise Advanced.