Enterprise testing automation is becoming a unit-cost challenge. Each release adds workflows, integrations and regression paths while Quality Engineering budgets stay tightly controlled. The pressure appears in maintenance, contractor spend, rework and rising cost per release.

Agentic QE gives technology leaders another way to scale. Goal-oriented AI agents can support requirements analysis, test generation, workflow mapping, execution analysis and automation maintenance under human governance. The value comes from increasing testing capacity with slower growth in recurring effort.

The World Quality Report 2025 found that 89% of surveyed organizations were piloting or deploying GenAI-augmented QE, while 15% had reached enterprise-wide implementation. Respondents reported an average productivity improvement of 19%. The gap keeps executive attention on operating economics, governance and integration quality.

What Agentic QE Changes Financially

Agentic QE extends AI test automation beyond isolated tasks by applying goal-oriented agents across requirements analysis, test generation, workflow mapping, execution support, maintenance, and quality intelligence.

For QE leaders, that can release hours spent creating and repairing test assets. For engineering leaders, it can expand release capacity. For CIOs and finance teams, the key measure is validated delivery per dollar of QE spend.

Why Enterprise Test Automation Develops a Cost Ceiling

Automation makes high-volume regression practical, yet every automated asset creates an operating requirement. UI changes, API updates, new acceptance criteria and evolving integrations can trigger script updates, reruns and failure analysis across mature test estates.

That work behaves like a maintenance tax on delivery. Time spent repairing automation is unavailable for new coverage, exploratory testing or release readiness. As regression scope grows, maintenance can push the cost curve upward.

The executive metric is validated delivery capacity per dollar of Quality Engineering spend. It connects QE activity to technology productivity and unit cost.

Four Cost Levers to Measure

- Test creation: Agents can turn requirements and user stories into candidate scenarios and automation faster, allowing specialists to spend more time on business logic, edge cases and risk.

- Maintenance: Self-healing and change-aware automation can reduce the recurring effort tied to selectors, workflow changes and broken regression paths. Track maintenance hours released back to delivery.

- Earlier risk detection: Per industry research post-release defects can cost up to 15 times more to fix than issues resolved early in development. Earlier detection protects developer capacity, release schedules and support costs.

- Headcount elasticity. Agent-supported testing can increase the amount of coverage and release volume a team supports before additional staffing or outsourced capacity is required. This is often the clearest finance-facing benefit.

What Finance and Technology Leaders Should Measure

These measures create a shared language across QE, engineering and finance. Script counts describe activity. Unit economics show whether the testing operating model is becoming more efficient.

Build the ROI Case Around a Real Baseline

A baseline-led model ties the investment decision to the actual environment. Labor mix, automation maturity and release cadence vary widely, so ROI from AI test automation programs should come from measured change.

A focused pilot should target a high-cost QE workflow, apply agents inside the existing toolchain, and compare effort, coverage, cycle time and quality against the baseline. Enterprise-wide scale still depends on integration, privacy, reliability and skills.

The Business Case for Agentic QE

Enterprise software portfolios will continue adding integrations, workflows and release volume. Quality Engineering needs an operating model that can absorb that growth while keeping the incremental cost of validation under control.

Agentic QE can move repetitive work across requirements analysis, test generation, maintenance and execution intelligence toward AI agents, while people retain control over business risk, governance, exceptions and release confidence. The financial case becomes stronger when leaders can show lower recurring effort, higher delivery capacity and a measurable improvement in unit cost.

For organizations evaluating the model, AppsTek Agentic QE Services provides one implementation perspective, while the Agentic AI adoption in QE checklist can help structure internal readiness discussions.

Frequently Asked Questions

It can reduce repetitive effort across test design, automation creation, maintenance, failure analysis and regression execution. The financial value appears through lower maintenance hours, lower cost per validated requirement, avoided external capacity and more release volume from existing teams.

Cost per release, cost per validated requirement, regression maintenance hours, outsourced QA spend, defect escape rate and release cycle time give leaders a practical view of the economics.

Establish a baseline for testing labor, maintenance, outsourcing, rework and release cycle time. Apply Agentic QE to a focused workflow, measure the change and compare the gain with implementation and operating cost.

Yes. A practical adoption model should layer agent-driven analysis, generation and maintenance into existing testing and CI/CD environments so enterprises can validate value without rebuilding the full toolchain.

Oracle has announced that Oracle AI Agent Studio, including the AI-native builder experience and AI Studio Skill, is available at no additional cost for Oracle Fusion Applications customers. Organizations should review current Oracle licensing documentation or consult their Oracle representative for environment-specific guidance.

Related Reading

About The Author

Myrlysa I. H. Kharkongor is Senior Content Marketer at AppsTek Corp, driving content strategy for the company’s digital engineering services to enhance brand presence and credibility. With experience in media, publishing, and technology, she applies a structured, insight-driven approach to storytelling. She distills AppsTek’s cloud, data, AI, and application capabilities into clear, accessible communications that support positioning and grow the brand’s digital footprint.

Moving an Oracle AI database used to begin with one question: how do we move it without disrupting production? That question still matters, but the decision is now broader. Oracle AI Database can run across OCI, AWS, Microsoft Azure, Google Cloud, supported on-premises environments, and Oracle-managed infrastructure inside the customer data center. The migration is therefore not only about where the data lands. It is about where the database should operate, how much of the operating model should change, and how to move without breaking the applications and processes that depend on it.

That makes Oracle database migration an architecture decision before it becomes a data-movement exercise. The target environment, database version, availability design, application dependencies, licensing, security controls, network path, and downtime tolerance all influence the migration method. The safest programs make those decisions before production data moves.

For OCI-led programs, AppsTek provides Oracle Cloud Infrastructure services across assessment, architecture, migration, modernization, and managed operations.

Why are enterprises moving Oracle AI database now?

For years, enterprises moved applications, identity, analytics, and integration platforms to the cloud while leaving Oracle databases on-premises. The database was often the hardest component to move because performance, availability, security, and downtime requirements left little room for error. Oracle multicloud services change that equation by allowing Oracle database services to run within major hyperscaler environments while preserving Oracle Database technology and familiar administration patterns, subject to the selected service and version.

Four pressures now tend to converge on the database layer: cloud strategies are reaching the final infrastructure tier, security and resilience requirements are increasing, infrastructure ownership continues to carry cost, and AI and analytics programs need easier access to operational data. These drivers do not mean every workload should move. They do mean the database should be reassessed in the context of the architecture around it.

What should you decide before an Oracle AI database migration?

The migration tool should not be the first decision. A successful plan starts by resolving four architecture questions in order. First, decide where the database should run. If the applications already sit mainly in AWS, Azure, Google Cloud, or OCI, placing Oracle AI Database close to that ecosystem can simplify connectivity. Workloads constrained by residency, sovereignty, or latency requirements may instead remain on-premises or use Exadata Cloud@Customer.

Second, select the region based on application latency, user location, data residency, availability design, and current service availability. Third, choose the service model. Exadata Database Service suits workloads that need Exadata performance with greater administrative control. Autonomous AI Database shifts more routine operations to Oracle. Base Database Service provides a flexible option for workloads that do not require Exadata-class infrastructure.

Finally, define what moves first. Build an inventory of database versions, host platforms, sizes, application dependencies, integrations, recovery configurations, compliance constraints, and business criticality. A nonproduction or disaster recovery environment is often a practical first wave because it allows networking, security, tooling, cutover, and rollback procedures to be proven before production.

How do you move Oracle AI Database to a new server or the cloud?

Whether the goal is to move Oracle AI Database to a new server or migrate it to a managed cloud service, the work follows four connected phases. Plan defines the target architecture, dependencies, availability requirements, licensing approach, and migration method. Prepare provisions the target, configures connectivity, checks compatibility, establishes performance baselines, and rehearses both cutover and rollback. Execute transfers or replicates the database, synchronizes changes where required, and performs the application cutover. Validate confirms application connectivity, performance, backup, monitoring, encryption, high availability, and disaster recovery before the new environment is accepted as production-ready.

These phases are intentionally connected. The target architecture determines the migration method. The migration method influences the downtime model. The downtime model determines how cutover and rollback must be rehearsed. Treating the phases as separate workstreams creates gaps precisely where migrations usually fail.

If the database move is part of a wider EBS, PeopleSoft, or JD Edwards transition, the application sequence should be planned with the database. See AppsTek’s Oracle Cloud Migration for EBS, PeopleSoft, and JDE for the application-specific migration layer.

Which Oracle database migration tool should you use?

Oracle provides several migration technologies, but Oracle Zero Downtime Migration (ZDM) and OCI Database Migration (DMS) are central to many cloud migration patterns. ZDM is commonly used when the team wants direct control over the migration host, method, cutover, and rollback. DMS provides a managed workflow that can orchestrate supported Oracle migration technologies and is particularly relevant when the target is Autonomous AI Database and the team wants Oracle to manage more of the migration process. Online and offline patterns depend on the source, target, version, platform, and downtime requirement.

Table of Contents

What Does AI Agent Testing Actually Validate

Why Testing Only the Final Answer Creates a Blind Spot

The Four-Layer AI Agent Testing Framework

How to Test AI Agents Step by Step

AI Agent Evaluation Metrics That Matter

Common AI Agent Testing Mistakes

How AI Agent Testing Fits Into the Development Lifecycle

How to Test AI Agents: A Practical AI Agent Testing Framework

AI agents create a different quality problem. They do more than generate an answer. An enterprise AI agent may retrieve data, select a tool, call an API, hand a task to another agent, retry a failed action, update a system or request approval before moving ahead.

A correct final response tells you only part of the story. The real question is whether the agent reached that outcome through an execution path the enterprise can trust.

That is where AI agent testing changes the Quality Engineering model. Testing has to evaluate the outcome, observable execution path, tool behavior, controls, stability and recovery behavior together.

What Does AI Agent Testing Actually Validate

AI agent testing evaluates whether an agent completes the intended task while using the right tools, following defined business rules, respecting its authority and producing enough evidence to explain its behavior

This is broader than checking whether the answer looks correct. Consider an agent that needs to retrieve an account balance and summarize it for a user. The response could be accurate while the agent first queries an unnecessary privileged system, encounters an authorization error, retries twice and eventually reaches the approved source. The user sees success, while Quality Engineering sees unnecessary risk.

A robust AI agent evaluation asks questions such as:

- Did the agent accomplish the intended business goal?

- Which tools did it select and were those tools permitted for the task?

- Were parameters and authorization scopes correct?

- Did required validation or approval steps occur?

- How did the agent behave when a tool failed?

- Did execution remain inside defined cost and latency boundaries?

- Can the observable sequence of events be reconstructed afterward?

In this framework, reasoning path validation refers to the agent’s observable execution trajectory: tool calls, state transitions, routing, retries, handoffs and control decisions. The focus is execution evidence rather than private model chain-of-thought.

Traditional QE remains essential for validating UI, APIs, integrations, performance and security. AI-powered QE builds on this foundation by using AI to accelerate test creation, maintenance, prioritization and analysis. AI agent testing extends assurance further by validating the agent’s decisions, tool use, execution paths, controls and runtime behavior.

Why Testing Only the Final Answer Creates a Blind Spot

Two AI agent runs can end with exactly the same answer and still carry very different operational risk. One run may use the approved source and follow the expected validation sequence. Another may call the wrong tool, hit a permission error, retry and recover through an alternate source.

An output-level assertion could mark both runs as successful. A trace-level evaluation can identify the recovered run as degraded because the agent selected the wrong tool, generated an avoidable failure and needed recovery before completing the task.

This becomes increasingly important as agents gain access to enterprise systems. OWASP identifies risks such as tool abuse, privilege escalation, excessive autonomy, memory poisoning, approval bypass and runaway tool loops. Its guidance also recommends structured adversarial testing before production and after material changes to tools, memory, retrieval, policies or model providers. OWASP AI Agent Security Cheat Sheet

The implication for enterprise QE is clear: agent quality depends on the integrity of the execution as well as the quality of the answer

The Four-Layer AI Agent Testing Framework

A practical AI agent testing framework needs to evaluate four connected layers: observability, tool behavior, consistency and guardrails. Together, these layers turn dynamic agent behavior into testable enterprise quality criteria.

Layer 1: Capture the execution trace

Testing begins with observability. Each test run should create a structured record of what happened across the workflow. Useful evidence includes scenario and model versions, tool requests and responses, state transitions, routing events, retries, approvals, errors, latency, resource usage and the final business outcome. The goal is to reconstruct the run accurately enough to locate the point where behavior diverged.

Layer 2: Verify tool calls and actions

Tool use moves agent testing beyond response quality. Validate tool selection, parameters, authorization scope, return handling, sequencing and intended side effects. Instead of forcing every successful run into one rigid route, define trajectory invariants: required actions, forbidden actions, approval checkpoints, allowed tool sets and retry boundaries.

Layer 3: Test consistency across repeated runs

An AI agent may make slightly different decisions each time a scenario runs. Variation is expected. The important question is whether it stays inside the acceptable operating envelope. Compare task outcomes, tool choices, critical trajectory events, control compliance, retry behavior, latency and cost across repeated runs. Sampling depth should follow business risk.

Layer 4: Test guardrails and boundary behavior

Routine scenarios show how the agent behaves when conditions are clean. Enterprise assurance also needs difficult conditions such as conflicting instructions, prompt injection through retrieved content, invalid tool responses, approval bypass attempts, privilege escalation and excessive retry loops. Success may mean asking for clarification, requesting approval, using a safe fallback or escalating to a human.

How to Test AI Agents Step by Step

A repeatable process makes AI agent evaluation easier to operationalize across releases and gives teams a consistent evidence trail for release decisions.

1. Define the business outcome and authority boundary Document what the agent is expected to accomplish, which data and systems it can access, what actions it can execute directly and where approval becomes mandatory.

2. Build a representative scenario set Cover routine workflows, edge conditions, tool failures, ambiguous requests, hostile inputs and previously observed production incidents.

3. Define outcome criteria and trajectory invariants Specify the business result plus the execution requirements that must remain true across valid routes.

4. Execute in a controlled environment and capture traces Version prompts, tools, model configuration, policies and test data so release differences can be diagnosed accurately.

5. Grade the outcome and execution separately Score task success independently from trajectory compliance so recovered failures stay visible.

6. Repeat runs and compare against a baseline Measure stability across representative scenarios and flag material changes in tool use, quality, controls, latency or cost.

7. Turn evaluation into a release gate Connect critical failures to CI/CD gates and feed production findings back into the regression suite.

AI Agent Evaluation Metrics That Matter

A single pass rate hides important information. A stronger AI agent evaluation scorecard combines measures that reflect the type of agent and the risk created by its actions.

Thresholds should reflect business impact. A read-only knowledge agent and an autonomous operational agent need different release requirements because the consequences of failure differ significantly.

Common AI Agent Testing Mistakes

Testing the answer while ignoring the execution

A correct response can hide an incorrect data source, excessive privilege, unnecessary retries or an approval gap. Evaluate both the outcome and the execution evidence.

Requiring one exact execution path

Agent workflows can have several acceptable routes. Test the conditions that must remain true across those routes.

Declaring success after one clean run

Probabilistic systems need repeated execution. Variation becomes measurable only after representative scenarios are exercised across enough runs to establish a useful baseline.

Ignoring retries, loops and efficiency

Functional success can still become operationally expensive. Track retries, tool calls, latency and resource consumption before scale magnifies inefficient behavior.

Treating production launch as the end of testing

Agent behavior can shift when models, prompts, retrieval sources, permissions, tools or user behavior change. Production evidence should feed the next regression cycle.

How AI Agent Testing Fits Into the Development Lifecycle

AI agent assurance works best as a continuous loop: Build → Evaluate → Deploy → Monitor → Refine → Re-evaluate

Pre-release testing establishes the approved baseline. Production monitoring then surfaces behavior that controlled test environments may miss. Incidents, near misses, unusual execution paths and new user patterns become inputs for the regression suite.

Material changes to the agent’s model, prompts, tools, retrieval layer, permissions, orchestration or governance policies should trigger targeted re-evaluation. This creates a feedback loop where production experience steadily improves test coverage.

How AppsTek Approaches AI Agent Testing

AppsTek treats AI agent assurance as a Quality Engineering problem with agent-specific evaluation layers. The objective is to make agent behavior measurable, governable and diagnosable while preserving enough flexibility for dynamic enterprise workflows.

1. Model the risk Define the systems, data, actions, approval requirements and potential business impact attached to the agent.

2.

An AI adoption framework is the operating model an enterprise uses to move AI from pilot to production at scale. The most effective frameworks combine two functions: an AI Center of Excellence, which sets strategy, governance, and standards, and an AI Factory, which builds, deploys, and monitors AI systems on a repeatable, industrial basis.

Most enterprise AI initiatives never get that far. According to Gartner, roughly 50% of generative AI proof-of-concept projects will be scrapped before reaching production. The reason is rarely the model itself, it’s usually unclear ownership, inconsistent governance, fragmented data, and no repeatable path from prototype to deployed system. A well-designed AI adoption framework closes that gap by giving strategy and execution separate, clearly defined owners that work in a continuous loop.

This guide breaks down what an AI Center of Excellence is, how it differs from an AI Factory, and how to structure an AI adoption framework that actually gets AI projects into production.

What is an AI Center of Excellence?

An AI Center of Excellence (AI CoE) is the centralized team responsible for enterprise-wide AI strategy, governance, standards, and skill-building. It does not build software. Its job is to decide how AI should be adopted across the organization, which platforms are approved, what data and privacy rules apply, how risk and bias are evaluated, and which projects are worth funding.

Who staffs an AI Center of Excellence:

- Chief AI Officer or equivalent executive sponsor

- Data governance and privacy leads

- Legal and compliance analysts

- Enterprise business strategists and risk officers

What an AI Center of Excellence owns:

- Approved cloud platforms and vendor selection

- Data privacy, security, and compliance standards

- Bias, transparency, and responsible-AI review criteria

- Enterprise-wide AI training and upskilling programs

How AI Center of Excellence success is measured: policy adoption rate, percentage of projects following approved standards, reduction in unsanctioned “shadow AI” tool usage, and regulatory compliance scores.

What is an AI Factory?

An AI Factory is the delivery engine that transforms an approved AI concept into a reliable, monitored production system. While the Center of Excellence determines what to build and the rules to follow, the AI Factory focuses on building, deploying, and operating it reliably, at scale, and cost-effectively.

Who staffs an AI Factory:

- Machine learning engineers and data scientists

- MLOps engineers

- Software engineers

- Product managers who translate business needs into technical requirements

What an AI Factory owns:

- CI/CD pipelines for model deployment

- Feature stores and centralized model registries

- Containerized, scalable compute infrastructure

- Continuous monitoring for model drift, data degradation, and latency

How AI Factory success is measured: time to deployment, model uptime, inference latency, deployment frequency, and return on investment.

AI Center of Excellence vs. AI Factory: Key Differences

Why You Need Both to Build a Working AI Adoption Framework

Neither function works well alone. A Center of Excellence without an AI Factory model produces policy documents and no shipped software. An AI Factory without a Center of Excellence ships fast but accumulates compliance risk, technical debt, and inconsistent standards.

An effective AI adoption framework creates a continuous handoff between governance and delivery. The Center of Excellence determines what should move forward and under what conditions. The AI Factory turns those decisions into production-ready systems. The cycle works like this:

- Prioritize

The Center of Excellence evaluates AI opportunities against business value, strategic priorities, risk, and feasibility.

- Build

Approved use cases move to the AI Factory, where teams develop them using standardized architecture, tools, workflows, and delivery practices.

- Run

The Factory deploys the solution into production and continuously tracks performance, cost, reliability, and risk.

- Learn

Production data flows back to the Center of Excellence, giving governance teams the evidence needed to refine standards, policies, and future investment decisions.

The result is a closed delivery loop that keeps AI moving. Ideas are evaluated, built, deployed, measured, and fed back into the next decision cycle.

That is what prevents pilot stall: a working proof of concept sitting in a sandbox with no clear path to production, funding, governance, or ongoing ownership.

How to Build an AI Adoption Framework in Four Phases

Phase 1: Assess readiness and align leadership

Audit current data infrastructure, technical talent, security posture, and the overarching organizational appetite for change. Define governance ground rules before any technological project starts.

Phase 2: Staff up the execution engine

Hire or reassign specialized talent directly into the AI Factory. Invest heavily in MLOps tooling, scalable cloud infrastructure, automated testing pipelines, and centralized model registries ensuring delivery remains fully repeatable.

Phase 3: Scale cross-functionally

Run the AI Center of Excellence and the AI Factory in parallel across multiple global business units. Invest strategically in enterprise-wide digital literacy ensuring technological adoption spreads across every single department.

Phase 4: Measure outcomes and refine

Track financial ROI, algorithm latency, deployment speed, and system uptime on the AI Factory side. Track compliance rates alongside specific risk metrics on the governance side. Use both data streams to refine the overarching framework continuously.

Conclusion

AI adoption needs more than a strong strategy or a capable engineering team. It needs an operating model that connects the two. The AI Center of Excellence sets the direction, standards, and governance, while the AI Factory turns approved use cases into production systems and feeds real-world results back into the next round of decisions.

That connection is what moves AI beyond pilots. The goal is to create a repeatable way to build, govern, operate, and improve AI solutions that deliver measurable business value.

If your enterprise is ready to move AI from strategy to production, AppsTek helps enterprises build the operating models and engineering foundations needed to take AI from pilot to production. Talk to our AI experts today.

Frequently Asked Questions

An AI adoption framework is a structured operating model, typically combining a governance function (AI Center of Excellence) and a delivery function (AI Factory), that enterprises use to move AI projects from prototype to sustained production use.

An AI Center of Excellence sets strategy, governance, and standards for AI across the organization. An AI Factory builds, deploys, and operates the AI systems themselves. One defines the rules; the other does the engineering.

A high failure rate for generative AI proofs of concept is driven less by model quality and more by unclear governance, fragmented data strategy, and the absence of a repeatable deployment process, exactly the gap an AI adoption framework is designed to close.

The formal team structure can scale down. A smaller organization may combine governance and delivery responsibilities in fewer roles, but the underlying functions, approval criteria, standards, and a repeatable build-and-deploy process, still need an owner.

On the governance side: policy adoption rate, reduced shadow-AI usage, compliance scores. On the delivery side: time to production, deployment frequency, system uptime, and ROI. A healthy framework shows improvement on both sets simultaneously.

About The Author

Myrlysa I. H. Kharkongor is Senior Content Marketer at AppsTek Corp, driving content strategy for the company’s digital engineering services to enhance brand presence and credibility. With experience in media, publishing, and technology, she applies a structured, insight-driven approach to storytelling. She distills AppsTek’s cloud, data, AI, and application capabilities into clear, accessible communications that support positioning and grow the brand’s digital footprint.

Three years into the enterprise AI buildout, the numbers should concern every leadership team that has signed off on the investment. Deloitte’s 2026 State of AI in Enterprise study found that only 25% of respondents had moved 40% or more of their AI experiments into production, while 54% expected it to reach that level within the next three to six months. MIT’s Project NANDA found that 95% of enterprise generative AI pilots deliver no measurable profit and loss impact, and S&P Global Market Intelligence reports that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% a year earlier. The ambition is clearly there. The conversion into production value is not.

That gap is often framed as a technology problem. I believe that diagnosis is increasingly wrong.

Across client conversations, I see a remarkably consistent pattern. An enterprise runs a strong pilot. The pilot works. It gets a case study, a demonstration, perhaps even executive visibility. Then momentum slows because the surrounding business has not changed with it. The workflow is still designed for human handoffs. Decision rights remain fragmented. Incentives still reward the old way of working. Governance arrives after the solution has already been built.

The AI works. The organization around it is not yet structured to operate it.

A year later, the enterprise may have twelve more pilots, several more platforms, and a much larger AI budget. Yet the number of scaled, production-grade use cases has barely moved.

The next phase of enterprise AI will not be won by the companies that accumulate the most models, copilots, or agents. It will be won by the companies that redesign how work, accountability, governance, and economics come together around them.

What Is an AI Operating Model?

An AI operating model is the connective structure that determines how AI actually functions inside a business. It defines who owns AI outcomes, how initiatives are funded and prioritized, how risk is governed, how data is made available, how systems are integrated, and how AI output becomes part of a business process rather than an additional layer beside it.

IBM has framed its own AI operating model around four connected systems: agents, data, automation, and hybrid infrastructure. The terminology will differ across enterprises, but the underlying principle is more important than the framework itself. AI has to move from being something the enterprise deploys to something the enterprise knows how to operate with rigor, accountability, and repeatability.

That distinction matters because many organizations have scaled access to AI faster than they have scaled the mechanisms needed to convert that access into value.

IBM’s CEO research offers a useful signal. Only 25% of AI initiatives surveyed had delivered their expected ROI, while just 16% had scaled enterprise-wide. Its 2026 CEO Study goes further, arguing that leaders making the most progress are rethinking decision rights, cross-functional collaboration, incentives, operating models, and end-to-end workflows around AI.

These are not simply adoption metrics. They are symptoms of a deeper operating problem.

The technology is advancing quickly. The organizational machinery required to absorb it is moving much more slowly.

Why Does Enterprise AI Adoption Stall?

Four reasons show up repeatedly, and each one reinforces the others.

An oft-cited RAND Corporation analysis puts the failure rate at more than 80%, roughly twice that of conventional IT projects, and Gartner’s 2026 research finds that only 28% of AI use cases fully meet their ROI expectations.

Fragmented ownership. AI often sits across several budgets at once: IT, operations, marketing, finance, innovation, legal, and individual business units. That may be manageable while teams are experimenting. It becomes a serious constraint when AI begins crossing functions and changing core processes.

The most valuable use cases rarely respect organizational boundaries. They move through systems, data domains, approval structures, and business units. If nobody owns the outcome end to end, accountability becomes diluted. Everyone can sponsor a pilot. Very few people have the authority to take a cross-functional use case all the way into production.

Use case sprawl. Enterprises often mistake activity for progress. Forty pilots can look more ambitious than five deeply operationalized use cases, particularly on a steering committee dashboard.

In practice, those forty pilots compete for the same integration specialists, data pipelines, security reviews, business SMEs, governance capacity, and leadership attention. The result is a portfolio that is wide but shallow. Resources remain distributed across experiments rather than concentrated on the few use cases capable of materially changing cost, revenue, risk, or customer experience.

Depth on five priority workflows can create more enterprise value than breadth across forty disconnected proofs of concept.

Incentives left untouched. Organizations frequently ask managers to embrace AI while continuing to measure them against performance systems created before AI entered the workflow.

That contradiction matters.

If a manager is rewarded for headcount growth, functional utilization, activity volume, or legacy productivity measures, they have little economic reason to redesign the work around AI. Training may increase awareness, but incentives determine behavior. Leaders cannot ask an organization to operate differently while continuing to reward it for operating exactly as it did before.

Governance bolted on late. Risk, compliance, cybersecurity, privacy, and legal teams are still too often brought into an AI initiative after a pilot has already demonstrated technical feasibility.

By that point, key decisions about data access, model behavior, human oversight, explainability, auditability, and third-party exposure have already been made. Governance then becomes a gate at the end of the process rather than an engineering input at the beginning.

That is backwards. Governance introduced late creates delay. Governance embedded early creates a path to production.

When The Operating Model Never Catches Up

The cost of this gap is not hypothetical. IBM spent over a decade and billions of dollars acquiring healthcare data assets to power Watson Health, positioning it as a breakthrough in cancer diagnosis. The technology was oversold in domains where training data was scarce and problems were poorly defined, and Watson for Oncology was abandoned by several hospitals after producing recommendations physicians described as unsafe and incorrect. IBM sold the business for a fraction of what it had invested, in 2022.

McDonald’s ran a similar experiment at smaller scale. Its AI-powered drive-thru ordering system with IBM had been running since 2021, but persistent accuracy problems with different accents and dialects were never resolved, and the pilot never expanded much beyond a small slice of its US restaurants. McDonald’s shut the program down in 2024 and restarted its search for a voice-ordering partner.

Klarna took the opposite path and still hit the same wall. In 2023 it deployed an AI-first customer service model that handled 2.3 million conversations in its first month, about 66% of all chats, while the company froze hiring and let attrition shrink headcount by roughly 40%. But executives later acknowledged the AI-only support had led to lower quality service, and by early 2025 CEO Sebastian Siemiatkowski reversed course, rehiring agents so customers would always have the option to reach a human.

None of these companies lacked access to capable AI. What they lacked was an operating model, clear ownership of quality and outcomes, governance built in before scale, and incentives tied to more than a headline metric, that could carry the pilot into a durable, production-grade capability.

What The Leaders Getting This Right Are Actually Doing

The companies moving furthest with AI are treating this as a management transformation, not a software deployment.

IBM’s 2026 CEO Study makes that point clearly. Its research shows that CEOs making greater progress with AI are actively redesigning decision rights, cross-functional collaboration, end-to-end workflows, and the balance between human judgment and AI-driven execution. IBM reports that CEOs who actively redesign how teams work together are more than twice as likely to have delivered on their business objectives.

The significance is easy to miss. The advantage does not come simply from having better access to AI. It comes from changing the organization around it.

Accenture provides one of the most visible examples of a company applying that logic internally. The company recorded $923 million under a business optimization program completed in fiscal 2026, including employee severance and asset impairments, while also undertaking a major operating model and talent transformation. Julie Sweet has described the organizational redesign as the largest operating model change in Accenture’s history. The company has also made AI fluency part of how employees are evaluated for advancement.

That matters because it moves AI out of the innovation agenda and into the management system. Skills, roles, organizational structure, career progression, and execution expectations begin changing together.

HCLTech is demonstrating another dimension of the same shift: the economics of delivery.

C. Vijayakumar has pointed to increasing non-linearity between revenue growth and headcount, noting that HCLTech had grown revenue while headcount remained relatively flat and that revenue per employee was increasing. More recently, he has described AI, automation, IP, and platform-led delivery as part of an evolving business model in which the same work can increasingly be delivered with fewer people.

For services businesses, that is a fundamental change.

August 1, 2026

All across Teekay, we regularly hire talented people to join us in our offices and aboard our ships and units. We take our recruitment process seriously, and we NEVER charge candidates any fees to apply for or secure a job with us.

Unfortunately, recruitment scams have become increasingly common. We are aware of fraudulent individuals and organizations impersonating Teekay or claiming to represent us by offering fake job opportunities in exchange for payment or personal information.

Please note: Teekay will never ask candidates to pay any fees at any stage of the recruitment process.

How We Hire:

- Via our website at www.teekay.com/careers

Every legitimate opportunity for both our shore-based and seagoing roles will direct you to our official Careers site.

- Directly through Marine HR and HR departments and representatives – people who work for Teekay.

These opportunities will always be linked to Teekay’s official website, social media channels (Facebook, Instagram, LinkedIn, X (formerly known as Twitter) or shared by someone using an @teekay.com email address.

- Occasionally through reputable 3rd party recruiters or manning agents, who NEVER ask for recruitment, placement, processing, visa, medical or company approved training fees from applicants.

NEVER proceed with an application if someone claiming to represent Teekay asks you to:

-

Pay an application, recruitment, placement, processing, visa, medical examination, training, document verification, security clearance, or travel fee as a condition of employment.

- Provide banking or financial information before receiving a formal offer.

- Share sensitive personal information without a legitimate recruitment purpose.

When in Doubt:

- Verify communications coming from a legitimate @teekay.com email address, as similar-looking domains may be used to impersonate Teekay.

- Confirm that the role is posted on our official Careers page – www.teekay.com/careers

- Be cautious of unsolicited messages received through social media or messaging apps.

-

Contact media@teekay.com if you’re unsure whether a recruitment communication is legitimate.

At Teekay, we live by our SPIRIT values. We believe in high standards with all our stakeholders inside and outside the company, so if you have doubts about the recruitment process, please double check website and email addresses, and the identity of people recruiting.

We wish you every success in your career journey and look forward to welcoming talented people who want to build their future with Teekay.

Please share this message with any friends who have been looking for new roles.

August 2, 2026

We mark the special occasion with the first steel cutting for a fully owned conventional tanker in many years.

Teekay recently marked an exciting milestone with the steel cutting of our new Suezmax tanker at Daehan Shipyard in South Korea. The ceremony brought together Teekay employees, shipyard representatives, and ABS Class as we celebrated the official start of construction.

This moment is especially meaningful as it marks the beginning of new opportunities as we celebrated the steel cutting of a 100% owned conventional tanker, reflecting an important step forward in the continued growth and renewal of our fleet.

We are grateful to our partners at Daehan Shipyard and ABS for joining us on this journey and helping bring this vessel to life. Once delivered, the vessel will be named “Torben Spirit” in honor of our founder, recognizing the legacy that continues to guide us today.

As construction gets underway, we look forward to welcoming Torben Spirit to the Teekay fleet in mid-2027.

August 13, 2026

When the Maritime and Port Authority of Singapore (MPA) offered a 12-week internship for Jonathon Lee and Yi En Cha, their world opened up to our vast and intricate maritime industry. What struck them the most was Teekay’s commitment towards Reliability and Passion for play.

On Learning Straight from the Desk

“As a data analytics student, I wanted to see what the numbers I work with actually look like in practice. That took me to Teekay’s Singapore office first, and then to London for the second half.

In Singapore, I worked mostly on procurement and commercial analytics under the guidance of Yi Chuen Ho, Regional Commercial Operations Manager and Sajeev Soman, Manager, Procurements & Contracts. I built and deployed a fleet procurement website end to end, with dashboards for spares delivery and port call costs to optimise our deliveries. I also built a machine learning workflow to forecast vessel earnings from voyage, market, bunker, port, and utilization data, and automated a previously manual charterer name-matching process. A lot of what I know about commercial and operations came from them who were both very patient and generous with their time. 

In London, Tanvi Narayan, Commercial Analyst, took me further into market analysis and extracting and making sense of commercial data. This led me to build a natural language chatbot which I then presented to our stakeholders with the team’s support. Tanvi pushed me to think harder about what the numbers were saying which helped me recalibrate my approach.”

– Jonathon

On Being on a Teekay Ship 

“Had the opportunity to step onboard Kanata Spirit for my first vessel visit and it was truly an eye-opening experience. 

Jasdeep Anand, Fleet Training Officer and Chief Engineer Shashikant Waghmare gave us a thorough tour of the vessel. Getting to see everything up close really brought what I’ve been learning in school to life. Even seeing how provisions are stored onboard was quite fascinating! The food prepared by the galley crew was really good too.

Beyond the technical side, it was great to get a better sense of the human side of shipping and how the crew work together to keep daily operations running smoothly. Really appreciated the warm welcome from Captain Krishna Mohan and the rest of the crew.

As everything was new to me, the team’s reassurance, company, and insights made my visit a lot less intimidating. Looking forward to more vessel visits and learning opportunities ahead in my maritime journey!

– Yi En

On Volunteerism in Teekay

“

A group of us from the London office took part in the Soup Kitchen London Charity Walk, covering over 23 kilometers and 5 hours on foot. It reminded me that small acts like giving out food and water can make someone’s day a little better. In Singapore, we organized a book drive and donated books and funds to Dignity Mama. It made me realize how simple actions like donating pre-loved books could create opportunities for others. 

In general, I really like that Teekay genuinely encourages giving back to the community, not just as a one-time activity but something we’ve continuously done over the years. Although Teekay offices are in different countries, the same culture of supporting the community is shared across both teams.”

– Yi En

On Hanging Out With Teekay Colleagues

“Exposure to daily operations taught me something no dataset could, which is how views get formed, challenged, and changed. But the parts I will remember most are the smaller ones like walking across London on the way home and slowly working out the city, lunches with colleagues where the conversation drifted well beyond shipping, badminton at lunchtime in the London office, which turned out to be the fastest way to get to know a team, and visiting Kanata Spirit, where the scale of the vessel and the work happening onboard made everything I had been analyzing on a screen suddenly feel very real.

I walk away with sharper technical skills, a much better feel for how a global shipping business actually works, and a genuine sense of the #TeekaySPIRIT in the people I met across both offices.

Thank you to Yi Chuen, Sajeev, Tanvi, the Kanata Spirit ship team, and to MPA and Teekay for the opportunity.”

– Jonathon

We would like to thank Jonathon and Yi En for their willingness to learn throughout the program and, more importantly, for their patience, engagement, and enthusiasm. We hope this experience has provided them some valuable insights to help guide them in their future careers.

See some images of Jonathan and Yi En’s Teekay journey in Singapore, London, and onboard Kanata Spirit:

August 31, 2026

And the Winners for this Quarter Are ….

Congratulations to the ships that are receiving an award this quarter! May all other vessels follow the example set by the winners for their hazard reporting.

Swipe through our photos of winning vessels who have reported the highest number of hazards in their teams

About the Hazard Reporting Awards

Teekay Tankers employs a cloud-based digital hazard reporting platform. The mobile-friendly platform is used by seafarers to report unsafe acts or unsafe conditions on board as they notice them. By identifying hazards early and often, we can intervene promptly and senior management is able to implement a corrective action outside of regular inspections on-board.

When hazards are reported, they enter our hazard database. This database recognizes and highlights trends. Identifying trends on board helps our vessels narrow their focus on specific areas to fix hazards before danger occurs. These trends are reported fleet-wide so all vessels can benefit from added foresight.

The number of hazards reported by every vessel is then reflected in our Vessel Balanced Scorecard – a digital dashboard that allows us to have a bird’s eye view of fleet safety. This data is essential to make our ships a safer place for our seafaring colleagues to live and work.

To continue encouraging our seafarers to report hazards as they notice them, we have gamified the reporting process. Our vessels are put into teams competing to report the most hazards every quarter. The winners are recognized publicly and awarded a prize.

Hazard reporting is a cornerstone of our achievements in safety and vetting and we are truly grateful to our dedicated seafarers for their participation in the hazard reporting process.

September 21, 2026

Reuniting sea and shore in a virtual space to learn, inspire and engage.

Every year, our Virtual Senior Officers Conference brings together colleagues from across the globe to learn, connect and share ideas. While separated by oceans and time zones, this event creates an opportunity for our Teekay family across sea and shore to come together in one virtual space.

This year’s theme, Reinforcing Excellence, The Teekay Way, highlights our commitment to accountability, continuous learning and an ownership mindset. More than a set of processes, The Teekay Way is how we work together to deliver excellence.

Watch the recap to revisit the highlights and celebrate what makes Teekay successful.