My most-cited BYTE cover story was 1994’s Componentware, which made the case for a two-tier architecture best exemplified then by Visual Basic and its component ecosystem. The prevailing strategy for software reuse, object-oriented programming, hadn’t gained the traction we all expected. Visual Basic showed us why it hadn’t. Objects were written in the same languages, and by the same specialized coders, as the programs that reused those objects. VB flipped the script. Code-savvy component builders created building blocks that domain-savvy systems thinkers could wire together.

Then the web flipped the script again. The browser was the new canvas, and it left the component ecosystem behind. Plugins came and went. The web platform eventually did define standards for components but they’ve been eclipsed by the web’s de facto standard framework, React, and its component architecture. And just like objects 30 years ago, React components are both produced and consumed by specialized coders. There wasn’t a good way for a modern solution builder to tap into React’s component ecosystem.

The framework that I co-maintain, XMLUI, harks back to the VB model. A UI is defined by concise semantic XML markup that refers to a catalog of components. There is no visual canvas but, as we debated whether or how to recreate that experience, the question became moot. When agents write declarative markup in conversation with us, direct manipulation matters less than it used to.

A better target language for LLMs

It’s no accident that Markdown has become a primary way for humans and AIs to collaborate. Why not HTML and CSS? Markdown constrains AIs to a smaller set of patterns, and that’s a good general rule. Our new agentic team members are powerful but undisciplined. Left to their own devices they behave in unpredictable ways. The fewer degrees of freedom we allow them, the better things will go for all of us.

The same principle applies to coding. When you ask an LLM to build an app with React and CSS, you invite it to operate with few constraints. Nothing stops an agent from writing a useEffect that subscribes to something and then forgets or misuses its cleanup function.

XMLUI automatically endows every component with three life-cycle events, shown in this example.

onMount runs once when the component becomes visible. onUnmount runs once when it leaves. onError catches anything either of them throws and receives { source, error }, where source is "mount", "unmount", "beforeDispose", or "action". The agent does not write a return value, does not pick a dependency array, does not name a cleanup function. There is nothing to forget.

We say that XMLUI is to React as Java and C# are to C++: a managed language that abolishes many kinds of errors and vulnerabilities. In both cases there are valid reasons to pierce the abstraction and reach for low-level primitives, but that should be the exception not the rule. If most of what needs doing can happen in a managed layer, it should.

Wrapping React components

XMLUI components are wrappers around React components; they expose properties and APIs for declarative use. The core set of components delivered in the XMLUI runtime handle layout, data access, lists, tables, and UI controls including buttons, switches, and sliders. More advanced components like ECharts, Tiptap, and Masonry are wrapped in the same way and delivered as loadable extensions. All components share a common mechanism for semantic tracing. When enabled, semantic tracing captures a rich history that includes API calls and results, handler timings, and — this is the semantic part — trace events keyed to ARIA labels.

The aria-label property becomes the component’s accessible name in traces, so a screenreader announces “Volume, slider, 50” and the trace records value:change didChange Slider [Volume] "53". This unlocks accessibility, semantic traces that AIs can reason about, and regression tests generated from user journeys.

The wrapper can even make interaction with a observable. When ECharts draws a chart, for example, the browser sees a rectangle of pixels. Click a bar and all the DOM sees is that you clicked a rectangle. The XMLUI wrapper opens the black box by deriving a name for the chart, so the canvas becomes “Revenue by Quarter — bar chart” to a screen reader, a test runner, and a trace. And it bridges ECharts’ own event model into the trace, so a click becomes “series0 → Q2 = 200” and a legend toggle becomes “Series 1: hidden”. The trace no longer says something was clicked, it says what data the user saw.

Agents now often build user interfaces from scratch. An agent receives a prompt, writes React and CSS, and ships something that seems to work. Then comes the unhelpful bug report: “The chart did something weird when I clicked on it.” A UI built from traceable components yields a different kind of report. It says they clicked Q2 on the revenue chart, hid Series 1, changed the date range, and triggered an API call that returned 500. If you ask an agent to instrument a from-scratch UI this way, it will invent conventions that the next agent won’t share. Components done well can deliver consistent observability.

Libraries and components

Agents do reuse plenty of code in the form of libraries that provide clear APIs, that do careful versioning, and that embody years of hard-won interoperability. What separates a component from a library isn’t quality or packaging; it’s what the host knows about it.

When an app calls a library the runtime sees function calls. When an app hosts a component the runtime sees a declared unit: these properties, these events, this configuration. In the VB era that contract enabled the property sheet to display a component’s settings and empowered the developer to wire its events.

React components can play this role, and XMLUI wraps them because that’s where the ecosystem is today. But it’s the contract between component and container that matters, not the framework. As agents become solution builders it may be time to reconsider the web’s own component standard.

Agents that can easily write bespoke code tempt us to think that reusable parts matter less. No! Every app they build costs effort to review, operate, and maintain. When instrumentation and security fixes and policy checks live in a component, every app that uses the component lightens that effort for hybrid teams of people and agents.

Below the water line

UI is just the visible tip of the iceberg. Below the water line is code that does hard and risky work. Consider /n software, the company that funded XMLUI’s early development. It has built components for that layer since the 1990s. Its IPWorks line, for example, covers SSH, SSL, SFTP, MQ, EDI, encryption, and S/MIME, protocols that businesses use to communicate securely.

If an agent can write an SFTP client in an afternoon, why buy one? The real world is messy. A component that has connected to many counterparties over many years has absorbed edge cases that an agent’s bespoke code won’t meet until production.

When a vulnerability is found and fixed, a maintained component delivers the fix to every customer. A price tag doesn’t guarantee any of this, but incentives matter. A vendor whose business is one component, used by many customers, is motivated to do it right and keep it right.

Suppose an agent builds an app that enables a finance team to send invoice batches to trading partners. The transfer uses an SFTP component. The organization’s policy says transfers may go only to registered partner hosts, with host-key verification required.

Here is a sketch of how things might go. An SFTP component declares its configuration so the host can validate it before anything runs. Is this endpoint on the partner list? Is host-key checking turned on? If not, the component doesn’t start, and the error says why. That’s a check performed by the runtime, not a convention the agent is asked to remember.

And because the component reports into the same trace as the UI, the user’s journey and the transfer show up in one record:

selection:change Table [Pending invoices] 12 rows
click Button [Send to Acme]
sftp:connect [Acme partner] host-key verified
sftp:upload invoices-2026-10.edi 48 KB
sftp:error permission denied (remote path /inbound)

Whoever maintains the app, human or agent, can see at a glance that the UI did its job, the connection was trusted, and the failure happened on the partner’s side.

Governing with components

Every agentic deployment begs the same questions: how do we know what the apps they built are doing, and whether they are doing it safely? Logging is necessary but not sufficient when the logs point back to thousands of lines of bespoke integration code. A component architecture helps answer the questions. You know what each system is made of, you validate how the parts are configured, you observe them through the lens of a shared vocabulary.

In 1994, component builders made parts that solution builders could compose, relying on their experience and judgment more than their coding skill. Now agents are wildly prolific solution builders. We need to connect them to an ecosystem of trusted, observable, governable parts so the apps they build can reflect the experience and judgement of today’s domain-savvy systems thinkers.

Agentic AI has become a powerful enterprise business tool with increasing capabilities, and it has never been easier to address business pain points by applying a large language model (LLM) to develop a plausible automated solution.

But is that solution as reliable as you need it to be, especially when the insights gleaned are used to inform critical business decisions?

LLMs are incredible resources that play a significant role in a business’s agentic AI infrastructure. But when they have to work across complex data sets, business policies, industry regulations, decision hierarchies, and multiple software systems, they do not inherently provide the enterprise-grade provenance needed to show which evidence, assumptions, constraints, and decision logic produced a recommendation. Additionally, when gathering inputs from a volume of data sources, the accuracy of their outputs can break down and potentially create hallucinations. If business decisions are made based on LLM outputs that can’t be explained or may be inaccurate, it can create significant consequences that impact product sales, revenue, compliance, or customers.

The problem is that the LLM is asked to carry too much of the enterprise reasoning without the harness and enterprise foundation around it.

A structured foundation for decision-making

While enterprise interest in agentic AI has grown substantially over the past few years, what works in concept hasn’t always proven results in the pilot phase and beyond. A common reason agentic AI pilots can fail in production is that an LLM is asked to carry too much of the enterprise reasoning without the support of an enterprise foundation. LLMs are powerful for some use cases, like demos, but enterprise decision-making will always require structure beyond a good prompt. While AI tools and platforms are becoming more commonplace and efficient at producing outputs, enterprise decisioning depends on plan versions, constraints, policies, approval logic, and financial guardrails. Additionally, enterprises will still need to rely significantly on the expertise, judgment, and reasoning capabilities of their workforces when implementing and scaling AI usage to ensure that outputs are trusted and can be applied in critical business decision-making.

LLMs will always play a critical role in building out an effective enterprise AI infrastructure, but the other critical component is the information, institutional knowledge, and context that is unique to how your business operates and makes decisions. Neurosymbolic AI strengthens enterprise AI by combining the pattern recognition and language capabilities of neural AI with an explicit symbolic representation of the enterprise, including its entities, relationships, plans, policies, constraints, decision logic, and context. Unstructured information such as emails, meeting notes, spreadsheets, contracts, and policy documents can contribute to that model, with the goal to give AI a structured enterprise foundation against which it can reason.

Neurosymbolic AI is a framework that combines the core strengths of symbolic AI, which represents explicit enterprise structure, relationships, rules, constraints, and decision logic, with neural AI, which powers capabilities such as language understanding, pattern recognition, and synthesis. This framework builds upon the domain expertise and rules of symbolic AI and the capability of neural AI to find and learn from the complex patterns and relationships found in vast amounts of data. A straightforward conceptual model for describing this architecture is 10-80-10. The first 10% is neural, as the LLM helps interpret the user’s intent and translate it into a structured enterprise question. The middle 80% is where the enterprise foundation carries the reasoning that the LLM should not be asked to improvise. The system resolves enterprise context and can invoke plans, policies, constraints, decision rights, forecasting, causal analysis, simulation, optimization, rules, and solvers to evaluate scenarios and trade-offs. The final 10% is neural again, as the LLM explains the result in clear business language and makes the answer accessible for business decision-making.

As a result, neurosymbolic AI can make sense of large volumes of data at scale and recall complex patterns, while also incorporating structured reasoning and contextual knowledge that is unique to an organization. This grounds outcomes in reality and significantly reduces the chance of hallucinations.

Understanding the business question in context

A crucial component to incorporating neurosymbolic AI into a business’s larger AI strategy is a structured enterprise and decision-model foundation that can connect data, knowledge, plans, policies, constraints, and decision context. For example, the o9 Digital Brain’s Enterprise Knowledge Graph provides a structured and continuously updated semantic foundation that organizes enterprise information and connects it to decision models for capabilities such as forecasting, optimization, scenario analysis, and recommended actions. Better prompt construction is becoming irrelevant with each new frontier model. The system needs to understand the business question in context: the objective, relevant enterprise scope, current plans and actuals, policies and constraints, available decision levers, and who has authority to act. A neurosymbolic architecture allows much of that context to come from the enterprise model itself rather than requiring the user to recreate it in every prompt.

There are a few areas where neurosymbolic AI is already providing tangible business value, such as data integration and transforming unstructured data into the insights that guide decision-making.

But perhaps one of the most significant value-driven impacts of neurosymbolic AI can be seen in enterprise agility. Cross-functional decision-making, also known as integrated business planning, is a persistent challenge that is fundamentally a coordination problem. Teams across demand, supply, finance, and commercial each operate with different models, different data, and different incentive structures. When a neurosymbolic agent can not only bridge these silos, translate between domains, and reconcile plans across functions, but also apply similar reasoning and understand the constraints or rules that your most experienced planners know and use daily, the outputs provided are more accurate and trustworthy to base business decisions upon. Over time, the system also can learn from the enterprise’s decision history by preserving what was known, what was predicted, what alternatives were considered, what was decided, and what happened afterward. Comparing expected and realized outcomes can turn successful decision patterns into reusable organizational knowledge and, where appropriate, governed playbooks. This accumulated decision history can also help guide planners by bringing relevant prior situations, outcomes, and established practices into the context of a new decision.

The enterprise AI landscape has reached a phase where business leaders are asking more substantive questions, like where can AI provide trustworthy outputs and measurable value that is reliable?

I believe the neurosymbolic approach provides the clearest answer to that question for the domain of enterprise decision-making. LLMs are an indispensable component of an enterprise AI strategy. But when an LLM is combined with the symbolic layer—the structured data models, the knowledge graphs, the decision frameworks informed by deep domain expertise—it transforms into a trustworthy enterprise system that can inform business decisions across the organization.

—

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.

The UK’s digital watchdogs have warned enterprises that they can’t evade their legal responsibilities by blaming errors on AI agents that they have deployed.

“By taking action on behalf of users, such as making purchases and communicating with businesses, these agents could transform how people use digital services, engage with markets and unlock wider innovation,” said the Digital Regulation Cooperation Forum (DRCF), a body comprising the UK’s Competition and Markets Authority (CMA), Financial Conduct Authority (FCA), Information Commissioner’s Office (ICO), and communications regulator Ofcom, in a joint statement.

While the DRCF welcomed such uses it advised, “firms developing or deploying personal agents should think carefully about how consumers can understand when and how an agent acts on their behalf, how authority to act is given and how their personal data is used.”

The DRCF didn’t pull its punches. “We want to be explicit that existing legal and regulatory frameworks apply to personal AI agents, including competition, consumer and data protection law, online safety, financial services, payments and cyber security requirements,” it said, adding, “An AI agent’s autonomy does not diminish the responsibility of organisations that deploy it to comply with applicable law and relevant regulation.”

There is certainly a degree of uncertainty over the legal position of autonomous AI agents. Gartner has warned that companies are increasingly facing legal challenges over “AI-induced” decisions, while attorneys have weighed in over gray areas in AI governance.

The four UK regulators aren’t immune to that doubt: Only a few weeks earlier, they issued a Call for Input on their 2027-27 work plan to help them avoid overlap and uncertainty about the interplay between their respective regulatory regimes.

This article first appeared on CIO.

OpenAI is buying Pierre Computer Company in order to incorporate the San Francisco-based software developer’s Code.Storage infrastructure layer for Git into its Codex AI-powered programming tool.

Pierre Computer, whose employees number just barely in the double digits, has got plenty of clout for its small size. It’s well-known for Code.Storage offering, as well as for its open-source software libraries, Trees and Diffs, which OpenAI already uses in Codex.

OpenAI has experienced some of the limitations of Git itself, and its in-house engineering teams are already working to improve its support for human coders and AI agents working in parallel. Earlier this week the company described how it built a new back end for Git repositories, Pando, to enable concurrent working at scale.

The AI developer has been pushing Codex more aggressively this year: offering it to Mac users and expanding it to Windows. It cited Pierre Computer’s ability to help developers review code as one of the reasons for the acquisition. OpenAI highlighted the Diffs’ Edit mode and the recently released Highlights as components that were particularly helpful to development teams.

Announcing the deal on its news page, OpenAI set out how it would integrate the company into its existing offerings. “With the Pierre team, we wish to set the standard for modern software development: from the first branch an agent creates to that magic moment when code is deployed to the world. We want to make Codex the place where developers and agents take on their most ambitious projects.”

Neither company disclosed details of the acquisition price. OpenAI said that Code.Storage customers will be able to continue using the product until it brings the features into Codex, while Pierre Computer’s open-source projects will remain open, and OpenAI will continue to contribute to them.

A memory-safety flaw in CPython can allow malicious AI model templates to escape code sandboxes and execute arbitrary code inside inference servers, according to security researchers at RunSybil.

“By exploiting this vulnerability, attackers could gain a foothold inside servers responsible for processing millions of user requests,” Darius Houle, a security researcher at RunSybil, wrote in a blog post. “They also could strike directly at the underlying cloud infrastructure hosting those workloads.”

The researchers demonstrated how a specially crafted model could exploit the flaw to bypass Jinja, a Python-based templating engine used to structure interactions between users and LLMs, sandbox protections, and execute code in the process of serving the model. The attack could expose AI hosting providers that allow customers to upload and run their own models, potentially giving attackers a foothold inside infrastructure processing requests for multiple customers, the post added.

However, the Python Security Response Team (PSRT), which handles security reports involving CPython, disputed the security implications of the demonstration in a response to CSO. “We acknowledge the underlying CPython bug reported by RunSybil and appreciate their contribution to fixing it. However, we do not consider the demonstrated sandbox escape to be a CPython security vulnerability,” the team said.

The disagreement centres on whether the interpreter should be responsible for preventing sandbox escapes. While RunSybil argues that the flaw creates risks for AI inference infrastructure, PSRT says executing untrusted Python code within a sandbox is outside CPython’s security threat model.

Exploiting Python’s type-handling mechanism

“The bug we discovered abuses CPython’s handling of generic types to accomplish a breakout,” Houle wrote. “We exploited it using objects that sandboxes make available in every template, even in empty sandbox contexts.”

The researchers found that CPython can use a cached list of parameters even after an object has been modified through a callback. When the interpreter subsequently looks for a newly introduced parameter in the original list, it can receive an invalid index. An assertion designed to catch the condition is disabled in normal release builds, allowing the interpreter to access memory outside the expected bounds.

RunSybil used this behavior to retrieve references to Python objects that the sandbox was supposed to keep inaccessible.

“While an invalid address will generally crash the interpreter, an address pointing to a useful live Python object gives our callback a reference to that object (even when the sandbox never intends to expose it),” Houle wrote.

The researchers then used the recovered object references to access Python classes and functions needed to construct executable code.

Malicious model templates enable code execution

To demonstrate the attack, RunSybil modified the Qwen2.5-0.5B-Instruct model by inserting a backdoored chat_template.jinja file. When the model was loaded and used through an inference-serving engine such as vLLM, the template enabled arbitrary code execution in the serving process.

“Breaking out of the chat template sandbox and executing code represents a supply chain risk that endangers inference providers, library developers, and model users,” Houle wrote.

The researchers said they shared proof-of-concept exploits with multiple inference providers supporting bring-your-own-model (BYOM) features, which allow customers to upload models from external sources.

Python disputes vulnerability classification

RunSybil disclosed the issue to CPython, the Pallets Project, which maintains Jinja, and Hugging Face. The researchers said they encountered conflicting views about which project should address the underlying problem.

CPython maintains that the interpreter does not support sandboxing untrusted Python code as a security boundary. In its response to CSO, the PSRT referred to the project’s security policy, which states that sandbox escapes should be addressed by the maintainers of the affected sandboxing software.

“Escapes from such sandboxes are therefore outside our security threat model and should be addressed by the maintainers of the affected sandboxing software,” the team said.

The team also disputed RunSybil’s suggestion that there was no coordinated remediation process. It said the researchers had submitted the report by email rather than through CPython’s designated private GitHub vulnerability reporting channel.

Fix backported to three Python branches

RunSybil submitted a patch to CPython, which was merged into the main development branch on Aug. 14. According to the PSRT, the fix was also backported to the 3.13, 3.14, and 3.15 branches as a regular bug fix rather than a security fix.

The distinction matters because RunSybil had raised concerns that the fix would not reach all supported Python versions.

The researchers said the absence of a backport to Python 3.12 could delay adoption of the fix across AI infrastructure deployments.

“With major portions of the AI ecosystem still solidly aligned on Python 3.12, we might not see organic adoption of our memory-safety fixes until late 2028, when it reaches its end-of-life date,” Houle wrote. The researchers recommend that AI hosting providers treat sandboxed code, template engines and expression evaluators as best-effort security controls rather than relying on them as standalone security boundaries.

The article originally appeared on CSO.

A major experimental component of Python, its native JIT (just-in-time) compiler, is to be removed. But that won’t make Python any less attractive or powerful. Follow the links below to read about all its new features, explore one of its major libraries for computer vision, discover how Python apps can be made into click-and-run executables, and more.

Top picks for Python readers on InfoWorld

Python jettisons the native JIT, at least for now
A promising experiment in natively speeding up CPython has come to a halt due to questions about its maintainability. But while it’s gone for now, it isn’t forgotten.

Video: The 10 biggest new things in Python 3.15
Watch our unboxing video for Python 3.15 and all the goodies it gives you: Lazy imports! The frozendict type! The sentinel object! And tons more!

OpenCV explained: The computer vision library for AI apps
Now in its fifth major revision, OpenCV is a staple for Python developers creating AI apps that use OCR, object detection, face recognition, other vision analysis capabilities.

Redistribute Python apps easily with PyCrucible
This Rust-powered tool takes any pip-installable package and converts it into a redistributable binary you can give to anyone to run as-is. Some assembly is required.

More good reads and Python updates elsewhere

Python community-maintenance project Jazzband is closing its doors
Founded to help share the responsibility of maintaining open source Python projects, Jazzband is shutting down after a decade. It wasn’t any one thing that broke up the band, but AI-slop PRs, the “one-roadie problem” (it’s hard to be the only one in charge), and a dozen other cuts all took their toll.

Google releases TorchTPU to run PyTorch on Tensor Processing Units
If you have access to Google TPUs and you want to boost PyTorch workloads by running them on that silicon, Google has released a library to do just that. You will need to change some code to make it work, but you will still be using the PyTorch you know and love.

Astral previews integration of uv and ty
The uv package installer and the ty type checker, both from Astral, now work more closely together via an experimental integration. Running uv check sets up a project and checks it with ty automatically.

Using MicroPython to power an open source wearable
What could you do with only 64K of RAM and 4MB of storage? With MicroPython, a lot more than you might think. Read this one to the end for a heartwarming conclusion!

Most enterprise AI conversations still start in the wrong place. They begin with models, platforms, and cloud services. Which foundation model is best? Which provider has the most GPUs? Which tool can build the flashiest demo? Those questions matter, but they are not where production AI usually succeeds or fails. The better question is: Where should the inference actually happen?

That sounds simple, but it is becoming one of the most important architecture decisions in AI. Not all inference belongs in the central cloud. Not all inference belongs on the device. Not all inference belongs at the edge. The right answer usually involves all three, working together as a pipeline. I call this an edge-cloud AI inference architecture. It splits AI workloads across devices, edge locations, and centralized cloud platforms so latency-sensitive decisions happen close to the user or machine, while heavier reasoning, aggregation, governance, and retraining remain centralized.

This is where the next generation of useful enterprise AI systems is headed.

Latency changes the design

Cloud-first AI works well when the user can wait. A chatbot can tolerate a few hundred milliseconds, sometimes more. A document analysis workflow can wait seconds. A batch analytics process can wait minutes or hours. Many operational AI systems cannot. A manufacturing robot cannot wait for a round trip to a distant cloud region before stopping a defective process. A retail checkout camera cannot depend on a remote model call for every frame. A vehicle, medical device, warehouse scanner, or energy-grid controller cannot treat network latency as an afterthought.

In these cases, inference needs to happen locally or very close to the source. That may mean on the device itself, on an on-premises edge server, in a telecom edge facility, or in a regional micro data center. The point is not the label. The point is proximity.

Latency is not just about speed. It is about reliability. A system that works only when the network is perfect is not a production system. If the business process is time-sensitive, safety-sensitive, or mission-critical, the architecture has to assume intermittent connectivity, congestion, and failure.

That is why edge inference matters.

Not all inference is equal

A mistake I see often is treating inference as one thing. It is not. Some inference is simple classification. Is this part defective? Is this transaction suspicious? Is this sound pattern abnormal? Some inference is detection or recognition. Is a person present? Is a vehicle in the wrong lane? Is an asset overheating?

Other inference is more complex. It may require multi-step reasoning, access to enterprise data, historical context, or coordination across multiple systems. A local model may detect an anomaly, but a central cloud workflow may determine whether the anomaly is part of a larger pattern across facilities.

That is where the pipeline model matters.

You might run a small model on a device to filter raw signals. You might send only the interesting events to an edge node for richer analysis. You might send summarized results, metadata, and exceptions to the cloud for deeper reasoning, human review, audit, or retraining. This is a better design than streaming everything to the cloud and hoping bandwidth, cost, and latency stay manageable.

Edge saves more than time

People usually justify edge AI with latency. That is valid, but incomplete. Edge inference can reduce bandwidth costs by filtering data before it leaves the local environment. A video camera generating continuous high-resolution footage should not send every frame to a central cloud if only a small fraction of frames matter. A sensor network should not push every reading upstream if local aggregation can identify what is important.

Edge AI can also improve privacy and compliance. If sensitive data can be processed locally and only conclusions or anonymized features are sent to the cloud, the enterprise may reduce exposure. This matters in healthcare, manufacturing, financial services, government, and retail.

It can also improve resilience. Local systems can continue operating when the network degrades. They may not have access to every central service, but they can still make basic decisions and synchronize later.

This is the point many cloud-only AI strategies miss. Centralization is efficient until it is not.

The cloud still matters

None of this means the central cloud goes away. In fact, the cloud becomes more important, not less. The cloud is where enterprises should manage the larger AI life cycle: model training, fine-tuning, version control, evaluation, observability, policy management, and global analytics. It is often where heavier reasoning workloads belong, especially when they need access to broad enterprise context.

The cloud is also where data from many edge locations can be combined. A single store may see a pattern locally. A manufacturer may see a quality issue at one plant. But the cloud can determine whether the same pattern is emerging across hundreds of stores or dozens of facilities. This is where centralization creates value by turning isolated events into enterprise intelligence.

One architectural mistake is using the cloud for everything. The opposite mistake is pushing too much to the edge. Edge devices are constrained. They have limited compute, memory, power, storage, and management capabilities. They may be difficult to patch. They may operate in harsh environments. They may be physically accessible to attackers.

The cloud should coordinate. The edge should act. Devices should sense and respond.

Model placement is now architecture

Enterprises need to make model placement a first-class architecture decision. That means deciding which models run where, why they run there, and how they are updated.

A small vision model may run on a camera or gateway. A medium model may run on an edge server inside a factory. A larger model or agentic workflow may run in the cloud. Each placement decision should be based on latency, cost, privacy, resilience, accuracy, and operational complexity.

The same applies to data placement. Raw data may stay local. Features may move to the edge. Summaries may move to the cloud. Exceptions may trigger more detailed uploads. Training data may be sampled, anonymized, or transferred under controlled conditions.

This is distributed systems architecture with AI inside it.

Operations will be the hard part

Running AI across device, edge, and cloud sounds elegant until someone has to operate it. Models need to be deployed, monitored, rolled back, and refreshed. Drift must be detected. Edge nodes need secure updates. Devices need identity. Data must be synchronized. Logs need to be collected without overwhelming the network. Security policies must be enforced consistently across environments.

This is where many projects will fail. The demo works because the model runs in one place under controlled conditions. Production fails because there are 5,000 locations, three hardware profiles, unreliable connectivity, different local data patterns, and no clean way to update models safely.

Enterprises should design the operations model before they scale the inference model.

The winners will split the work

The best AI systems will not be cloud-only, edge-only, or device-only. They will divide the work intelligently. Latency-sensitive decisions will happen close to the source. Bandwidth-heavy filtering will happen locally. Centralized reasoning, model improvement, governance, and global optimization will happen in the cloud. This is the architecture that makes AI practical. It reduces cost, improves responsiveness, protects sensitive data, and gives the enterprise a better path to scale.

AI will not become operational because every workload gets sent to the biggest model in the biggest cloud region. It will become operational when enterprises put the right model in the right place for the right reason.

AWS on Thursday launched Kiro bots, generally available within Kiro Crew, its open-source multi-agent development environment, to help developers coordinate parallel coding tasks, maintain context across sessions, and automate recurring software development workflows.

Kiro bots are designed to take responsibility for specific parts of a developer’s workflow rather than execute isolated tasks within individual agent sessions, in turn addressing the growing coordination burden developers face as they increasingly rely on multiple AI agents to handle software development tasks in parallel, AWS said in a statement.

Setting up bots and how do they work

Developers can create a bot by opening the Customize section in Kiro Crew and selecting the “Add a bot” option, where they can choose either a default agent or an existing custom agent as its foundation.

Each bot can be assigned a specific responsibility, such as issue triage, build monitoring, or release readiness, and customized with its own name, avatar, instructions, tools, and permissions based on the tasks it is expected to handle, the hyperscaler said.

Developers can use each bot to launch multiple worker-agent sessions in parallel and have it monitor their progress, redirect those that deviate from the plan, and consolidate their results. If a task requires their input or a decision, the bot can seek their approval while continuing with other tasks that do not depend on it, it added.

To maintain continuity across sessions, each bot also maintains its own persistent memory through a feature AWS calls Notes.

These Notes capture a bot’s understanding of projects, including developer preferences, previously made decisions, project requirements, and constraints gathered through its work and feedback from developers. The accumulated context helps each bot apply the same instructions and judgment to subsequent tasks without developers having to repeatedly explain their expectations, the hyperscaler said.

This persistent context also allows developers to schedule recurring activities through a bot’s chat, such as investigating overnight CI failures every weekday morning or preparing release notes on a particular day, enabling it to apply what it has learned to subsequent runs, the hyperscaler added.

Developers also have the option of inspecting, editing, or deleting a bot’s Notes to refine what it remembers and to shape its behavior for future sessions or tasks, AWS further added.

The hyperscaler is also introducing a feature named Dashboards in Kiro Crew, which will allow developers to describe how they want to visualize a bot’s ongoing activities and reports.

Productivity gains come with a “coordination tax”

The introduction of bots in Kiro Crew could reduce the coordination burden on developers working with multiple AI agents in parallel, shifting their focus from managing individual sessions to overseeing broader development workflows, analysts say.

“Running several agents in parallel can turn the developer into a dispatcher, checking progress, reconnecting context and deciding what happens next. Kiro Bots attempts to take over more of that coordination, resulting in less supervision of individual sessions,” said Stephanie Walter, practice lead of AI stack at HyperFrame Research.

Ashish Chaturvedi, executive research leader at HFS Research, echoed Walter’s assessment, saying that bots in Kiro Crew essentially help enterprises organize AI agents in the same way a well-run engineering team organizes people.

However, orchestrating multiple worker agents through a supervisory bot introduces what Dave McCarthy, group vice president at IDC, terms “coordination tax” primarily because parallel background retries and tool calls can rapidly compound token consumption and compute costs, which CIOs need to be wary of.

CIOs, therefore, should evaluate the productivity gains from bots against their operating costs, according to Walter.

“Ideally, they should start with one bounded process and measure the full result: work completed correctly, developer review time, and operating cost. More activity in the background is not, by itself, higher productivity,” she said.

Moreover, CIOs should rationalize whether all recurring development work needs an AI agent or whether some tasks would be better handled through conventional automation, she added.

“An agent is more useful when the task requires investigation, interpretation, or adaptation to unfamiliar conditions. Customers should ask where the bot adds judgment and where ordinary automation would be simpler, cheaper, and easier to verify,” Walter said.

Auditability and governance concerns

Beyond the cost implications, the growing autonomy of bots could also make it harder for developers to trace decisions made across multiple sessions, Chaturvedi cautioned.

While Kiro allows developers to inspect, edit, or delete Notes and review work logs, explaining why a bot made a particular decision could become more difficult as its behavior evolves through weeks of interactions and feedback, he said.

Different developers could also end up with bots that behave differently based on the instructions and corrections they have accumulated, he added.

Further, Chaturvedi warned of potential permission creep, a scenario arising from bots requesting access to additional tools, with developers potentially becoming accustomed to approving such requests without adequately reassessing the authority granted to the agents. Therefore, CIOs and IT leaders will need to govern bots much like human contractors, with strict identity scopes, budget guardrails, and centralized telemetry, McCarthy said.

Meta has acquired AI coding startup Conductor, gaining technology that coordinates work across competing AI coding agents as it seeks a bigger role in software development tools.

Conductor announced the move on Wednesday, saying it would wind down its existing product while developing a new interface that it plans to introduce in early 2027. The company did not disclose financial terms or provide details about how its technology would be incorporated into Meta’s offerings.

Launched in July 2025, Conductor provides a platform that allows developers to run multiple AI coding agents simultaneously. Its software supports tools including Anthropic’s Claude Code and OpenAI’s Codex, enabling developers to manage coding tasks across different AI systems from a common interface.

The company said it had stopped accepting new users following the announcement. Its cloud service will become read-only on November 13 before shutting down on November 20, when Conductor will begin deleting cloud user data. Existing customers can transfer their cloud workspaces to the local application or export their data.

The local version will continue receiving new AI models and critical bug fixes until early 2027, when it will begin winding down. Conductor said it would delete user data when the application shuts down.

Meta’s strategy for AI coding

Conductor could help Meta establish itself as a provider of AI development platforms rather than competing solely through its own models, according to Lian Jye Su, chief analyst at Omdia.

“The most important differentiator of Conductor is it sits above individual coding agents,” Su said, adding that he expects Meta to maintain its model-agnostic approach.

That would allow developers to continue working with different AI coding systems through a common interface, although Meta has not disclosed whether Conductor’s existing integrations will be retained in the product planned for next year.

Pareekh Jain, CEO of Pareekh Consulting, said Meta may pursue a hybrid strategy, continuing to support third-party AI models while integrating its own more closely with the platform. He said such an approach could improve performance and reduce costs without sacrificing the model flexibility enterprises need to maintain their development workflows.

Su said the broader enterprise shift toward running AI agents in parallel could create an opportunity for Meta to provide the infrastructure needed to support their deployment in corporate environments.

But the acquisition may not immediately put Meta on equal footing with Microsoft, which owns GitHub, or AI coding providers OpenAI and Anthropic.

“It’s a small step, not a game-changer,” Jain said. “Meta still needs enterprise-grade security, governance and integration capabilities to challenge these established players.”

Governance challenges

The shift toward multi-agent development also introduces new complications for enterprises seeking to automate software engineering, particularly when several agents work on the same project.

Developers can assign different coding tasks to agents operating on separate copies of a codebase. Human review before merging changes is an important control point, according to Su, who warned that variations in agent performance could complicate coordination across systems.

Jain said parallel AI agents could accelerate software releases and reduce development costs, although enterprises would need to manage code quality and resolve conflicts when integrating their outputs.

The growing interaction between agents also introduces security concerns. Su warned that additional agent-to-agent communication increases the potential attack surface, while determining responsibility for actions taken by autonomous systems becomes more difficult without continuous human oversight.

Meta could capitalize on growing enterprise demand for reliability, security, and governance capabilities in multi-agent development environments.

Existing Conductor customers face a more immediate decision. Those wishing to preserve their cloud workspaces must transfer them to the local application or export their data before November 20. It remains unclear whether the new interface planned for early 2027 will support the AI coding tools they currently use.

A few years into working with data, I’ve learned that the hardest part of an AI system is rarely the model. Usually it’s the question of who gets to ask what. That question came up for me while building an LLM analytics tool on Snowflake Cortex for healthcare engagement and field-performance data. The tool let people ask questions in plain English, and it cut recurring analytics turnaround from days to minutes. It also made me realize that a fast, accurate answer can still be the wrong answer.

A correct query can still be the wrong one

Most of us test text-to-SQL the same way. We ask a question, check that the query runs, and compare the output to what we expected. That works right up until the answer is correct for the wrong person. Picture a sales rep who types “quarterly sales for my hospitals” and gets every hospital in the region back. The SQL is clean. The result is still a problem, and the same thing can happen in a multi-tenant app, an HR system, or a finance tool.

Start with who is asking

The first change I’d make is to what the model is allowed to see. Before anything is generated, look up who is asking: their role, business unit, territory, and assigned accounts. Then give the model only the tables and columns that person can use. Sensitive fields such as customer IDs, contract terms, or salaries should be tagged in your metadata catalog so they are never offered in the first place. It sounds obvious, but it is easy to skip when a demo is working.

A prompt is not a permission system

It is tempting to add “only show my territory” to the system prompt and move on. I understand the appeal. But a prompt is a suggestion, and the model can ignore it, forget it, or misread it on a hard question. A better setup parses the generated SQL and rewrites it before anything runs, so the rules live in code that the model cannot talk its way around. In the benchmark behind this work, the most common fix across 900 test queries was adding a row filter to the WHERE clause (285 times). Column masking came next (240), followed by scope restriction (165).

Yes or no is rarely the real answer

Most real questions don’t fit neatly into allow or deny. In the same 900 queries, 40% could run unchanged. Another 20% needed a row filter, 15% needed column masking, and 11.7% needed a join rewrite. Around 6.7% went to a human reviewer, and another 6.7% were blocked. Most people still got a useful answer. It was just a safer one, and I think that trade is the right one to make.

Check before it runs, and keep the account small

Validate every query before it executes. Reject SELECT *, pulls that cross scope boundaries, oversized result sets, and risky joins. Then send everything through a gateway that connects with a narrow database account. That way, a prompt injection or a bad generation can’t walk around your rules, even when the model gets creative.

Count the leaks, not just the accuracy

Accuracy numbers can hide a real problem. Plain text-to-SQL returned up to about 80 unauthorized rows on some queries. Static role-based access control still leaked, because it can’t see context. The policy-aware approach leaked none, and it added only about 6.5 milliseconds per query, which nobody will notice in practice. Keep a record of the question, the user context, the policy applied, the final SQL, and the result. When a compliance team asks who saw what and why, you want the answer in minutes, not weeks.

If you’re starting this work

My advice is to decide who the user is before you decide how smart the model is. Get the access rules right first, then tune accuracy. The model will keep getting better at writing SQL. What makes it trustworthy is everything that happens before and after the query runs.

Source note: All results come from a synthetic, de-identified benchmark. No real patient, provider, or commercial records were used. This work is based on “Governed LLM-to-SQL for Pharma Commercial Data,” accepted at IEEE ICICNIS 2026.

Enterprise AI has produced a lot of noise about models, GPUs, vector databases, and agent frameworks. Those conversations matter. But the shift that will decide whether enterprise AI works is happening underneath the models.

For decades, metadata meant documentation. Teams built catalogs so people could find data sets, governance programs recorded definitions and ownership, and lineage helped reconstruct what broke, after it broke.

Metadata described the business. AI expects metadata to run it. That gap is bigger than it sounds.

An AI system doesn’t inherit the years of institutional knowledge a senior analyst holds in their head. It doesn’t know that finance’s definition of revenue excludes returns while sales’ definition includes them. It doesn’t know a customer ID became unreliable after a migration three years ago. It doesn’t know churn got redefined last quarter.

People pick that up over time, usually by getting burned once. AI simply answers using whatever definition it happens to land on, with no burned-once memory to fall back on. That’s what turns metadata from documentation into infrastructure.

Business meaning is now infrastructure

Infrastructure is anything every application depends on without thinking about it: the network, identity, storage. Every application assumes it exists. Business meaning belongs on that list now too.

Every AI application depends on the same definitions of customer, revenue, product, contract, and risk holding steady across systems. When they don’t, AI scales the inconsistency faster than any team of humans ever could.

BI showed us this problem first. Two dashboards would return two different numbers because two tools implemented the same metric two different ways. Most organizations learned to live with it: reconciliation meetings, spreadsheet showdowns, a standing argument about whose report is right.

AI broke the tolerance for semantic inconsistency. A wrong number on a dashboard gets caught by someone in the room. A wrong number an agent acts on can move through automated workflows before anyone notices.

The model reasons against whatever business context it’s handed. Fragmented context produces a confidently wrong answer, and that’s worse than an obviously wrong one. Without governed context, an AI agent is just a fast, well-spoken guesser.

That’s an architecture problem. No amount of model scale changes it. The fix is ensuring every AI system reasons from governed business definitions that stay consistent across the enterprise, regardless of which platform consumes them.

Governance has a new job

Enterprise governance has spent 20 years answering one question: who can access this data? That question still matters. AI raises a second question that’s becoming just as important: what does this data actually mean?

Two analysts with identical access can produce two different numbers if they calculate the same metric two different ways. Most governance platforms document definitions and stop there. Enforcing them is a separate job, and usually a missing one.

Most enterprises got here by combining multiple metadata tools into an assembled solution: the right tool bought for each symptom, at a different point in time. A lineage tool to reconstruct what broke. A catalog for discovery. A governance platform for policy. A semantic layer for BI. None of them were designed on a shared foundation.

Each purchase solved its own slice and kept its own copy of what things mean. Four tools later, the work is funded in four places, owned in none, and measured nowhere, and the enterprise is still asking the question it started with.

AI makes that gap harder to ignore. A model uses whichever definition it finds first and sounds equally confident either way, blind to the conflict between them. Confidence is a property of the model, independent of whatever business logic sits underneath it.

Governance needs to reach past access control. It needs to connect business definitions to the systems that implement them, with ownership, version history, and lineage attached. A glossary entry and the system enforcing that definition should never drift apart.

When the documented definition of a metric differs from the one the applications actually execute, governance becomes an administrative exercise instead of an operational capability. AI simply exposes that gap faster than any previous technology, making it impossible to ignore.

Vendor neutrality just became a strategic call

Something else is shifting at the platform level. Every major cloud vendor now ships some version of governance, metric definitions, or AI context natively. That’s genuine progress, and enterprises should expect it.

Almost no enterprise lives inside one vendor’s perimeter though. Most run multiple clouds, a stack of legacy applications, SaaS tools, several BI platforms, and AI services from more than one provider. Each platform optimizes for its own world.

Business definitions must be able to travel across all of them. If every platform keeps its own version of what things mean, organizations rebuild the same fragmentation, only now it sits further inside AI workflows, where it’s harder to catch.

A vendor-neutral metadata architecture solves a different problem than any single vendor’s platform does. When business definitions can move with the enterprise rather than remain trapped inside individual platforms, organizations gain strategic flexibility instead of accumulating another form of lock-in.

Ownership stays with the enterprise, independent of which technology happens to consume those definitions. That means never having to redefine the business every time the infrastructure changes.

As AI ecosystems keep shifting, holding onto ownership of business meaning matters as much as holding onto ownership of the data itself.

Where this goes over the next five years

Metadata management is entering its second generation.

The first generation was about discovery: find the data sets, document who owns them, build the catalog. Necessary work, still running in most enterprises today. It’s no longer enough on its own.

The second generation is about execution. Metadata will shape how AI systems reason, how analytics platforms calculate metrics, how governance policy is applied, and how organizations prove the provenance behind a decision a machine made on their behalf.

That takes a different design: lineage, cataloging, governance, and business definitions all drawing from one shared metadata foundation. Business context becomes one operational model that every consuming system reads from directly.

Business definitions will start looking a lot more like software too. Version-controlled. Moved through development pipelines. Impact-tested before deployment, the same way a code change gets tested before it ships. AI agents, analytics platforms, databases, and applications will all read the same governed definitions.

The discipline has a name, MetadataOps, and a role to go with it. A MetadataOps engineer owns the path a business definition takes to production the way a platform engineer owns the path code takes. The role sits upstream of context engineering: context engineering decides what reaches an agent’s window, and MetadataOps decides what exists to be retrieved in the first place.

Enterprises build and maintain business meaning as an engineered asset, with the same discipline as everything else running in production. The real breakthrough here is enterprises finally giving context the same engineering discipline they’ve spent years giving code, infrastructure, and security.

For two decades, metadata explained the enterprise after the fact. The next decade will depend on metadata guiding it before decisions are made.

—

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.

MariaDB on Wednesday said it was adding four new agent-focused capabilities to Enterprise Platform 2027, the latest version of its enterprise database platform, to help developers retrieve enterprise data faster, maintain agent memory across sessions, and reduce the cost and latency of repeated model queries.

These new capabilities include AI Retrieval, AI Plugins, Agent Memory, and Semantic Cache.

While AI Retrieval is designed to help agents access information from enterprise documents and live operational data through a single managed service, AI Plugins are designed to bring MariaDB-specific expertise into coding agents such as Anthropic’s Claude Code and OpenAI’s Codex, helping developers generate database-related code more accurately, the company said in a statement.

AI Retrieval also converts natural-language questions into read-only SQL queries, which MariaDB said would eliminate the need for developers to manually write queries for every request.

Agent Memory, meanwhile, provides agents with a persistent, in-memory store that allows them to retain information across sessions and resume tasks without having to rebuild their context each time, according to the company.

Semantic Cache, the fourth capability, is intended to reduce response times and AI inference costs by identifying semantically similar questions, even when phrased differently, and reusing previously generated answers instead of processing each query from scratch, MariaDB said.

AI retrieval simplifies data access, but raises reliability concerns

For developers, AI Retrieval can increase productivity, said Ashish Chaturvedi, executive research leader at HFS Research.

“Most RAG setups keep documents in a vector store and live records in the transactional database, with glue code deciding which to query and how to merge results. Putting both behind one managed service eliminates a component and a sync step, so agents read operational facts at the moment they are true,” Chaturvedi added.

That consolidation, in turn, for CIOs would mean reducing cost and complexity, particularly for MariaDB-centric enterprises, as it can retire a separate vector database and sync pipeline, shrinking licensing, operations, and the number of places sensitive data lives, Chaturvedi further said.

However, he cautioned that the natural-language-to-SQL capability could face reliability challenges when dealing with complex enterprise databases.

“Reliability is likely to drop with sprawling schemas, cryptic column names, complex joins, and business terms that lack documented definitions. If you ask for ‘active customers’ and the model has to guess what that means, it is likely to produce plausible but different numbers,” Chaturvedi said.

“The capability is likely to become dependable only when paired with curated business definitions and testing against real user questions,” he added.

AI plugins require oversight

Similarly, the AI Plugins capability is likely to boost developers’ productivity, said Michael Leone, principal analyst at Moor Insights and Strategy.

“Coding agents tend to write for the databases they know best, so teaching them MariaDB is smart. General models, typically, know standard SQL but still trip on MariaDB-specific syntax and newer features like vector search,” Leone added.

However, Chaturvedi cautioned that CIOs should not assume that database code generated by AI coding agents is inherently reliable or secure.

“AI-generated code should undergo the same review, testing and security scanning as code written by human developers, with particular attention to SQL injection risks, excessive database permissions and agent-proposed schema changes, which can be difficult to reverse,” he said.

“CIOs should also track which AI tools generate specific pieces of code to help development teams identify recurring errors and address weaknesses in their coding workflows,” he added.

Agent memory and caching bring efficiency, but add risks

Agent Memory and Semantic Cache, too, could also help enterprises improve the efficiency of AI agents, although both capabilities introduce considerations around data management and reliability.

While without Agent Memory, every agent session starts from scratch, wasting tokens and increasing the risk of inconsistent decisions in long-running processes, CIOs need to ensure that the memory is governed through clearly defined ownership, retention policies and access controls, as it could contain personal and commercially sensitive information subject to privacy regulations, Chaturvedi said.

“Outdated memory could also cause agents to act on incorrect information, such as superseded supplier terms or customer preferences. Enterprises would therefore need mechanisms to expire or correct stored information, isolate memory across users and protect it against deliberately planted false entries,” he added.

Similarly, Semantic Cache could deliver substantial compute and AI inference cost savings, particularly for workloads involving relatively stable information, such as helpdesk queries, HR policies and product FAQs.

However, the benefits are likely to be more limited for personalized or analytical queries, where users’ requirements and underlying data frequently change, Chaturvedi said.

“Mainly because it is extremely difficult to judge similarity between questions. For instance, questions about a company’s refund policy and its refund policy in Germany might appear similar but require different answers. Similarly, two users asking the same question may be entitled to different responses depending on their access permissions,” he explained.

CIOs should therefore classify workloads based on how frequently their underlying data changes and the potential consequences of an incorrect response, caching more aggressively only where both risks are low, he added.

They should also monitor cache hit rates alongside answer accuracy to ensure that cost savings do not come at the expense of user trust, he further added.

For enterprises looking to adopt the new capabilities, MariaDB Enterprise Platform 2027 has been made generally available, although the AI Retrieval capability will enter public preview on MariaDB Cloud later this month.

The platform includes MariaDB Enterprise Server 12.3, MariaDB Exa, MariaDB GridGain, MariaDB MaxScale, MariaDB Enterprise Manager, and the MariaDB Enterprise Kubernetes Operator.

Enterprises have the option of running it on-premises, in any cloud or as a managed service on MariaDB Cloud, the company said.

htmx lets you add rich functionality to web pages without writing JavaScript. But it also lets you integrate JavaScript if you need it, either by adding functions in-line to elements or by writing more complex hooks for events.

These behaviors let you take web pages that already use JavaScript, and either migrate to htmx entirely or add htmx only where it’s needed — for instance, in new parts of an application.

Generally, htmx works best with green-field applications, since you can start with a non-interactive page and just layer in the behaviors you want as they’re needed. But htmx can also work as an add-on for a page that already uses JavaScript, or as a migration target away from existing JavaScript.

Using htmx with JavaScript

When you want to integrate htmx with hand-rolled JavaScript, htmx offers you several ways to do it. Some are extremely basic, but tightly coupled to the objects they work with. Others are more advanced and flexible, but require more work to use.

Using hx-on attributes

A basic way to add JavaScript behaviors to objects is through a very htmx-like mechanism, the hx-on attributes. Add one of these to a given object and you can provide code or function calls inline. For example:

<button hx-on:click="console.log(`${this} clicked`);">
    Click here to log to the console

The inline code can be a whole code block, as shown here, or a function call to your own code.

One advantage of using hx-on is consistency with other hx- attributes. If all your existing interaction is powered by htmx, adding more hx- attributes for custom functionality keeps things uniform. On the other hand, if you want your custom functionality to be mechanically distinct from htmx, consider the approach discussed next: registering callbacks.

Using the htmx API

The more complex way to “wire up” JavaScript functionality for htmx-enabled pages is to use the htmx object and its methods. With htmx you can register callback functions for any behavior.

The htmx object provides a set of interfaces for triggering htmx behaviors on objects in the DOM. Three of the most commonly used interfaces:

• htmx.on() adds an event listener to an object, in much the same manner as the hx-on attribute does. The main difference is that adding an inline attribute typically requires changing how you render the object (e.g., from a server-side template).
• htmx.onLoad() registers a callback to run whenever new content is added to the DOM by htmx, after htmx has already processed it. This way, content loaded dynamically via a fetch action can be wired up in some custom way. Normally, anything loaded by htmx that contains hx- attributes will automatically be wired up, but this allows you to do that for “plain” content with no hx- attributes.
• htmx.ajax() issues a custom htmx request, the results of which are processed by htmx and inserted into the DOM.

All the behaviors htmx exposes through attributes can be triggered manually though the API. So, if you wanted to, you could skip wiring up objects by adding hx- attributes, and instead use the API via your own JavaScript code.

To some degree this defeats the purpose of htmx. But there may be cases where you will want to start using htmx without annotating objects, at least at first (for instance, to avoid making immediate changes to your HTML templates).

Using hx-live and the q() function

htmx 4 introduced a new feature called hx-live, which allows you to select objects using a query function, q(), and perform operations on them using a syntax similar to that used for hx- attributes.

You can think of q() as a less verbose way to run document.querySelector() on the current page, then work with the returned objects. Most of what you would do with q() involves DOM manipulations where the behavior of one object affects many others. For instance:

<button hx-on:click="q('.item').toggle('.selected')">
    Select all
</button>

Clicking the button would locate every element on the page with the class item and toggle the presence of the class selected on that element.

q() exposes a few other methods in the same vein:

• take() removes a class or attribute from selected elements, then adds them to the element making the call. It’s a convenient way to perform an action on everything but the given element (e.g., all other buttons in a div but this one).
• trigger() dispatches a given event to everything matching the query. It includes options for keeping the event from bubbling if needed.
• insert() adds HTML within or around selected items.

What’s important about q() is that you can use it entirely outside of htmx attibutes, as part of your own custom-written JavaScript functions or callbacks. You could even begin adding htmx functionality to a page by using only q() and its behaviors, hand-in-hand with JavaScript, then build outwards from that to replace a site’s legacy functionality with htmx over time.

Using htmx with Alpine.js

As a rule, front-end web frameworks shouldn’t be mixed, the better to minimize side effects and unpredictable behaviors. If you use htmx to add reactive behaviors to a page, you will get the best results if htmx (and whatever JavaScript you integrate with it) is the only source of reactive behavior.

Still, htmx makes provisions for working hand-in-hand with other ways to add reactivity. Aside from hand-written JavaScript, you can integrate the Alpine.js library.

Alpine.js is a JavaScript library with a similar philosophy to htmx. WIth Alpine, you can add behavior to elements in a web page by adding special attributes that begin with x-. For instance, x-on:click would add some behavior to an element when clicked.

It isn’t hard to see how this behavior could conflict with htmx, or vice versa. But htmx comes with an extension, hx-alpine-compat, that ensures Alpine behaviors are consistently enabled and kept active in components handled by htmx.

InfoWorld’s Matt Tyson has explored in detail how htmx and Alpine.js can complement each other.

Using htmx with server-side libraries

Back-end web frameworks are by definition front-end agnostic. You don’t tend to see a web framework favor, say, Boostrap or Alpine.js, because that just limits the potential audience and creates unnecessarily tight couplings between front end and back end.

But some web frameworks do offer supplementary support for specific front ends, including htmx. Django and FastAPI have third-party libraries that provide convenience features for developers building HTMX-powered front-ends. Jinja2, the templating language used with many back-end frameworks, has a third-party extension called Jinja2 Fragments that makes it easier to render templates in part so only the relevant bits can be supplied for an htmx fetch operation.

One of the more recent Python web frameworks, Litestar, has native htmx support. This allows you to render htmx-specific templates that are automatically populated with htmx-specific attributes such as target elements or event names.

The big appeal of htmx is how it sidesteps the inherent complexities of JavaScript. It gives you the vast majority of the interactive functionality you need for a web page by way of declarative HTML syntax. At the same time, htmx leaves the door open for JavaScript integration, for working hand-in-hand with Alpine.js, and for web frameworks that elect to work more closely with htmx’s simplified approach.

Something strange is going on in the job market for software developers. 

Everyone is worried that their job is going to go away and businesses are going to turn software development over to the machines. Few dispute that agents write good code. I’ve even argued that our days of writing code are pretty much over. 

Sure, agents are writing the code, but we aren’t quite ready to turn the whole thing over to agents. We are still feeling the need to supervise what they do, look closely at the code they write, and serve as gatekeeper for what gets checked into Git. 

We can do this because we are seasoned, experienced developers, with hundreds of thousands of lines of code under our belt, and we’ve seen it all. We can spot bad designs, inefficient algorithms, and code smells. If the agent isn’t doing things the right way, we can spot the problem and correct it. 

Coders of hard knocks

And how did we become seasoned, experienced developers? We started out writing bad code that was reviewed — probably first by a high school teacher or college professor, and later by senior devs. Or maybe we just wrote a lot of sloppy code and learned it was sloppy by reading, studying, and gaining experience on our own. But however it happened, it was more or less “learn by doing.” 

But we aren’t “doing” anymore. So the question becomes, how is anyone going to learn to code if we don’t code? It doesn’t take advanced calculus to realize that if we don’t teach early-career developers how to develop software, then we will lose all the expertise in the profession as time relentlessly marches forward. 

The classic example of a job that AI promised to take was radiology. The thinking was that AI can look at an x-ray and see the problems as well as or better than any human — often spotting problems that humans would overlook. The demise of the profession was predicted, but the opposite has occurred as demand and salaries for radiologists have risen. 

And this raises an interesting question. To become a radiologist, you need to go to medical school for four years, and do an internship and a residency. And let’s not forget the four-year undergraduate degree. 

But how do you become a seasoned software developer? If the job is going to become “Review this code an agent wrote for accuracy, good design, and correctness,” then how does one acquire the knowledge and experience to be able to do that job?

Senior developers wanted

The training to become a radiologist involves looking at thousands of existing x-rays and learning what those x-rays reveal. The students have a specific curriculum designed to teach them everything they need to know. Their first real-world experience is under close supervision. It’s a time-tested system that trains radiologists in a proven and effective way long before they have to diagnose the maladies of actual patients on their own. 

Interestingly, we don’t have any such training program for software developers. We don’t show them fully designed systems with flaws in them, pointing out what the problems are, and teaching them to understand bad code and why it’s not right. Instead, we just throw them into the deep end and say “Well, here’s a Jira ticket, get to work, and we’ll tell you how you screwed up.” 

Sure, you can go to a boot camp or get a computer science degree, but those places mainly just teach you the basics, or take you somewhat beyond the basics. There really isn’t a place where developers learn what is and isn’t good code except on the job, struggling in the deep end until they can swim laps. There is no equivalent to “Here are a thousand x-rays and what is wrong with them.”

The job market for software developers is bearing this out. Sure, the numbers are going up, but 71% of that growth is companies looking for senior developers. Good for us grizzled veterans, but you can only hire so many senior developers before the lack of hiring junior developers comes up and bites you in the rear end.

So if junior developers stop writing code, how will they become senior developers?

That, my friends, is the question of the day. 

Snowflake is hoping to improve the reliability of AI agents with a new tool called Business Ontology, as part of its Horizon Catalog, meant for data discovery, management, and governance.

Horizon Catalog received a boost in June with the launch of Horizon Context, a set of semantic and metadata management capabilities to help enterprises collect, enrich, and organize metadata across their data estates and give AI agents a better understanding of enterprise data, its relationships, and how it is used.

Business Ontology builds on that foundation by allowing enterprises to define and approve business concepts, assign owners to those definitions, and link them directly to the underlying tables and views, Snowflake said in a statement.

That, in turn, should give enterprise AI agents access to authoritative business definitions, such as what constitutes net revenue, rather than relying on competing interpretations of the same data across different systems, it added.

Business Ontology also offers enterprises a way to define and approve business meanings and relationships that have not been formally documented.

Typically, enterprises subscribed to Snowflake have had to rely on Cortex Sense, Snowflake’s AI-powered business context engine, to infer these meanings from available metadata and usage patterns, which may not always reflect the intended business definitions.

With Business Ontology, enterprise users would now be able to review, formalize, and approve these definitions, ensuring AI agents use business-validated meanings rather than relying solely on AI-generated inferences, the company said.

Business Ontology could simplify agent development

For developers, Business Ontology can reduce the effort and time required to stitch context for agents or agentic applications as they no longer have to bake business logic into every agent they build, said Ashish Chaturvedi, executive research leader at HFS Research.

Primarily because agents can draw on the centrally maintained definitions in Business Ontology, allowing developers to reuse the same business context across multiple agents and applications, Chaturvedi added.

This, in turn, could also reduce inconsistencies between agents interpreting the same business data differently, while making it easier to develop and maintain agentic applications as business requirements evolve, echoed Michael Ni, principal analyst at Constellation Research.

For CIOs, that same ability to establish a common set of business definitions could make it easier to scale AI agents across departments without having to worry about different agents interpreting the same business data differently, Chaturvedi said.

However, he warned that keeping business definitions current could still be challenging for enterprises.

“Each core term needs a named owner, a review whenever pricing, products, or reporting rules change, and a link to the data behind it, so a schema change prompts someone to check the definitions that depend on it,” Chaturvedi said.

That process might be further complicated by the fact that different departments may define the same business concept differently.

“Sales, finance, and operations, for instance, may have different interpretations of what constitutes a customer or revenue, based on their respective business requirements. Enterprises will need to decide whether to reconcile these differences into a common definition or retain them as separate, clearly identified terms, a process that requires agreement across business units,” Chaturvedi said.

Business Ontology, according to Snowflake, is expected to be available in public preview soon.

New controls to monitor and govern agent activity

Beyond establishing a common understanding of enterprise data, Snowflake is also adding capabilities to Cortex AI Gateway, its agent control layer, to help enterprises oversee how AI agents execute tasks, access data, and consume resources.

These include Cortex Sandboxes and Agent Trace Intelligence, which provide agents with isolated environments to execute custom code alongside enterprise data and allow developers and data teams to examine agent execution traces against business data, respectively.

For developers, Cortex Sandboxes are likely to increase productivity, Chaturvedi said: “It takes away a chore most developers would happily skip, which is setting up a safe place for agent-written code to run. Today teams either build and secure their own containers, copy data somewhere else, or simply don’t let agents run code.”

“Sandboxes start next to the data, follow the permissions of whoever launched the agent, and shut down once the job is done, so developers can build agents that write and run analysis code without managing servers or juggling credentials,” Chaturvedi added.

That, in turn, for CIOs, should reduce risks, especially in terms of any damage an agent could do, as it will run in a walled-off secure environment, according to Ni.

This means that while an isolated environment can limit the impact of faulty or malicious code on surrounding systems, it does not necessarily prevent an agent from misusing data or access rights that the user is already authorized to exercise.

For Chaturvedi, however, the bigger concern for CIOs is ensuring that the code executed by agents produces accurate and reliable results. While sandboxing can limit the damage caused by faulty or malicious code, it does not validate the logic used or the accuracy of the output, he said.

Both Cortex Sandboxes and Agent Trace Intelligence are currently in private preview.

Alongside Cortex AI Gateway’s capabilities, Snowflake is also introducing Agent Abuse Detection to help enterprises address security concerns around agents.

For its part, Agent Abuse Detection can help enterprises identify agents operating beyond their permissions, such as attempting to bypass approval processes or accessing sensitive data, the company said. It is currently in private preview.

Most enterprises went into cloud computing with the idea that flexibility was part of the deal. Move faster. Scale on demand. Pay for what you use. Avoid long procurement cycles. Stop buying hardware that sits around waiting for peak demand. That was the promise, and much of it was real.

However, many enterprises also made an assumption that turned out to be only partly true: If you need to leave a cloud provider someday, you can. Technically, yes. Practically, not always. In many cases, the way systems are designed, deployed, secured, integrated, and operated makes leaving a provider expensive enough that the option is more theoretical than real.

This is where cloud exit architecture comes in.

Cloud exit architecture is not a plan to abandon the cloud. It is not a rejection of native cloud services. It is not a return to the old days of pretending everything should run the same way everywhere. It is a discipline for designing systems so they can move when pricing, regulation, outages, geopolitical concerns, vendor strategy, or business priorities change. That sounds boring until the day you need it. Then it becomes the most important architecture decision you did not make.

Portability is a business requirement

Enterprises usually talk about portability as a technical goal. That is too narrow. Portability is a business risk control. If a provider changes pricing, if a region becomes unavailable, if regulations require data to move, or if a major outage exposes concentration risk, the business needs options. Those options should not require a two-year rewrite and a budget that shocks the board.

The mistake many organizations make is waiting until there is a reason to leave before thinking about how leaving would work. By then, every dependency is already buried in production systems. Identity is tied to one provider’s access model. Data is stored in proprietary services with provider-specific formats or APIs. Networking is built around cloud-specific constructs. Infrastructure-as-code templates are full of assumptions that only work in one environment. Monitoring, logging, secrets, key management, and deployment pipelines all depend on the same control plane.

At that point, you are not really using the cloud. You are being used by it.

Identity should travel

Identity is often the first portability problem and the last one architects think about. Many systems depend too heavily on provider-native identity services without creating a clean abstraction. This works fine until the organization needs to move workloads, support multiple clouds, or satisfy a regulatory requirement that changes where authentication and authorization must occur.

The better approach is to design identity so it can travel. That usually means using standards-based federation, such as SAML, OAuth, or OpenID Connect, and keeping enterprise identity anchored in a place that is not inseparable from one cloud deployment. It also means separating human identity, workload identity, service-to-service identity, and authorization policy.

Too many systems mix these together. A service account, a cloud role, a permissions boundary, and an application authorization decision become a single tangled mess. It works, but only in one place. A good exit architecture makes identity understandable outside the provider. Who is the user? What is the workload? What can it access? Where is that policy defined? Can those rules be represented somewhere else without reverse-engineering the whole application? If the answer is no, the system is not portable.

Data is the real trap

Compute is usually easier to move than data. Data has gravity, governance, cost, and format problems. Enterprises love managed databases, object stores, analytics platforms, and AI data services because they remove operational burden. That is fine. The problem starts when organizations stop thinking about how data would be extracted, transformed, validated, and rehydrated somewhere else.

Cloud exit architecture requires clear thinking about data formats, metadata, lineage, encryption, retention, and replication. If the only usable form of your data lives inside a provider-specific service, you have a portability problem. This does not mean every database must be open source or self-managed. That is another extreme and usually a bad one. It means architects should understand the exit path before choosing the service.

Can the data be exported in standard formats? Are schemas documented outside the platform? Are encryption keys controlled in a way that allows migration? Can another system consume the data without rebuilding every pipeline? What is the cost of moving it? How long would it take? How would you verify correctness? These questions are the difference between strategic flexibility and cloud captivity.

Networking decides how stuck you are

Networking is where many exit plans go to die. Applications rarely live alone. They connect to users, partners, data centers, SaaS platforms, APIs, message brokers, security tools, and other cloud services. Over time, the network becomes a map of assumptions about where everything lives. If that map is specific to one cloud provider, moving becomes painful.

Good exit architecture uses network design that can be reproduced. Addressing should be planned, not improvised. Connectivity should be documented. DNS strategy should support movement. Traffic management should avoid hard-coded endpoints. Private connectivity should be designed with alternatives in mind.

Enterprises also need to think about egress costs and latency. A system that is technically portable but financially impossible to move is not portable in any meaningful way. The architecture should make clear which data flows are expensive, which dependencies are latency-sensitive, and which workloads must move together. Cloud networking is not just plumbing. It is the skeleton of the exit plan.

IaC should describe intent

Infrastructure as code was supposed to make environments reproducible. In many enterprises, it made provider lock-in executable. Teams write templates that perfectly describe one cloud environment and nothing else. They use provider-specific modules, assumptions, policies, naming patterns, and deployment workflows. Again, this is not inherently wrong. Native tools are often the best way to use a platform well.

The problem is pretending this is portable because it is code.

Good infrastructure as code should separate intent from implementation where it matters. The architecture should define the required capabilities: compute profile, network exposure, storage durability, database behavior, identity model, observability requirements, and recovery objectives. Then provider-specific implementations can map to those capabilities.

This does not require a lowest-common-denominator platform. In fact, that approach often produces bad systems everywhere. The goal is not perfect portability. The goal is understood portability. You should know what is easy to move, what is hard to move, what would need redesign, and what you deliberately choose to bind to a provider because the value is worth it.

Native services are not the enemy

Some people hear “exit architecture” and assume it means avoiding cloud-native services. That is not the point. Using native services can be the right decision. Managed databases, event systems, security services, AI platforms, and serverless capabilities can provide real value. The issue is not whether you use them. The issue is whether you understand the dependency you are creating.

Lock-in is not always bad. Accidental lock-in is bad.

If a provider-native service saves millions in operational cost or gets a product to market faster, use it. Just document the trade-off. Define the exit cost. Identify alternatives. Make sure the business understands that the decision creates both value and dependency.

Ever since Stephen O’Grady’s The New Kingmakers, we’ve all been trying to figure out how to appeal to developers. Now we’re going to have to figure out how to appeal to their agents. AI agents, after all, increasingly write our code and decide which tools, libraries, etc., to use in writing that code. This means that although developers still own the application, it’s often the agents that own the decisions that factor into building that app.

So how do we deal with this?

Software vendors and open source project leaders must make their technology understandable and usable by an agent. Developers and their employers, meanwhile, should make sure an agent’s default reflects what they actually want.

A recommendation is already a decision

Richard Seroter recently pointed to research challenging the comforting-but-false assumption that people reserve important decisions for themselves while the agent “writes the code, runs the numbers, and offers advice,” as the research’s authors note. Anthropic studied 50 professional analysts working with agents given secretly randomized preferences. Across four analytical choices, participants followed the agent’s guidance 86% of the time. For people like me who may not be good at math, that translates to “nearly always.”

A technology recommendation can work the same way. By the time a developer inspects an application’s dependencies, the agent may have built enough working code around its initial choice that changing course means discarding progress. At that point, it’s easier to just stick with the agent’s pick (and developers are all about convenience).

This is a plausible consequence of agent-assisted development, but it’s not yet clear how this will impact enterprise purchasing. Supabase, for example, has done interesting work with documentation, skills, and more to ensure agents and LLMs see, understand, and recommend Supabase. But this isn’t the same as signing a purchase order. Even so, technologies can enter a project long before money changes hands and can help steer that money in certain directions.

Just because the agent or LLM recommends certain technology, however, doesn’t mean it’s doing so effectively. As Microsoft developer advocate Waldek Mastykarz argues, first you should determine if an agent picks up on your tech to answer a given prompt. Second, you should check to see whether it’s answering accurately. He therefore suggests you test the first with tasks that don’t name your product and test the second with tasks that do.

Write for the work the agent attempts

There is already evidence that people can influence which tools an agent uses. The more interesting problem, however, combines deep human understanding of a particular task to inform agents how to fix a bad plan.

Microsoft’s Garry Trinder described such a situation in June. An agent upgrading a SharePoint Framework project kept editing package versions manually. The actual upgrade required other changes, which the CLI for Microsoft 365 could handle. A more direct documentation tip got the agent to use the CLI in only one of five runs. Explaining that changing package versions alone would produce build failures got the agent to use the tool in all five runs.

Five runs per condition is a small test, and this was tool selection within an existing Microsoft project, not a contest among cloud vendors. Even so, it’s a concrete example of documentation changing an implementation choice. The writer understood why the agent’s approach was wrong and put that explanation where the agent encountered it. It’s the best kind of agentic-era documentation.

Supabase has reported a related problem. Agents knew about its platform but still missed security requirements and guessed at commands. In its account of building agent skills, the company says agents sometimes skipped separate reference files so it moved critical security guidance into the main instructions. It also directs agents to current documentation rather than relying on remembered APIs.

These are changes to what agents read and when they read it. They require people who know the product well enough to recognize a plausible but dangerous implementation. Producing another hundred pages of fluent product description wouldn’t fix that problem.

For a database vendor, the useful material might be a tested path from a customer’s existing schema to a working application, including permissions and failure recovery. For an API company, it might be an example that handles retries without charging twice. The commercial value comes from removing a specific reason the developer’s project would fail, so that it doesn’t fail.

Treat content as part of the product

The human work also continues after the first instructions ship. Products and projects change, yet a new model may be stuck interpreting old information.

Google’s Remigiusz Samborski recently described the company’s approach. Changes to Google Agent Skills require versioning, evaluation evidence, automated checks, AI review, and approval from a human subject matter expert before export to GitHub. An instruction edit is treated as a change in behavior that needs testing. That’s a useful model for developer marketing and documentation teams because their output often determines the long-term go-to-market success of a product.

I’ve written that enterprise AI needs people who can turn business understanding into something a system can use. The same applies to vendors trying to earn an agent’s recommendation. Someone has to select representative customer tasks, identify meaningful failures, and decide which limitations must be made explicit. AI can help generate and run the tests; it doesn’t make the choice of tests commercially or technically neutral.

One useful discipline would be to include cases where the product shouldn’t win. Most vendors are loath to tell the world not to use their product, but when done well, it’s a great way to earn trust with developers (and their employers). For example, in the early years of MongoDB, cofounder Dwight Merriman insisted on having a page that identified where the database was excellent, but also where it wasn’t. Those use cases have changed as the product has evolved, but it’s good practice for any vendor or open source project. For example, does the agent recognize an unsupported deployment requirement, or warn about a cost that matters at the customer’s scale? A vendor that measures only how often its name appears may end up burning trust if effective answer engine optimization (AEO) directs its tech to be built into applications where it’s likely to fail.

The developer also has work to do here. For example, stating the constraints before asking for a recommendation and asking what evidence would favor a different choice. Where the decision matters, examine alternatives before the agent has built an application around one. These practices don’t guarantee independence, but they give the developer a better opportunity to exercise it.

Earn the choice

If all this sounds like search engine optimization (SEO) gamesmanship, well, that’s because it is. We call it AEO now and vendors have every incentive to make their products the default. Agents may reward familiar technologies, persuasive instructions, or material that happens to be easy to retrieve. This is one reason open source projects tend to get recommended most: It’s simply easier with open source to build ubiquity of documentation and other support materials.

There is a real opportunity here for people who understand developers’ problems. They can make product knowledge usable at the moment an implementation decision is made, instead of hoping a developer remembers a webinar from six months ago. But earning adoption requires more than influencing the first recommendation. The software needs to work, and the people using it need to understand why it fits.

An agent may choose your product. Your job is to give your human customer a sound reason to keep that choice.

I recently moved my own setup from one coding agent to another. It took about 10 minutes and I thought it went well.

The first agent had a lot to carry. Today it has a global instruction file, 114 skill folders (most installed, a few written by me), 189 small memory notes spread across 24 projects and 73 scripts that shell out to its command-line tool. To give a second agent the same footing, I copied the instruction file to the name the other tool reads, AGENTS.md, and ran a find-and-replace on the product name.

I didn’t read the result properly until this month. It tells the new agent to make every model call with Codex -p. In that CLI, -p is short for –profile. Followed literally, my instruction loads a configuration profile named after whatever prompt it was handed. The same file still warns the new agent, in bold, never to use the old vendor’s API key, a key it had no reason to go near. Nothing errored. The file sat in my home directory for almost three months looking like a finished migration.

That is the exit problem in miniature. I could switch models in an afternoon. The work didn’t come with it, and nothing told me.

Portability claims stop at the model

Vendors have learned to answer the lock-in question. Ask about switching and you hear about model choice, standard protocols and conversation export. InfoWorld has already made the case that the new AI lock-in lives in the layers around the model rather than in the model. The standards side is moving too. MCP and AGENTS.md now sit under the Linux Foundation’s Agentic AI Foundation, which is good news for the plumbing.

None of that tells you whether a half-finished job survives a change of agent.

An agent that has worked in your codebase for six months has picked up things that are neither the model nor the transcript: decisions it was told to respect, approaches it tried and dropped, changes it made, changes it only planned and the permissions and hooks wired around it. Exporting a conversation gives you a record of what was said. It doesn’t give you the state of the work.

Regulators have noticed the general shape of this. The EU Data Act’s cloud switching rules have applied since September 2025, and from January 2027 providers can’t charge customers for the switch itself. Those rules were written for data processing services. How they’ll be read for an agent’s working state is anyone’s guess, and I wouldn’t plan a procurement around it being settled in your favor.

The exit test

So test it yourself before you sign or renew. The drill takes a day and one realistic task.

Pick maintenance work that needs memory. The example I’d use, and this is illustrative rather than a study I’ve run, is upgrading a logging library across a service with a dozen modules. Partway through, a human decision changes the plan: the team agrees to keep the old log format for one downstream consumer, which reverses an assumption the agent made on day one.

Let the first agent get about halfway. It has migrated seven modules, skipped an eighth on purpose because of that decision and left a note saying why. Stop it there. Ask the product to export whatever it says represents the work, meaning requirements, decisions, completed actions and remaining steps. Hand that export, and only that export, to a second agent. A different vendor’s agent is the real test. A fresh session with no access to the first one’s memory is the minimum.

Then watch what the second agent does with it. Four things matter.

1. Does it redo finished work? If it re-migrates the seven modules, the export recorded intent and lost completion. Repeated changes are cheap in a logging upgrade. In a schema migration, they are an incident.
2. Does it bring back a retired assumption? This is the failure I care about most. If the second agent helpfully “fixes” the module the team deliberately skipped, the export carried the original plan and dropped the decision that overrode it. A handoff has just undone a human call, and nothing in the build will flag it, because the code is perfectly consistent with the plan that no longer exists.
3. How long does a human spend rebuilding context? Time it with a stopwatch. Every question the engineer has to answer from memory is state the export didn’t hold.
4. What broke on the way over? Instruction files that name one vendor’s commands. Skills written in one tool’s format. Hooks that fire on one tool’s events. Credentials scoped to one product. Write each of these down. That list is your real switching cost, and in my experience it is longer than anything in the contract suggests.

Run the drill twice. Once inside the same product, a new session picking up the old one’s work, and once across vendors. The first tells you whether the product’s own continuity is real. The second tells you what leaving costs.

Don’t let the vendor pick the task. Every product has a demo path where its memory looks flawless, and it is usually a greenfield feature with no history and nobody’s earlier decision to trip over. Keep the task boring enough that nobody argues about the right answer. The question isn’t whether the second agent writes good code; most of them will. It’s whether the agent knows which code it shouldn’t write. Your logging upgrade, with its one awkward exception that exists only because someone said so in a meeting in March, is the case that matters. If your task doesn’t have an awkward exception, add one. Real projects are full of them, and they are exactly what a transcript export loses first, because they were decided out loud and written down in a single sentence that nobody tagged as a requirement.

Ask the vendor to show you, not tell you

Ask them to run the drill on your task, live, using the export format they would actually hand you on exit. Ask what that export contains, field by field, and whether decisions and completed actions are stored separately from the chat log. Ask whether their memory and skill formats are documented well enough for another tool to read. Ask what happens to that state on the day the contract ends: how long you have, in what format and at what charge.

A vendor that trusts its product should be happy to do this. The serious ones have thought about it already, because their larger customers have asked. If what you get back is a slide about open models and a link to a protocol spec, you have learned that their exit story covers the model and not your work.

Score it like a test, not a feeling

Record the result the way you would a test report. Task, export size, changes repeated, retired assumptions brought back, human minutes, broken dependencies. File it with the contract and run it again at renewal. Products change between versions, and the export you tested last year may not be the one you’d get today. I made the same argument in my last column about green AI testing dashboards: a check you never re-run is only a memory of a check.

One caveat, in fairness to vendors. Some of this state is genuinely hard to move. A skill tuned to one model’s habits won’t behave the same on another even if the file format is perfect, and no export standard fixes that. The exit test isn’t meant to prove a switch would be free. It’s meant to put a number on the cost while you still have leverage to negotiate it.

The part I’d rather not admit

My own exit test failed, and I wrote the instructions on both sides. I knew both tools. I had both files open. I still produced a migration that looked complete and would have pointed every model call at a configuration profile that doesn’t exist.

That was one person with full access to both systems and every reason to get it right. At renewal, most teams will be in a worse spot, with the outgoing vendor holding the state and very little reason to make the export good.

A malicious version of Anthropic’s Claude Code extension distributed through the Cursor marketplace attempted to install a persistent Secure Shell (SSH) backdoor on developers’ machines, potentially giving attackers remote access to systems holding source code, credentials and other sensitive information.

“Between about 2:27am PT and 1:35pm PT today, a maliciously modified version of Anthropic’s Claude Code extension was made available in the Cursor VS Code Extension Marketplace,” Cursor said in a security notice.

Cursor removed the compromised versions, 2.1.312 and 2.1.313, after discovering they had been available in its VS Code extension marketplace for approximately 11 hours on October 29.

The company said the malicious code attempted to add an attacker-controlled SSH key, enable local SSH access, and establish a reverse tunnel to an attacker-controlled server.

“These malicious versions of the extension were not developed by Anthropic,” Cursor added in the notice. The affected versions were available for Windows and macOS.

Anthropic subsequently clarified how the tampered extension had been distributed. In a post on X, Felix Rieseberg, a member of Anthropic’s technical staff, said the incident did not involve a compromise of Anthropic’s systems or employee laptops. A malicious actor had used access to Cursor’s marketplace to publish the modified extension, he said.

“The versions on our official channels are not affected, and this only impacts Cursor users,” Rieseberg wrote. Anthropic said it was working with Cursor on the incident.

Cursor and Anthropic had not responded to requests for comment by publication time.

Malware ran without user interaction

Security company Phorion, which analysed the compromised extension, found that malicious code had been inserted at the beginning of its JavaScript file. It ran as soon as the extension loaded, before its normal activation code.

“The user doesn’t need to interact with the extension for the payload to fire,” Phorion said.

The malware attempted to add an attacker-controlled SSH key to the user’s authorized_keys file and establish a connection to a remote server. It also created scripts and startup entries intended to keep the connection available after a system restart, the company added.

Phorion identified a flaw in the macOS code. The malware tried to check whether Remote Login was disabled using a system command that required administrator privileges. When run without those privileges, the command returned an access error rather than the expected status. The malware consequently skipped the attempt to enable SSH.

Phorion also found an error in the Windows code that could prevent its SSH service setup command from running correctly.

Microsoft Threat Intelligence, in a separate analysis, detailed the information the malware collected, including machine names, usernames, operating systems, working directories, and Git email addresses.

“It also looks for environment-variable names containing terms such as KEY, TOKEN, SECRET, PASS, AWS, or GCP, keeping up to forty matches,” Microsoft wrote in the analysis. It said the code collected matching variable names, not their values.

Removing the extension may not be enough

Cursor said enabling the local SSH service would generally fail without administrator privileges on affected Windows and macOS machines. However, the extension could still add the attacker’s SSH key, install persistence mechanisms, and send host information to the attacker.

The company warned that uninstalling the extension alone might not remove these components because the malware placed scripts outside the extension’s installation directory.

Steve Povolny, vice president of AI strategy and security research at Exabeam, said the planted SSH key made cleanup particularly important. “Removing the extension only sends the visitor away while the spare key stays on the hook,” he said.

Povolny recommended checking authorised SSH keys on machines accessible to affected developers, rotating potentially exposed credentials, and reviewing logs for logins using unfamiliar keys. Developers often have access to source code, cloud accounts, and production systems, he said, making a compromised workstation a potential route to other enterprise resources.

Phorion also advised checking the SSH key’s fingerprint rather than relying only on the comment svc-telemetry attached to it.

Questions raised about extension security

Yash Kadakia, founder and CTO of Security Brigade, said enterprises should treat extension marketplaces as part of the software supply chain.

“An extension marketplace is effectively another software supply chain,” Kadakia said. “When malicious code can reach developers through what appears to be a legitimate, routine update, the traditional assumption that software from a trusted marketplace is safe starts to break down.”

He recommended stronger publisher verification, checks on package integrity, and controls over which extensions and versions developers can install.

Kadakia also called for extension allowlisting, controlled updates, endpoint monitoring, and restrictions on outbound connections. He said short-lived credentials, segregated development environments, and limited access to sensitive infrastructure could reduce the impact of a compromised developer machine. Cursor said it removed the malicious versions, temporarily shut down its marketplace, audited access, rotated keys, and rebuilt the marketplace before restoring the service.

The article originally appeared on CSO.

Same question, a different answer

Earlier this year, in Are AI certifications worth the investment?, I argued that AI certifications ranked among the highest-return investments an IT professional could make. Much of that case still holds. But the ground has shifted since I wrote that piece in February, and a responsible update has to say so plainly.

Two of the six flagship credentials I recommended can no longer be earned. Cloud vendors retired them in favor of exams built around generative AI and agents. Model makers and governance bodies have launched entirely new credential families. And employers, buried under AI-polished resumes, have grown more skeptical about what any single credential proves.

My updated verdict: AI certifications are still worth it, but for narrower reasons, for more specific roles and with a shorter shelf life than I suggested in the spring. The value has moved away from the badge itself and toward what the preparation forces you to build. For CIOs, that shift should change how training dollars get spent.

The great certification reset

The biggest change since spring is not a new credential. It is the disappearance of old ones.

Amazon Web Services gave its last Machine Learning Specialty exam on March 31, 2026. In its place, AWS built a role-based ladder that runs from the AI Practitioner through the Machine Learning Engineer Associate to the new Generative AI Developer Professional, which came out of beta this year. AWS also refreshed its Security Specialty exam with dedicated coverage of generative AI and machine learning security. Existing ML Specialty holders keep the credential through its original expiration date, but no one new can earn it.

Microsoft moved even more aggressively. On March 6, 2026, it announced the retirement of seven certifications and the launch of nine AI-focused replacements. The Azure AI Engineer Associate (AI-102), which I featured in the spring, retired on June 30. Its successor, AI-103, leads to the Azure AI App and Agent Developer Associate and centers on Microsoft Foundry, retrieval-augmented generation and agent orchestration. AI-900 gave way to AI-901, the Azure Data Scientist exam was replaced by a new MLOps credential and the venerable Azure Developer Associate became an AI cloud developer exam.

The pattern matters more than the exam codes. Both vendors concluded that credentials built around training models from scratch no longer reflect how enterprises actually work. Most teams now consume foundation models through managed services and spend their effort on integration, retrieval, evaluation, security and agents. The new exams test exactly that.

There are two practical lessons. First, the shelf life of an AI credential is now measured in quarters, not years. Anyone who began preparing for AI-102 or the ML Specialty after reading articles like mine had to rush or start over. Second, many job descriptions and HR requirement lists still name retired exams. A posting that asks for AI-102 is describing a skill set, not a credential anyone can still obtain.

Two new categories worth watching

Model vendor certifications

In the spring, the major AI credentials came from cloud platforms, academic programs and professional bodies. That changed on March 12, 2026, when Anthropic launched its Claude Certified Architect, Foundations exam alongside a Claude Partner Network backed by a $100 million investment. In July the company expanded the program to four role-based credentials covering everyday users, developers and two levels of architects, and reported more than 36,000 consultants certified across more than 1,300 organizations. List prices run from $99 to $175.

Model vendor credentials carry real weight in one specific setting: consulting and partner firms, where certified headcount determines partner tier and client credibility. For an enterprise practitioner, the calculus is different. Model leadership changes quickly, and a credential tied to one model family is a bet on that vendor remaining central to your stack. If your organization has standardized on a model, these exams are inexpensive and tightly scoped. If it runs a multimodel portfolio, as most do, a platform or governance credential will travel further.

The governance stack

The gap my spring article underplayed was governance. As regulation tightens and boards ask harder questions, organizations need people who can audit, secure and manage AI risk, not just build with it. IAPP research from 2026 found that only 1.5 percent of organizations feel fully satisfied with their AI governance staffing.

Three credential families now address that need:

• IAPP Artificial Intelligence Governance Professional (AIGP). Launched in 2024 and refreshed in February 2026 with expanded coverage of agentic AI and ISO 42005, it costs $649 for IAPP members and $799 for nonmembers. It suits privacy, legal and compliance leaders.
• ISACA’s advanced AI credentials. AAIA targets auditors, AAISM targets security managers and AAIR, launched in April 2026, targets enterprise risk owners. Each requires an existing credential such as CISA, CISM or CISSP, which makes them extensions of established careers rather than entry points.
• ISO/IEC 42001 Lead Auditor and Lead Implementer. These are the certifiable credentials for organizations building formal AI management systems.

For security, audit and risk professionals, these programs offer something engineering certifications cannot: a direct link between AI and the accountability frameworks executives already trust.

What the money says now

The headline compensation data has only grown stronger. PwC’s 2026 Global AI Jobs Barometer, which analyzed more than one billion job advertisements across 27 countries, found that the average wage premium for AI skills rose to 62 percent, up from 57 percent a year earlier. Jobs requiring specific AI skills grew 69 percent, compared with 9 percent for the overall job market. The premium varies widely by sector, from as high as 118 percent in consumer markets to 16 percent in government.

Read those numbers carefully, though. PwC measures a premium for AI skills demonstrated in the job market, not for AI certifications. That distinction is the most important refinement I would make to my spring article. Several of the certification-specific salary figures I cited then, including premiums of 23 to 47 percent, came from training and exam-prep sites that have a commercial interest in the answer. They are directionally consistent with the broader data, but I would no longer lean on them. Payroll-based benchmarks such as Ravio’s, which showed a 12 percent premium for individual contributors in AI roles and 3 percent for managers, remain the soberer anchor.

The PwC data also reveals where the jobs are. In the UK alone, almost 66,000 new AI roles went to “AI user” positions inside existing business functions, while roles focused on AI development added just 2,600. The bulk of the opportunity sits with people who apply AI in finance, operations, security and customer work, not with those who build models. That argues for broad literacy and governance credentials reaching far more of the workforce than engineering certifications ever will.

PwC’s leaders framed the winners as companies using AI to amplify human expertise, and the report found employers placing more weight on judgment, creativity and leadership. A certification can document AI fluency. Only experience supplies the expertise and judgment it is meant to amplify.

What hiring managers actually check

Employer surveys released this year paint a more nuanced picture than the salary headlines.

Western Governors University’s Workforce Decoded 2026 report found that 60 percent of hiring professionals say AI is making it harder to evaluate candidates’ real skills. When they assess AI skills specifically, 41 percent look at hands-on, real-world experience with AI tools, while 34 percent look for certifications. Certifications matter, but they rank second.

Resume Genius’s 2026 survey of 1,000 U.S. hiring managers points the same way. Eighty-two percent said certifications can be as valuable as a bachelor’s degree. Yet when asked how they prefer candidates to demonstrate AI skills, only 15 percent chose certifications or courses, and AI and machine learning ranked sixth among priority skills, behind communication, critical thinking, domain knowledge, project management and data analysis.

Put those findings together and a clear role emerges for certifications in 2026. They help a candidate clear the filter and earn the interview. Verification happens afterward, through work samples, technical conversations and references.

There is a counterintuitive upside here. When AI can polish any resume and draft any portfolio narrative, a proctored exam is one of the few signals a language model cannot fake on a candidate’s behalf. Rigorous, scenario-based, proctored credentials may gain credibility precisely because so much else on a resume has lost it. Unproctored completion certificates will likely move the other way.

An updated decision framework

Before committing 80 or more hours to any AI credential, I now suggest four tests:

1. Does your stack or target employer name it? A credential matched to the platform you run every day beats a prestigious one for a platform you never touch.
2. Is it proctored and scenario-based? Exams that test architecture decisions and trade-offs signal more than recall-based quizzes.
3. How current is it, and what is the vendor’s retirement track record? Check when the exam was last revised and whether holders get a renewal or upgrade path when it changes.
4. Will the preparation leave you with something to show? The best programs end with a working project you can demo in an interview. That artifact often outlasts the credential.

Applied to today’s market, those tests point to different choices by role:

The largest group, the many employees who use AI inside their daily work, may not need a paid certification at all. Free vendor academies from Microsoft, AWS, Google and Anthropic now cover practical AI fluency well.

What CIOs should do with training budgets

For IT leaders, the 2026 churn carries a budget lesson. A certification program designed in 2025 may already be funding exams that no longer exist. Here is how I would reshape it:

• Fund ladders, not badges. Tie certifications to the platforms and models your organization actually runs, and map a progression from literacy to practitioner to professional level.
• Budget for churn. Assume a 12- to 24-month useful life for technical AI credentials. Favor vendors that offer free renewal assessments or clear upgrade paths, and reserve funds for re-certification.
• Require a deliverable. Pair every funded certification with a project that solves a real internal problem. You get a working prototype, and the employee gets the portfolio evidence hiring managers now look for first.
• Audit your job descriptions. Remove retired credentials such as AI-102 and the AWS ML Specialty from postings, promotion criteria and vendor contracts, and describe the underlying skills instead.
• Invest in governance talent now. The staffing gap in AI governance, audit and risk is wider than the gap in engineering. Sponsoring existing security, audit and privacy staff into AIGP or ISACA credentials is often faster and cheaper than hiring.
• Scale literacy for free. Use vendor academies for the broad workforce, and reserve paid exams for roles where the credential carries market or contractual weight.

Treated this way, certification spending becomes a structured upskilling program with measurable outputs rather than a reimbursement line item.

The bottom line

In the spring I wrote that the real question was not whether AI certification is worth it, but which credential best positions you for the role you want. That still holds. Six months of retirements, launches and hiring data add two more questions: when, and for how long.

The market rewards AI skills more than ever, with a 62 percent average wage premium and AI-skill jobs growing nearly eight times faster than the overall market. Certifications remain one of the clearest ways to signal those skills and to structure the learning behind them. But they now expire faster, matter most when matched to a specific stack or accountability, and carry the most weight when backed by work a hiring manager can see.

Choose credentials that fit the work you do today and the platform your organization runs. Treat the preparation as the real product. And expect to do it again sooner than you think.