On July 16, Hugging Face disclosed that an autonomous agent system had breached part of its production infrastructure. Five days later, OpenAI identified its own models as responsible. Its subsequent investigation described agents operating under reduced safeguards, exploiting flaws in shared infrastructure, and reaching the internet through a package-management service. They exchanged discoveries on an improvised message board and coordinated further attacks.

Likewise, on July 30, Anthropic reported three incidents across six of 141,006 evaluation runs reviewed. Models had reached real organizations through environments mistakenly believed to be isolated. In one incident, a malicious software package was downloaded and ran on 15 real systems. In August, Meta confirmed to Reuters and other outlets that a misconfigured evaluation environment had allowed one of its models to reach the internet and exploit a third-party service.

In September, an OpenAI agent bypassed network restrictions by sending questions through internet address lookups. Monitoring raised an alert, but the run did not stop automatically as expected. Staff stopped it roughly two and a half hours after the alert.

The concern extends to ordinary tasks. In an October 9 report, Anthropic described models submitting real forms when they should have stopped beforehand or used practice copies. The company characterized the reported impact as minimal. Still, a form submission is the kind of action an enterprise agent might perform every day.

The incidents discussed above involved different failures of containment, authorization and intervention. They do not establish that one completion check would have prevented them; yet, they do give CIOs a reason to examine both sides of an agent workflow. Indeed, what governance rules permit an agentic action, and what evidence allows an organization to call it complete?

Permission is not proof

An agent calls a tool, the tool returns “success,” and the workflow moves on. That response might mean a request entered a queue, or it might mean a record changed. It may say nothing about whether the intended result occurred or whether this particular action produced it.

That ambiguity matters when other systems act on the completion signal. For instance, an invoice could leave an exception queue while the settlement remains unconfirmed. A misleading status can conceal the need for follow-up or trigger another action. Business owners need to decide what evidence is sufficient before the workflow proceeds.

Finance departments separate payment execution from reconciliation for a reason. NIST’s separation-of-duties control, AC-5, similarly calls for documented duties and access authorizations that support their separation. Applying that discipline to AI requires more than asking the acting agent to review its own work.

I developed the proposed Common Transparency Protocol (CTP) framework to make that distinction enforceable and have filed a provisional patent application covering aspects of its architecture. CTP’s central rule is that autonomous systems performing a change cannot, by themselves, certify the action as complete.

A deployment that enforces CTP places a controlled gateway between agents and the consequential operations it governs. A gateway holds the relevant execution credentials and enforces scope, authority and any required human approval before execution. Afterward, a qualified verifier obtains fresh evidence from the designated authoritative source. A qualified closure authority then accepts that evidence and records completion only when every required condition passes.

These roles can be implemented in software. Human approval and review remain mandatory where the applicable policy requires them. Using a second AI agent does not itself establish independence, for its credentials, selection and controlling dependencies must meet the separation requirements.

What verified completion looks like

Consider a hypothetical accounts-payable workflow. A workflow instructs an agent to pay an approved invoice. Before execution, authorized policy defines the payee, amount, required approval, settlement evidence and how that evidence must connect to this specific payment attempt. The agent cannot weaken those requirements afterward.

The gateway submits the authorized payment. A response saying “accepted” records the submission; it does not establish settlement. A reconciliation service, selected outside the control of the systems making the payment, uses separate read credentials to consult the authoritative payment record. It checks the amount, recipient, settlement status and transaction identifier linking the result to the governed attempt. A matching amount alone could describe an earlier payment.

A separately qualified completion service acts as the closure authority. It confirms that the evidence, verifier and authority requirements are satisfied before assigning the action’s final status. Neither the agent nor the payment gateway can grant itself that status.

If the effect or its attribution remains unresolved at the deadline, the original action closes as incomplete. Later evidence goes into a separate, authorized record linked to the original. The current outcome can then reflect the resolution while preserving the earlier uncertainty. A retry that could move money requires its own authorization and record.

Independence is tested across the relevant systems that performed or controlled the change. Policy identifies prohibited shared credentials, administrative control or other dependencies. One prohibited overlap disqualifies the verifier or closure authority; missing evidence cannot count as a pass. Shared infrastructure is permissible only when all required separation rules remain satisfied.

These controls govern completion within the deployment’s defined boundary. They do not repair an unmediated network path, guarantee that a source contains truthful data or reverse a payment already made. Containment, monitoring and incident response remain necessary.

Keeping delegated work accountable

CTP connects the overall assignment to individual actions through two kinds of machine-readable records, called envelopes. The CTP Agentic Envelope records the objective, permissions, aggregate risk and completion rules. Action Envelopes, of which there can be zero to many, record the governed steps, including authorities, evidence and original final status.

Integrity protections make any changes to protected records detectable, though they do not establish the capture of every relevant event. Therefore, the organization must also define which actions its gateway actually mediates.

When an agent delegates a sub-objective to a sub agent or another agent, a linked child envelope carries the applicable constraints. Delegation may narrow permissions but cannot silently expand them. Splitting work among agents cannot reduce the safeguards required for their combined effect.

An authorized mechanism applies the objective’s completion rules to the current outcomes of its subordinate actions, including later authorized resolutions. The coordinating agent cannot override those rules with its own success assertion. This keeps accountability attached to the assignment as work passes between agents.

What CIOs can do now

Start with one bounded workflow and an authoritative system that can supply useful evidence. For a payment pilot, the finance process owner should define completion and acceptable exceptions. The CIO’s team should implement the integrations, and the CISO should assess the sufficient separation of execution, verification and closure events. Internal audit should review whether the resulting records support reconstruction.

Agree on the decision criteria before the pilot begins. Measure verification delay, cost per action, the share of actions left incomplete, and human review effort. Test delayed responses, duplicate requests, stale evidence and attempted self-certification. Expansion should depend on meeting agreed service limits while refusing completion whenever mandatory evidence or authority is missing.

The pilot should also establish what happens operationally when an action remains incomplete. Assign an owner to investigate it, define which dependent actions must wait, and specify when human intervention is required. Recording uncertainty is useful only if the organization has a practical way to resolve it without blindly repeating the original action.

Ask vendors to demonstrate where execution credentials reside, who selects the verifier, and which component can record completion. Request a demonstration of an unresolved action and its later reconciliation. An architecture diagram or a dashboard labeled “success” is insufficient evidence of these capabilities.

We tested a CTP proof of concept across seven internal scenarios.  These included successful completion, incomplete and denied outcomes, tampering and VistA scenarios with and without audit evidence. All seven scenarios produced the expected results. These demonstrations provide initial evidence of CTP’s viability within the tested scope. Broader testing is still needed to assess production-scale reliability, performance and operating costs.

Before giving an agent more authority, ask what evidence your organization will require when it says the work is done, and who has the right to accept that evidence. Those decisions belong in the system’s design.

At a Fortune 100 bank, I watched a coding agent open a routine session on a payments service. Before the developer typed a word, the agent had read the repository, including the .env file. Production database credentials had entered the agent’s working context, potentially exposing them to a model provider the bank had never assessed. Whether the credentials left the environment depended on controls nobody had verified. Nothing malicious happened. The agent did what it was built to do. That is the problem.

My argument is simple. AI coding-agent vendors and their downstream dependencies form a supplier ecosystem, not just another developer tool. They need the same four control disciplines applied to other privileged suppliers. Govern vendor terms and downstream dependencies. Limit the secrets they hold. Approve the servers they connect to. Restrict where they can send data. Much of this builds on existing controls, though an enterprise may need a governed gateway or platform service. It requires procurement, security and engineering to recognize a supplier when they see one.

In May, I wrote about how agentic AI is rewiring the SDLC. This is the security half of that argument.

Adoption has outrun control

On Aug. 28, OpenAI told SpaceX, Cursor’s new owner, that it intends to stop supplying models to Cursor, with Nov. 12 proposed as the cutoff. Cursor CEO Michael Truell said OpenAI models carry about 5 percent of its traffic, DevOps.com reported, so the operational risk is small. The governance lesson is not. Enterprises that standardized on Cursor learned they depended on a downstream model supplier whose terms they did not directly control and a change of ownership they had not planned for.

That gap is now the norm. Coding agents are developers’ most common AI use, and investment is accelerating. Governance is not keeping pace, and emerging evidence of credential exposure underscores the gap.

Vipin Jain

The agent was bought as a seat and installed as a supplier

What I see most often is a category error. The coding agent was bought as a seat and installed as a privileged integration. Within its assigned permissions, it can read repository content, encounter credentials, invoke tools, access networks and connect to Model Context Protocol (MCP) servers. A contractor with that access would go through vendor risk review. The agent went through a one-line install.

Drawn as a supply chain, the developer stack looks different. The agent sits between your code and direct and downstream dependencies you may not have assessed: model providers, plugin marketplaces, MCP registries, package managers and the open internet. Each can be acquired, compromised or switched off. Verizon’s 2026 DBIR finds third parties involved in 48 percent of breaches, and source code is the data most often sent to external generative AI.

Vipin Jain

Four controls were never applied

Across the programs I advise, the exposure lands in the same four places.

1. Contract. At a healthcare payer, the agent vendor switched model providers mid-contract. No clause covered it, because the seats had been bought on a corporate card below the procurement threshold. No one had asked where code would be processed or what happens on a change of control.
2. Secrets. At the bank, credentials reached the agent’s context because the required access restrictions were not configured; that alone does not establish external transmission. Claude Code’s managed settings, for example, can deny reads of .env files in a way developers cannot override. Nobody had configured them because nobody owned them. Gartner predicts that by 2028, a quarter of enterprise security breaches will trace back to AI agent abuse rooted in unmanaged machine privileges and legacy credential practices.
3. Servers. At a specialty retailer, developers installed 23 MCP servers in one quarter. Security had approved none. Two could write to the CRM. My rule is simple: the team accountable for the underlying data approves its MCP access, while platform security verifies server provenance and enforces permissions before any agent connects. The retailer had it backward: each server belonged to whoever installed it. Astrix found late last year that 53 percent of open-source MCP servers rely on long-lived static keys or tokens. In June, CSO Online described Mitiga research showing how one malicious npm package can rewrite an agent’s MCP configuration and harvest its tokens. Anthropic deemed it out of scope because it requires code the user chose to run. That is a fair vendor position. It also means the control is yours. Few of the MCP servers in use at most enterprises were built by the team that owns the underlying system; most come from vendors, partners or public registries. Allow only security-assessed, approved servers; verify provenance, enforce least privilege and monitor supported interactions through a centrally governed MCP gateway.
4. Egress. On a state Medicaid program, the build environment where agents ran could reach any public endpoint. This July, an autonomous agent in OpenAI’s own evaluation sandbox exploited a zero-day in one of its permitted egress paths, a package-registry cache proxy, and reached Hugging Face’s internal systems. If a frontier lab’s allowed path became the way out, an unrestricted build network is an open door. In late October, CIO.com reported two more containment lapses at OpenAI and Anthropic. The fix is unglamorous: restrict shell execution, isolate agent runtimes, govern MCP connections through an approved gateway and enforce default-deny network egress. Every AI-initiated change should pass through verified CI/CD gates, with rate limits, spending controls and an emergency stop.

The failure sits between functions, and attackers have found it

None of these is a model failure. Procurement saw a low-cost seat. Security reviewed the vendor, if anyone did, but not the plugins, servers and model providers behind it. Engineering saw a productivity tool. Each function did its job, and the agent fell between all three.

The exposure is measurable. In IBM’s 2026 Cost of a Data Breach report, unapproved AI tools figured in 43 percent of incidents in its studied breach population, more than double the previous year. Among organizations reporting breaches involving AI models or applications, 92 percent lacked what the study classified as proper AI access controls. The average breach now costs $4.99 million, a record.

Attackers now target the same seams. On Sept. 18, CSO Online reported Plugin4Shell, a zero-click remote code execution flaw in the plugin systems of Codex, Claude Code, Gemini CLI and Copilot. Anthropic and OpenAI have patched. GitHub’s mitigation was reported as incomplete at disclosure, and Google deprecated Gemini CLI rather than patch it. In April, Vercel disclosed a breach that entered through Context.ai, a third-party AI tool an employee had connected. In August, the self-spreading npm worm GitGuardian tracks as ChainDrop planted a Claude Code SessionStart hook and a VS Code task in infected projects, so the malware ran the moment a developer opened the repository or started an agent session. The attack surface is the update channel, the plugin, the connected tool and the network path. That is supply chain risk, and CIOs already have a playbook for it.

Regulators already treat this as third-party risk

Few rules name coding agents. Few need to. Existing third-party and software supply-chain obligations can apply, depending on the regulated entity, service and deployment context.

The common thread is inventory, contract terms and exit rights. An agent bought outside procurement can bypass all three.

Standards and vendors have moved; procurement has not

Over 15 months, incidents and controls arrived side by side. The OWASP Top 10 for Agentic Applications lists agentic supply chain vulnerabilities as ASI04. The Coalition for Secure AI recommends signature verification and a central inventory for MCP servers. CISA, the NSA and four allied agencies, in Careful Adoption of Agentic AI Services, warn against third-party components with excessive permissions. Vendors are shipping matching controls, from Salesforce’s MCP Risk Scores to Okta’s newly announced Shadow AI Agent Discovery for Endpoints.

The analyst market reached the same conclusion from the buyer’s side. Gartner’s first Magic Quadrant for Enterprise AI Coding Agents, published in May, named Anthropic, Cursor, GitHub and OpenAI as Leaders. In the announcement, analyst Philip Walsh listed governance, pricing, support, commercial maturity and market durability alongside model quality as tests for long-term commitments. Market durability is a procurement test, not a developer one. Three months later, one of those Leaders was losing a model supplier.

In October, the firm went further, and it changed one piece of my advice. At its IT Symposium in Orlando, Gartner named the AI coding agent harness one of its top strategic technology trends for 2027 and said CIOs should give ownership of it to a dedicated platform team. In every program above, the controls existed somewhere. What was missing was one owner. A category with a Magic Quadrant is enterprise software. Buy it that way, and give it an owner.

Here is what that platform team builds. Next year the most demanding customer of your internal platform will be coding agents, not developers. An enterprise-governed harness is the versioned policy and configuration that adapts the vendor-provided agent runtime to your environment: rules files, skills, enforcement hooks, verification gates, tool permissions and sandboxes. The platform team supplies approved tools, MCP allowlists, sandboxes and scoped credentials, and developers declare the harness they need as versioned configuration. That design answers the Cursor problem directly. A declared harness makes an agent or model change more manageable, provided compatibility and regression tests pass; a well-tailored harness may also improve results on a midtier model. An organization that owns its harness can change suppliers. One that rents it cannot.

The harness must also govern what the agent produces. AI-generated changes should follow the same trusted delivery path as human-written code: automated security testing, dependency verification, code review, build provenance and controlled production deployment.

5 moves for the next 90 days

The fix begins with supplier-risk review and configuration work, not necessarily a new platform purchase. Give all five moves to one accountable owner, the platform team that runs your coding agent harness, while procurement, security and infrastructure retain clear decision rights and operational accountability. Sequence matters: inventory first, because every other move depends on knowing what is installed.

1. Inventory, owned by the CIO and procurement. List every coding agent, plugin and MCP server and who installed each. Done when every approved tool has an owner, a supplier or risk-acceptance record, and its models and downstream dependencies documented.
2. Contract, owned by procurement and legal. Add model-provider disclosure, change notice, change-of-control and exit terms. Done when each enterprise-approved agent has documented contractual terms or an approved open-source/self-hosted exception, downstream visibility and a tested exit plan.
3. Secrets, owned by the CISO. Deny agent reads of .env and credential files through managed settings and move secrets to a vault. Done when agents hold only short-lived, scoped credentials.
4. Servers, owned by platform engineering and security. Maintain an internal MCP registry and mediated access to security-assessed, approved servers. Done when every approved server has verified provenance, a named owner, scoped permissions and activity logs, and write access to systems of record goes through change control.
5. Egress, owned by infrastructure. Default-deny outbound traffic across agent shells, tools and build runners; run agents in isolated sandboxes and govern release promotion through CI/CD. Done when only explicitly approved destinations are reachable, exceptions are monitored and isolation is tested.

Two details make the difference. Reconcile the inventory against expense reports, not just license records; card statements usually tell the truer story. And write the contract assuming change: the Cursor notice proposed 76 days, and the next one may run shorter.

The takeaway

The most common mistake I see this year does not look like one. Teams are adopting coding agents fast, and they are right to. But they are buying a supplier ecosystem as if it were a developer tool, and governing it like one. Governed properly, a coding agent can earn greater autonomy with scoped identities, approved dependencies, controlled execution and a trusted route to production.

Put three questions to your team this week.

You would never give a contractor unrestricted production access on day one. Coding agents should meet the same standard.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects. 

On November 1, 2026, Grok Bot users gave IT buyers a live example. Subscribers reported that their weekly usage allowance ran out sooner than expected, and Elon Musk wrote on X that the cost of serving Grok Bot was “unsustainably high relative to revenue.” He confirmed it was not a glitch, but he did not say how the limits would change.

The cost of running the service is the seller’s problem. The allowance that a buyer thinks they bought is the buyer’s.

Grok Bot is a consumer product, but any team that buys metered AI plans faces the same exposure. The allowance can shrink or run out early, and the overrun lands in a department budget. This example shows what a price page does not tell a budget owner: the rules and limits behind the allowance can matter more than the price. Your AI bill will not look like your last software bill. Seats are no longer the whole story, and the line item that finance approved in January may not describe what you are actually buying in June.

The price page is also a poor guide. Stanford’s 2025 AI Index found that the cost of inference at GPT-3.5 level fell more than 280-fold between November 2022 and October 2024. Yet the FinOps Foundation’s State of FinOps 2026 survey found that 98 percent of respondents now manage AI spend, up from 31 percent two years earlier. Cheaper units have not made the bill easier to predict.

I recently published research on how AI companies publish their prices. I read the public pricing pages and documentation of the Forbes AI 50 and a set of cloud platforms that sell AI services, captured in mid-September 2026. The goal was to describe what is on the page, not to judge whether any price is fair. The finding that matters most for a budget is not the pricing model. There are four rules attached to the credit allowance: expiry, rollover, minimums and recharge.

What the pricing pages show

Classic software charged per seat because serving one more user cost almost nothing. Model inference is different. Every request has a real cost, and usage can differ by orders of magnitude from one customer to the next. Pricing has moved to follow that cost.

The most common model among AI-native companies is a subscription with a usage credit allowance. Sixteen of the 29 companies whose pricing I could observe use it. The allowance is usually counted in credits, compute units or generation time. The flat tier price is the headline. The credit balance is where the real limit lives.

Many companies publish nothing at all. Twenty-three of the 52 AI-native companies in the sample show no pricing, and about half of those show a call to contact sales instead. Every cloud platform in the sample did publish its prices.

Model APIs split on when you pay. Of eight model API and inference providers, two require prepaid credits that draw down as you use them. The other six bill after the fact. Established products tend to keep the per-user price and add a meter on top, with an allowance for AI use and a higher rate once you pass it. Pricing by outcome appeared only in customer service, where a resolved conversation is easy to observe and agree on.

Four rules that decide what an allowance is worth

Most budgeting advice stops at the pricing model. The part that changes your bill sits one level below, in the rules attached to the credit allowance. In my sample, plans with the same shape differed on four rules.

1. Expiry. Some free credits expire every month, and prepaid balances on a model API can carry an expiration too. Unused allowance is not an asset. A quiet month does not bank value for a busy one.
2. Rollover. One media tool lets unused time carry over and a comparable one does not. Two plans at the same price cost a team with uneven demand very different amounts.
3. Minimums. A customer service product that charges per resolved conversation also sets a monthly minimum of 50 resolutions. A vector database service sets a minimum of $50 per month. The unit price is not your floor. The minimum is.
4. Recharge. A prepaid balance can top itself up when it runs low. That protects the service and removes a natural pause point. A cap in your spreadsheet is not a cap in the billing system.

These are illustrative cases from the pricing pages. Others have seen part of this. Flexera warns that credit expiration, reset, and rollover rules “can silently create overages or strand value”. Zuora notes that prepaid credit packs give the seller working capital. Read from the buyer’s side, a prepaid pack is money you advance to a supplier, subject to expiry rules. The pricing pages show how widely those rules differ, and the difference is where a budget goes wrong.

What I would do with this as an IT leader

The rest of this article is my own personal, practical view. It is not a finding from the study. It comes from building and running billing systems.

• Split every AI line into fixed and variable. A single line called “AI tools” hides what you need to see. Put the subscription in one line, the usage allowance in a second and the overage you might incur in a third. When someone asks why the cost rose, you should be able to say which of the three moved.
• Ask what the allowance is counted in, then ask four more questions. Tokens, requests, credits and compute time are not interchangeable, and one supplier’s credit is not another’s. Ask what one unit buys. Then ask what expires, what rolls over, what minimum applies and what recharges automatically. Get the answers in writing next to the contract. If the supplier cannot state them, treat that as a risk you must price in.
• Budget a range with a ceiling, not a single number. Heavy users can use far more than typical users, so the average is a poor guide. Pick one typical user and one heavy user for each workflow and estimate the cost of each. That gives you a low case, an expected case and a ceiling. Rework recommends setting a monthly cap and alerts at 50, 75 and 100 percent of it before anyone starts using a metered feature. I agree with the order. Then check whether the supplier enforces your cap or only sends an email. With auto-recharge on, the cap in your budget may not exist in the system.
• Give each workflow a named owner. Apu Pavithran calls AI credits that the company pays for, but decision makers cannot see “shadow tokens”. An owner per workflow is the plainest fix. Keep the fixed subscription apart from the extra usage charges. Where you must estimate how to share a cost, say that it is an estimate and write down the method. A central AI budget can also be the right choice, as long as finance can see which teams depend on the work before anyone cuts it.
• Plan for prices to change. Public pricing in the AI era has moved quickly. One widely used developer tool changed its pricing in June 2025 and clarified the change two weeks later. Put a review date on every AI contract and ask what happens to your terms if the supplier reprices.
• Insist on usage data that matches the invoice. When the dashboard says one number and the invoice says another, someone has to explain the gap, and it will be you. Before you sign, ask for a sample invoice and the usage export that goes with it. Check that you can reconcile the two on a small account.
• Be careful with outcome pricing. Paying only when the work succeeds is fair only when both sides agree on what success means. Write down the definition of an outcome, the edge cases and how a dispute will be settled. If you cannot define it in a sentence your own team can check, you are handing the definition to the supplier.
• If there is no published price, ask for the rate card first. Nearly half of the AI-native companies in my sample publish no pricing. That is not a reason to avoid them. It is a reason to ask for the rate card, the allowance rules and a sample invoice before the conversation about discounts.

A short checklist for your next review

✓ Fixed, allowance and overage are separate lines.

✓ Every allowance is stated in units you understand.

✓ Expiry, rollover, minimum and recharge rules are written down for each plan.

✓ Each workflow has an owner and a typical, heavy and ceiling case.

✓ Every contract has a review date and a repricing clause.

✓ Invoices and usage data reconcile on a small account.

AI pricing will keep changing. Your budget does not need to predict every change. It needs to show which parts are fixed, which parts move with use and who is watching them.

Claude Code has quickly become one of the most widely adopted AI agents in the enterprise. Developers use it to write and refactor code, troubleshoot builds, run tests, and manage infrastructure, often by describing an objective and letting the agent determine the steps required to accomplish it.

That autonomy is the point. It is also why Claude Code is a governance decision for CIOs, not just a developer tooling choice. Claude Code runs locally on employee workstations, executes commands with the developer’s permissions, and can reach source code, credentials, cloud environments, and connected services as it works.

Anthropic has given enterprises meaningful controls to govern how Claude Code behaves, including centrally managed settings and hooks. These controls are essential. But controls that evaluate what an agent intends to do are not the same as visibility into what it actually does.

Here are five things CIOs need to understand to secure and govern Claude Code at enterprise scale.

1. Claude Code acts with your developers’ authority

Consider a developer who asks Claude Code to fix a failing build. The agent might read the codebase, install a dependency, run a setup script, edit a configuration file, query a cloud environment, and validate the result. One human instruction becomes a sequence of actions across multiple systems, all conducted with the developer’s level of access.

And it happens at machine speed. CrowdStrike internal usage data found that endpoint AI agents consumed roughly 700 times more tokens than humans using AI chatbots via the browser. Every one of those interactions is an opportunity for the agent to read, write, or execute something.

For CIOs, the question is no longer whether Claude Code makes developers more productive. It is whether the organization can account for what the agent does on its behalf.

2. Claude Code hooks are a strong first line of governance

Claude Code includes native governance capabilities that every enterprise deployment should use. Managed settings let IT define policies that individual developers cannot override. Permission rules determine which tools and commands the agent can use. And hooks give organizations programmable checkpoints throughout the agent’s life cycle.

Hooks run automatically at defined moments: when a session starts, when a user submits a prompt, before the agent uses a tool, and after that tool completes. At each checkpoint, a hook can inspect the proposed action and allow it, block it, log it, or require human approval. Organizations use hooks to stop commands that touch production credentials, prevent edits to sensitive directories, and send a record of agent activity to security teams.

If your organization is deploying Claude Code without centrally managed settings and hooks, start there. Treat hook configurations like any other security policy: version them, enforce them centrally, and review them as your use of agents matures.

But it is equally important to understand what hooks were designed to do, and what they were not.

3. Hooks see the checkpoint, not what happens next

A hook evaluates the action an agent is about to take: the command text, the file path, the tool being called. It does not follow that action into the operating system to see what it actually causes.

That distinction matters. A command such as “npm install” or “python setup.py” looks routine, so the hook approves it. The script that runs may then spawn additional processes, read cloud credentials from the developer’s machine, and open an outbound connection to an unknown destination. None of that activity passes back through the checkpoint.

The same applies to Model Context Protocol (MCP) servers, package install scripts, and other processes the agent launches. A hook can see that the agent requested an MCP tool. It cannot see what that server then does on the endpoint or the network.

Hooks are also rule-based. A rule that blocks a known-dangerous command will not necessarily catch an encoded payload, a script the agent writes and then runs, or a chain of steps that each look harmless on their own. Hooks are a policy enforcement point, not a detection and response system.

4. The most consequential decisions happen between checkpoints

Agents reason continuously. Between tool calls, Claude Code is reading files, documentation, web content, and tool output, and deciding what to do next. This is where risk often takes shape.

It is where indirect prompt injection lands, when instructions hidden in a README file, a third-party dependency, a web page, or an issue ticket redirect the agent’s behavior. It is also where agentic misalignment emerges, when an agent pursues a legitimate objective in an unsafe way, such as uploading sensitive data to a public service because it is the fastest way to finish the task.

Hooks do not observe that reasoning. They see only the next proposed action, which may look entirely normal. A manipulated or misaligned agent does not need to break a rule at any checkpoint to cause a breach.

This is not a theoretical concern. According to the CrowdStrike 2026 Threat Hunting Report, CrowdStrike is seeing AI agent-triggered detection leads at 2.5 times the rate of human-triggered leads.

There is also a scope challenge. Hooks govern Claude Code on the machine where they are configured. Most development teams use several AI agents, including Claude Code, OpenAI Codex, GitHub Copilot, and Cursor, and security teams need a consistent, fleet-wide view across all of them.

5. Runtime execution visibility closes the gap

If hooks govern what an agent intends to do, runtime execution visibility verifies what it actually did.

Runtime visibility means observing the activity an agent causes on the endpoint, including the processes it launches, the files it accesses, the network connections it makes, and the credentials it touches, and connecting that activity back to the prompt and agent session that initiated it. This creates a causal chain from prompt to agent activity to runtime impact.

That chain is what allows security teams to answer the questions that matter during an incident: What did the agent do? What did it touch? Was that behavior intended? And how do we stop it?

There is a useful precedent. A decade ago, signature-based antivirus checked files at the door, and attackers learned to walk past it. Endpoint detection and response (EDR) changed security by watching behavior at runtime. Agents require the same shift. AI executes on the endpoint, so that is where it must be secured.

CIOs can use five questions to assess where their organization stands:

• Which AI agents are running on our endpoints today, and who is using them?
• Are our Claude Code policies centrally managed, or configured by individual developers?
• If an agent ran a malicious script that passed our hooks, would we see it?
• Can we trace an incident from the prompt that started it to its impact on our systems?
• Who is alerted when agent behavior moves outside intended boundaries, and how quickly can they respond?

Hooks and runtime visibility are not competing approaches. They are complementary layers. Hooks enforce policy at the points where an agent asks to act. Runtime visibility watches everything that happens as a result. Hooks tell you what the agent asked to do. Runtime visibility tells you what it actually did.

CrowdStrike helps organizations secure AI agents with AI detection and response (AIDR) in the CrowdStrike Falcon® platform. CrowdStrike Falcon® Guardian integrates with Claude Code hooks to bring agent activity into the Falcon platform, connects that activity with runtime behavior on the endpoint, and gives security teams the context to investigate and respond when agent activity creates risk.

Learn more: Explore CrowdStrike’s AI security to see how organizations can secure AI agents across the agentic lifecycle.

Meta has hit pause on new terms of service for its business customers that would have granted it the right to grab any content from their websites. Not only that, but it would also have shifted the blame for every error produced through faulty AI to its customers.

The new terms of service were revealed on October 19 and initially due to take effect on October 30, though Meta later pushed the start date back to November 20.

But that small delay wasn’t enough to calm customer pushback, and now Meta has posted a note on Facebook’s business help center saying that the update had now been paused indefinitely.

Given the strength of feeling, Meta’s U-turn will not have come as a surprise. The terms would have been seen as far too onerous for customers, as well as exposing them to a legal minefield of the sort that UK regulators recently warned about.

In a statement to Harvard’s Nieman Lab, the company said that “We’re pausing the changes as we continue to engage with stakeholders and take our time to get this right.”

Meta has had a troubled time recently. Two weeks ago, it was fined for illegal use of customers’ data and in May, the company laid off 8,000 employees.

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.

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.

This article first appeared on InfoWorld.

As a leader, you’ve probably spent years nudging your managers to create psychological safety. After all, organizations benefit greatly when it feels safe to challenge the boss, surface bad news early, and say the uncomfortable thing before it becomes the expensive thing.

The Space Shuttle Challenger disaster of 1986 has become the canonical warning. Engineers raised concerns about the O-rings used in the solid rocket booster before launch. Their warnings were overruled by managers under schedule pressure. Seventy-three seconds after liftoff, seven astronauts were dead. The lesson still holds: When people are afraid to speak or are pressured to comply, organizations miss what they already know.

AI, however, is introducing a complication most leaders haven’t accounted for. Your employees now have another place to speak, and emerging research suggests they may be more willing to challenge a machine than a human leader, while another body of research challenges our assumptions about psychological safety itself.

Put those together, and you’re no longer managing psychological safety only between people. You’re managing it across people and machines, and the two may tell you very different things about your organization’s health.

Safety needs accountability

Psychological safety became popular for good reason: Teams perform better when people can admit mistakes, question assumptions, and challenge authority without fear of it following them into a performance review. But here’s the misconception: Psychological safety and accountability sit at opposite ends of the same dial. Turn safety up, the thinking goes, and standards come down. They don’t. The strongest teams have both; people feel safe enough to challenge one another and accountable enough to deliver.

Researchers studying five workplace settings, from hospital nurses to knowledge workers to four years of sales data across 229 retail stores, found that the relationship between psychological safety and performance wasn’t simply linear. At high levels of psychological safety without matching accountability, performance on routine work could decline; collective accountability substantially buffered that decline. The problem wasn’t that people felt too safe; it was safety operating without another ingredient the team needed.

A newer conceptual paper helps explain why. Psychological safety lowers the interpersonal risk of speaking up, which is what you want, but safety alone doesn’t create the discipline that keeps a team sharp: preparing for meetings, thinking carefully before weighing in, and taking shared norms seriously. That discipline comes from accountability.

Aviation offers a useful analogy. Sterile cockpit rules eliminate nonessential conversation during critical phases of flight, not safety-critical challenge. If something is wrong, you still speak. What changes isn’t how much psychological safety is allowed. It’s how tightly decision rights, operating discipline, and accountability are enforced.

Your AI pilots and early experiments need maximum candor. A junior engineer questioning a model or vendor claim should have every opportunity to be heard. Once a decision moves into production, incident response, or customer-facing execution, accountability tightens. Psychological safety doesn’t go down; accountability goes up.

Culture won’t automatically make people trust AI

Here is another set of assumptions in this area for IT leaders to challenge: that inclusive leadership, meaning leaders who stay approachable and treat employees’ input as worth acting on, builds psychological safety, that psychological safety makes people comfortable with AI, and that comfort with AI drives adoption. The evidence is messier.

One recent study found that inclusive leadership did improve psychological safety, but psychological safety itself did not significantly predict trust in AI. What mattered more was an individual’s ability to tolerate uncertainty. That matters because AI adoption is an uncertainty event: Capabilities shift every few months, outputs can be confidently right and impressively wrong, and the impact on jobs, workflows, and careers remains unclear. Employees are being asked to exercise judgment around systems whose behavior is probabilistic, not deterministic.

Another study of employees in South Korea found that AI adoption was associated with lower psychological safety, which in turn was associated with greater employee depression. Ethical leadership, meaning leaders who are transparent and fair about what’s changing, softened that relationship but didn’t eliminate it. Neither study is universal proof — different countries, samples, and methodologies matter — but together they raise an important question for CIOs.

A healthy culture may help people absorb the disruption AI creates without necessarily making them trust the technology itself. Those are two different problems. One is organizational: Do employees believe they can question what is happening around them? The other is psychological and technical: Can they work productively when the tool is probabilistic, and do they know when to trust it, challenge it, verify it, or ignore it? That requires more than another culture initiative. It requires AI literacy, judgment, and comfort operating under uncertainty.

Your people may be honest. Just not with you.

A 2026 series of scenario-based experiments with participants in China found that employees were more willing to voice concerns to an algorithmic leader than a human leader during cognitive tasks. Perceived fairness and psychological safety helped explain the difference. That doesn’t mean employees want robots for bosses — the effect didn’t hold in the same way for emotionally charged situations — but for analytical work the finding is worth paying attention to. One possible explanation feels remarkably human: An algorithm can’t embarrass you at the next staff meeting, downgrade your reputation with the executive team, or remember that you challenged its favorite project six months ago.

Now think about what happens as generative and agentic AI become embedded in everyday work. Somewhere in your company, an engineer may tell an AI assistant that the proposed architecture is flawed, explain why, work through three alternatives with the model, then walk into a meeting an hour later and nod along while a senior leader advocates for the original design.

The concern existed. The organization just never received it. AI didn’t suppress the dissent; your management system did.

You’ve created a psychologically safe chatbot sitting inside a psychologically unsafe org chart, and your AI adoption dashboard will never show you the difference. Both employees look like successful AI users, one using AI to accelerate work, the other using it as the only place they feel comfortable saying what they really think. Usage looks identical. Organizational health doesn’t.

We spend a lot of time asking whether employees trust AI. We may need to spend just as much time asking whether they trust people enough to repeat what they already told it.

What only you can fix

First, keep psychological safety constant and let accountability flex by phase. Push for aggressive challenge during strategy sessions, architecture discussions, AI pilots, and early experiments, and make disagreement cheap before decisions get expensive. Once execution starts, tighten decision rights and expectations without closing the channel for legitimate safety, ethical, or operational concerns.

Second, stop measuring psychological safety only through sentiment. Ask whether dissent changes decisions: what major initiative was redesigned because someone challenged an assumption; what AI pilot was narrowed, delayed, or killed because someone surfaced a risk early; what executive decision changed because somebody several layers down challenged the prevailing view. If nobody can remember one, another engagement survey isn’t going to tell you much.

Third, build a path for concerns raised to AI to reach the human decision system. That doesn’t mean reading employees’ private AI conversations; doing that would create exactly the surveillance problem that destroys candor. Instead, design mechanisms that let employees elevate a concern without reconstructing it from scratch: an anonymized escalation channel, a prompt-to-retrospective workflow, a mechanism to flag questionable AI outputs, or a structured path from an AI conversation into an architecture or investment review.

The design question is simple: Can an employee move a concern discovered in an AI conversation into the organization’s decision process with one deliberate action? Increasingly, that’s where the concern may show up first.

None of this argues against psychological safety. It argues against assuming psychological safety works in isolation, or that human trust and AI trust are the same problem. AI is creating a second conversation inside your organization, one that happens in meetings, reviews, and Teams calls, and one that happens quietly between an employee and a machine.

The real question isn’t whether your employees trust the AI. It’s whether AI has quietly become the place where they say the things your organization most needs to hear.

Second Opinion offers technology leaders an evidence-based perspective on their most consequential decisions. Khalid Kark brings 25 years as a trusted advisor, researcher, and operator. In an enterprise technology market crowded with noise, this column separates signal from spectacle.

By 2027, competitive advantage may depend less on which AI model a company uses and more on how effectively it redesigns its business around AI agents.

The software engineer starts his day by going through the changes made by a team of agents for coding using AI. The finance executive gets a report that contains exceptions in different financial systems and supporting information along with corrective suggestions. The procurement manager reviews supplier risks and recommendations regarding contract renewal for those suppliers after an analysis performed by the AI agents of pricing, deliveries and contracts.

For years, enterprise AI competition focused on model intelligence, including reasoning, coding, context windows and content generation. These capabilities remain important, but the next phase will depend on whether AI can perform substantial parts of business processes rather than simply assist employees with individual tasks.

As OpenAI, Anthropic and other frontier AI companies advance agentic capabilities, enterprises face a strategic decision. Should they use AI to make existing processes marginally faster, or should they redesign those processes around a new relationship between human judgment and machine execution?

By 2027, that distinction could separate companies that experiment with AI from those that translate it into a durable economic advantage.

Software engineering becomes an orchestration problem

Software development provides one of the earliest examples of this kind of evolution.

AI coding assistants have evolved from generating snippets and explaining code to working across repositories, proposing changes, running tests and supporting refactoring. Anthropic’s 2026 agentic coding research describes the progression toward more collaborative and autonomous development workflows.

From my firsthand experience working with Claude Sonnet to facilitate application modernization, I gained a realistic viewpoint on this transition. The process of modernizing a legacy application requires more than just converting old code to a new environment. It means comprehending the current business logic, pinpointing all the existing dependencies, maintaining the previous behavior and ensuring that suggested changes are valid for the entire application. I used Claude Sonnet to help with the modernization and explore approaches for implementing it and to accelerate the code-related work, but kept all the technical decision-making and validation under human control.

This experience once again emphasizes an essential point – AI can speed up some parts of modernization, but it cannot substitute engineering judgment completely.

An attainable example of an enterprise use case by 2027 may be that of a software development team using various specialized agents to implement a business function. The different agents would be responsible for requirements analysis, proposing implementation modifications, generating tests, reviewing dependencies and finding security vulnerabilities.

The responsibility of the engineer does not vanish but rather moves into architecture, system boundaries, engineering judgment and production results.

Companies must, therefore, begin measuring something more than lines of code or the number of pull requests created by artificial intelligence. These measures include defects in production, how often new versions are delivered, recovery time, security discoveries and total costs of delivering a reliable change.

This competitive edge will belong to companies using agents plus sound engineering practices, not companies creating code only.

Enterprise software moves from screens to outcomes

A second paradigm shift relates to the enterprise software paradigm itself.

Almost all corporate applications are built on screen navigation, forms, dashboards and workflows that humans interact with manually. Even where different systems are tightly integrated, humans typically form the glue that connects them by transferring data, assessing conditions, seeking approval and updating records.

AI agents can potentially transform this paradigm.

Consider the sales operations agent that spots a customer account at risk, analyzes its service history and contract terms, develops a retention strategy and creates a series of follow-up actions within the customer relationship management system. The human account manager evaluates the proposal and commits the company to the plan.

OpenAI’s enterprise agent initiatives reflect the industry’s movement toward agents connected to enterprise context, business applications and governed execution.

But should this approach reach maturity, the worth of enterprise applications might shift from what users can achieve using them to how effectively users can use their interface.

Systems of record—including accounting ledgers, customer databases and transactional applications—will remain essential for data management and business controls. Agents may become an execution layer above them, retrieving information and coordinating activities while underlying platforms preserve data consistency and enforce business rules.

It would be essential for software vendors to develop reliable application programming interfaces, agent-enabled interfaces, fine-grained permissions and auditable actions. Enterprises would have to consider whether their applications are automation-friendly or too dependent on human interventions.

The larger commercial question is whether value remains concentrated in software licenses and user seats or increasingly shifts toward outcomes, completed workflows and measurable business results.

AI agents at work: finance

Financial activities provide examples of how AI can be applied in the field of processes that have financial and regulatory implications.

Specific examples exist in the banking domain, where AI is being used to classify and route numerous client inquiries and assist humans in accessing pertinent data. In this way, AI is assisting financial activities and the decision-making process at the same time.

In the same way, AI agents could be used to match transactions, identify financial differences, analyze effects on cash flow and create management reports. People would take care of exceptions and make the decisions themselves.

This limited autonomy system gives an idea of how AI can be useful in finance.

Reference: How a global bank scales Claude across its operations — Anthropic

The new operating model: humans supervise execution

With increased responsibilities assigned to agents, the way teams are organized and managed would have to change.

In a typical company, accountability is distributed among various positions, departments, levels of approval and applications. People do the job, managers manage and controls are used to decide whose decision is required at each step of the work.

A new actor appears with agent-technology: the software which is able to plan and perform some tasks of the work but not necessarily to make independent business judgments or be accountable for the process.

This presents a completely new problem for managers. Whose responsibility is the result of the work when there are several agents involved? Whose fault is the mistake in the decision based on old information?

By 2027, businesses may come up with ways to clearly define ownership for work done by agents. The outcomes and risk tolerance will be defined by management; technology staff will be responsible for integration and reliability; risk and compliance teams will set the controls; while the rest will handle exceptions and critical decisions.

Management must measure agents by business outcomes—not deployment counts—including processing time, accuracy, rework, productivity and customer impact.

They have to think about the total cost of running a workflow, which includes not only model use but integration, monitoring, security, human verification and remediation.

A process that looks cheap because of automation may be expensive if there is a lot of verification needed or it keeps failing at handling exceptional cases.

Trust and data quality become competitive infrastructure

More advanced agents will not solve the historical problems associated with enterprise data. Some may even make them worse.

An agent analyzing a supplier, approving a transaction or proposing a financial correction will have the need for accurate information, appropriate rights and an understanding of the corresponding business rules.

If the client data is inconsistent across systems, the contract clauses are obsolete or the necessary data lacks proper context, the agent may come up with a compelling conclusion based on an incomplete set of facts.

Therefore, enterprises must include data quality, application integration, identity management and observability as key elements of their AI strategy.

Enterprises need input validation, access controls, audit trails, workflow testing and clear approval limits. Summarizing a report is different from changing a production system, just as preparing a payment is different from releasing funds. Appropriate autonomy depends on risk, reversibility and the ability to detect and correct errors.

This infrastructure may not attract the same attention as a new frontier model, but it could determine which enterprises can deploy agents reliably at scale.

The real competition begins after the model is selected

The frontier AI race will remain important. Innovation by OpenAI, Anthropic and other model makers may make reasoning, programming, tool usage and task completion more effective.

However, corporations need not rely solely on picking the right model for their AI.

Results will depend on data quality, application access, workflow design and controls. Organizations should start with a valuable, clearly owned process, establish a baseline, introduce agents at selected steps and expand autonomy only when measured results justify it.

Strong integration and clear workflows will let organizations adopt improved models without redesigning operations around a single provider.

Organizations with disparate AI experiments, on the contrary, may find it hard to transform pilot projects into corporate success.

The key strategic challenge is to create an organization able to absorb the advances of frontier AI consistently.

The enterprise advantage of 2027

The future stage of AI evolution will not be defined just by intelligence. Rather, it will be defined by the interaction of intelligence, execution and organizational design.

The companies most likely to succeed in 2027 will not necessarily be the companies with the biggest budgets or early access to frontier models. They will be the companies that understand what tasks are fit to be automated, what decisions should stay human and how to link AI execution to their business systems.

In this light, the critical question that the modern entrepreneur faces is not merely: “What kind of AI technology should I use?”

The critical question is: “Given the fact that AI technology can do more of the work, how can I organize my business to add value?”

Museum IT departments have traditionally served as support functions to manage security and systems. But the National Museum of Korea goes further, identifying and pursuing AI initiatives to preserve cultural heritage, broaden its use, and improve the visitor experience.

The National Museum of Korea uses technology to expand the possibilities to preserve and display physical artifacts, and its digital museum division (DMD) plans and oversees that transformation. A dedicated team responsible for digital strategy and content took shape in 2019, and in 2020, the museum informatics division adopted its current name.

“The director at the time placed great importance on investing in technology and felt we needed a department that could bring a strategic direction to work that had been carried out separately,” says Choi Seungae, former DMD head. “The digital museum division was created as a way to prepare for the next generation.”

A cultural transformation

In just over five years, the DMD has delivered a range of services, including AI guide robots, smart kiosks, and multilingual and sign language services. It’s also developed immersive experiences that use large-scale imagery and sound to recreate cultural heritage.

More recently, its focus has shifted toward data. The aim is to move beyond storage and preservation, making data previously confined to the museum available for wider use. Physical artifacts face restrictions on movement and display because of security concerns and risk of damage. Digital data can help overcome those limitations.

One example is an immersive content project featuring the Denny Taegeukgi, Korea’s oldest surviving national flag, undertaken last year to mark the 80th anniversary of Korea’s liberation.

The project displayed images of the 130-year-old flag once held by Owen Denny, a diplomatic adviser during the late Joseon period, on a large outdoor media screen in front of a department store in central Seoul.

At first glance, the project might appear to have involved little more than photographing an artifact and displaying it. But it required highly detailed data since enlarging existing photographs would’ve produced visible pixelation on such a large display.

Therefore, the division created a new, ultra-high-res dataset containing 10.8 billion pixels at a two-meter scale from the original flag, which measures approximately one meter. Precision scanning captured even the fine texture of both sides of the fabric.

Plan of action

Earlier this year, the museum was selected for the government-led K-Science initiative, through which it plans to pursue data projects beginning in 2027. The cross-ministerial R&D program combines Korea’s historical, cultural, and environmental assets with advanced science and technology to create economic, social, and cultural value.

Through the initiative, the museum will digitize over 2.5 million artifacts and develop technologies to expand the commercial potential of Korean cultural assets. The central goal is to connect the entire process, from archaeological exploration and preservation, to digitization and content development.

The resulting technologies are expected to help overcome technical limitations in detailed surveys of ancient tombs, for example. In preservation and collection management, AI could also automatically control temperature, humidity, and lighting in museum storage facilities.

Never a single right answer

Data presents challenges across both private and public sectors. For museums, however, they’re particularly complex because artifact data contains layers of interpretation, facts, and history.

Consider an AI system designed to answer questions about a particular artifact. It needs data to support its responses. But what should it say if records from Baekje and Silla, two ancient Korean kingdoms, offer conflicting accounts of the same event. Ideally, it would adequately represent different perspectives, but that’s not always possible since the same artifact can tell different stories depending on who used it, when, and for what purpose.

Choi says current LLMs don’t adequately account for these layers of context. When users ask for an accessible explanation, models can produce answers that overgeneralize or oversimplify. Reducing an event with multiple interpretations to a single sentence can obscure or distort its context.

But ensuring accuracy is another challenge. According to Choi, historical discrepancies introduced during initial training can prove difficult to correct, even when a model is subsequently asked to revise them.

The DMD is, therefore, concentrating on building data with clearly identifiable sources. The aim is to let users verify if an AI response is based on material from the National Museum of Korea to assess its reliability.

With these characteristics of artifact data in mind, the division is working with external experts to redesign its database structures around both the nature of the artifacts and the purposes for which people use the data.

Upgrade with AI

Where earlier databases focused on registering and managing objects, the new approach seeks to capture their different meanings and relationships while making relevant materials easier to find. Images, 3D data, videos, and related literature previously scattered across separate records are being connected. Metadata describing file sizes, formats, and how the data was created are also being expanded to support reuse so linking different names for the same artifact makes searching easier, for instance.

“Cultural heritage can’t be standardized like manufactured goods,” Choi says. “We need to organize and structure the data and materials we’ve accumulated in ways that reflect the character of our artifacts, while at the same time, identify connections between them. Once that foundation is in place, curators and external users like content creators, researchers, and educators will be able to find and use materials suited to their needs.”

Leaving room for discovery

After nearly two decades spent researching artifacts and developing exhibitions, Choi didn’t expect to find herself working in the DMD. Now director of the Jeju National Museum, she looks back on her digital work where there were many times her previous experience alone couldn’t guide her decisions. Exhibitions have clear opening and closing dates, and experience helps curators judge what further research and preparation will improve outcomes.

Digital projects offer fewer such reference points, however. It can be difficult to assess how far an initiative has progressed, or anticipate how emerging technologies will affect work already underway. Even so, her expertise provides a foundation to decide where change should lead, and help propose ideas to assess what new tech serves the museum’s purpose.

“Whether it’s curatorial or digital work, I hope the many things we do at museums can make a small contribution to help visitors think for themselves and arrive at their own insights,” she says.

The conversation about agentic AI is shifting: Rather than focusing solely on what the technology can produce, IT leaders are now considering what they are prepared to let it do. 

Unlike traditional AI assistants that primarily respond to user prompts, agentic AI systems can make decisions and execute actions autonomously across business processes. This creates opportunities to accelerate workflows and improve productivity but also introduces new challenges involving risk and organizational readiness.

The shift is already well under way. In a recent HCLTech survey, 87% of the participating enterprises reported using generative or agentic AI in IT operations, underscoring the growing importance of effective governance. These challenges were central to a recent HCLTech and Google Cloud roundtable on the business impact of agentic AI in which the participants explored what it takes to move from experimentation toward enterprise-wide adoption.

Agentic AI is showing promise across a wide range of business functions, including IT operations, software engineering, customer experience, HR, marketing, finance, and sustainability. Across these areas, intelligent agents can streamline complex workflows; automate routine tasks; and support faster, more informed decision-making.

Realizing potential

But realizing that potential requires more than deploying new technology. Successful implementations begin with identifying high-value use cases, establishing measurable key performance indicators (KPIs), and connecting AI initiatives to specific business outcomes.

Roundtable participants highlighted concerns about cost, ROI, and insufficient testing, reinforcing the importance of a measured approach to adoption. To manage these risks, organizations are typically starting with lower-risk business processes, demonstrating tangible value before expanding their use of autonomous agents as confidence and capabilities mature. Those concerns are reflected in HCLTech’s AI Impact Imperatives 2026 research, conducted by Omdia, which found that respondents expect approximately 43% of their major AI initiatives to fail.

Rethinking governance for autonomous systems

As AI moves from assisting employees to acting on their behalf, traditional approaches to governance and compliance may prove inadequate. Autonomous agents introduce operational and reputational risks that require organizations to reconsider how decisions are monitored, audited, and controlled.

Governance must be built into agentic AI initiatives from the outset rather than added after deployment. That includes establishing clear boundaries for autonomous agents and determining where human intervention remains necessary. Human oversight is particularly important in high-stakes areas such as financial transactions, regulatory compliance, cybersecurity, and decisions affecting customers or employees. The appropriate level of oversight should reflect the potential business impact and risk associated with an agent’s actions.

Clear accountability, transparent decision-making, and escalation mechanisms can help organizations balance greater autonomy with continued human control over critical decisions.

Preparing for new ways of working

Technology alone won’t determine whether agentic AI succeeds at enterprise scale. Organizational readiness is another major hurdle, requiring businesses to align data, governance, people, and processes around common objectives. Change management and AI literacy are particularly important. Employees across technical and nontechnical roles will need new skills to supervise agents, evaluate their decisions, and collaborate effectively with autonomous systems.

As agents become increasingly integrated into business operations, organizations will also need to reconsider how their performance is managed and measured. Over the next several years, enterprises may see the emergence of hybrid teams in which employees focus more heavily on strategic decisions and oversight while AI agents take on more operational responsibilities.

Achieving this vision will require organizations to rethink operating models and invest in workforce readiness alongside technology. Ultimately, the autonomous enterprise will be defined by how effectively AI agents are integrated into business operations and deliver measurable results, rather than simply by how many agents an organization deploys.

Learn more about how HCLTech and Google Cloud are helping enterprises navigate the transition to agentic AI. 

The true promise of agentic AI lies in agents maneuvering, making decisions, and taking actions autonomously throughout the enterprise, but few IT leaders appear ready to give bots widespread control.

According to a KPMG survey from July and August, 62% of IT leaders reported they were building, deploying, or developing AI agents, up from 53% in the previous quarter. But many IT leaders still say they are uncomfortable with the prospect of turning over internal processes to agents, with some exceptions for basic, low-risk functions like tier 1 IT support.

Jim Olsen, CTO of AI lifecycle management and governance vendor ModelOp, sees agent autonomy making inroads in limited circumstances — for example, to process customer refunds or credits without human intervention. But early lessons in the risks of full autonomy remain top of mind for IT leaders.

“We saw the large adoption of Clawdbot and OpenClaw by individuals where they would allow it full access to their email and gave it full autonomy,” he says. “For some people that worked out well, but it was a large risk exposure.”

For IT leaders deploying autonomous bots, Olsen recommends confining them to a strict sandbox with well-defined policies to limit their autonomy.

“I do not see allowing agents full and complete autonomy to do whatever they want being used in an enterprise in the near future,” he says. “But restricted autonomy is, in fact, already in use today.”

Activities that aren’t mission critical and don’t have access to sensitive information will be where IT leaders first grant agents full autonomy, Olsen predicts. “As trust improves, so will the breadth of use cases,” he adds.

Some IT leaders are concerned about “autonomy creep,” when agents quietly take more authority than they are given. And many AI and security experts warn that human-in-the-loop guardrails don’t always give employees the authority or time needed to fix agent errors.

Still, IT leaders have several methods for enforcing runtime policies and keeping agent behavior within acceptable goals, including API gateways, OS-level enforcement, and credential management, Olsen says.

“This means having clear policies in place and being able to tie them to the specific agent and use case,” he adds. “Some of these solutions are available now, but a more overall cohesive strategy is needed to bring about this minimal level of trust.”

Defining the sweet spot for autonomy

With about 2,000 agents deployed within her enterprise, Siroui Mushegian, CIO of cybersecurity vendor Barracuda Networks, still has human employees checking bot actions.

“We have many agents that are very close [to autonomous] — many of our ticketing automations are in the ‘trust-but-verify’ category with the agents that oversee them,” she says. “The more we see success, the greater comfort we have, but I am still not 100% certain I want to allow zero human accountability, especially when it comes to auditable processes.”

Mushegian expects autonomy to expand as agents demonstrate they can handle specific tasks reliably. “The consequences of a mistake should determine how much evidence you need before giving an agent more authority,” she says.

Autonomy will likely come to agents executing specific tasks within a function, she adds. Routine internal support requests are a reasonable candidate for autonomy when the answer is well documented, the action is limited, and a mistake is straightforward to correct, she suggests.

Less likely candidates for autonomy are agents that can change access permissions or make changes to a production system, Mushegian adds.

“Even within one workflow, an agent might complete some steps on its own and need approval for others,” she says. “I’d give it only the authority it needs for the task, with human approval for decisions where a mistake could have serious consequences.”

It’s about the action, not the agent

Joshua Rowe, co-founder and CTO of household bills app provider Taupia, agrees that IT leaders shouldn’t give agents complete freedom in every circumstance.

“I’d draw the line at the action rather than the agent,” he says. “The same agent can act alone on one step and need sign-off on the next.”

However, Rowe sees a lot of areas where agents can run near-autonomously right now, including read-heavy work such as gathering data, triage, drafting, and comparing options.

Taupia is testing agent functionality that compares energy deals and takes steps to allow customers to switch providers without its employees approving each step. However, the customer still would have to review the change and confirm it before it goes into effect.

For agents to get autonomous authority for irreversible actions, the timeframe doesn’t depend on AI models getting smarter, Rowe says.

“It depends on how quickly an organization can make each action reversible or bounded, with spending limits, cooling-off periods, rollback, and an audit trail good enough to undo a mistake,” he says. “Once an action has those, it can go autonomous. Where it can’t be undone, like signing a contract or moving money out of an account, I’d keep a person approving it for the foreseeable future.”

A question of deliberate design

Maciej Walaszczyk, CTO at AI customer service platform provider Text, points to customer service as an area where IT leaders have begun to cede control to agents.

“In customer service, which is my field of expertise, agents can indeed answer customer inquiries without the need for constant supervision, as they learn from knowledge provided by humans,” he says. “The scope of autonomy depends on permissions and the consequences of an action. Furthermore, the scope of these responses can be tailored to specific needs.”

But Walaszczyk says he would not hand entire departments over to agents. Instead, IT leaders should delegate specific processes where they can define the goal, set boundaries, and verify the outcomes, he recommends.

“An agent acting on my behalf cannot have more authority than I do,” he adds. “I don’t think it’s a question of being comfortable or even courageous, but of deliberately designing the environment, permissions, instructions, and oversight.”

Trust will come from real work and verified results, and humans must remain in the loop to check agent outcomes in many cases, Walaszczyk adds.

“Oversight must be real,” he says. “It takes time and attention, and it means much more than clicking approve. Saying ‘AI did it’ does not remove their responsibility. Irreversible actions or those with major consequences require human review.”

AI has evolved past simple corporate optimization. Today, it is a definitive engine of macroeconomic power. All over the world, governments and large corporations are launching highly subsidized efforts to develop their own artificial intelligence. For C-level executives, this shift signals a fundamental reorganization of the global tech stack. The decisions made by global superpowers today will directly impact supply chains, compliance requirements, and data architectures tomorrow.

According to researchers at Bain & Company, governments worldwide—including India, Japan, France, Canada, and the United Arab Emirates—are spending billions of dollars to subsidize sovereign AI. They are investing heavily in domestic computing infrastructure and localized AI models trained on regional data and native languages. Market intelligence from McKinsey & Company estimates that sovereign AI could represent a market of $600 billion by 2030. Furthermore, a survey of executives, investors, and government offices revealed that 71% believe sovereign AI is an “existential concern” or “strategic imperative” for their organizational goals.

For CIOs and CTOs, understanding the underlying drivers of this movement is essential for future-proofing corporate IT strategy. Below are the core factors forcing global leaders to act, along with the strategic trade-offs every organization must consider.

The core drivers of the sovereign AI movement:

• Economic competition and zero-sum dynamics: The economic implications of the AI race mirror the early days of the commercial internet, but at an accelerated velocity. Research published by the McKinsey Global Institute suggests that generative AI could generate as much as $2.6 trillion to $4.4 trillion in annual economic value alone. In this highly volatile geopolitical landscape, multilateral collaboration is surrendering to unilateral competition. AI has become the premier battlefield for nations competing for economic leadership, turning the technological landscape into a zero-sum game.
• National security and infrastructure resilience: Digital sovereignty policies are increasingly serving as a bulwark for security. If foundational AI models become the primary engine of a nation’s economy, depending on foreign cloud providers or cross-border infrastructure introduces a vulnerability. An adversary could cause catastrophic disruption simply by knocking those external capabilities offline. Consequently, state leaders are highly hesitant to trust foreign entities—even close geopolitical allies—with such critical infrastructure assets.
• Data governance and local values: Training enterprise-grade models requires immense data volumes, which many governments view as an intrinsic risk to data privacy and regulatory alignment. By building local sovereign infrastructure, nations can institute precise governance controls to protect rights and uphold regional laws. Beyond regulatory compliance, leaders are prioritizing AI systems that accurately reflect and shape the specific societies they serve, so local languages, historical nuances, and distinct ethical values are deeply embedded in the underlying models.

Navigating the corporate impact: Trade-offs for the C-suite

As nations build localized tech stacks, enterprise leadership teams face complex trade-offs regarding vendor lock-in, data hosting, and infrastructure costs. Research firm Gartner says that nations establishing a sovereign AI stack will need to invest at least 1% of their GDP in AI infrastructure by 2029. Enterprise leaders must balance the benefits of public cloud scalability against the compliance of regionalized hardware.

• Security vs. flexibility: Standardizing on a single, global public cloud provider maximizes engineering speed. However, it exposes the business to regulatory penalties or abrupt service disruptions if international data laws shift.
• Local compliance vs. operational scale: Deploying sovereign infrastructure can provide compliance with regional governance laws. Yet, managing isolated data silos across multiple countries increases operational complexity and drives up total cost of ownership (TCO).

Strategic recommendations for CIOs

To prepare for an increasingly fractured and regionalized tech ecosystem, executive leadership teams should prioritize two immediate actions:

1. Audit infrastructure interdependencies: Evaluate your current vendor portfolio to identify dependencies on centralized cloud ecosystems. Begin mapping how a sudden shift toward nationalized data borders would impact your analytics and operational models.
2. Evaluate strategic supercomputing partners: When planning long-term AI architecture, align with technology suppliers who possess a verified track record of building large-scale supercomputers and enterprise-grade data factories. AI data center solutions require intentional hardware and public-sector expertise to maintain resilience.

The enterprise tech stack is no longer decoupled from global politics. To understand how these national investments will transform corporate AI deployment, security standards, and infrastructure requirements, read The race is on: 6 reasons why countries are rushing to develop sovereign AI.

*************

HPE and AMD are partnering to deliver the next generation of AI and supercomputing infrastructure. Combining HPE’s deep expertise in large-scale system design with AMD EPYC™ processors and AMD Instinct™ accelerators, the two companies help customers build platforms capable of supporting the most demanding AI, modeling, simulation, and analytics workloads. Whether accelerating scientific research, enabling digital engineering, or training advanced AI models, HPE and AMD focus on what matters most: faster insights, greater efficiency, and the flexibility to scale. Together, they provide the technology foundation organizations need to solve complex problems, drive discovery, and create lasting business and societal impact.

As organizations scale out their production AI infrastructure, technology leaders are moving from localized model optimization to the more complex realities of industrial-grade deployment. For those who have spent years embedding machine learning into their core business processes, the current inflection point is defined by massive data pipelines, expanding compute clusters, and strict data governance. Scaling out requires an architectural evaluation: Can your infrastructure support exponential workload growth while simultaneously keeping your data entirely secure and compliant?

For European CIOs and engineering teams tasked with managing this operational expansion, scaling introduces a critical structural bottleneck: Where does our data live at scale, and who ultimately controls the underlying infrastructure?

In an era of intensive model training and widespread inference deployment, relying blindly on public cloud environments presents significant long-term structural risks. For organizations operating under stringent local regulations like the EU AI Act, expanding your AI footprint means managing larger volumes of proprietary intellectual property and customer data than ever before. If that scaling happens across jurisdictions that do not align with European privacy laws, your entire competitive advantage and regulatory standing could be compromised.

This clear need for scalable, autonomous infrastructure has catalyzed a major movement across the continent: Sovereign AI. At the absolute center of this infrastructure paradigm shift is the High-Performance Computing Center Stuttgart (HLRS) in Germany. As an elite computing institution, HLRS is serving as the operational blueprint for how European enterprises can aggressively scale out their AI implementations without sacrificing absolute data sovereignty.

The modern enterprise challenge: Innovation vs. autonomy

For years, commercial enterprises looking to train massive AI models had few choices outside the major global hyperscale cloud providers. While these platforms offered rapid scalability, they also created a complex web of dependencies. European enterprises frequently encountered architectural lock-in, unpredictable data egress fees, and the persistent compliance headache of transferring sensitive data across international borders.

For organizations in highly regulated sectors—such as automotive engineering, financial services, aerospace, and healthcare—these barriers were often insurmountable. Innovation slowed because the risk of exposing proprietary data was simply too high.

HLRS recognized this friction point early on. Rather than forcing organizations to compromise between computational horsepower and data security, the center designed an environment specifically tailored to the unique operational, cultural, and legal realities of European industry.

A deeply customer-centric approach to high-performance computing

HLRS does not view itself merely as a data center filled with flashing server racks; it operates as a specialized co-innovation partner for industrial enterprises and scientific researchers.

HLRS provides a unique collaborative bridge between academic research and commercial application. Its customer-centric model enables an industrial engineering team or a climate research group to receive tailored computational environments optimized for their specific mathematical models and workflows.

Consider the automotive industry, a cornerstone of the German economy. Designing the next generation of autonomous or electric vehicles requires running billions of simulation cycles. By leveraging the local, highly secure infrastructure at HLRS, these manufacturers can train complex AI vision models and run aerodynamic simulations knowing that their intellectual property remains fully insulated from external entities. The data stays in Germany, conforms entirely to European standards, yet benefits from processing speeds that rival supercomputing clusters around the world.

This customer-first focus democratizes access to elite computing. It allows midsize enterprises and massive multinational corporations alike to scale their AI ambitions without the fear of compromising their foundational data assets.

Engineering sovereign AI: The powerhouse ecosystem

Building a sovereign computing ecosystem capable of supporting next-generation AI workloads requires an extraordinary combination of hardware reliability, system architecture, and processing efficiency. To deliver this level of performance to its users, HLRS has cultivated deep strategic partnerships with industry-leading technology pioneers including HPE and AMD.

1. Architecting the future

AI and deep learning workloads are fundamentally different from traditional corporate computing. They require massive data pipelines to move fluidly across thousands of nodes without encountering bottlenecks. HPE brings its world-class supercomputing system architecture to the HLRS data center floor.

By utilizing HPE Cray Supercomputing platforms, HLRS can offer its users an infrastructure optimized for massive parallel processing. HPE advanced liquid-cooling technologies help maximize data center energy efficiency—a critical requirement for European organizations operating under sustainability mandates. For the HLRS customer, this translates to predictable, highly reliable performance even when training the most demanding, multibillion-parameter AI models.

2. Driving computational breakthroughs

Today’s AI workloads are incredibly compute-intensive, requiring advanced hardware capable of executing complex matrix mathematics at blinding speeds. HLRS integrates cutting-edge AMD processors and accelerators to meet these heavy operational demands.

AMD-powered infrastructure is deliberately engineered to handle both traditional high-performance computing simulations and modern AI training workloads simultaneously. Plus, AMD’s focus on energy efficiency per watt allows HLRS to maximize its computational output without exponentially increasing its environmental footprint. For end users, this means faster time-to-insight, accelerated product development cycles, and the ability to iterate on AI models at a fraction of the time.

By tightly integrating HPE system engineering with AMD processing innovation, HLRS delivers a sovereign computing alternative that matches—and often exceeds—the capabilities of non-sovereign platforms.

The strategic value for the enterprise CIO

For CIOs, the lesson of the HLRS model is clear: sovereign AI is no longer a niche regulatory preference; it is a core business strategy. Investing in sovereign architectures allows organizations to achieve three critical enterprise goals:

• Future-proof compliance: By anchoring AI development within a sovereign framework, organizations can be insulated from shifting international compliance regulations and the evolving complexities of global data laws.
• Intellectual property protection: Keeping model training local means proprietary algorithms, customer data, and trade secrets don’t feed into public or third-party AI models.
• Uncompromised performance: Selecting a dedicated infrastructure stack powered by HPE and AMD enables local data processing without sacrificing the speed or scale required to compete on a global stage.

As AI continues to mature, the organizations that build their digital strategies on a foundation of data autonomy and sovereignty will be the ones positioned to lead. HLRS stands as a powerful testament to what is possible when customer-focused design meets world-class technology infrastructure.

Learn more about Europe’s strategic investments in digital autonomy, the evolution of supercomputing, and how industrial organizations are leveraging these advanced technologies to drive competitive advantage by listening to the full conversation on This Week in HPC Podcast Episode 400.

*************

HPE and AMD are partnering to deliver the next generation of AI and supercomputing infrastructure. Combining HPE’s deep expertise in large-scale system design with AMD EPYC™ processors and AMD Instinct™ accelerators, the two companies help customers build platforms capable of supporting the most demanding AI, modeling, simulation, and analytics workloads. Whether accelerating scientific research, enabling digital engineering, or training advanced AI models, HPE and AMD focus on what matters most: faster insights, greater efficiency, and the flexibility to scale. Together, they provide the technology foundation organizations need to solve complex problems, drive discovery, and create lasting business and societal impact.

AI is writing more code than ever. Software specialist Sonar’s 2026 State of Code Developer Survey, based on more than 1,100 professional developers, found that 72% of those who’ve tried AI coding tools now use them every day, and that today, AI now accounts for 42% of committed code, a number that’s expected to reach 65% by next year.

But while developers embrace AI-enabled coding services, many professionals are uncertain about how their businesses will cope with this influx of AI-generated code. Sonar’s research additionally discovered that 96% of developers don’t fully trust it, and only 48% always verify it before committing.

In fact, 38% of developers told the researchers that reviewing AI code requires more effort than analyzing code written by human colleagues. That’s a pattern recognized by Tim Chilton, a managing geospatial consultant at UK mapping agency Ordnance Survey (OS). “There’s truth in the headlines that AI can get carried away, and developers spend more time fixing the code that’s been created than not,” he says.

While that’s not a pattern he sees at the OS, Chilton says his organization is cautious about how developers use AI coding tools, and conversations with other digital leaders suggest a similar approach. AI-enabled coding is indeed almost ubiquitous, and it can allow developers to reach new, higher levels of productivity, but more doesn’t necessarily mean better code.

To ensure that such coding services produce business benefits, CIOs must take control of the development process. They should exploit agents carefully, set professional responsibilities, and establish guidelines, policies, and organization-wide training.

Exploiting the agents

Snowflake co-founder and president Benoît Dageville suggests there are two ways to view AI-powered coding. One is the scary way, where AI takes over your tasks without human input. The second is the efficient way, where AI helps you do the same things as before, but at a fraction of the cost. He’s a big believer in the latter, both for himself and his teams.

“The route depends on the organization; their application of AI coding depends on their priorities,” he says. “However, I hope that overall, AI will have a positive effect on humans. I’m using AI every day to code, and if I compare myself to one or two years ago versus now, I’m more efficient and productive, but I’m also writing five times more code.”

Steve Lucas, CEO of integration technology specialist Boomi, also notes the increase in output. He quotes research that suggests 4% of GitHub public commits are already being authored by Claude Code. That proportion is expected to rise to 20% of all daily commits by the end of this year. Staff at Boomi already use AI tools to produce more code.

“We’re writing 10 times the amount today than we did two years ago,” says Lucas. The increase in AI-enabled coding is so significant that he’s spoken with Boomi chief product and technology officer Ed Macosky about goals for the proportion of self-modifying code.

“I believe AI should recursively modify 80% of a software organization’s code,” Macosky says. “Infinite improvement is demanded. If AI is extraordinarily good at breaking security protocols, the only way to keep up isn’t the kind of accordion model of human code design. AI use must be linear in scale and continuous.”

Crucially, Lucas suggests using AI to check and modify that AI doesn’t mean coders go away. “In fact, I think we’ll need more engineers, not fewer,” he says. “We need these professional experts to ensure the quality of the code that’s written.”

At OS, Chilton uses Coco, Snowflake’s coding agent. The tool does as much as 90% of a development task that he would otherwise complete from scratch. “It’s taken an hour to finish, instead of weeks or never,” he says, reflecting on the power of AI coding services.

However, the tool’s influence is carefully constrained. The agent doesn’t work in isolation, and Chilton checks its output in detail. He says all organizations need a similar process and should value experienced professionals who can use AI coding tools effectively.

“If you’re giving a tool to someone who isn’t capable of checking an agent’s work, as a digital leader, you run the risk of putting too much faith in AI just running with its output,” he says. “I think that’s a big risk, so there’s still a need for experienced developers.” 

Setting clear responsibilities

While placing humans in the loop can help ensure AI-enabled code is safe and effective, developers shouldn’t be weighed down by their new management responsibilities.

Gill Haus, CIO at Chase, the consumer banking arm of JPMorgan Chase & Co, says AI coding benefits can only be realized when agents are introduced with a strong focus on automating supporting technology and processes, which reduces the need for too much human input.

“If you have 12,000 engineers, they can write 12,000 engineers’ worth of code in a day,” he says. “If those 12,000 engineers have agentic technology, they can write much more. But if you don’t have automation left to right with confidence, you create more manual processes. You can’t move as quickly since there are only so many humans you can put in the middle.”

Haus says Chase never releases services in production that don’t pass its high bar for quality and security. Strong engineering practices, pipelines, and architecture, plus a tried-and-tested approach to automation, can help ensure AI coding produces solid outputs without a burdensome amount of human intervention.

“We’re focused on effective automation so we’re able to unleash this technology safely and effectively,” he says. “This is something many other companies should be focused on if they aren’t already, because otherwise you can’t keep up with the pace of change.”

François-Xavier Pierrel, group chief data and ad tech officer at French TV network TF1, is another digital leader who says maintaining control as AI writes more code means keeping the human in the loop in a clearly defined manner. His team documents agentic processes using Atlassian project management and collaboration tools, such as Confluence.

Pierrel says policy management is crucial as the agentic transformation gathers pace.  One key step is ensuring professionals who use agents conform to internal standards. Smart businesses set policies that state clearly when staff can explore an agent, delegate work to it, or release it in production.

“We don’t have hundreds of agents deployed yet,” he says. “But the moment you reach a certain level of volume, if you don’t have compliance and policies in place, AI becomes a critical mess, and then it can be disruptive in a negative way.”

Building strong foundations

Kirsty Roth, chief operating officer at content and technology specialist Thomson Reuters, agrees digital leaders must be proactive. Her firm’s explorations with models and agents suggest that AI can help with time-intensive coding processes, such as writing. This capability means her organization carefully considers the roles people fulfil.

“In the last 12 months, we’ve put lots of thought into where we’re seeing benefits,” she says. “It’s great AI can do some of the coding work, but what does that mean for people’s jobs? We used to have thousands of engineers. Do we now need more architects or product people?”

Roth refers to security. While cyber is always a priority for Thomson Reuters, the firm dedicates significant resources to controlling threats in the AI age. Developing high-level development and security skills requires a concerted effort. Yet Roth says ensuring people have the right skills to manage AI is in many ways a familiar IT trend.

“All this effort is no different than digital, cloud, mobile, social, or other big tech trends,” she says. “They all take several years to have an impact as the initial hype comes, and then you’ve got to work through the reality and think about how you upskill people for the new world.”

Crucially, coding is no longer the sole preserve of the software developer. AI coding tools make it much easier for non-IT professionals to vibe code applications. Tal Carmi, CIO at technology specialist WalkMe, says non-developers can create useful tools. However, effective outputs rely on a careful balance between enablement and guidance.

He adds that most of these employees don’t need in-depth capabilities, such as a database or a content delivery network. Instead, non-IT staff require a dedicated place to upload their products. WalkMe’s engineering specialists ask key questions to ensure their outputs are safe, considering credentials and potentially problematic packages.

“You need to add guardrails,” he says. “A lot of the work for in-house engineers is shifting from building to testing. The people who aren’t coders don’t necessarily have security in mind.”

The key takeaway, suggests Emmanuel Frenehard, chief digital officer at biopharmaceutical giant Sanofi, is that digital leaders must help professionals feel comfortable. Successful digital leaders ensure the business generates value from agents, and his firm is helping its staff, particularly its developers, to embrace these tools.

“I genuinely worry for professionals who don’t use AI to code, because in five years, they may not have jobs,” he says. “So we’re guiding, coaching, and training them, but people must take the journey. The train has left the station. You can decide to be on it, or just look at it.”

Investors back Journify’s push into the US and Europe

Journify, the ad signal infrastructure company, today announced a $12 million Series A at four times its previous valuation. Al Mada Ventures led the round, co-led by returning investor Silicon Badia, with Shorooq and Bunat Ventures increasing their investment and Du Ventures and Oraseya Capital joining as new investors. The funding will take Journify into the US and Europe and expand the AI behind its platform.

Global ad spend will exceed $1 trillion in 2026, with algorithms expected to place three quarters by 2028, according to dentsu. These systems learn from the customer outcomes brands send back. Browser restrictions, broken tracking, and disconnected offline sales leave them with an incomplete picture of who buys.

Journify makes sure ad platforms such as Google, Meta, TikTok, Snap and Amazon Ads see the purchases, sign-ups and store sales a brand’s customers actually make. More than 100 businesses use Journify today, from fast-growing ecommerce brands to some of the region’s largest retailers, representing hundreds of millions of dollars in annual ad spend.

Customers include Jarir Bookstore, one of Saudi Arabia’s largest retailers, which increased its return on ad spend on Meta by 182%, and Saudi ecommerce brand Baytonia, which grew its return on ad spend on TikTok by 80% while cutting cost per purchase by 44%.

“AI is transforming advertising, but the intelligence behind it is only as good as the signals it receives,” said Taoufik El Jamali, Co-Founder and CEO of Journify. “Businesses know who buys, who comes back and what creates lasting customer value. Too little of that knowledge reaches the ad platforms driving their growth. Our vision is to close that gap, turning real customer outcomes into intelligence ad platforms can learn from. We’re building toward a future where advertising AI understands what makes a customer valuable to each business, not just what makes them click.”“As AI takes on a greater role in marketing, we believe the connection between reliable customer data and the decisions built on it will become increasingly valuable,” said Omar Laalej, Managing Director at Al Mada Ventures. “What interests us about Journify is its approach to building that connection from the data layer up: a privacy-first foundation that can evolve into intelligence and action. The founders’ understanding of that opportunity gives us confidence in their ability to build a platform that marketers can increasingly rely on, both to understand their customers and to act on that understanding.”Hossam Shafick, Partner at Silicon Badia, Seed Lead and returning investor, added, “Since our initial investment, Journify has grown its valuation by more than 4x, and its revenues more than 5x, validating both the strength of its technology and the team’s ability to execute at scale. That performance has deepened our conviction that Journify can become a global leader in ad signal infrastructure. We are proud to double down and co-lead this round as the company expands into the world’s largest advertising markets.”

Journify already uses AI to monitor every connection continuously, detect signal-quality issues and fix them. The new funding will grow those capabilities as Journify expands beyond the GCC. In the US alone, digital advertising revenue reached $294.6 billion in 2025, according to IAB and PwC.

“I’m excited to help Journify scale in the biggest ad market in the world,” said Ryan Burke, a newly appointed member of Journify’s board and three-time Chief Revenue Officer. “I’ve known Taoufik since our InVision days, and I’ve seen his product execution in action. Based on the success they’re already seeing in the Middle East, it’s not a question whether it works in the US, but how fast we can scale.”

About Journify

Journify builds ad signal infrastructure for performance marketers. Its privacy-first, real-time data layer helps brands improve the quality and reliability of the first-party signals used in advertising and measurement.

Journify connects data across web, mobile, offline sales, CRM, ecommerce platforms, backend systems and data warehouses. It validates and enriches conversion events and activates consented signals server-side across Google, Meta, TikTok, Snap, Amazon Ads and other platforms.

Founded in 2022 by Taoufik El Jamali, Amine Chouki and Omar Al Shoubaki, Journify is headquartered in San Francisco with offices in Dubai and Riyadh. Learn more at journify.io.

Journify has obtained a SOC 2 Type II report and is committed to GDPR compliance.

Contact

Head of Marketing

Vanessa Moreno

Journify

vanessa.moreno@journify.io

CIOs have always felt pressure to deploy emerging technologies rapidly. Implementation brings challenges, including calculating and measuring upfront investment costs. Deploy too quickly, and when the hype fades, many IT departments are left with a costly architecture to support, security gaps, and operational issues.

The same trend is happening with AI. Many CIOs procured enterprise-wide AI model licenses and empowered employees to experiment with language models and develop AI agents. Others asked DevOps teams to accelerate AI code generation and vibe coding. The shift from rapid experimentation to deploying more AI capabilities to production can leave CIOs with mounting AI debt and AI FinOps gaps.

CIOs’ near-term concern is managing budgets amid consumption-based AI pricing models. Even as AI token costs decrease, more employees are using AI, and agents are given more challenging, expensive assignments. Here are seven common mistakes IT leaders make that result in blown AI budgets.

Defining an AI strategy without measurable business outcomes

Most CIOs and CAIOs recognize the need to establish AI strategies focused on areas where AI can provide lasting business value. But many fail to quantify targeted business outcomes, leaving employees to use adoption metrics as the primary objective.

“Every token spent on a pilot that never proves its value is money leaders can’t get back and lost opportunity cost, which is a governance failure more than a technology one,” says Rob Scudiere, CTO at Verint. “Every agent and workflow should have to earn its budget by showing results that achieve the desired business outcome, or lose it.”

Kris Beevers, CEO and cofounder of Netbox Labs, says to use existing business metrics to see whether the areas adopting AI are improving them faster. “If adoption is climbing but the outcomes aren’t moving with it, that’s a pretty good signal to rethink where you’re spending,” Beevers says.

Recommendation: Financial impacts may be hard to target during experimental phases, but employees should set financial objectives before moving AI agents into development and deployment phases.

Experimenting without AI governance

CIOs may find they have a real mess on their hands when a few pilot AI agents quickly scale to thousands running in production. Much of AI governance focuses on identifying owners, setting data-access rules, defining target business outcomes, and establishing accuracy guidelines. CIOs must also educate employees on underlying cost factors, including model selection and platform standardization.

“Delayed AI governance gets framed as a compliance risk, but it’s just as much a budgetary concern,” says Guy Bourgault, head of agentic systems at Concentrix. “The longer organizations wait to define ownership, standards, and controls, the more they end up funding inefficiency, rather than progress.”

Varun Goswami, global head of product and AI at Newgen, says AI budgets are wasted on scattered pilots, duplicated integrations, and agents that run quietly without ever proving value. “Build on one governed platform rather than a dozen parallel stacks, reuse templates and connectors instead of custom-building each use case, and match the model to the job rather than routing everything to the priciest foundation model,” Goswami recommends.

Data quality is a third concern, according to Collibra and The Harris Poll, with 96% of IT leaders saying project failure almost always traces back to poor data foundations, and 51% reporting significant staff hours spent manually correcting autonomous AI agent outputs. CIOs should set data quality metrics and establish data products to build a trustworthy AI context layer.

Recommendation: CIOs should update and communicate their AI governance policies monthly, as AI cost, capabilities, compliance, and security considerations evolve rapidly.

Focusing tokenomics on model costs and not business value

Much of the discussion around AI token economics, or tokenomics, focuses on the costs of using different AI models. But the FinOps Foundation defines tokenomics as “the study of how the production, distribution, and consumption of tokens generate business outcomes and AI value within an organization.”

Because many organizations use multiple models, SaaS with AI agents, and internally developed AI agents, CIOs should partner with the CFO to measure total impact, including AI’s direct token costs, employee efforts, ongoing inference costs, and the value delivered.

“Companies can quickly overspend on AI when they focus too narrowly on token consumption, and the starting point should always be the business outcome,” says Prakash Kota, CIO at UKG. “I use the Three T’s: does the work require talent for judgment or expertise, can existing tools solve it efficiently, or do tokens create enough value to justify the investment?”

CIOs should then set AI budgets at the employee, department, and workflow levels. Each group’s budget should be reviewed and adjusted regularly based on outcomes. This discipline promotes fiscally smart decisions about when and how to use AI capabilities and can drive a top-down culture change.

“The same tokens can go to a skilled engineer shipping a product faster, or to a non-expert generating 10 versions of the same slide deck,” says Tom Shea, CEO and cofounder at OneStream. “The line item in the budget looks identical either way, and true token efficacy requires governance to ensure those tokens are empowering experts to accelerate output, rather than fueling a massive cost explosion.”

Recommendation: Setting AI budgets too soon may curtail employees’ enthusiasm in learning and experimenting with AI. Establish financial targets based on a maturity curve to encourage experimentation first, then fiscal discipline when AI agents are deployed to production.

Developing AI agents without standards

CIOs should communicate these two cost considerations to DevOps teams using AI code generators.

First, according to Stack Overflow’s 2026 Developer Survey, 73% of developers use AI coding assistants and agents daily, but developers care more about quality (75%) over cost (38%) when shaping prompts and picking models. CIOs should set guidelines for balancing cost and quality tradeoffs, establish DevOps non-negotiables, and require code analysis in deployment pipelines.

“Coding is no longer a constraint, and the bottleneck has moved to how we ensure the correctness of code,” says Anurag Dhingra, SVP and GM of networking and collaboration at Cisco. “There’s just no humanly possible way to review every piece of code that is written by AI.”

The problem is that 96% of developers don’t fully trust AI-generated code and 48% always check their AI-assisted code before committing, according to Sonar’s State of Code Developer Survey. As large organizations may use several AI code-generating tools, they need to benchmark quality, cost, and developer satisfaction.

“Teams need clear guardrails and engineering standards, especially as AI agents accelerate development and can introduce costly rework,” says Andrea Malagodi, CTO at Sonar. “Having live data aggregated from your one or many providers, to enable you to see the cost per PR [pull request], is a good governance mechanism.”

Recommendation: While AI code generation is a remarkable breakthrough, it also brings new costs and quality considerations CIOs should track.

Using frontier models for all AI needs

Another cost consideration comes as organizations deploy hundreds of AI agents and provide developers several AI models to choose from. Developers may choose models based on preferences rather than performance and cost considerations.

Craig Wiley, VP of AI at Databricks, says 77% of companies now juggle multiple model families because the best model for one task is rarely the best for another. “The flexibility comes at a cost of managing shifting prices, scattered vendors, and zero visibility into where your budget’s actually going. The fix is real-time budgets and smart routing that automatically sends queries to the most cost-effective model,” Wiley says.

Recommendation: Josh Fecteau, chief data and AI officer and CIO at Teradata, says that frontier models are expensive and not necessary for every task. “Diversify your model strategy with cheaper small language models, custom models, and industry-specific models,” Fecteau recommends.

Deploying AI agents without monitoring cost spikes and inefficiencies

A key challenge with AI agents is their variable costs, especially when they are given tasks of varying complexities. While some AI providers are moving to outcome-based pricing models, many still use a license model with a fixed number of tokens, plus consumption-based pricing for overages. This means CIOs must monitor costs, set AI observability standards, and define rules for handling performance variances in AI agents.

“I spent 25 years in telephony where every minute had a price, and agentic AI is the first software I’ve seen that bills like a phone call and gets budgeted like a license,” says CJ Combs, AI strategy executive at Columbus. “AI costs stop being predictable the moment an agent can loop, because it keeps pulling in context, retrying, and calling tools in ways nobody budgeted for.”

Experts suggest several implementation cost inefficiencies to review. Babak Pahlavan, founder, CEO, and CPO at NinjaTech AI, says that AI agent processing duration is an easy indicator. “A single autonomous agent running a multi-hour task can burn a month’s allocation in an afternoon because every tool call, every retry, every piece of context it re-reads gets billed,” Pahlavan says.

Other cost factors require experts to review an AI agent’s decision logs to determine optimization. Adi Elimelech, CTO and cofounder of Jedify, says, “If every query drags an entire database schema back to the LLM, token costs scale with the size of your environment rather than the complexity of the question. The cost compounds, since the model often doesn’t get it right on the first pass and loops back for another round trip before landing on the correct answer.”

Recommendation: CIOs will need to mature several AgenticOps and site reliability engineering practices to monitor AI agents and respond to cost, security, quality, performance, and other incident types.

Building agents without a change management plan

One of the biggest gaps in deploying AI agents is that deployment is just one step in a change management process. AI governance requires identifying agent owners who are accountable for decisions and responsible for outcomes. These owners should also sponsor the underlying change management process.

“The biggest AI cost overruns rarely come from technology,” says Abhijit Kakhandiki, SVP and GM of digital business automation at BMC Software. “They come from organizations deploying AI without redesigning processes, ownership models, and governance.”

Part of the change process requires identifying human-in-the-middle responsibilities to review the agent’s recommendations. The review process builds trust and lets owners switch to autonomous decision-making for low-risk, high-volume, trusted recommendations.

“It’s not going to be a binary switch where, from day one, you’re going to trust AI agents to run tasks autonomously,” says Joel Hellermark, chief AI officer at Workday. “Progressively, they’re going to earn the right to run those workflows autonomously. If it’s your fiftieth time approving an expense below $50 for one of your direct reports that looks exactly on policy, you can trust the agent to run it for you.”

Recommendation: Growing adoption isn’t the end game, but it’s a key step toward delivering business value. Metrics to track adoption include AI response quality, trust scores, repeat usage, and value delivered to adopters.

A simple rule is that you can’t manage what you don’t measure. CIOs should set budgets, track costs, and measure outcomes, especially as more agents move into production.

It’s early days for AI-assisted work, and sentiments are mixed about its benefits: Does AI actually bring value and save employees time, or does it bog them down and add unnecessary activities?

Data from ActivTrak seems to vacillate between those two potential realities: The latest research from the productivity tracking software company says employees who use AI most heavily are working up to 90 minutes longer each day, yet its previous research, published earlier this year, found that, in general, all employees are actually working less.

The discrepancy may be due in part to the timespan and sample sizes of the data collection for the two reports, but it indicates that enterprises should still be wary of vendor claims about AI-related productivity gains. Measuring them remains incredibly difficult.

AI use compared

ActivTrak’s current findings are based on behavioral work data gathered from 9,140 knowledge workers across 467 enterprises over a five month period (April 1 to September 25, 2026). This sample is much smaller than that of its previous report based on 443 million hours of work performed by 163,638 employees across 1,111 organizations over a three year period (January 1, 2023 through December 31, 2025).

According to the latest findings, heavy AI users are working between 8.42 and 9.08 hours per day, compared to 7.58 hours for those not using AI. ActivTrak’s previous findings revealed that, overall, average workdays had decreased by roughly 9 minutes (a 2% decline).

On the productivity front, heavy AI users have 22% shorter focus sessions than light users (37.8 minutes versus 48.2), suggesting their work is more fragmented due to AI use; further, they switch apps 15% more frequently than non-users.

“Over time, those interruptions add friction to high-value work that requires concentration, critical thinking, and sustained attention,” Sarah Altemus, manager of the ActivTrak Productivity Lab, said in a blog post describing the latest findings.

ActivTrak’s previous report had found that over the period of the earlier study, focus efficiency, the percentage of work time spent in focused, uninterrupted activity, fell to a three year low of 60% with AI use, and average focused session time in 2025 declined by 9% from 2023. However, that same report found that daily productive time increased by 19 minutes, or 5%, to 6 hours and 36 minutes, with AI in the workplace. Furthermore, productive sessions grew by 13%.

The company’s latest report also tracked the productivity differences between users of tools with embedded AI and users of web-based AI tools. Those using embedded AI switched apps 0.6 times an hour, while those using AI on the web switched between 1.7 and 4.2 times per hour. That’s up to 4x more switching than by employees who don’t make use of AI at all, which creates what ActivTrak describes as a “swivel-chair tax” — the additional effort spent by employees due to the movement between apps.

Similarly, in its previous report, ActivTrak had found that, overall, task switching in general rose 12%, or 10-plus minutes during the survey period.

Interestingly, according to the latest research, light users spend more active work time in core job-specific apps (81.4% compared to 78%).  “In other words, more frequent AI engagement doesn’t necessarily translate into more focused work,” Altemus pointed out.

The larger issue is the way organizations manage the additional capacity that AI may create, Altemus noted. “When employees complete tasks faster, managers may assume they have room for more responsibilities,” she said. Without clear workload boundaries, time savings may be redirected into additional work that can be taxing.

The numbers often don’t tell the full story

ActivTrak has a useful view of how work moves across applications, noted Sanchit Vir Gogia, chief analyst at Greyhound Research, but he also pointed out that it sells the capability that produces these measurements.

Recorded use depends on what the instrumentation can detect, he observed. For example, an employee can use AI at work and still appear in the non-user group, and work on an unmanaged personal device sits outside the measured estate. In addition, an API or a background agent can finish work without producing a desktop session, and passive screen time, an offline meeting captured through a calendar, and paid hours are also different measures. Furthermore, switching apps is easier to observe than switching attention within an application.

Ultimately, he noted, those judging the value of AI need to establish what happened after the first task became faster. “An improvement per paid hour can conceal effort left off the timesheet,” said Gogia. “The [enterprise] board should be able to say whose day improved and whose work made that improvement possible.”

This article has been updated to clarify that some stats are not related to AI.

The hype around AI agents and the models that power them is warranted. But while they can give organizations a real competitive advantage, in reality, how much value they deliver ultimately depends on something much less glamorous: the middleware and integrations that connect agents to systems across enterprise workflows.

Enterprises have used AI in various forms for decades, but agents represent a significant shift in how we put AI to work and what we ask it to do. The first phase of AI largely focused on generating, summarizing, analyzing and recommending information. Agents go a step further by executing actions and this is where the middle layer often gets overlooked.

Without the right APIs, MCPs, data streams, tools, deterministic logic, identity management and systems of record, agents and models essentially operate in a sandbox. As enterprises adopt agents into real-world workflows, the question CIOs need to ask isn’t simply, “Which AI agent should we deploy next?” It’s, “Can our enterprise faithfully support software action on our behalf?”

The model is becoming the commodity layer

After decades of leading a technology organization and countless implementations, I’ve seen firsthand how important it is to align technology with the business problems it is meant to solve. When it comes to AI agents, one of the biggest mistakes I see organizations make is setting unrealistic expectations for how a model will operate within their existing enterprise environment.

AI agents and models are often touted for what they can accomplish, which naturally focuses attention on their reasoning and execution capabilities. But we cannot simply layer them onto existing workflows and expect them to make decisions or take consistent, repeatable action reliably.

Financial services make for a great example of this. Think about an investing agent who evaluates companies using financial data. When they need it to calculate something precise, like a company’s cash burn ratio or runway, they don’t ask the LLM to do the math. Instead, they use a modern coding language such as python or node.js to perform deterministic analysis, then pass the results to the model to interpret their meaning in the broader context of the company.

As models continue to improve, the real differentiator isn’t the model itself, but what we engineer around them to turn their reasoning into trustworthy action.

The middle layer is where agents become enterprise software

For agents and models to deliver value outside a sandbox environment, they need connectivity to the enterprise systems supporting workflows. They also need to retrieve information from these systems, pass data between them and regularly execute actions within business-critical applications. 

Think of the middle layer as the connective tissue between reasoning and execution. The difference between an agent that can answer questions using information you’ve provided versus one that can retrieve a customer’s information, determine the appropriate next step and execute that action in a CRM or ERP system is fundamental. Building, managing and maintaining these connections across systems at scale requires a mature approach to integration.

Integration maturity varies across the enterprise landscape today. While some organizations have “point-to-point” technical debt, others have already developed mature AI integration infrastructure, investing in platforms such as Workato, MuleSoft or Apigee and building the engineering practices and dedicated teams needed to operate these connections. From what I’ve seen working with enterprise technology teams, it’s the latter that will find adding agents exponentially easier.

Another “gotcha” is how prominent MCP’s (Model Context Protocol) are becoming. MCP’s are quickly becoming the new standard for how Agents communicate with systems. There are hundreds already available within Enterprise AI tools such as Claude, Gemini or ChatGPT, but that still does not replace the need for an API/MCP management tool. B2B transactions will soon be performed via MCP or custom vibe-coded apps will need their own MCP to expose capabilities.  Regardless, the technical requirement stays the same.

For organizations without a purpose-built foundation for connecting Agents with core systems, what starts as an AI initiative can actually turn into an integration modernization initiative. Before agents can reliably interact with systems, organizations need to connect them.

Agents will expose the technical debt we’ve learned to work around

Modernizing the connections between enterprise systems to prepare for agent integration can help us uncover critical gaps in our existing environments. We see where humans commonly pick up the slack between disconnected systems through manual processes like data unification or handoffs. Agents, however, cannot compensate for these inconsistencies in the same way.

Regardless of the type of AI model, if data is inaccessible, APIs are unreliable, business logic is undocumented or systems can’t communicate with each other, an agent’s capabilities are hindered. This doesn’t mean agents create new architectural problems; instead, they help us expose technical debt we’ve grown accustomed to. The danger is trying to recreate those human workarounds for individual agents rather than fixing the underlying problem.

As organizations deploy more agents, one-off fixes can snowball into novel integrations, data access patterns and workflows that IT teams have to maintain. Instead of reducing complexity, we risk adding another fragmented layer to the enterprise architecture.

Enterprise-grade agents require a different engineering discipline

Beyond these architectural challenges, Agentic AI integrations also inform software engineering. Unlike enterprise software, which is built around predictable inputs, deterministic logic and defined failure status, agents introduce probabilistic behavior into enterprise environments. This means that the same request can produce different outputs or actions depending on the context and information available to the model.

I’ve seen this play out in the enterprise environments we work with. Even relatively simple agentic workflows can become unreliable when connections are faulty, schedules are inconsistent or prompts drift over time. What looks straightforward from the outside can require significant engineering and oversight to operate reliably.

If a relatively simple, low-stakes workflow like this example is easily derailed, consider the engineering required when an agent is expected to take consequential action across ERP, CRM or financial systems. This is why real software engineering is necessary when integrating agents.

Enterprises can’t simply buy an agent and expect stable automation in the same way they might configure and deploy other platforms. Agents must operate as part of the whole system, often spanning multiple apps and requiring ongoing testing, monitoring and maintenance. This requires a team of dedicated engineers and developers to make agent behavior observable, recoverable and reliable enough for enterprise use.

CIOs need to build the organization around AI Agents

For CIOs, preparing your organization to scale agents requires looking beyond the technology itself. Mature integration practices and dedicated software engineering teams are important, but those capabilities need to be matched by strong technical leadership and a culture that understands software, data and calculated risk.

Strong technical leadership is especially important because, remember, not every workflow should be agentic. We need leaders to recognize where AI reasoning and adaptability create value and where conventional automation or deterministic software is the better choice. At the same time, teams need to be comfortable experimenting with probabilistic systems, learning from failures and pushing innovation without sacrificing the engineering discipline required for enterprise environments.

For CIOs, preparing your organization to scale agents requires four capabilities: mature integration practices, dedicated software engineering teams, strong technical leadership and a culture that understands software, data and calculated risk. These capabilities reinforce each other; having two or three isn’t enough. Organizations need all four to move beyond individual AI experiments and scale agents across the enterprise.

Enterprise connectivity has a new purpose

Enterprise connectivity used to enable information to move between systems. In the agentic era, it increasingly enables software to reason and act across them. Organizations can see improvement in operations and service delivery, but it depends on infrastructure that supports connectivity between systems.

With the right connections in place, agents can eliminate manual handoffs across complex workflows, accelerate decision-making and help organizations scale expertise and services without adding another layer to existing operations. That’s where I see the real competitive advantage emerging.

As agents and models become more capable and widely available, access to the technology itself will become less of a differentiator. What will separate organizations is their ability to build systems around Agentic AI, enabling it to work dependably across the systems that run their business.

The organizations that gain the greatest advantage from Agentic AI may not be those with the most agents deployed or even the best models, but those that have invested in the infrastructure, integration practices and engineering capabilities around them.

For IT leaders mapping out the next five to ten years of computational strategy, the true business value of quantum will not be unlocked by independent quantum processors operating in a vacuum. Instead, the future lies in the seamless orchestration of hybrid cyberinfrastructure—where quantum processing units (QPUs), graphics processing units (GPUs), and classical high-performance computing (HPC) environments operate in tandem.

This paradigm shift is exactly what is driving the latest strategic investments at the Pittsburgh Supercomputing Center (PSC).

Moving beyond standalone quantum systems

For years, the narrative surrounding quantum computing has focused heavily on the hardware timeline: counting qubits, minimizing error rates, and anticipating the arrival of fault-tolerant systems. While those milestones remain critical, Dr. Bruno Abreu, the Director of Research & Development at PSC, highlights a more immediate operational challenge: integration.

Enter TangleLab, a groundbreaking hybrid quantum-classical supercomputing platform led by the PSC. Backed by a $5 million grant from the U.S. National Science Foundation (NSF) and built in partnership with HPE and Rigetti Computing, TangleLab serves as a national testbed. Its core goal is to understand how QPUs can be tightly integrated with classical HPC systems to manage complex, multi-tiered workflows.

“We are not deploying a standalone quantum computer,” Abreu notes. “Our goal is to make TangleLab the prototype open platform for a future where quantum information processing and distribution are core elements of advanced cyberinfrastructure.”

For CIOs, this strategy underscores a vital truth: quantum will not replace your classical infrastructure. Instead, it will act as a highly specialized accelerator. Just as GPUs revolutionized machine learning workloads by taking over parallel processing tasks from CPUs, QPUs will step in to handle highly specific, mathematically complex sub-problems that classical binary logic struggles to solve.

Defining “quantum utility” for the enterprise

A key theme of a This Week in HPC interview is the shift from pursuing abstract “quantum supremacy” to achieving practical “quantum utility.” In an enterprise context, quantum utility occurs when a hybrid system delivers an optimized solution—whether measured by speed, accuracy, cost, or energy efficiency—that classical infrastructure cannot achieve alone.

By pairing Rigetti quantum hardware with HPE advanced supercomputing architectures and classical GPUs, TangleLab is designed to tackle specialized optimization and simulation problems. The target application areas have direct corollaries in the commercial sector:

• Advanced chemistry and materials science: Accelerating molecular modeling for pharmaceuticals, energy storage, and manufacturing.
• Complex optimization tasks: Solving multi-variable logistical, supply chain, and financial risk problems.
• Cryptography and security: Preparing enterprise data architecture for the post-quantum encryption landscape.

By investigating these hybrid quantum-classical workflows today, PSC is laying the software and algorithmic groundwork required to make quantum resources composable and scalable for real-world scientific and industrial applications.

Cultivating a quantum-ready workforce

Beyond the technical hurdles of hardware and software integration, Dr. Abreu highlights a critical bottleneck that every CIO must confront: the talent gap. Developing applications for a hybrid supercomputing environment requires an entirely new blend of skills. Engineers must understand classical HPC optimization, AI/ML pipelines, and quantum circuit design simultaneously.

TangleLab is addressing this by functioning as an open educational resource, offering hands-on access, workshops, training, and consulting for researchers and students. For forward-thinking IT leaders, the takeaway is clear: the time to build a quantum-ready workforce is now. Organizations that begin upskilling their data scientists and infrastructure architects on hybrid frameworks today will be positioned to seize a definitive competitive advantage as quantum hardware matures.

3 key takeaways for enterprise tech leaders

1. Quantum is an accelerator, not a replacement: Do not wait for a standalone quantum savior. The future of enterprise compute is hybrid, requiring orchestrations between CPUs, GPUs, and QPUs working together on complex workflows.
2. Focus on practical utility over theoretical supremacy: Look for immediate areas where “quantum utility” can optimize existing business processes—such as logistics optimization, molecular simulation, or financial risk modeling.
3. The workforce must be upskilled today: The transition to quantum-classical computing is as much a human talent challenge as a hardware one. Enterprise IT leaders should proactively build pipelines and training programs around hybrid computing concepts.

Listen to the full episode

To dive deeper into how the Pittsburgh Supercomputing Center is pioneering the integration of quantum technologies into the modern supercomputing environment, listen to the complete discussion with Dr. Bruno Abreu on This Week in HPC Episode 404: Quantum at PSC on SoundCloud.

The Pittsburgh Supercomputing Center (PSC) actively incorporates AMD architecture across its HPC platforms. Bridges-3, is slated to be built by HPE and will leverage high-core-count AMD EPYC™ CPU nodes for massive parallel processing. The center operates an AMD Heterogeneous Accelerated Compute Cluster (HACC), which features dual AMD EPYC 9654 96-core processors paired with 16 AMD Instinct™ MI210 GPUs and 8 AMD Alveo™ V80 compute accelerator cards. Bridges-2, relies on HPE Cray architecture, deploying AMD EPYC 7742 64-core processors (128 cores per node) across its primary computing resources. Learn more at https://www.psc.edu/. 

*************

HPE and AMD are partnering to deliver the next generation of AI and supercomputing infrastructure. Combining HPE’s deep expertise in large-scale system design with AMD EPYC™ processors and AMD Instinct™ accelerators, the two companies help customers build platforms capable of supporting the most demanding AI, modeling, simulation, and analytics workloads. Whether accelerating scientific research, enabling digital engineering, or training advanced AI models, HPE and AMD focus on what matters most: faster insights, greater efficiency, and the flexibility to scale. Together, they provide the technology foundation organizations need to solve complex problems, drive discovery, and create lasting business and societal impact.