DEV Community: Improving

The Complete Guide to Choosing a Data Integration & Engineering Partner

Improving — Tue, 22 Sep 2026 12:01:17 +0000

A stalled analytics rollout. A legacy pipeline nobody wants to touch because it might break if you look at it wrong. A pile of point-to-point integrations that quietly fail every time a source system changes. For most enterprises, the moment they realize they need a data integration and engineering partner is also the moment they can least afford to pick the wrong one. This guide breaks down what actually separates a dependable delivery partner from a risky one, and where nine of the field's most established names land on that spectrum.

Executive Summary

Data integration and engineering is the discipline of connecting fragmented systems, moving data reliably between them, and shaping it into a form analytics, applications, and AI models can actually use. Done well, it replaces manual reconciliation and stalled reporting with a single trusted data foundation the rest of the organization can build on.

This guide walks through nine established data integration and engineering companies and outlines how to assess partners based on platform certifications, real-time and streaming capability, governance discipline, delivery model fit, and a proven, quantified track record. It also breaks down when to bring in outside help versus building in-house, with the goal of choosing a partner who can operate as a long-term data foundation rather than a one-off project team.

Who Is This Guide For?

Chief Technology Officer (CTO): Evaluating whether to build an internal data engineering team or bring in a partner to accelerate a stalled integration or modernization program.
VP of Engineering or Data: Comparing platform-specific delivery expertise (Databricks, Snowflake, Azure, AWS) across vendors before committing budget to a multi-quarter program.
Procurement or Sourcing Lead: Benchmarking pricing models, delivery locations, and contract structures across global systems integrators and boutique specialists.
Head of Data Governance or Compliance: Assessing which partners build lineage, quality, and access controls into delivery from the outset rather than as an afterthought.
Director of Analytics or BI: Looking for a partner who can unblock downstream reporting and AI initiatives stalled on unreliable or fragmented source data.

Each of these roles shares the same underlying goal: a data foundation reliable enough to support real-time decisions, not just periodic reports.

What Is Data Integration & Engineering & How Does It Work?

Data integration and engineering is the practice of connecting disparate systems, applications, and data sources, then designing the pipelines, architecture, and orchestration that move and transform that data reliably at scale. It covers everything from batch ETL jobs that run overnight to real-time streaming architectures that move events as they happen, and it underpins nearly every downstream analytics, reporting, and AI initiative an enterprise runs. Buyers typically engage a partner either to build this foundation from scratch, modernize a legacy pipeline that has become too brittle or expensive to maintain, or extend an existing platform to new data sources.

Common models and approaches

Batch ETL/ELT: Data is extracted, transformed, and loaded on a schedule, still the backbone of most enterprise reporting and data warehousing workloads.
Real-time and streaming integration: Event-driven architectures (Kafka, Confluent, Azure Event Hubs) move data continuously, supporting use cases like fraud detection and live inventory tracking.
API-led integration: REST, GraphQL, and iPaaS platforms connect applications directly, often replacing brittle point-to-point connections.
Cloud data warehouse and lakehouse modernization: Migrating legacy on-premises warehouses to platforms like Snowflake, Databricks, or Microsoft Fabric.
Managed or fully outsourced data engineering: A partner operates the pipeline and platform on an ongoing basis rather than handing off a one-time build.

Key Advantages of Data Integration & Engineering

Unified, trusted data by consolidating fragmented source systems into a single governed pipeline, giving business teams one accurate view of operations instead of reconciling conflicting reports.
Faster time to insight through automated, fully managed ELT pipelines that free engineering teams from constant maintenance work. Organizations using this model are nearly twice as likely to exceed ROI targets on the reclaimed time, according to Fivetran.
Reduced integration overhead by replacing custom point-to-point connections with reusable APIs and orchestration layers. IT teams currently spend 39% of their time building custom integrations, according to Salesforce, a burden that shrinks once integration patterns are standardized and reused.
Real-time decision-making enabled by streaming and event-driven architectures that move data continuously rather than in nightly batches, supporting operational use cases like fraud detection and inventory alerts.
Lower total cost of ownership as consolidated pipelines and reusable connectors reduce the duplicated engineering effort that comes with maintaining dozens of one-off integrations.
Stronger governance and compliance posture by centralizing lineage, access controls, and data quality checks in one architecture instead of scattering them across disconnected systems.

When to Use Data Integration & Engineering Services

Most organizations do not go looking for a data integration partner until one of the following starts costing them real time or money.

Analytics or BI initiatives are stalled because source data lives in disconnected systems that do not reconcile.
Legacy ETL jobs are breaking frequently or taking too long to run as data volumes grow.
A cloud migration or platform consolidation (to Snowflake, Databricks, Azure, or AWS) is on the roadmap.
Real-time use cases, such as fraud detection, personalization, or operational dashboards, require data faster than nightly batch jobs can deliver.
Compliance or governance requirements demand better data lineage and access control than current pipelines provide.
Internal engineering capacity cannot keep pace with the number of new data sources being onboarded.

How to Choose the Best Data Integration & Engineering Partner?

Use the criteria below to separate a partner who can execute from one who can only pitch.

Platform and hyperscaler certifications: Confirm the partner holds current certifications across the specific clouds and data platforms in your stack (Azure, AWS, GCP, Snowflake, Databricks). Certification depth is a reliable proxy for how quickly a team can operate independently in your environment.
Real-time and streaming capability: Ask whether the partner has delivered production streaming or event-driven architectures (Kafka, Confluent, Azure Event Hubs), not just batch ETL. This matters increasingly as 73% of organizations now operate hybrid cloud environments that require integration across heterogeneous platforms, according to Flexera.
Integration track record, not just staffing history: Review named case studies with quantified outcomes rather than generic staff-augmentation claims. A partner who cannot point to a specific before-and-after metric has not proven they can execute at scale.
Governance and data quality discipline: Evaluate how the partner builds lineage, access controls, and data quality checks into pipelines from day one, since bolting governance on later is far more expensive than designing for it up front.
Vendor evaluation transparency: Look for partners willing to share security, compliance, and integration-capability documentation early in the sales process.
Delivery model fit: Determine whether a fully offshore, hybrid onshore/nearshore, or fully onshore team best matches your governance requirements, budget, and time-zone overlap needs.
Cultural alignment and communication cadence: Assess how the partner runs stand-ups, status reporting, and escalation paths across distributed teams, since data engineering programs typically run 12 months or longer and depend on consistent collaboration.
Questions to ask directly: How quickly can your team ramp up on our existing Snowflake or Databricks environment? What happens if our data volumes double mid-contract, does pricing or team size change? Can you show us a reference client at a similar data maturity level to ours?

The right partner combines certified platform depth with a proven, quantified track record, not just headcount or a logo slide.

Top 9 Data Integration & Engineering Companies

1. Improving

Improving Enterprises delivers data integration and engineering services built around modern pipeline architectures, real-time and batch data flows, and enterprise system integration, drawing on named partnerships with Microsoft, Snowflake, and Databricks. Its engineers hold platform certifications across Azure, AWS, GCP, Databricks, and Snowflake, and its delivery approach spans streaming and event-driven architecture (Kafka, Azure Event Hubs), ETL and ELT modernization (dbt, Spark, Azure Data Factory), and API design and management. This combination of platform-agnostic delivery and certified expertise positions Improving as a strategic contributor to enterprise data integration and engineering initiatives across industries.

Why Is Improving the Best Data Integration & Engineering Partner?

Improving pairs consulting-led data strategy with engineering-led delivery, hybrid teams that combine onshore governance with distributed nearshore engineering capacity to keep large-scale integration programs both accountable and cost-efficient. Its platform-agnostic stance means it architects solutions around each client's actual data environment rather than a fixed technology stack.

NPS 90+: among the highest in modern enterprise technology services.
7.5-year average partnership length: built around long-term relationships, not one-off projects.
Global footprint: 7+ countries, 3 continents, 21 offices, and 2,500+ consultants delivering data and engineering programs worldwide.
Key verticals: healthcare, energy and utilities, financial services, manufacturing, retail, telecom, life sciences, and the public sector.
Platform stack: Azure Data Factory, Synapse, Purview, Snowflake, Databricks, Confluent/Kafka.
Relevant strengths: certified across Azure, AWS, GCP, Databricks, and Snowflake data-engineering tracks; proven streaming and ELT modernization delivery; platform-agnostic data architecture design.

"As a Confluent Elite Systems Integrator and Premier Partner, we are proud to showcase our deep expertise in data streaming, integration, and engineering."
— Ehren Seims, Lead, Global Alliances, Improving

Global Delivery Access

Improving operates from 21 offices spanning the United States, Canada, Mexico, Argentina, Chile, Guatemala, Costa Rica, and India, giving data integration and engineering programs follow-the-sun coverage across time zones. This distributed delivery model lets clients pair onshore data architects and governance leads with nearshore and offshore engineering teams sized to the scope of each integration program.

Proven Track Record

Integra Connect, a healthcare technology company serving oncology and precision-medicine practices, ran on a legacy SQL Server data warehouse that could not scale within Azure, driving long processing times, rising costs, and blocked real-time analytics. Improving migrated the warehouse to Snowflake, using dbt for transformation, Azure Data Factory for orchestration, and Power BI for reporting. The result: data processing times dropped from several days to minutes, sharply improving operational efficiency.

Strategic Advantage

Improving's strategic advantage in data integration and engineering rests on three verified pillars: named technology partnerships with Microsoft (Azure Data Factory, Synapse, Purview), Snowflake, and Databricks; a certified engineering bench spanning Microsoft Azure Data Engineer, AWS Data Analytics Specialty, GCP Data Engineer, Databricks Data Engineer Professional, and SnowPro credentials; and delivery experience across Fortune 500 healthcare, energy, and financial services environments. That combination of platform-agnostic certification depth and named partner status is what lets Improving design integration architectures suited to each client's actual technology footprint rather than a one-size-fits-all stack. Explore Improving's Data Integration & Engineering expertise →

2. Capgemini

Capgemini delivers enterprise-scale data integration and engineering programs anchored in two branded offerings: Databricks on IDEA, an industrialized delivery framework the firm says accelerates workload deployment by roughly 40% over traditional approaches, and Capgemini RAISE, which embeds generative AI directly into data pipelines built on Databricks infrastructure. The firm also holds a strategic Snowflake partnership for cloud data-warehouse migration and modernization work.

Quick Facts

Headquartered: Paris, France
Team Size: 420,000+
Key verticals: Financial services, manufacturing, retail/CPG, life sciences
Key platforms/technologies: Databricks, Snowflake, AWS, Azure, GCP
Relevant strengths: Industrialized migration accelerators, GenAI-embedded pipeline delivery, dual elite Databricks and Snowflake partner status

Why Consider Capgemini? Capgemini suits large enterprises that want generative AI capability built directly into their data engineering delivery, backed by elite-tier partnerships with both Databricks and Snowflake.

Talent Pool Access: Capgemini draws on a global workforce of more than 420,000 professionals across dozens of countries, giving programs access to specialized Databricks and Snowflake delivery teams regardless of region.

Proven Track Record: Capgemini holds global systems-integrator status with both Databricks and Snowflake, and publishes its "40% faster deployment" claim for Databricks-based data engineering work delivered through its IDEA framework.

3. TCS

TCS delivers data integration through its Cloud Data Integration Factory, a migration engine built specifically for large-scale moves and running on Informatica's Intelligent Data Management Cloud, alongside a Master Data Management Center of Excellence for hybrid MDM programs. The firm has held Informatica Global Systems Integrator status for multiple decades, layering Talend, Apache Airflow, and cloud-native platforms like Databricks and Snowflake on top of that core delivery model.

Quick Facts

Headquartered: Mumbai, India
Team Size: 600,000+
Key verticals: Finance and insurance, manufacturing, retail, life sciences and health, aviation and transportation
Key platforms/technologies: Informatica IDMC/IICS, Talend, Apache Airflow, Databricks, Snowflake, Microsoft Azure
Relevant strengths: In-house MDM Center of Excellence, cloud migration factory (CDIF) built for large-scale legacy moves, multi-decade Informatica GSI relationship

Why Consider TCS? TCS fits organizations running complex, multi-decade legacy environments that need a partner with an established master-data-management practice and a cloud migration factory built for exactly that kind of legacy complexity.

Talent Pool Access: TCS operates one of the largest global delivery workforces in IT services, giving clients access to specialized Informatica, Databricks, and Snowflake delivery pods across multiple time zones.

Proven Track Record: TCS has published data-integration case studies for Alstom, unifying data across the transportation manufacturer's operations, and Equifax UK, supporting the credit bureau's data modernization program.

4. Wipro

Wipro built the Wipro Data Intelligence Suite specifically to migrate enterprises off Hadoop and legacy warehouses such as Teradata, Oracle, and SQL Server onto Databricks lakehouses, including a Unity Catalog upgrade path. In 2026 the firm stood up a self-contained Databricks business unit to concentrate this migration expertise, building on more than 125 documented use cases across over 75 clients.

Quick Facts

Headquartered: Bengaluru, India
Team Size: 240,000+
Key verticals: Healthcare, aerospace, retail, energy, finance and back-office operations
Key platforms/technologies: Databricks (Global Elite), Snowflake, Microsoft Azure Data Lake, AWS Redshift, SAP
Relevant strengths: Legacy-to-lakehouse migration tooling built specifically for this shift (WDIS), 1,500+ Databricks-focused engineers, Global Elite Databricks partner status

Why Consider Wipro? Wipro is a strong fit for enterprises still running Hadoop or legacy on-premises warehouses, offering a proven, tooled migration path straight to a modern lakehouse instead of a from-scratch rebuild.

Talent Pool Access: Wipro backs its Databricks practice with more than 1,500 engineers and consultants, supporting delivery across its global footprint.

Proven Track Record: Wipro's Azure Data Lake deployment, documented directly by Microsoft, unified order-to-cash, finance, and record-to-report data for an enterprise client over an 18-month engagement, and its Databricks partnership spans more than 125 documented use cases across over 75 clients.

5. HCLTech

HCLTech runs its data integration and engineering practice through a Snowflake Center of Excellence, upgraded three times in eighteen months to Elite Services Partner status, alongside AIFoundry, a joint platform with Databricks spanning data modernization, migration frameworks, and AI-engineering pipelines. The firm pairs Snowflake and AWS in combined lakehouse delivery for enterprise clients.

Quick Facts

Headquartered: Noida, India
Team Size: 220,000+
Key verticals: Financial services, manufacturing, life sciences and healthcare, retail and CPG, telecom and media, public sector
Key platforms/technologies: Snowflake (Elite Services Partner), Databricks (AIFoundry), AWS, Matillion, Tibco
Relevant strengths: Elite-tier Snowflake Center of Excellence, combined Snowflake and AWS lakehouse delivery model, published Data and AI case-study library with quantified outcomes

Why Consider HCLTech? HCLTech suits enterprises standardizing on Snowflake who want a partner with elite-tier certified status and a track record of publishing specific, quantified data-modernization outcomes.

Talent Pool Access: HCLTech's Snowflake Center of Excellence concentrates certified data engineering talent specifically around Snowflake and AWS delivery, supported by the firm's broader global workforce.

Proven Track Record: HCLTech's published healthcare data-modernization case study on Snowflake and AWS documented a 7 to 8% increase in data-sharing revenue opportunity, a 5% improvement in clinical-trial site-enrollment data quality, and roughly 6,000 annual hours saved through automation.

6. N-iX

N-iX builds enterprise-scale ETL and ELT pipelines, batch and streaming data architectures, and production data warehouses and lakes, holding Premier or Advanced partner status with AWS, Snowflake, and Databricks specifically for this work. ISG has recognized N-iX as a Rising Star in data engineering, backed by a team of more than 150 certified data and cloud specialists.

Quick Facts

Headquartered: Valletta, Malta (engineering hubs based in Lviv, Ukraine)
Team Size: 2,400+
Key verticals: Finance, retail, healthcare, manufacturing, telecom, energy and utilities, logistics, automotive, agritech
Key platforms/technologies: Databricks, Snowflake, Palantir Foundry, AWS (Premier Tier), Microsoft Azure, Google Cloud, SAP
Relevant strengths: Premier-tier AWS and Snowflake partner status, in-house DataOps and observability practice, 150+ certified data engineers
Clutch Rating: 4.8/5

Why Consider N-iX? N-iX fits enterprises that want deep hyperscaler and data-platform partnership credentials paired with a data-observability practice built into every pipeline from day one, not bolted on afterward.

Talent Pool Access: N-iX draws primarily on its Eastern European engineering base, concentrated in Lviv, Ukraine, giving European and North American clients strong time-zone overlap alongside a certified data-and-cloud specialist bench.

Proven Track Record: N-iX built an end-to-end big data delivery pipeline for in-flight internet provider Gogo that used predictive analytics to cut the connectivity provider's no-fault-found equipment rate by 75%.

7. Itransition

Itransition runs a data engineering practice covering ETL and ELT pipeline development, data warehouse and lakehouse builds, and legacy BI and data-platform modernization, backed by one of the broadest documented tool benches in the category, spanning Informatica PowerCenter, Talend, Matillion, Fivetran, SSIS, MuleSoft, Azure Data Factory, AWS Glue, and Databricks.

Quick Facts

Headquartered: Denver, Colorado, USA (delivery hubs across 11+ countries)
Team Size: 3,000+
Key verticals: Healthcare, finance, manufacturing, retail, insurance, software and hi-tech, automotive, media and entertainment, logistics, telecom
Key platforms/technologies: Databricks, Snowflake, Informatica PowerCenter, Talend, Matillion, Fivetran, Apache Airflow/NiFi, AWS Glue, Azure Data Factory, MuleSoft Anypoint
Relevant strengths: Broadest documented ETL and integration tool coverage in the category, 15+ years of focused data-engineering delivery, combined BI-plus-data-warehouse offering
Clutch Rating: 4.9/5

Why Consider Itransition? Itransition is a strong match for organizations running a mixed, multi-vendor integration stack who need a partner equally comfortable across nearly every major ETL and integration tool, not locked into pushing one preferred platform.

Talent Pool Access: Itransition delivers from more than a dozen global offices spanning the Americas, Europe, and Asia, giving clients flexible time-zone coverage and access to specialists across its broad tool bench.

Proven Track Record: Itransition built a new ETL process and data warehouse for an international software company, migrating 150 BI reports and reducing the underlying dataset size by roughly two-thirds in the process.

8. STX Next

STX Next, Europe's largest Python-focused engineering firm, pivoted its backend engineering heritage toward data engineering in 2020 and now builds unified lakehouses and ETL systems on Databricks, Snowflake, and Microsoft Fabric, with documented pipelines processing more than 100 million records per day for enterprise clients.

Quick Facts

Headquartered: Poznań, Poland
Team Size: 500+
Key verticals: Financial services, manufacturing and industrials, healthcare, energy, EdTech, e-commerce
Key platforms/technologies: Snowflake, Databricks, Apache Iceberg, Microsoft Fabric, dbt
Relevant strengths: Largest Python-native engineering talent pool in Europe, nearshore Poland-plus-Mexico delivery model, enterprise clients including Mastercard, Decathlon, Canon, GSK, and Nestlé Purina
Clutch Rating: 4.7/5

Why Consider STX Next? STX Next suits teams that want Python-native data engineering talent paired with a nearshore delivery model built for European and North American time-zone overlap.

Talent Pool Access: STX Next delivers from Poland and Mexico, giving clients nearshore coverage across both European and North American business hours without offshoring the entire engagement.

Proven Track Record: STX Next built a production Microsoft Fabric lakehouse platform ingesting 110 source tables into 218 dbt models for Agro-Sieć, and built an automated reconciliation and unified data platform for UK wealth manager Mattioli Woods that saves more than 14,000 staff hours annually.

9. InData Labs

InData Labs is a boutique data science and AI firm whose data engineering practice builds data lakes, lakehouses, and warehouses across batch, streaming, and lambda architectures, primarily on AWS and Databricks, positioned as a technology partner for mid-market clients that want data engineering and applied AI delivered by the same team.

Quick Facts

Headquartered: Nicosia, Cyprus
Team Size: 80+
Key verticals: FinTech, healthcare and pharma, marketing and MarTech, transport and logistics, e-commerce, retail, manufacturing, gaming
Key platforms/technologies: Databricks, Delta Lake, AWS, Microsoft Azure, Apache Spark, Apache Airflow, Apache Kafka, Snowflake, dbt
Relevant strengths: Combined data-engineering and applied-AI/ML delivery under one team, AWS and Databricks technology partner status, close-knit boutique engagement model
Clutch Rating: 4.9/5

Why Consider InData Labs? InData Labs fits mid-market teams that want data pipelines built by the same team that will eventually feed machine learning models, avoiding a handoff between separate data-engineering and data-science vendors.

Talent Pool Access: InData Labs operates as a boutique team of more than 80 data scientists, engineers, and architects, favoring smaller, focused pods over large offshore staffing pools.

Proven Track Record: InData Labs built an anti-fraud data solution for Wargaming's Creative Research division, documented in a client review from the company's Head of Machine Learning, and delivered freight-rate prediction software for logistics firm AsstrA.

Building a Data Integration and Engineering Partnership That Scales With You

Data integration and engineering is not a one-time project. Pipelines, warehouses, and the data flowing through them need to keep working as data volumes grow, new sources come online, and reporting demands shift from static dashboards toward real-time, AI-ready answers. The organizations getting the most value from their data are the ones treating integration and engineering as an ongoing discipline, not a single migration project with a defined end date.

We have seen this firsthand in our own client work: a healthcare technology client's data warehouse migration to Snowflake turned multi-day processing runs into a matter of minutes, freeing analysts to focus on decisions instead of waiting on reports. The constraint in that engagement, as in most, was never ambition, it was whether the underlying data could be trusted, unified, and queried fast enough to act on.

That is the same gap Improving works through with clients across healthcare, energy, and financial services: unifying fragmented source data into a single foundation that reporting, analytics, and AI can actually rely on. Explore Improving's Data Integration & Engineering expertise →

Frequently Asked Questions

1) What is the difference between data integration and data engineering?
Data integration focuses on connecting systems and moving data between them, while data engineering covers the broader design, transformation, and operation of the pipelines and architecture that data moves through. In practice, most enterprise partners deliver both as a single combined service.

2) How long does a typical data integration or engineering engagement take?
Most enterprise-scale programs run from six months to well over a year, depending on the number of source systems, the complexity of transformation logic, and whether the work includes a full platform migration. Smaller, single-pipeline projects can complete in a matter of weeks.

3) Should we choose a global systems integrator or a boutique data engineering firm?
Global systems integrators typically offer broader bench strength, established MDM and governance practices, and experience with very large, multi-year programs. Boutique firms often move faster, offer closer collaboration, and specialize deeply in specific platforms like Databricks or Snowflake. The right choice depends on program size, budget, and how much hands-on platform expertise you need versus scale.

4) What certifications should a data integration and engineering partner have?
Look for current certifications on the specific platforms in your stack, such as Microsoft Azure Data Engineer, AWS Data Analytics Specialty, Databricks Data Engineer Professional, SnowPro, or Google Cloud's data engineer credential. Certification depth signals how quickly a team can operate independently in your environment.

5) Can a data integration partner also support real-time or streaming data needs?
Not all partners have production streaming experience. Ask specifically about delivered event-driven architectures using tools like Kafka, Confluent, or Azure Event Hubs, rather than assuming batch ETL experience transfers directly to real-time use cases.

6) How do we evaluate a vendor's data integration track record?
Ask for named case studies with specific, quantified outcomes, such as a reduction in processing time or a measurable cost or efficiency gain, rather than general claims about experience or headcount. A partner who cannot point to a concrete before-and-after metric has not proven they can execute at scale.

How to Build an AI Business Case That Gets Executive Buy-In

Improving — Tue, 22 Sep 2026 11:59:20 +0000

I've sat across the table from a lot of AI champions pitching their leadership team, and the pattern that predicts whether the pitch lands has surprisingly little to do with the quality of the ROI model.

Every organization runs an informal social economy where attention and trust get priced like currency, and every ask draws down a balance. When you ask an executive to approve budget, reroute headcount, or absorb the political risk of backing something new, you are spending that currency against whatever balance you have already built with that person.

Most AI champions walk into the pitch with an empty account and try to make a large withdrawal. That's exactly what this blog post on building a fundable AI business case will help you fix.

What an AI Adoption Strategy Actually Has to Sell

An AI adoption strategy document lists use cases, timelines, and projected ROI. A strategy only moves budget if the room already trusts the person presenting it.

A technically sound AI adoption and transformation plan and a fundable pitch are two different documents built from the same material. Here, we will talk about building the second one.

Why a Business Case Still Gets Rejected

When someone else vouches for your work, the message arrives with no visible motive, so the listener takes it at face value. When you vouch for your own work, the motive is visible, and the listener discounts it because they can't separate the signal from your interest in being seen as the person who found the big opportunity.

Champions treat rejection as proof that their AI business case needed a stronger ROI model. Usually the model was fine. The room just didn't trust the person holding it, and no amount of additional modeling fixes that.

An AI champion pitching "this will transform how we operate" is making a self-referential claim about a project they're personally attached to. The more enthusiastically it's delivered, the larger the discount, because enthusiasm reads as motive.

The fix is shifting the weight of the pitch from claim to evidence, without giving up conviction.

A working prototype carries more weight than a slide.
A small result a business unit leader is willing to describe in their own words carries more weight than the champion's own testimonial.
A number that came from someone other than the person asking for the budget survives the room's discount, because the room can't apply the self-interest tax to a number they didn't hear from the interested party.

A regulated regional bank recently was living in this tension in real time. Two of its own executives were debating which AI use case to bring to the rest of leadership first. One was flashy and easy to demo, the kind that would get people excited. The other was harder to explain and far less visible, agents verifying multi-layered compliance testing on core banking transactions, but it returned the most value once you looked past the demo.

They needed one exciting example to get attention, but the less flashy compliance use case was the one most likely to win funding. Most champions get that balance wrong. A vision-first pitch may energize the room, but an evidence-first pitch is what survives the budget conversation.

Price the Pitch in Each Executive's Currency

A CFO, a general counsel, a CTO, and a CEO aren't weighing the same risk, and a pitch that treats them as one audience wastes the parts of the case that would have landed with each of them individually.

The CFO's currency is risk-adjusted AI ROI, and the operative word is adjusted.

A number without a downside case reads as a number nobody stress-tested. What lands is a range, an explicit statement of what has to be true for the low end versus the high end, and a comparison against what the same budget would earn doing something else entirely. CFOs approve capital that's been priced honestly far more often than capital priced optimistically.

General counsel's currency is pricing exposure.

A pitch that arrives without an AI governance and risk section reads as one that either skipped the work or is hoping nobody asks. Naming the exposure yourself, what data the system touches, what decision it's allowed to make unsupervised, what happens when it's wrong, converts the GC from a blocker into a collaborator.

That diagnostic work happens up front. The GC does not have to do it under time pressure after the project already has momentum.

The CTO's currency is technical credibility.

The CTO is checking whether the champion understands where the system breaks. A pitch describing only the upside sounds like it was written by someone who hasn't operated the thing yet.

Naming the failure modes, what happens under load, what happens with bad input, what the fallback is, reads as written by someone who has actually run it.

The CEO's currency is opportunity cost.

"This will make our team more efficient" rarely moves a CEO.

"This is the difference between being the company that did this in year one and the company still evaluating it in year three, while a competitor already moved" often does.

CEOs approve fewer efficiency projects than positioning moves, because efficiency is a departmental concern, and positioning is theirs to own.

Common Executive Objections to AI Investment

"We tried this before and it didn't work" is rarely a statement about the technology.

It's a statement that the last person who asked for this kind of investment already spent the organization's patience. The current champion is asking the room to extend credit against a balance the last attempt drained.

Defending the new approach on technical merits alone doesn't address that. What addresses it is naming, specifically and verifiably, what's different this time. Is it different data? A narrower scope? A different owner? A different failure mode that got fixed? The room needs something to check, not something to believe.

"We don't have the data for this" is often true.

Do not try to argue past it. Use it as a signal that the current AI use case is too broad, too early, or not ready for funding yet. Narrow the ask to what your data can support today. Then make the missing data work a separate budget item. That gives executives a smaller, clearer decision: fund a practical first step now, instead of rejecting a large idea that depends on data you do not have yet.

If this objection appears late in the process, it may mean the use case was chosen before anyone checked whether it was the best opportunity to pursue. That is exactly the problem identifying high-value AI use cases across the enterprise is meant to solve before the pitch gets built.

"This isn't core to what we do" is a positioning objection.

Arguing the technology is broadly applicable rarely moves this objection. Showing the competitive consequences of sitting out could change the CEO's view.

If there isn't a real consequence to name, the objection is probably right, and pushing past it anyway spends currency on an ask that doesn't deserve it.

Why This Also Fails the Quiet Engineer

A system that rewards evidence over enthusiasm still rewards the champions who already know how to produce evidence. But the quiet engineer with the technically strongest AI proposal in the building may never get a chance to pitch their solution.

This is where leaders can make the biggest difference. A strong AI idea may come from someone who does not have visibility, influence, or a track record with executives yet. If leaders only wait for ideas that already have that support, they may miss the best technical opportunities. CEOs and CFOs can fix this by giving promising, technically sound proposals a chance to prove their value, even before they have built political momentum.

The AI hype cycle already rewards volume and confidence over evidence more than most technology categories in recent memory.

A leadership team that funds whoever pitches loudest will systematically fund the wrong AI investments.
Better AI investments come from looking past the loudest pitch. Leaders should ask for clear evidence, and they should also give quieter, technically strong ideas a fair chance to produce it.

Improving's AI Strategy & Roadmap Assessment work exists because most enterprise AI failure traces back to exactly this kind of AI governance gap.

Earn the Credibility Before You Build the Slide

The champions whose pitches get approved almost always did something before the pitch that the room already knew about.

A small proof of value that a peer, not the champion, described favorably in a hallway conversation.
A pilot with numbers that survived someone else's skepticism before they reached the leadership meeting.
A track record of naming risk honestly in a previous project, so the current risk section reads as credible rather than performative.

Getting that pilot to produce numbers worth defending is its own discipline, which is why scaling AI beyond the pilot and earning the budget to do it are really the same conversation.

It's also why most pilots never make it past this stage in the first place. Improving's breakdown of why AI pilots fail to scale covers the same failure pattern from the delivery side.

Before you build the next slide, go find the last person who validated your pilot's results and ask them to say so, unprompted, in the room where the decision gets made. Check whether your risk section names a real failure mode or just gestures at "responsible AI." If you can't point to one number in your deck that came from someone other than you, that's the gap to close first. What would it take for your case to survive the room without you in it?

If you want a second read on your AI adoption strategy before you walk into that room, reach out.

FAQ

Our last AI pitch got rejected. Does this mean we start over?
You do not have to start over. Diagnose what got discounted, the evidence gap or the trust gap, before rewriting anything. Most rejected pitches need a narrower ask and one outside voice.

What if we genuinely don't have a validated pilot or an outside voice to vouch for us yet?
If you don't have a validated pilot or an outside voice to vouch for you, then that's the actual first project. A small, bounded pilot scoped specifically to produce a number someone else can defend. Don't pitch the big case until you have it.

How long does it take to build this kind of credibility?
Building credibility takes long enough that it has to start well before the budget cycle you're targeting. Think in quarters, not weeks. A pilot that wraps the month before the pitch rarely has time to collect outside validation.

Do all four executives need a fully separate pitch, or can we combine some?
A CFO and a CEO can often share a room, but the risk-adjusted framing and the competitive framing still need to appear as distinct sections.

Right Way to Onboard an AI Coding Agent

Improving — Tue, 22 Sep 2026 11:58:08 +0000

When you hire a new engineer, you spend time teaching them how your organization writes code. You show them your standards, your patterns, and why you do things in a certain way. You do this because you know that without it, they'll write code that works but doesn't belong, like putting the implementation of a service method in the repository, or reimplementing business logic rather than using the existing service to do it.

AI has the same problem. The agent wasn't in the meetings where you discussed and decided on your architecture. It doesn't know what "the right way" means in your context. If you don't tell it, it will do what it thinks is right, which is usually whatever was the most common and popular approach on the internet.

You need to onboard the AI agent and help it by capturing context. You'll have to write down what "the right way" actually means. But don't just document everything. You'll spend a thousand dollars generating documentation that only increases your token costs.

Providing Context to Onboard an AI Agent

The goal of providing context is to provide the knowledge that matters with consistency, so the AI coding agent can onboard successfully.

Here are a few ways to do it:

1. Start with coding standards

Different code serves different purposes.

Production code should be succinct, while test code should be descriptive. Less code in production means fewer bugs, less cognitive load, and less token spend.
Test code is different, and when a test fails, you want it to immediately reveal what went wrong. So test names should be descriptive enough to reveal the intention.

That information shows up in your standards, not just the hows, but the whys too.

2. Your architecture patterns matter

You want the agent to follow your design decisions, including the rationale behind why you chose one approach over another. This is where Architectural Decision Records (ADRs) come in.

An ADR captures the stuff everybody knows but nobody writes down. It takes the implicit understanding about where a given behavior should live and makes it explicit. For AI, this is critical, as the agent can read an ADR and understand not only what you decided, but why. That means it can continue that pattern, instead of the internet default.

3. A quick aside about guardrails

Context is what you document: your architecture, coding standards, ADRs, glossary of business terms. Guardrails are the constraints you encode. They are specific, enforceable guidelines, like "keep code coverage above 80%" and "code should be formatted like ..."

The AI agent needs to understand the intent before it can follow the "what" correctly. And you want those guardrails to run deterministically. But we can often conflate context with constraints in conversations. Rules like "keep code coverage above ..." are only suggestions if we include them in any document. This kind of context is best captured as a guardrail. Guardrails will be covered in future posts.

4. Structure your context file

For context management, you can't just dump all your documentation into a folder and hope the AI finds it. Suppose you have three documents about old patterns and one about the new pattern. Guess which one the AI is more likely to reproduce? Yeah, the more common one. The context you keep where the AI can find it has to serve the AI and the human.

Structure your documentation so the most important information comes first. An ADR starts with the decision and rationale. A coding standards document starts with the most critical rules. Documenting the thinking upfront would also reduce your AI costs, as input tokens are cheaper than output tokens. That means your AI spends fewer tokens hunting for the right file, because you fed it the critical information first.

5. Delete over deprecate

When you change a pattern, don't mark the old documentation as "deprecated." Delete it. Deprecated documentation is poison for AI. The agent will read it and think it's still valid.

When you delete it, don't just let it sit in the trash for 30 days. The AI agent can sometimes peek inside the trash as well. Remove the file from the directory or folder completely.

6. Start small

Pick one area, architecture or coding standards. Document what already exists and make it discoverable. Then iterate.

Each time the agent makes a mistake, ask yourself: did I document this? If not, document it. If you did, make the documentation clearer or more prominent.

Final Words

You're not trying to create a perfect knowledge base. You're trying to make your AI more consistent. Consistency comes from making implicit knowledge explicit. The work hasn't changed. The tool has changed.

Now the question is: what does your team know that you haven't written down yet?

Improving has been helping enterprises build AI systems that work the way they actually work, not the way the internet assumes they should. Talk to Improving's AI team to see where your context is thin and how to fix it.

AI Strategy & Roadmap Assessment: Choosing a Partner Who Can Actually Execute

Improving — Tue, 22 Sep 2026 11:57:16 +0000

88% of AI proof-of-concepts never reach production, according to CIO. The technology rarely fails on its own. What fails is the strategy behind it, built for a demo rather than for the data quality, governance review, and budget scrutiny a live system has to survive. Enterprises are rarely short on AI ideas; they are short on a credible plan for turning one into a system that runs unattended and holds up under audit, which is exactly what an AI strategy and roadmap assessment is supposed to produce. This guide breaks down what a credible AI strategy and roadmap assessment actually includes, compares ten companies that offer one, and, for a deeper look at why most AI strategies stall before reaching production, see this related breakdown of AI strategy and roadmap assessment failure patterns.

Executive Summary

An AI strategy and roadmap assessment is a structured engagement that evaluates an organization's business priorities, data readiness, technology foundations, and governance maturity, then translates the findings into a phased plan for where and how to deploy AI. Done well, it replaces scattered pilots and competing departmental requests with a prioritized set of use cases, a realistic timeline, and clear success metrics tied to business outcomes rather than technology for its own sake.

This guide profiles 10 leading AI strategy and roadmap assessment companies and outlines how to assess partners based on technical depth, industry experience, execution capability, cultural fit, and cost transparency. It also compares firms that lead with strategy against firms that pair strategy with in-house engineering delivery, and closes with a framework buyers can use to evaluate whether a prospective partner can move a roadmap from a slide deck into a governed, production-ready system.

Who Is This Guide For?

Chief Information Officers and Chief Technology Officers deciding whether to build AI strategy capability in-house or bring in outside expertise.
VPs of Data, Analytics, or AI who need a structured way to prioritize competing AI use cases across business units.
Heads of Digital Transformation responsible for turning AI pilots into enterprise-wide, governed deployments.
Procurement and Sourcing Leads running a formal evaluation of AI consulting vendors.
Business unit leaders sponsoring an AI initiative who need a partner that can speak to both business value and technical feasibility.

Each of these roles shares the same underlying goal: turning AI ambition into a roadmap that is specific enough to execute and disciplined enough to survive the transition from pilot to production.

What Is AI Strategy & Roadmap Assessment & How Does It Work?

An AI Strategy & Roadmap Assessment is a structured engagement that helps an organization understand where AI can create measurable business value and how to pursue it responsibly and at scale. Rather than starting with tools or models, the assessment evaluates business goals, data readiness, technology infrastructure, governance requirements, and organizational maturity before a single use case is greenlit. The output is a prioritized set of AI initiatives, a phased roadmap describing what to build and in what order, and the capabilities an organization needs at each stage to execute it. Because the assessment is grounded in real technical constraints rather than aspirational framing, the result is meant to be executable rather than merely directional.

Common engagement models include:

Discovery engagements (2 to 4 weeks): short, structured workshops that identify and validate a handful of high-ROI use cases for organizations still exploring AI's potential.
AI readiness assessments: evaluations of data quality, cloud infrastructure, governance maturity, and team capability that benchmark how prepared an organization is to deploy AI responsibly.
Governance and risk framework design: definition of policy frameworks, model auditability standards, and compliance alignment for regulated industries.
Phased roadmap development: multi-quarter plans with timelines, ownership, KPIs, and tooling decisions for scaling AI beyond an initial use case.
Organizational change enablement: training plans, communication strategies, and executive alignment work designed to accelerate adoption once the roadmap is approved.

Key Advantages of AI Strategy & Roadmap Assessment

Fewer stalled pilots. A structured assessment forces an honest look at data readiness and production requirements before development starts, which is why organizations already running AI in production tend to have addressed these questions early: 42% of enterprise-scale companies already have AI in production, according to IBM.
Measurable cost and revenue impact. A roadmap tied to specific business processes, rather than general AI enthusiasm, produces outcomes finance can defend: cost reductions of 15 to 20% in targeted processes have been documented in banking, according to McKinsey.
Clearer executive alignment. A shared roadmap gives business and technology leaders a single reference point for prioritization, reducing the number of competing, unfunded AI requests reaching the CIO.
Stronger data and governance foundations. Assessing data quality and compliance requirements up front avoids costly retrofits of governance and explainability controls after a model is already in production.
Better resource allocation. Ranking use cases by feasibility and business value keeps engineering effort concentrated on initiatives with a realistic path to scale, rather than spread thin across parallel pilots.
A defensible timeline. A phased roadmap sets realistic expectations for when value will materialize, reducing the risk that an initiative gets cancelled before it reaches maturity.

When to Use an AI Strategy & Roadmap Assessment

An AI strategy and roadmap assessment is not necessary for every organization at every stage, but a handful of situations make it close to essential:

An organization is stuck running AI pilots that never reach production.
Multiple business units want AI investment and there is no shared framework for prioritizing between them.
AI initiatives need to align with a broader enterprise architecture or cloud modernization effort already underway.
The organization operates in a regulated industry that requires documented governance, auditability, and explainability before deployment.
Leadership is preparing for AI-driven changes to how work gets done and needs a structured way to plan for it.
A first AI investment is being proposed and leadership wants an outside, evidence-based view before committing budget.

How to Choose the Best AI Strategy & Roadmap Assessment Partner?

Not every firm that claims AI expertise can back it up once an engagement moves past the workshop stage.

Technical depth and engineering capability: Confirm the consultants can speak credibly to cloud architecture, MLOps, and data engineering, beyond frameworks and slideware.
Industry experience and domain expertise: Regulatory and data patterns differ enough across healthcare, financial services, and manufacturing that generic AI experience does not always transfer.
Execution capability: Ask what share of the firm's recommended solutions actually reach production, and whether it builds or only advises.
Cultural fit and collaboration model: Check how the consultants work day to day and how well that matches your organization's pace and existing processes.
Cost and commercial transparency: Get a clear breakdown of what the base fee includes, what is billed separately, and what the payment terms look like.
Data readiness and governance rigor: Look for a firm that treats data quality and compliance as a first-class part of the assessment, not an afterthought.

Two questions worth asking directly: what percentage of your recommended solutions reach production, and can you share an example where you recommended against AI? The bottom line: a partner who cannot answer both in specific terms probably has not closed that gap before.

Top 10 AI Strategy & Roadmap Assessment Companies

1. McKinsey & Company

McKinsey & Company advises boards and C-suites on enterprise AI strategy through its QuantumBlack AI practice, which pairs classic strategy consulting with data science and machine learning execution teams. The firm is closely associated with its Rewired framework for AI-led transformation and publishes some of the industry's most widely cited research on enterprise AI adoption and ROI. Engagements tend to start at the board level, aligning AI investment with executive priorities before handing detailed implementation to internal teams or systems integrators.

Quick Facts

Headquartered: New York, NY
Team Size: 35,000+
Key verticals: financial services, healthcare, technology, energy, and the public sector
Key platforms/technologies: cloud- and vendor-agnostic AI advisory, QuantumBlack AI tooling
Relevant strengths: board-level access, AI ROI research, cross-industry benchmarking

Why Consider McKinsey & Company? McKinsey is the clearest choice for organizations that need AI strategy validated at the board and executive level before committing capital, backed by some of the most extensively cited AI adoption research in the industry.

Talent Pool Access: McKinsey draws on a global network of consultants and QuantumBlack data scientists based in major financial and technology hubs across North America, Europe, and Asia.

Proven Track Record: McKinsey's annual State of AI research is one of the most frequently cited sources on enterprise AI ROI and adoption trends, and the firm has advised AI strategy for Fortune 500 companies across banking, healthcare, and energy.

2. Improving

Improving Enterprises pairs business-aligned AI strategy work with the cloud and data engineering depth needed to carry a roadmap into production. Its AI Strategy & Roadmap Assessment combines AI readiness evaluation, use case identification, governance and risk framework design, and phased roadmap development, delivered by consultants holding Microsoft Azure AI Engineer, AWS Machine Learning, Google Cloud Machine Learning, Databricks Data Engineer Professional, and SnowPro certifications. As a Microsoft Solutions Partner for Data & AI and a partner to AWS and Google Cloud, Improving grounds its strategy recommendations in the same Azure OpenAI, Azure Machine Learning, Fabric, SageMaker, Bedrock, Vertex AI, and BigQuery environments its engineering teams use to build production AI systems.

Why Is Improving the Best AI Strategy & Roadmap Assessment Partner?

Improving does not treat an AI strategy engagement as a slide deck exercise: strategy without engineering produces a roadmap that never leaves the page, and engineering without adoption produces a demo that never reaches users. Every engagement, including Improving's own AI Readiness Assessment, is mapped against Improving's proprietary 8-stage AI Maturity Model, the same framework behind 250+ AI projects and $4.4B in ROI generated for Improving's AI clients. As a build partner with Anthropic, Improving brings Claude's safety-focused models directly into the production-grade agentic systems an AI assessment is ultimately meant to lead to, closing the gap between a strategy document and a system enterprises can trust to run autonomously.

250+ AI projects delivered: across strategy, agentic deployment, and production machine learning engagements.
$4.4B in AI-driven ROI: generated for Improving's AI clients to date.
400+ AI practitioners: across 21 offices in 7 countries dedicated to Improving's AI practice.
Key verticals: healthcare, financial services, energy, retail, automotive, manufacturing, and government.
AI platform stack: Microsoft Azure OpenAI, AWS Bedrock, Google Vertex AI, and Anthropic Claude.
Relevant strengths: a proprietary 8-stage AI maturity model, engineering-backed roadmaps, and production-grade agentic deployment.

"Our partnership with Cognition represents a shared vision for where software development is headed. We're not just handing teams a new tool. We're guiding them through a maturity progression that builds trust, governance, and operational readiness at every stage."
— Devlin Liles, Chief AI Officer, Improving

Global Delivery Access: Improving's AI strategy consultants draw on delivery teams across North America, South America, and India, carrying certified expertise spanning Microsoft Azure Solutions Architect Expert, Microsoft Azure AI Engineer Associate, AWS Machine Learning, Google Cloud Professional Data Engineer, and Databricks Certified Data Engineer Associate credentials. That range lets an AI strategy and roadmap assessment plug directly into whichever cloud and data platform an enterprise has already standardized on.

Proven Track Record: Improving's AI engagements span enterprises including Abbott, Home Depot, Honda, Toyota Connected, UnitedHealthcare, and Catalis across healthcare, retail, automotive, and government. In one engagement, Lakeshore Learning's sales team spent hours manually sourcing educational funding opportunities across government websites and spreadsheets. Improving built an agentic AI system that crawls live data sources, identifies relevant opportunities autonomously, and hands off to sales with full context, deployed in 90 days. The engagement delivered a 3x increase in qualified leads, a 90-day delivery timeline from kickoff to production, and a 42% improvement in operating speed.

Looking to achieve similar results with a trusted partner? Connect with our AI strategy experts to explore how we can accelerate your AI roadmap.

Strategic Advantage: Improving's AI Strategy & Roadmap Assessment work is anchored in its AI Maturity Model, an 8-stage model that has already guided enterprise clients through 250+ AI projects and $4.4B in generated ROI, and in its build partnership with Anthropic, which puts Claude's safety-focused models behind the agentic systems an AI assessment is designed to lead to. Backed by Microsoft, AWS, and Google Cloud partnerships and delivery experience across healthcare, financial services, retail, and manufacturing clients including Abbott, Home Depot, and Honda, Improving can move an AI assessment from readiness scoring into a governed, production-ready build without a second procurement cycle. Learn more about Improving's AI Strategy & Roadmap Assessment →

3. BCG

Boston Consulting Group advises on AI strategy through BCG X, its build-and-design unit that pairs traditional strategy consulting with in-house AI engineers and data scientists. BCG is closely associated with value-capture frameworks for AI investment, including its widely referenced 10-20-70 rule for allocating effort across algorithms, technology, and organizational change. The firm typically works alongside a client's internal teams rather than embedding full delivery squads on a long-term basis.

Quick Facts

Headquartered: Boston, MA
Team Size: 30,000+
Key verticals: financial services, industrial goods, consumer, healthcare
Key platforms/technologies: BCG X AI tooling, cloud- and vendor-agnostic advisory
Relevant strengths: value-capture economics, organizational change design, executive workshops

Why Consider BCG? BCG is a strong fit for organizations that want an AI strategy grounded in a specific value-capture methodology, rather than a general framework, and that need help quantifying expected ROI before committing budget.

Talent Pool Access: BCG X embeds AI engineers and data scientists alongside its strategy consultants, with hubs across North America, Europe, and Asia Pacific.

Proven Track Record: BCG has published extensively on AI value capture across banking, industrial, and consumer sectors, and its BCG X unit has grown into one of the firm's fastest-expanding practices.

4. Accenture

Accenture delivers AI strategy as part of a broader systems integration and managed services relationship, making it a common choice for enterprises that want one firm to handle strategy, cloud migration, and long-term AI operations. Its AI practice spans data engineering, MLOps, generative AI, and industry-specific AI accelerators built on Microsoft, AWS, and Google Cloud. Its edge is scale and global delivery capacity, not boutique strategic focus.

Quick Facts

Headquartered: Dublin, Ireland
Team Size: 700,000+
Key verticals: financial services, retail, telecommunications, manufacturing, public sector
Key platforms/technologies: Microsoft Azure, AWS, Google Cloud, SAP, generative AI accelerators
Relevant strengths: global delivery scale, systems integration, industry-specific AI accelerators

Why Consider Accenture? Accenture works best for enterprises that want AI strategy and multi-year execution from the same firm, especially where the roadmap depends on large-scale legacy system integration.

Talent Pool Access: Accenture operates delivery centers across more than 120 countries, giving it one of the largest global benches of AI and cloud engineering talent among the firms in this guide.

Proven Track Record: Accenture reports tens of billions of dollars in annual technology and AI-related bookings and has deployed AI accelerators across banking, retail, and manufacturing clients worldwide.

5. IBM

IBM Consulting positions AI strategy work around governed, production-ready deployment in regulated industries, drawing on the watsonx AI platform and decades of enterprise infrastructure experience. The practice emphasizes explainability, model risk management, and hybrid cloud deployment for clients that cannot rely solely on public cloud AI services. IBM strategy teams are usually paired with the company's own AI platform and infrastructure products, which can speed delivery while narrowing platform choice.

Quick Facts

Headquartered: Armonk, NY
Team Size: 250,000+
Key verticals: banking, insurance, healthcare, government
Key platforms/technologies: IBM watsonx, hybrid cloud, Red Hat OpenShift
Relevant strengths: regulated-industry governance, hybrid cloud AI, model risk management

Why Consider IBM? IBM makes the most sense for regulated enterprises, particularly in banking, insurance, and government, that need AI governance and explainability built into the strategy from day one.

Talent Pool Access: IBM Consulting draws on a global AI and hybrid cloud delivery organization spanning North America, Europe, and Asia, backed by IBM Research.

Proven Track Record: IBM Consulting generates roughly 21 billion dollars in annual revenue and has deployed watsonx-based AI governance and strategy engagements across banking, insurance, and public sector clients.

6. Deloitte

Deloitte's AI strategy practice sits inside its broader risk advisory and consulting business, giving it particular strength in AI governance, regulatory compliance, and audit-ready documentation alongside traditional use-case and roadmap work. The firm frequently advises on responsible AI frameworks tied to emerging regulation such as the EU AI Act. The size of the mandate determines the mix: smaller engagements lean on strategy consultants alone, larger ones add technology implementation teams.

Quick Facts

Headquartered: London, UK
Team Size: 450,000+
Key verticals: financial services, life sciences, government, energy
Key platforms/technologies: cloud- and vendor-agnostic AI advisory, responsible AI governance tooling
Relevant strengths: AI governance and regulatory compliance, audit-ready documentation, risk advisory integration

Why Consider Deloitte? Deloitte is a natural fit for organizations in heavily regulated sectors that need an AI strategy partner who can also stand behind the governance, risk, and audit requirements tied to the roadmap.

Talent Pool Access: Deloitte's AI and risk advisory teams operate across its global network of member firms, spanning North America, Europe, Asia Pacific, and Latin America.

Proven Track Record: Deloitte reported more than 70 billion dollars in global professional services revenue for fiscal year 2025 and has advised AI governance and strategy engagements across banking, life sciences, and public sector clients.

7. Appinventiv

Appinventiv is a digital product engineering company that has expanded from mobile app development into AI strategy and AI-native product design, helping mid-market and enterprise clients scope generative AI and machine learning use cases alongside custom application builds. The firm positions itself around combining AI strategy with hands-on product development rather than strategy-only advisory. Appinventiv has been recognized by Clutch among the top AI development companies globally.

Quick Facts

Headquartered: Noida, India
Team Size: 1,000+
Key verticals: fintech, healthcare, retail, logistics
Key platforms/technologies: generative AI, cloud-native architecture, mobile and web platforms
Relevant strengths: AI-native product design, mobile and web engineering depth, mid-market pricing

Why Consider Appinventiv? Appinventiv suits mid-market enterprises that want AI strategy scoped directly against a mobile or web product roadmap, rather than a standalone advisory engagement.

Talent Pool Access: Appinventiv operates from Noida with additional offices in the United States, United Kingdom, Australia, and the United Arab Emirates.

Proven Track Record: Appinventiv has ranked among Clutch's top 1% of global service providers for multiple consecutive years and has delivered AI and mobile projects across fintech, healthcare, and retail clients.

8. LeewayHertz

LeewayHertz is an AI consulting and development firm, now part of The Hackett Group, that focuses on generative AI, agentic AI, and machine learning strategy for startups, SMBs, and enterprise innovation teams. The firm builds custom AI strategy engagements around specific use cases such as AI copilots, autonomous agents, and blockchain-AI hybrid systems rather than broad enterprise transformation programs. LeewayHertz has worked with clients including ESPN, Hershey's, and NASCAR.

Quick Facts

Headquartered: Gurugram, India
Team Size: 250+
Key verticals: media and entertainment, consumer goods, healthcare, fintech
Key platforms/technologies: generative AI, agentic AI frameworks, blockchain
Relevant strengths: use-case-specific AI strategy, generative and agentic AI depth, Hackett Group backing

Why Consider LeewayHertz? LeewayHertz works well for organizations that already know the specific generative AI or agentic use case they want to pursue and need a focused strategy-to-build engagement rather than an enterprise-wide roadmap.

Talent Pool Access: LeewayHertz operates from India, with its parent, The Hackett Group, providing additional benchmarking and advisory reach across North America and Europe.

Proven Track Record: LeewayHertz has delivered AI and blockchain engagements for clients including ESPN, Hershey's, and NASCAR, and its 2024 acquisition by The Hackett Group extended its reach into enterprise benchmarking clients.

9. SoftServe

SoftServe is a digital consultancy and engineering firm with three decades of experience that has built a dedicated AI practice spanning AI strategy, data engineering, and machine learning delivery across healthcare, retail, and energy. The firm positions itself as a hybrid of strategic advisory and hands-on engineering, with clients citing long-term partnerships built on Agile delivery. SoftServe holds Clutch recognition backed by verified enterprise client reviews.

Quick Facts

Headquartered: Austin, TX
Team Size: 10,000+
Key verticals: healthcare, retail, energy, financial services
Key platforms/technologies: Microsoft Azure, AI/ML engineering, cloud-native architecture
Relevant strengths: long-term client partnerships, Agile delivery maturity, healthcare and retail AI depth

Why Consider SoftServe? SoftServe is the better choice for enterprises that want an AI strategy partner capable of sustaining a multi-year engineering relationship rather than a one-time assessment.

Talent Pool Access: SoftServe operates from dual hubs in Austin, Texas and Lviv, Ukraine, with additional delivery centers in Poland, Bulgaria, and Singapore.

Proven Track Record: SoftServe's Clutch reviews cite unique expertise and well-organized project management across healthcare and advertising technology engagements, and the firm has scaled to a global team of more than 10,000.

10. Cleveroad

Cleveroad is a software and AI product development company that has expanded into AI strategy and use-case scoping for mid-market clients, particularly in fintech, insurance, and logistics. The firm has built its reputation on Clutch Top 1000 recognition across multiple years, positioning it as a smaller-scale alternative to the global systems integrators in this guide. A strategy engagement here is usually lightweight and paired directly with Cleveroad's own development teams.

Quick Facts

Headquartered: New York, NY
Team Size: 250+
Key verticals: fintech, insurance, logistics, healthcare
Key platforms/technologies: cloud-native architecture, AI/ML product development
Relevant strengths: Clutch Top 1000 recognition, mid-market pricing, combined strategy-and-build delivery

Why Consider Cleveroad? Cleveroad is a strong option for mid-market companies that want AI strategy scoped directly against an affordable, combined build engagement rather than a separate strategy-only phase.

Talent Pool Access: Cleveroad delivers primarily through European engineering teams, with additional presence noted in Estonia alongside its US corporate entity.

Proven Track Record: Cleveroad ranked 11th on the Clutch Top 1000 in 2025 and earned Clutch Champion recognition in both Spring and Fall 2025, reflecting sustained client satisfaction across its software and AI engagements.

Building an AI Strategy That Survives Contact With Production

An AI strategy and roadmap assessment only pays off if it changes what actually gets built. The difference between the organizations profiled here and a generic slide deck is whether the roadmap accounts for data readiness, governance, and production constraints from the start, rather than discovering them after a pilot has already stalled. Enterprises that get this right tend to keep the plan grounded in specific business problems, size the effort honestly, and treat data quality as a prerequisite rather than an afterthought. That discipline is what separates a roadmap that becomes a budget line from one that becomes a working system.

We have seen this play out directly in our own work, including an agentic AI engagement for Lakeshore Learning that replaced a manual, spreadsheet-driven process for identifying funding opportunities with an automated system built on AWS and generative AI. The lesson: a strategy grounded in a specific, well-scoped business problem is what makes an AI investment defensible, not the raw power of the technology itself.

If your organization is evaluating an AI strategy and roadmap assessment, we would welcome the conversation. Learn more about Improving's AI Strategy & Roadmap Assessment or schedule a consultation to discuss your organization's AI roadmap.

Frequently Asked Questions

1) How much does an AI strategy and roadmap assessment typically cost?
Cost varies with scope and organization size. Short discovery engagements that validate a handful of use cases often start around $25,000 to $40,000, while comprehensive enterprise-wide strategy assessments can range from roughly $40,000 to $500,000 or more depending on data complexity, regulatory requirements, and the number of business units involved.

2) How long does a full AI strategy and roadmap assessment take?
Most assessments take four to twelve weeks depending on enterprise size, data maturity, and how many use cases are in scope. Highly complex organizations spanning multiple business units or regulatory regimes may require twelve to sixteen weeks for a comprehensive assessment.

3) What is the difference between an AI strategy consultant and an AI implementation vendor?
An AI strategy consultant focuses on identifying use cases, assessing readiness, and building a roadmap, while an implementation vendor focuses on building and deploying the actual system. Many of the firms in this guide, including the global systems integrators and Improving, combine both functions under one engagement, which can reduce the risk of a roadmap that internal teams are not equipped to execute.

4) How do we know if we are ready for an AI strategy engagement?
An organization is generally ready if it can answer yes to at least three of the following: there is executive sponsorship for AI investment, at least three business problems have been identified where AI could create value, a dedicated budget exists for AI initiatives, some level of cloud infrastructure is already in place, and leadership acknowledges the need for outside expertise.

5) Should we hire the same firm for AI strategy and AI implementation?
There is no universal answer, but hiring separate firms increases the risk of a strategy that internal teams cannot execute without significant rework. Organizations that want to reduce that risk typically look for a partner whose strategy team includes engineers who have deployed production AI systems, rather than a strategy-only firm.

6) What should a comprehensive AI strategy and roadmap deliverable include?
A comprehensive deliverable typically includes prioritized business use cases, a data and infrastructure readiness assessment, a governance and compliance framework, a phased execution roadmap with milestones and ownership, and a set of success metrics tied to business outcomes rather than technical benchmarks alone.

7) How do we measure the ROI of an AI strategy engagement?
ROI is typically measured through a combination of time-to-value metrics, such as days from strategy completion to first proof of concept, and business impact metrics, such as cost reduction in targeted processes, revenue lift, or productivity gains in specific tasks. A credible strategy partner should propose these metrics as part of the roadmap itself, not after the fact.

The Human Cost of Security in the AI Era

Improving — Tue, 22 Sep 2026 11:55:21 +0000

AI-enabled adversaries increased attacks by 89% year-over-year and software supply chain security is one of the areas taking the hardest hit. AI accelerated phishing and automated reconnaissance are shortening the time from initial access to impact. Recently, TeamPCP obtained credentials for a service account used to maintain Trivy's official repositories.

These attacks have been surfacing for a long time now, but who has been dealing with them?

The humans.

Every issue that lands in a queue, a compliance flag in Jira, or an infrastructure alert in your monitoring tool, eventually reaches a person. That person has to read it, understand it, decide whether it's real, and act on it. It could be part of their job. Or if they are OSS maintainers, it might have to be handled in the narrow window they have between their job and life.

In this blog post, we will walk you through the type of vulnerabilities engineers have had to patch, and the kind of issues they've faced since the arrival of AI. You'll also see a demo of how to turn that same AI around, using a local LLM to reason through an issue and give humans the right set of information to act on.

(This post accompanies Sonali's keynote at KubeCon + CloudNativeCon India 2026 on The Human Cost of Security in the AI Era.)

Gap of Knowing and Doing: Low Effort Issue

Knowing something might be wrong is the first step. Confirming it, understanding it, and deciding what to do about it is comparatively hard. That gap between the two is where the real human cost sits.

When someone raises an issue with the bare minimum effort, they've only done the "knowing" half. The "doing" half lands entirely on whoever picks it up next. That person now has to rebuild everything the reporter could have already checked: does this hold up, what's the real context, what evidence would settle it. Raising an issue this way, knowing full well the other person has finite hours, widens that gap because:

Time meant for building goes into validating instead: Every under-specified issue is a fresh investigation someone else has to start from zero.
Same ground gets covered twice: With no detail in the original report, the same claim can resurface later and cost someone else those same hours again.
Trust wears down on both sides: Short reports read as low effort; short responses read as dismissive. Neither side set out to cause that.
Head start gets thrown away: The reporter is usually closest to the problem when they find it. A hunch about the cause, or what they already tried, gives the assignee somewhere to start instead of a blank page.

A Real World Example of Project Maintainers

Authorized organizations, researchers, and vendors identify publicly disclosed vulnerabilities and assign them official tracking IDs, termed Common Vulnerabilities and Exposures (CVEs). The severity level of these CVEs is identified by a score assigned using methods like the Common Vulnerability Scoring System (CVSS), which ranges from 0.0 to 10.0, where higher numbers represent a higher degree of severity.

When an issue is reported claiming a vulnerability in a project, the maintainers of that project become responsible for vulnerability triage. They have to understand attack vectors they did not create, write a patch for a vulnerability they did not introduce, and create reports that will be scrutinized by hundreds of people, many of whom will not be empathetic.

A well-known example is a low-effort issue raised in the Kubernetes project. Maintainers there had to spend time just responding that the vulnerability did not impact Kubernetes. The maintainer's response made clear they didn't appreciate the bug finder's effort, calling it a "scanner spit out."

That exchange takes about four minutes to read. It almost certainly took the maintainers considerably longer to investigate, confirm, and write up the response. Multiply that by however many issues get filed against a project the size of Kubernetes in a given month, and the hours start to add up fast.

This isn't unique to maintainers. A security engineer closing a Jira ticket, an SRE chasing an alert with no baseline attached, same problem, different title, carries this same cost well beyond open source. Maintainers just happen to be where this shows up most visibly, because their work and responses are public. The cost itself belongs to anyone whose job includes a queue.

Why the Human Cost is Growing

The human cost of maintaining security was already real before AI entered the picture. It's compounding now for specific reasons:

Volume explosion: Due to AI, there are more attacks, which means more scanners running more often, flooding queues with findings humans have to triage to separate signal from noise.
Speed mismatch: AI-accelerated attacks move faster than humans can respond. Time from breach to impact is shrinking, giving maintainers less window to investigate and act.
Harder containment: Supply chain attacks now spread through dependencies maintainers can't manually map. Even "contained" breaches resurface later. The Trivy team thought they had it handled, then 76 version tags were force-pushed 19 days after the initial response.

Trivy Supply Chain Attack

In March 2026, a threat actor tracked as TeamPCP compromised Aqua Security's Trivy, one of the most widely used vulnerability scanners in the cloud native ecosystem, by stealing CI/CD credentials and pushing malicious binaries through Trivy's own GitHub Actions.

The attack (CVE-2026-33634, CVSS 9.4 CRITICAL) followed a pattern that's become familiar in supply chain compromises: the initial breach wasn't the end of it.

The Trivy team rotated credentials, published an advisory, and communicated with users. They believed they had contained it. They had not.

Nineteen days later, 76 version tags were force-pushed to the repository, re-exposing every pipeline still referencing a mutable tag instead of a pinned SHA. The same stolen access was later used against Checkmarx's KICS scanner and against LiteLLM, an unrelated project reachable only because it shared infrastructure with the first two.

Later analysis put the potential exposure at more than 2,500 organizations worldwide, including names like AWS, Samsung, and Cisco, none of whom made a mistake; they were simply reachable through a shared dependency.

This is the environment maintainers and engineers are triaging in now: more tools generating more findings, a wider and less mapped attack surface, and the same limited hours to sort signal from noise. Every under-specified report that lands in that environment adds directly to the pile, at exactly the moment the pile can least afford to grow.

Turning the Same AI Around

If AI is behind both halves of this problem, the volume of attacks on one side and the volume of low-effort scanner output on the other, the obvious question is whether it can be pointed at the half that actually helps.

Local LLMs are well suited to exactly this kind of triage. They can reason through whether a claim holds up in a specific context, the way a human would if they had the time.

This is a narrow, practical slice of agentic AI cybersecurity: not a general-purpose assistant, but a scoped agent that works through one CVE at a time and hands back a verdict.

The mechanism doesn't change with the domain. Give it:

A report and access to the relevant context
An alert and a monitoring config
A dependency bump and a changelog
A CVE and a codebase

It works through the question. What changes is what it reads and what question it's answering.

Reasons for using local models for CVE triage:

Data sovereignty & compliance: Your dependency tree and source code stay within your boundaries, required for GDPR, HIPAA, SOC 2, and internal security policies. You maintain direct control over what's analyzed and where.
Offline resilience: Local models work without internet access. Essential during incident response when the network itself may be compromised or unavailable.
No shared risk: Cloud systems don't fail in isolation. Prompt injection attacks have tricked services into exposing other customers' data. Running analysis locally eliminates that cross-customer exposure risk entirely.
Fewer credentials to defend: You eliminate the need to manage API keys for cloud services. Security researchers have found thousands of exposed API keys in public databases; fewer third-party credentials means fewer attack vectors.
Predictable economics: High-volume CVE triage becomes cheaper with local hosting than per-token cloud pricing. You trade fixed infrastructure cost for unlimited analysis runs.

Setting Up a Local Model to Audit CVEs

A Python tool for CVE triage reasons through vulnerabilities using everything needed to answer the question: the public CVE record, your project's dependency manifests, and the source code.

The workflow itself doesn't change from what a maintainer would do by hand. The only difference is where that reasoning happens: on your machine instead of an external API or from memory.

Prerequisites

Before running the tool, make sure the following are in place:

Python 3.8 or above
Ollama installed and running locally
Access to the tool's GitHub repository

1. Deploy a local model runtime using Ollama

Pull a model (qwen3.5:latest was used for this walkthrough), then start Ollama and confirm it's serving on the default port:

ollama list

curl http://localhost:11434/api/tags

If you see your model listed and a response from the API, Ollama is ready. It runs as a background service, so this endpoint stays available across sessions without restarting it manually.

2. Set up the tool and project to check against

Clone the tool and install its dependencies:

git clone https://github.com/cerebro1/vulnerability-check-kubecon2026.git
cd vulnerability-check-kubecon2026
pip3 install requests rich

For this demo, the tool was run against a sparse clone of the Kubernetes repository, pulling only the files needed to evaluate the CVE rather than the full repository:

git clone --filter=blob:none --no-checkout --depth=1 \
  https://github.com/kubernetes/kubernetes.git k8s-demo
cd k8s-demo
git sparse-checkout init --no-cone
git sparse-checkout set \
  vendor/go.opentelemetry.io/otel/sdk/resource \
  vendor/modules.txt \
  go.mod \
  .go-version
git checkout HEAD

3. Run the check against the local model

Invoke the tool with a CVE ID and the path to the project:

python3 diagnose.py CVE-2026-33186 ./k8s-demo

The tool auto-detects the first available Ollama model, so no additional configuration is needed unless you want to target a specific one.

Underneath, two files drive what the model does with that request:

system_prompt.txt sets it up as a security analyst who understands Go build constraints and is explicitly told to say NOT AFFECTED if the evidence supports it, even when an automated scanner has already filed a report.
reasoning_instruction.txt gives it a six-step scaffold: identify the package, find the version in use, locate the vulnerable code, assess exploitability given the project's runtime, determine blast radius, and state a verdict, written to generalize across any CVE and any language ecosystem.

The tool streams that reasoning to the terminal, and once it's done, a color-coded verdict banner shows the result.

You can get reliable results from a local model with a few adjustments:

Keep the reasoning scaffold structured and specific to the task, not open-ended
Limit what gets fed in per step (relevant files only, not the entire repository)
Lean on it for classification and pattern matching (does this apply, yes or no, with evidence) rather than open-ended exploratory analysis

Final Words

Before you raise an issue on any project, spend the thirty seconds it takes to ask:

Whether your findings hold up in that work's context
Whether the information you provide will help the resolver

The issue resolver's time matters exactly as much as yours, so do not give them the work to do that you already did. The supply chain we keep trying to secure is made of tokens, tags, and build pipelines, but it runs through people.

We need to make sure we do not let our maintainers pay a human cost for powering the cloud native ecosystem. That's the same principle behind the tool walked through above, and it's the same lens Improving's AI consulting team brings to every engagement: point the automation at the part of the job that's actually eating your team's hours, not the part that just adds a dashboard.

Agentic AI Cost Management to Reduce your AI Expenses

Improving — Tue, 22 Sep 2026 11:54:07 +0000

I burned $3,000 in API usage over two days last month. It's not because I ran an agent for a long time, but the problem I handed it was too big, and the agent responded exactly the way a good agent should: it spun up sub-agents, zoomed in, zoomed out, and filled the gaps in my instructions with money.

A CFO who has run cloud compute budgets for a decade has good instincts: meter usage, forecast by volume, negotiate rate cards. Those instincts fail on agentic AI, because your bill tracks context complexity, how much you hand the model before it starts working and which model tier you assigned to handle it, far more closely than it tracks output volume.

In this blog post, we will explore why AI agent cost management enterprise-wide keeps breaking the cost models finance teams already trust.

Understanding AI Agent Cost Management

AI agent cost management enterprise-wide means tracking what a task costs to specify and route, not just what it costs to run.

Cloud compute bill scales with usage you already control: instances, storage, bandwidth.
Agentic AI bill scales with ambiguity: how much context a model has to resolve before it can act, and which model tier absorbed that ambiguity.

If you skip this distinction, you may inherit a budgeting process designed for volume while the actual spend is being set by scope and routing decisions.

How Models Turn Prompts into Tasks

Large language models (LLMs) never read your prompt as language. They convert it into point vectors in n-dimensional space, and what the model "sees" is a density map of how closely related those points are.

Zoom out far enough and a prompt like "build a website" looks like one clean idea.
Zoom in and it fractures into a hundred unresolved decisions: React or Angular, Node or Rust, which schema, auth model, or deployment target.

There is a granularity sweet spot between those two extremes, and it is the single highest-leverage cost lever most organizations have never named.

Too broad a prompt, and the model has to zoom in repeatedly, doing exploratory work at every pass, spinning up sub-agents to cover the ambiguity you left behind.
Too fragmented, and you have paid the coordination tax of breaking one problem into pieces that never needed separating.

Either mistake shows up on the invoice as tokens. Neither mistake shows up as a line item you can point to before the bill arrives. Here is a diagnostic that costs nothing to run: if a task requires more than one phase of changes, or the exploration step needs more than one or two sub-agents, the task was too big before the model ever touched it. A well-scoped task is common and easy to solve. An ambiguous one recruits agents, and agents recruiting agents is where your cost curve stops being linear.

Common mistake: Teams treat "add more sub-agents" as a scaling strategy instead of a warning sign. If your exploration step needs three sub-agents, the fix is a smaller, better-scoped task next time, instead of better agent coordination.

The Twenty-Eight Times Problem

Identical engineering teams, working the same backlog, produce nearly identical output at a 28 times cost differential, depending on which models they defaulted to and how well they scoped their tasks.

The output was 28 times more expensive for no measurable difference in what shipped.

Part of this is explained by a market dynamic working against you. Anthropic raised prices by roughly 37% with limited public notice earlier this year.

Frontier-tier models have seen something close to a two-hundred-times cost increase at the top end over the past three months once you account for reasoning-token overhead in multi-step tasks.
The bottom tier of models, the ones capable enough for well-scoped implementation work, continues the multi-year trend of costs collapsing.

You are living inside two cost curves moving in opposite directions, and most budgeting processes were only built to track one of them.

The other part of the 28 times problem is behavioral, and it has a name worth remembering: spend follows shiny.

When a new frontier model ships, usage spikes toward it immediately, regardless of whether the task in front of anyone actually requires that capability.

On a recent internal benchmark, a frontier-tier model solved a bug fix task in roughly the same wall-clock time as a mid-tier model, at nearly 3 times the cost, for a benchmark improvement of about fourteen percent. Tripling the spend to gain the fourteen percent of effective gain would never survive a real procurement review, if anyone were running one.

You can get an honest review of where your own spend sits before it becomes an audit finding with our AI strategy and roadmap assessment.

Align Models with Project Scope

Nobody commutes to work in a Bugatti. The Honda Civic is fit for purpose at roughly 40 cents a mile. An F1 car, at somewhere near six figures per mile once you amortize the car and the season, is fit for purpose exactly once: when the job is winning a championship, not getting to the office.

Software teams have never had to make cost-related choices before, because a developer's brain and keyboard were a fixed cost. The wattage, the caffeine, and the laptop budget did not vary by task. Model tier costs vary by two orders of magnitude or more, and most organizations are still using the high-end models for tasks that could be done with low-tier models as well.

The corrective discipline for LLM cost optimization is aiming at the minimum model tier capable of doing the work, not the maximum tier available.

Identify the Hidden Cost of Agentic AI with Instrumentation

None of the above is actionable without measurement, and this is where most organizations' AI cost management enterprise programs stop before they start.

A provider-level usage dashboard tells you the total. It tells you nothing about which task types, which agent roles, or which activity categories are driving that total, and without that breakdown, every optimization conversation is a guess dressed up as a strategy. This is the same discipline platform teams are learning to design in from the start rather than bolt on after the bill arrives, a topic covered in building cost observability into cloud infrastructure from day one.

The instrumentation that matters runs on five dimensions:

Per-task cost: Every agent session, tied to a token count and task metadata, so you can eventually ask which task types are expensive and whether they should be.
Cost by agent role: Reveals whether a role is consuming resources proportionate to its function, or whether a documentation agent is quietly burning implementation-agent money because its context window is bloated. This is also where platform-level governance over AI agent permissions pays off twice, once for security and once for cost, because an over-permissioned agent is usually also an over-context agent.
Model-tier optimization: The floor-versus-ceiling decision described above actually gets made here, empirically, task by task, rather than by habit or by whichever model had the best launch post.
Activity category: The dimension that turns raw spend into a number a CFO can act on: cost per story point implemented, cost per defect remediated, cost per feature shipped, including the recursion and remediation cost when an adversarial review agent catches something and sends it back.
Cost per story point: It specifically includes the fixing, not just the first attempt, and it includes root cause analysis on where the fixing cost originated: a coding agent that produced bad output, or a task breakdown that was too ambiguous for any model to have succeeded against.

Attributing that correctly is the difference between blaming your model and fixing your process, and it is the same math behind why compounding errors in a chained autonomous pipeline are a cost problem as much as a reliability one, an idea closely related to engineering context deliberately instead of relying on vibes.

The CFO Conversation You Are Actually Having

The author uses this exact framing when teaching cost observability internally at Improving. Imagine you're the executive who owns the AI budget, and someone offers you 5x the output for 3x the cost. Would you take the deal?

Having run this scenario live in front of technical teams more than once, nobody takes the deal once it is stated plainly instead of buried in a model launch announcement.

Most CFOs who have ever managed an IT budget say no to that trade, and they are right to. No company, including the frontier labs themselves, lets its own internal inference spend scale without a ceiling. They meter it against their own budgets for the exact reason you should meter yours. The same logic that governs cloud cost management applies here: nobody gets a blank cheque on compute, and agentic AI spend is compute with an unpredictable ambiguity tax layered on top.

This is where evidence-grounded routing earns its name, and where the discipline starts to resemble an expense report. If a task escalates to a frontier-tier model, you should be able to produce the equivalent of a receipt that includes the evaluation score. The receipt should cover:

The mid-tier model failed this specific task
The prompt tried first
Why using a high-end model was the cheaper option once you priced in the alternative of a human doing it manually for a week

Keeping that receipt is the exact discipline that lets you defend an escalation to a stakeholder who is, correctly, skeptical of AI spend by default.

The organizations still writing blank cheques for AI tooling are going to run out of credibility with the people who approve budgets, the same way early cloud migrations burned credibility when lift-and-shift workloads got more expensive in the cloud than they had been on premises, before anyone rebuilt them to be cloud-native.

With AI-native cost management, you get the agentic economics by rebuilding how you specify and route the work, and by being able to prove it, task by task, every time someone asks what the spend bought.

Closing Remarks

If you want a quick gut check before your next budget review, pull the last five tasks your team escalated to a frontier-tier model. Ask whoever made that call to produce the receipt with the eval score, the lower-tier attempt that failed, and the actual cost delta versus the alternative. If that receipt exists for fewer than three of the five, you already know where the rebuilding has to start.

What would your own version of the twenty-eight-times number look like if you pulled the data instead of estimating it?

If you want a second set of eyes on that number, reach out and let's talk through what your own version of this audit would find.

Frequently Asked Questions

Do we need new tooling to start tracking cost of agentic AI, or can we start with what we have?
You can start tracking the cost of agentic AI with what you have. A spreadsheet that tags every agent session with task type, model tier, and token count gets you most of the way to the four-dimension instrumentation described above. Purpose-built tooling matters once volume makes manual tagging impractical, not before.

What if our team genuinely can't predict task complexity in advance?
If your team is not able to predict task complexity, then you must track it retroactively for a month before trying to route anything. You need the twenty-eight-times gap to be visible in your own data before you can act on it, and most teams are surprised by which task types are driving the gap once they look.

Is this only relevant to engineering teams running coding agents?
No. Any workflow where an agent has discretion over how much context to pull in, and how many sub-steps to take, carries this same risk. Document processing and research agents show the same cost curve as coding agents once ambiguity enters the picture.

How long before this pays for itself?
Most teams find their single most expensive task category within two weeks of instrumenting, and fixing just that one category typically covers the cost of building the instrumentation. The twenty-eight-times gap tends to concentrate in a small number of task types, not spread evenly.

Own the Interface: Why Enterprise AI Needs a Governed Gateway

Improving — Tue, 22 Sep 2026 11:52:45 +0000

I ask every client the same two questions before we talk architecture: Have you calculated what happens to your bill if your model provider raises prices 30% tomorrow? And have you forecasted what a 1,000% increase in token usage per employee over the next year does to that same bill?

Most of the time, teams haven't run either number. That's not a knock on them. Six months ago, a lot of us were paying $20 a month for predictable, flat-rate AI access, and it was easy to treat that stability as permanent. But now, enterprise API pricing runs per token. The rate changes with every model release, and the providers setting those rates have no obligation to make your budget easy to plan around.

That's the starting problem. Most enterprises call a frontier model API directly, with no abstraction layer in between. It works fine until the vendor changes pricing, changes usage terms, or deprecates the model you built around. At that point, the direct line your platform depends on becomes the most expensive line item on your roadmap.

The Exposure You're Carrying

Calling a vendor's API directly creates risk in a few specific places, and most teams are only tracking one or two of them.

Pricing is the obvious one. You're on a per-token rate that changes with every release, and you have no counterparty when it moves.

Availability is next. When a provider's API slows down or goes down, you inherit that outage. Cloud infrastructure teams plan for this kind of failure everywhere else in the stack. AI inference usually isn't planned for the same way, because there's only one path to it.

Data residency and data privacy are related but distinct. Residency is about where the inference physically runs, which matters the moment you're operating under GDPR or a similar regulatory regime and need to guarantee which data center handled a given request. Privacy is about who can see the data and whether it trains someone else's model. Terms of service on this have been inconsistent enough across providers that "trust the vendor" isn't a real answer for critical systems.

Vendor viability matters more than people want to admit right now. Nobody knows for certain which labs are still standing in three years. Planning your architecture around a provider that might not exist on that timeline is a real bet, whether or not anyone frames it that way internally.

Model risk rounds it out. Providers deprecate models fast. Anthropic has already moved from Sonnet 4 to Sonnet 5, and no one can tell you exactly when the older versions disappear. If you have applications or agents tuned to how a specific model behaves, you're riding out that model on borrowed time, whether or not your team has budget allocated to migrate it.

None of these are hypothetical. All six are already showing up on client roadmaps.

Our Solution: From Model as a Service to Platform as a Service

Here's the reframe that fixes this: we've spent the last decade or two building cloud infrastructure as platform as a service, and AI inference can work the same way. Instead of calling a provider's API directly, you can route through a hyperscaler like AWS Bedrock (the same logic applies to Azure AI Foundry or Google Vertex AI), which hosts Anthropic, OpenAI, and open-weight models behind one governed layer that you control.

The principle underneath this is simple. Whoever owns the interface to AI inference owns the leverage. Own that layer, and you control a lot more of your own destiny than you do renting a direct line to one vendor.

The Path, in Three Steps

You don't need to build all of this at once. Here it is broken into three stages, and each one is a real, usable stopping point on its own.

Step one: go direct to a hyperscaler

If your agents or harnesses currently point at api.openai.com or api.anthropic.com, pointing them at an AWS Bedrock endpoint instead is close to a one-line change. The API compatibility holds, so you send the same payload with a different authentication token and get the same inference back. There's no hardware to buy and no infrastructure migration. You immediately get model flexibility across providers and a consolidated, predictable billing relationship with the cloud you're probably already on. The limitation at this stage is that you're locked into that one hyperscaler's endpoint, without the routing intelligence that comes next.

Step two: put a governed gateway in front of it

This is where the architecture starts doing real work. A gateway sits between your applications, agents, and harnesses on one side, and your hyperscaler (or any inference backend) on the other. It receives the same API-compatible requests, logs everything about them (which prompt, which model, which system, which user), then forwards the request and streams the response back exactly as before. Because it sees every call before it leaves your environment, it can inspect prompts for policy violations, strip data that shouldn't leave the building, and route requests to a cheaper model when a cheaper model can do the job.

Step three: add multiple backends behind the gateway

Once the gateway is in place, it doesn't have to point at one destination. A request for a specific model can go to that model hosted on your hyperscaler, get routed to the vendor's own API when there's a reason to, or land on an equivalent open-weight model through a third-party inference provider for a speed or cost advantage. Your applications never know the difference, because to them an endpoint is an endpoint. Your infrastructure team decides where the traffic goes.

What the Gateway Buys You

The gateway itself is a small, self-contained piece of software (a UI, an API, and usually a Postgres-backed data layer) that you run on the same cloud as your models. Once it's running, a few capabilities show up that you don't get any other way.

Every user or team gets a virtual key instead of a raw API key. That key can carry a budget, a cost ceiling, and a model routing policy, so a $50-a-week limit for a team or a per-request cost cap for a product line becomes something you enforce technically instead of asking people to respect.

Model routing happens automatically once policy is in place. A simple request can get quietly routed to a cheaper open-weight model without the user ever knowing, at a fraction of the cost of the frontier model they asked for by default.

Data governance runs at the same layer. If a prompt contains something that shouldn't leave the environment, the gateway can strip it or block the request before it reaches any external provider.

Observability is the piece most teams don't realize they're missing until they have it. Provider dashboards give you basic usage charts, because their incentive is for you to use more AI, not less. A gateway gives you real visibility into who's using what, at what cost, with what outcome, across every team and every provider at once.

Several of these platforms also run an MCP gateway. This solves the real headache of giving an AI agent secure access to something like your Jira board, which usually means handing users more credential access than you'd like. A gateway can hold hardened, enterprise-grade authentication for that connection centrally, so users get the capability without anyone having to manage the credentials themselves.

You don't need to build this from scratch. LiteLLM was one of the first open-source gateways to mature into something enterprise-ready, and there are a dozen or more legitimate options now, from Bifrost to Kong AI to Portkey.

The Cost Metric That Actually Matters

Once you have this visibility, the conversation shifts from cost per token to cost per successful task. That distinction matters more than it sounds like it should. A hundred dollars in tokens can be worth its weight in gold, or it can be a hundred dollars wasted, plus the time lost cleaning up after it.

Two runs can burn identical token counts and produce completely different value. An open-weight model that costs a third of the price per token isn't a third of the cost if it needs twice as many tokens to finish the same task. Gateways are starting to build early versions of this metric in, and it's worth getting ahead of before it becomes the standard way finance asks about AI spend.

This Reaches Further Than Your Own Agents

The same architecture applies to the tools your developers already use. Claude Code, Codex, and similar harnesses point at a provider's API by default, but they're typically two or three configuration settings away from pointing at your gateway instead. On managed machines, that's a policy your IT team can push without users noticing anything changed, beyond the fact that their usage is now governed, budgeted, and visible.

It also solves a problem that looks like a software maintenance problem but is really a model lifecycle problem. Applications and agents outlive the models they were built against. When a provider sunsets a model your production agent depends on, migrating that workload happens at the gateway, on the virtual key, without touching the application code at all.

Deciding When to Move

Not every organization needs to reach step three on day one. Four variables tell you when to move:

Your current monthly AI spend
Your growth rate in tokens or active users over the past twelve months
Whether your applications have latency requirements a routing layer might affect
Whether compliance or data residency requirements already constrain your options

In practice, compliance is usually what accelerates the timeline. Even organizations with modest spend move to a gateway sooner once they realize it's the only way to demonstrate to auditors that their AI usage actually aligns with SOC 2, GDPR, or their existing cloud governance standards. Everyone else can build the case on cost and flexibility alone. For most teams, that means running your own numbers before picking a date.

It's also worth knowing there's a fourth option outside the gateway architecture entirely: running smaller open-weight models locally, on hardware you own. A high-RAM laptop can run models like Qwen with inference that never leaves the device, which sidesteps the residency and privacy questions completely in exchange for an upfront hardware cost instead of an ongoing cloud bill. It won't replace frontier-model workloads, but for the right use cases, it's a real option worth having on the table alongside the gateway.

Reminder: This Isn't a Vendor Swap

Swapping vendors gets you the same service under different pricing. Owning the interface changes your actual frame of reference: which models your teams can use, how you control spend, how you prove compliance, and how fast you can move when the leaderboard shifts again next quarter (because it will).

If you want help running these numbers against your own workload or working out where you sit on the path from a direct API call to a fully governed, multi-backend gateway, Improving would love to hear what you're building. Reach out to our team, and let's figure out what the right next step looks like for you.

Responsible AI: Building Ethics and Governance into your Strategy from Day One

Improving — Tue, 22 Sep 2026 11:52:05 +0000

In my two decades of working with Fortune 100 companies' stakeholders, I've seen a dramatic change in the way companies are shipping products in the new AI-native age. Most responsible AI programs I have reviewed share the same structural flaw: they run a one-time audit, produce a document, and call it governance. The audit gets updated once a year, maybe once a quarter if the organization is disciplined. Between audits, the model drifts, the training data shifts, and new features ship against the same model without a second look. Unfortunately, that's how responsible AI governance is treated: a snapshot bolted onto a system that never stops moving.

Let's assume a quarterly audit is a photograph, and a production system is a video. No number of increasingly detailed photographs substitutes for watching the video continuously, and every regulator who has ever asked a company to demonstrate ongoing compliance rather than point-in-time compliance already knows this.

Let me take you through building a responsible AI system where ethics and governance are part of your AI strategy from day one.

Understanding Responsible AI Governance

Responsible AI governance is the set of controls, measurements, and enforcement mechanisms that keep an AI system's fairness, privacy, and explainability behavior within limits chosen by the organization.

These are checked continuously rather than at a single point in time. It covers the full lifecycle:

How a model gets designed
What data feeds it
How its behavior gets measured after launch
What blocks a deployment when that behavior drifts

Frameworks like NIST's AI Risk Management Framework and ISO/IEC 42001 describe what responsible AI governance should cover. They say almost nothing about how to enforce responsible AI for enterprises between review cycles, which is the gap this piece is about.

Importance of Responsible AI Governance

Implementing responsible AI governance is critical because damage happens when you skip continuous enforcement, and there are long gaps between audits. A model that passed its fairness review at launch can drift into disparate impact eighteen months later, with no one noticing until a regulator, a journalist, or a plaintiff's attorney notices first.

Under GDPR's Article 22, under the EU AI Act's phased obligations, and under state laws like Colorado's rules on high-risk automated decisions, the expectation is shifting from "you had a policy" to "you can show the control was live on the day the decision was made." A document from last year's audit deck cannot show that. A checked-in floor that gates every deployment can.

Software Delivery Discipline Has Already Solved Responsible Governance

Software engineering had an almost identical problem with code quality, and it solved it with a mechanism worth importing directly: the ratchet pattern.

Quality metric regression in software is gradual and invisible by default. Test coverage drifts down a few points with every sprint and lint warnings accumulate in recently touched files. No single commit introduces a dramatic regression, and the decline is the sum of many small, individually defensible decisions. The ratchet's answer is mechanical rather than cultural. Here's what actually happens:

Quality metrics get stored in a checked-in file that records the current floor for each one: branch coverage, lint violation count, type errors, whatever the team tracks.
The file updates when a change improves on the floor. It never updates downward.
Every merge gets measured against that floor before it lands, and anything that would drop a metric below its recorded value is blocked, with a report showing exactly what regressed.

The name is literal: a ratchet is a gear with a pawl that permits rotation in one direction and locks against the other so quality can climb. It cannot slip back, because the floor is enforced automatically on every single change, not remembered by a reviewer or protected by a team norm that depends on someone paying attention.

The author has also discussed how this pattern runs day to day inside an engineering organization in a companion piece on ratchet patterns in AI-assisted development.

Responsible AI needs the identical mechanism applied to a different set of metrics. It is the same checked-in file, the same automated gate, pointed at ethics and governance measurements instead of code quality measurements. This is the mechanism Improving's responsible AI and governance advisory work is built to help organizations design before the first model ships, not retrofit after a regulator asks for evidence.

What the Ratchet Looks Like Applied to Ethics

AI Governance in Health

We worked with a regional health plan running production agents across eleven business domains, more than 130 data subdomains, and upward of 80 external data suppliers, everything from claims records to care management notes. The ethics question in that program, PHI and PII exposure, could not be handled as a document, because no single team had visibility into the whole data estate.

The floor that ended up getting enforced was structural rather than a number in a spreadsheet: every dataset feeding a production agent carried column-level access control and automated lineage tracking through the platform's catalog layer, so a model could not train on or retrieve a protected field the catalog had not explicitly cleared for that purpose.
Every access, human or agent, produced an audit log entry satisfying HIPAA's trail requirement as a byproduct of the access itself.
The health plan's security function required six separate approvals across the program before any agent reached production, each one verifying that the control lived in the platform and not in a policy memo somebody hoped people would read.

That is the ratchet in the form a regulator actually recognizes: not a target number filed away, but a boundary the system enforces on every single request, whether the requester is a person or an agent.

Common mistake: Teams treat this kind of catalog-level enforcement as a data governance project separate from AI governance. It is the same project. If your data catalog can't tell a model no, your ethics policy is a suggestion.

AI Governance in Recruitment

A hiring model that screens resumes illustrates the same idea, though the author has not yet seen a client run the full mechanical version of it. The metric that matters is disparate impact, the ratio of selection rates across protected groups. Most responsible AI programs measure this once, at model launch, as part of an initial fairness review, then treat that review as done.

The ratchet approach records that measurement as a floor in a checked-in file, the same file structure a software team would use for coverage percentage, and gates every retraining, every feature addition, every data refresh against it before it ships. If a model update would push disparate impact below the recorded floor, the deployment blocks automatically, with a report showing which group's selection rate moved and by how much. This is the clearest illustration of the pattern, but it is also one where the author is describing the mechanism the ratchet implies rather than an engagement where he watched it enforced end to end.

AI Governance in Finance

The same logic extends to financial services organizations operating under GDPR's Article 22, which gives individuals the right to an explanation for automated decisions that significantly affect them. An explainability coverage metric, the percentage of decisions for which the system can produce a human-legible reason at the confidence level the model actually used, is measurable today in most mature model governance programs. Recording it as a floor and gating deployment against it is the identical mechanism applied to a different regulatory obligation, and it never requires inventing new measurement science.

Fairness metrics, PII detection rates, and explainability coverage are already measurable in most mature AI programs. What is usually missing is the mechanical enforcement: the automated block that makes regression impossible to ship quietly, rather than the manual review that makes regression merely embarrassing to discover later.

Audit Report That Actually Matters

A checked-in ratchet file updated on every deployment creates a continuous, tamper-evident history of the trend. The commit history of that file shows exactly when each metric improved, by how much, and what change produced the improvement. For a compliance team preparing for a GDPR data protection impact assessment or a CCPA-driven review of automated decision-making, this history is a materially better artifact than a static report, because it demonstrates ongoing due diligence rather than a single point of attention paid once a year.

The ratchet strategy reframes responsible AI as competitive advantage rather than compliance overhead, and the mechanism explains why. An organization with enforced ratchet metrics can approve model updates faster than an organization relying on a manual review board, because the mechanical gate has already done the checking that the review board exists to do by hand. The review board still matters for judgment calls the gate cannot make, but routine updates that pass the automated floor do not need to wait on a monthly compliance meeting.

The organizations moving fastest on AI adoption are automating it thoroughly enough that governance stopped being a scheduling bottleneck.

Calibrating the Floor Honestly

The practical question the ratchet raises immediately, in software and in ethics alike, is what the starting floor should be.

Set it above where the system currently performs and every deployment blocks immediately.
Set it at the system's current performance, whatever that performance actually is, and let improvements accumulate from there.

This is uncomfortable advice for an organization that has not yet measured its own bias or privacy exposure honestly, because it means the first step is measuring the current state, not the ideal state, and recording an uncomfortable number as the starting point. That discomfort is the signal that the exercise is working. A floor set at an aspirational number the system does not currently meet is not a governance mechanism. It is a promise with no enforcement behind it, the performative version of responsible AI this approach exists to replace.

Counterintuitively: The health plan's six-approval gate (mentioned above) looked like it would slow deployments down. It did the opposite. Once the floor lived in the platform instead of in review meetings, routine changes stopped needing a meeting at all. Approvals compressed to the cases that actually required judgment.

There is legitimate nuance in how floors get structured. A model serving multiple markets under different regulatory regimes, GDPR in the European Union, CCPA in California, needs per-jurisdiction floors rather than one global number, the same way a codebase with legacy modules carries per-directory quality floors instead of a single blanket standard. A model in active experimentation, still in a sandboxed pilot rather than production, can carry a different floor than the same model once it reaches general availability, provided the transition between the two is itself a deliberate, documented gate rather than a quiet default.

Where This Breaks and Where It Does Not

The ratchet is not a complete answer. It works for anything that can be measured and aggregated, including disparate impact ratios, PII detection rates, and explainability coverage percentages.

It has nothing useful to say about qualitative judgment:

Whether a use case should exist at all
Whether a model's purpose is ethical regardless of how cleanly it scores
Whether a borderline case deserves an exception

Such questions still need a human ethics review, and no mechanical floor replaces that judgment. The ratchet handles the part of responsible AI that is measurable and repetitive, freeing the human review process to spend its attention on the part that is genuinely hard to automate, a better allocation of scarce expert judgment than having that same review process re-verify metrics a machine could check continuously.

Goodhart's law applies here with the same force it applies to software quality metrics, and it applies harder, because the stakes are higher. Once disparate impact becomes a target rather than a measure, an organization can find ways to satisfy the number without addressing the underlying fairness problem, narrowing the population the model is applied to, for instance, rather than fixing the model's actual behavior.

The ratchet enforces the floor on whatever gets measured, and it says nothing about whether the chosen metric captures what actually matters. Choosing what to measure is the real decision, and it deserves the same rigor as building the enforcement mechanism itself. A well-built ratchet enforcing the wrong metric is worse than no ratchet, because it manufactures false confidence.

Why Day One Matters

The instruction to build ethics and governance in from day one is usually heard as a values statement. It is better understood as a sequencing argument.

A ratchet floor set after a model has been in production for a year has to be calibrated against whatever bias, privacy exposure, or explainability gap already exists, and every subsequent improvement gets measured against a starting point that was never chosen deliberately.

A floor set at the design stage, before the first version ships, gets to start at a number the team actually chose, informed by what the model is for and who it affects, rather than a number the team is stuck defending because it happened to be where things landed.

Final Words

If you run a responsible AI program today, the next step is small: pick one metric you already measure, like fairness, PII exposure, or explainability coverage, and check whether it is recorded anywhere as a floor that gates deployment, or whether it just lives in last year's audit deck. A companion post on what every enterprise needs in place before production walks through the broader checklist this ratchet sits inside.

The author states his bias directly: a governance document nobody's system enforces is worse than no document, because it creates the appearance of control without the substance.

If your fairness, privacy, or explainability metrics live in a report instead of a gate, that's the first thing worth fixing this quarter. If you want a second opinion on where your program stands, reach out and let's talk it through.

FAQ

Do we need a ratchet for every AI metric we track, or just a few?
Start with whatever metric already has regulatory teeth for your industry: disparate impact for hiring or lending, PII detection for healthcare, explainability coverage for financial services. You can expand from there once the mechanism proves out on one metric.

What if we don't have the engineering resources to build automated gates right now?
A manual gate that runs on every deployment and blocks on a documented floor still beats an annual audit. The ratchet's value is in the floor never moving down and the check happening every time, not in the automation itself. Automate it once the manual version is working.

How do we pick the starting floor if we've never measured this before?
Measure current performance first, even if the number is uncomfortable, and set the floor there. The floor's job is to stop things from getting worse, not to declare the system already good.

Does this replace the human ethics review board?
No. It removes the repetitive, measurable checking from the board's workload so the board can spend its time on judgment calls a metric can't resolve, like whether a use case should exist at all.

Leading Data Platform Modernization Companies: What to Look for in a Partner?

Improving — Tue, 22 Sep 2026 11:51:05 +0000

Choosing a data platform modernization partner means weighing global scale against specialized, hands-on delivery, all while data volumes and format complexity keep expanding across every industry. The global data integration market is projected to grow from USD 17.58 billion in 2025 to USD 33.24 billion by 2030, according to MarketsandMarkets. This guide compares nine leading data platform modernization providers, from global systems integrators to boutique specialists, on delivery model, industry fit, and proven outcomes, to help IT and data leaders choose the right partner.

Executive Summary

Data platform modernization gives organizations a path off legacy, on-premises databases and onto scalable, cloud-native platforms that support real-time analytics and AI workloads, without disrupting the business the data supports. As data volumes and format complexity keep expanding, modernization helps teams reduce legacy drag, unlock unstructured data, and build a governed foundation that scales with future AI initiatives.

This guide profiles nine leading data platform modernization companies and outlines how to assess partners based on platform certifications, delivery bench depth, governance design, and industry-specific experience. We also compare delivery models across large-scale systems integrators and specialized engineering providers, giving buyers a clear framework to evaluate vendors, choose the right cloud platform partner, and design a modernization approach that fits their scale and industry.

Who Is This Guide For?

CTOs and VPs of Engineering deciding whether to modernize a legacy data warehouse in place or migrate to a new cloud-native platform.
Chief Data Officers and VPs of Data & Analytics responsible for data governance, quality, and AI-readiness across the organization.
Procurement and Sourcing Leads comparing vendor delivery models, pricing structures, and contract risk across global and boutique providers.
Enterprise Architects evaluating which platforms (Snowflake, Databricks, Microsoft Fabric, Azure, and similar) fit an existing technology stack.

Each of these roles shares the same goal: modernizing the data platform without disrupting the business it supports.

What Is Data Platform Modernization & How Does It Work?

Data platform modernization is the process of moving data storage, processing, and pipelines off legacy, on-premises, or end-of-life systems and onto scalable, cloud-native platforms that support real-time analytics and AI workloads. It typically combines data migration, pipeline re-engineering, governance redesign, and cost-model changes rather than a single lift-and-shift step.

Common models and approaches:

Lift-and-shift migration: moving existing databases to cloud infrastructure with minimal re-architecture, prioritizing speed over optimization.
Re-platforming: migrating to a new data platform (e.g., Snowflake, Databricks, Microsoft Fabric) while re-engineering pipelines for the target environment's cost and performance model.
Data mesh / decentralized ownership: distributing data ownership to domain teams on a shared self-serve platform, rather than centralizing all data engineering in one team.
Hybrid modernization: modernizing selected high-value data domains first while legacy systems continue running, reducing cutover risk.

Key advantages of data platform modernization:

Faster decision cycles: real-time, cloud-native analytics increasingly replace batch reporting, and organizations using real-time analytics report a 29% improvement in decision speed and a 21% reduction in operational costs, according to Hydrogen BI.
Reduced legacy drag: retiring systems that constrain the broader technology roadmap frees engineering time for new capabilities instead of maintaining brittle infrastructure.
Lower data-quality risk: rebuilding pipelines with governance and validation built in reduces costly downstream errors, and poor data quality costs organizations an average of $12.9 million per year, according to IBM.
Unlocked unstructured data value: modern platforms are built to handle non-tabular formats such as documents, images, and sensor data, turning previously unusable data into a source of insight.
AI-readiness: consistent, governed data pipelines give AI and machine learning initiatives a reliable foundation to build on, rather than ad hoc extracts assembled project by project.

How to Choose the Best Data Platform Modernization Partner?

Platform-specific certifications: confirm hands-on delivery experience, not just a sales partnership, on the specific cloud data platform (Snowflake, Databricks, Microsoft Fabric, Azure) the buyer has standardized on. A logo on a partner's website is not proof of delivery depth.
Verified delivery bench depth: 38% of businesses report a data talent shortage, according to 365 Data Science. A partner's ability to staff a project without long ramp times matters as much as its brand name.
Industry-specific pattern libraries: look for prebuilt data models and compliance patterns for the buyer's industry, such as healthcare, financial services, or manufacturing, rather than a generic migration playbook applied to every client.
Cloud-native cost management experience: the cloud data warehouse market is projected to grow from USD 11.56 billion in 2025 to USD 31.7 billion by 2030, according to Grand View Research. That growth rewards partners who can control consumption-based spend, not just complete a migration.
Governance and lineage design: confirm the partner designs data ownership and quality rules to survive the transition, not just execute the migration itself.
Transparent, outcome-based case studies: ask for named clients and specific metrics, rather than accepting generic claims of being "faster" or "more efficient."
Regional and delivery-model fit: determine whether the buyer needs onshore governance oversight, nearshore delivery for cultural and time-zone alignment, or globally distributed engineering capacity, since the right model varies by buyer.
Buyers should also ask: Can this partner show a reference client in our industry? What is the realistic timeline to first production workload? How does pricing change after the initial migration is complete?

Bottom line: the right data platform modernization partner is judged less by size and more by whether its governance model, platform certifications, and case studies match the buyer's specific cloud platform and industry.

Top 9 Data Platform Modernization Companies

1. Accenture

Accenture is one of the largest professional services firms running data platform modernization work worldwide, anchored by its Data & AI practice spanning data strategy, cloud data platform builds, and applied AI and GenAI delivery. Accenture routinely coordinates multi-region modernization programs for the largest global enterprises, running concurrent workstreams across geographies without losing a single point of accountability.

Quick Facts

Headquartered: Dublin, Ireland
Team Size: 700,000+
Key verticals: financial services, retail, healthcare, public sector
Key platforms/technologies: Azure, AWS, GCP, SAP, Salesforce data ecosystems
Relevant strengths: global scale, cross-industry accelerators, AI integration

Why Consider Accenture? Staffing large, concurrent workstreams across geographies without outgrowing a single vendor relationship is where Accenture's scale matters most, particularly for multi-region, multi-platform data modernization programs.

Talent Pool Access: Accenture draws on a globally distributed workforce spanning delivery centers across the Americas, Europe, and Asia-Pacific.

Proven Track Record: Accenture publishes data and AI transformation case studies across banking, retail, and healthcare clients as part of its Data & AI practice portfolio.

2. Capgemini

Capgemini is a global technology and consulting firm with a Data & AI practice built around data engineering, cloud data platform delivery, and enterprise AI and GenAI transformation. That practice runs deepest in European regulatory and manufacturing data environments, where multi-country governance requirements shape platform design from the outset.

Quick Facts

Headquartered: Paris, France
Team Size: 400,000+
Key verticals: banking, manufacturing, retail, public sector
Key platforms/technologies: Azure, AWS, SAP, Snowflake
Relevant strengths: European enterprise depth, industrialized delivery, AI/GenAI integration

Why Consider Capgemini? Capgemini's strength in European regulatory and manufacturing data environments makes it a fit for multinational buyers needing consistent governance across jurisdictions.

Talent Pool Access: Capgemini operates delivery centers across Europe, North America, and Asia, supporting follow-the-sun data engineering teams.

Proven Track Record: Capgemini's Data & AI practice publishes client work spanning banking, manufacturing, and retail data modernization programs.

3. Improving

Improving Enterprises modernizes legacy data warehouses and pipelines into cloud-native, lakehouse-ready architectures on Snowflake, Databricks, Microsoft Fabric, and Azure, combining Fortune 500 migration experience with a hybrid delivery model that keeps senior data architects engaged from initial assessment through steady-state operations. The practice holds Microsoft Solutions Partner designations across five solution areas, including Data & AI, and a direct Confluent partnership for real-time streaming work, giving clients platform-specific delivery depth rather than a generalized migration playbook.

Why Is Improving the Best Data Platform Modernization Partner?

Improving keeps senior architects engaged from design through go-live rather than routing work through standardized offshore delivery factories, an approach reinforced by Microsoft Solutions Partner designations across five solution areas, including Azure and AI.

NPS 90+: among the highest in modern enterprise technology services
7.5-year average partnership length: built around long-term relationships, not one-off projects
Global footprint: 7+ countries, 3 continents, and 21 offices with 2,500+ consultants
Key verticals: healthcare, manufacturing, financial services, technology, energy & utilities and more
Platform stack: Azure, Snowflake, Databricks, Microsoft Fabric, and Confluent
Relevant strengths: hybrid delivery model, Microsoft Solutions Partner designations, and real-time streaming expertise, recognized externally through the 2025 Confluent Enablement Partner of the Year (AMER) award.

"Confluent has always been a reliable, innovative, and forward-thinking technology partner that has provided our team with the groundbreaking tools and platforms to create solutions that have helped reshape how our clients in the healthcare, manufacturing, financial services, and energy sectors utilize their real-time data for meaningful change."
— Ehren Seim, Global Alliances Lead, Improving

Global Delivery Access

Improving's 21 offices sit across the United States, Canada, Mexico, Guatemala, Chile, Argentina, and India, giving data platform modernization clients onshore architecture leadership paired with nearshore and offshore engineering capacity in closely aligned time zones. That structure is what lets Improving hold senior data architects on an engagement from design through go-live instead of transitioning ownership to a separate delivery organization partway through.

Proven Track Record

Integra Connect, a precision medicine and specialty oncology care platform, was running a legacy SQL Server-based data warehouse that could not scale with its growing operations, with long processing times and high fixed compute costs. Improving modernized the environment by migrating Integra Connect to Snowflake, re-engineering pipelines built for a distributed cloud environment, and moving to consumption-based compute, reducing data processing time from several days to minutes.

Looking to achieve similar results with a trusted partner? Connect with our data engineering experts to explore how we can accelerate your cloud data platform migration.

Strategic Advantage

Improving's advantage in data platform modernization comes from combining Microsoft Solutions Partner designations across five solution areas, a named Confluent partnership for real-time streaming, and real Fortune 500 migration experience on Snowflake, Databricks, and Microsoft Fabric, all reinforced by a 7.5-year average client tenure that points to a firm built for the long life of a data platform, not just the migration event. Learn more on Improving's data platform modernization page.

4. TCS

Tata Consultancy Services (TCS) is a global IT services company with a Data & Analytics unit focused on data governance, warehousing, and predictive analytics for large-scale enterprise clients. At that scale, large, multi-year data modernization programs run concurrently across banking, retail, and life sciences accounts without straining delivery capacity.

Quick Facts

Headquartered: Mumbai, India
Team Size: 500,000+
Key verticals: banking/capital markets, retail, life sciences, manufacturing
Key platforms/technologies: Azure, AWS, SAP, Google Cloud
Relevant strengths: delivery scale, cost efficiency, vertical-specific analytics accelerators

Why Consider TCS? TCS suits buyers prioritizing cost-efficient delivery at scale across large, multi-year data modernization programs.

Talent Pool Access: TCS maintains a large global delivery workforce concentrated in India, with additional regional delivery centers worldwide.

Proven Track Record: TCS publishes data and analytics engagements across banking, retail, and life sciences clients through its Data & Analytics unit.

5. IBM

IBM is a global technology company known for a data platform stack that includes Db2 and Cognos Analytics, combined with watsonx and Cloud Pak for Data to support AI-embedded data management and governance. Because IBM builds and sells the underlying platform, its consulting arm can offer tightly integrated tooling that platform-agnostic competitors cannot match.

Quick Facts

Headquartered: Armonk, New York, USA
Team Size: 250,000+
Key verticals: financial services, retail, manufacturing, public sector
Key platforms/technologies: Db2, Cognos Analytics, watsonx, Cloud Pak for Data
Relevant strengths: AI-embedded governance tooling, long-standing enterprise data platform heritage

Why Consider IBM? Tightly integrated governance and AI tooling, delivered by the platform vendor itself, is the main draw for buyers already standardized on IBM's data and AI stack.

Talent Pool Access: IBM Consulting draws on a global technical workforce with deep product-level expertise in its own data and AI platforms.

Proven Track Record: IBM's Data and Analytics Service holds a Gartner Peer Insights rating of approximately 4.3/5 across roughly 53 reviews, among the highest of the global integrators profiled in this guide.

6. DATAFOREST

DATAFOREST is a premier product and data engineering company specializing in AI digital transformation and custom software. Since 2017, they have empowered startups and mid-sized companies to improve operations and drive revenue. Integrating large-scale data analysis and web development, DATAFOREST delivers tailored, data-driven solutions that foster business growth.

Quick Facts

Headquartered: Kyiv, Ukraine & Tallinn, Estonia
Team Size: 170+ in-house employees
Key verticals: startups, mid-sized businesses (SMBs), eCommerce, and tech
Key platforms/technologies: Generative AI, Machine Learning, NLP, ETL Pipelines, BI & Big Data, Cloud Solutions, Web & Mobile Development
Relevant strengths: generative AI and machine learning integration, end-to-end custom software delivery

Why Consider DATAFOREST? DATAFOREST offers 15+ years of expertise in business automation and large-scale data analytics. They integrate custom ML models to reduce costs, improve scalability, and build robust, data-driven products tailored to specific needs.

Talent Pool Access: Access to 170+ skilled in-house professionals, including top-tier data scientists, AI engineers, and web developers. This dynamic team supports rapid scaling, deep technical expertise, and proactive execution.

Proven Track Record: With 300+ successful projects and 200+ satisfied clients since 2017, DATAFOREST's leadership is recognized globally, with titles such as Clutch Champion 2024 and Top Artificial Intelligence Company.

7. ScienceSoft

ScienceSoft is an IT consulting and software development company known for data warehousing, ETL/ELT pipeline design, and automated database migration. Its proprietary Ispirer Toolkits accelerator automates significant portions of schema and code conversion, which shortens timelines for buyers with a well-scoped migration.

Quick Facts

Headquartered: McKinney, Texas, USA
Team Size: 750+
Key verticals: healthcare, financial services/insurance, manufacturing, retail
Key platforms/technologies: Snowflake, Azure, AWS, SQL/NoSQL databases
Relevant strengths: migration accelerators, ETL/ELT specialization

Why Consider ScienceSoft? ScienceSoft's Ispirer Toolkits accelerator automates significant portions of schema and code conversion, a clear advantage for buyers with a well-defined database migration scope.

Talent Pool Access: ScienceSoft operates a team of 750+ specialists supporting data warehousing and migration engagements.

Proven Track Record: ScienceSoft has completed database and data warehouse migrations for clients across healthcare, insurance, and manufacturing, with its Ispirer Toolkits accelerator built specifically to shorten schema and code conversion timelines.

8. Simform

Simform is a software engineering company with a Microsoft Solutions Partner designation for Data & AI. Purpose-made accelerators, including TrueMorph and Data Jumpstart, sit alongside that designation to modernize legacy data platforms onto Microsoft Fabric, Azure, and Databricks.

Quick Facts

Headquartered: Orlando, Florida, USA
Team Size: 800+
Key verticals: fintech, healthcare/life sciences, supply chain/logistics, retail/e-commerce
Key platforms/technologies: Microsoft Fabric, Azure, Databricks
Relevant strengths: proprietary migration accelerators (TrueMorph, Data Jumpstart), Microsoft Data & AI partnership

Why Consider Simform? Microsoft Solutions Partner status and purpose-built migration accelerators give Simform an edge with buyers already standardized on Microsoft Fabric or Azure.

Talent Pool Access: Simform combines a US-based client-facing team with an engineering delivery hub in Ahmedabad, India.

Proven Track Record: Simform's Microsoft Solutions Partner status for Data & AI reflects validated delivery experience on Fabric, Azure, and Databricks migrations for fintech, healthcare, and retail clients.

9. N-iX

N-iX is a software engineering company with a dedicated data specialist team of more than 170 engineers focused on enterprise data analytics and big data engineering. More than 170 dedicated data specialists have built data ecosystems for large manufacturing and industrial clients, including Bosch and Siemens, giving N-iX particular depth in high-volume industrial data environments.

Quick Facts

Headquartered: Lviv, Ukraine (operational base; company records list a Valletta, Malta legal entity)
Team Size: 2,000+
Key verticals: finance/fintech, manufacturing, retail/e-commerce, healthcare, telecom
Key platforms/technologies: Azure, AWS, Kafka, Spark
Relevant strengths: dedicated 170+ person data engineering team, enterprise manufacturing clients

Why Consider N-iX? N-iX's 170+ person data specialist practice gives buyers a dedicated, scalable big-data engineering team without assembling one from generalist staff.

Talent Pool Access: N-iX maintains engineering offices across Ukraine, Poland, Colombia, and the United States.

Proven Track Record: N-iX has built data ecosystems for enterprise manufacturing clients including Bosch and Siemens, per its published client list.

Choosing a Data Platform Modernization Partner Built for the Long Term

Data platform modernization is no longer optional for organizations trying to run real-time analytics or AI workloads on top of legacy infrastructure. The right partner depends less on brand size than on platform certifications, delivery model, and a track record of specific, quantified outcomes rather than general claims. Global integrators bring scale and cross-industry breadth. Boutique specialists bring accelerators and focused delivery. The right fit depends on the buyer's platform, industry, and governance needs.

We have seen these dynamics firsthand in our own client work, including a Snowflake migration that cut data processing time from several days to minutes for a specialty oncology care platform, without disrupting ongoing operations. If your organization is evaluating a data platform modernization partner, explore Improving's data platform modernization services or schedule a consultation to discuss your specific environment.

Frequently Asked Questions

1) What is the difference between data platform modernization and a simple cloud migration?
A cloud migration typically moves existing systems to cloud infrastructure with minimal changes. Data platform modernization goes further, re-engineering pipelines, governance, and cost models for the target platform rather than simply relocating the existing architecture.

2) How long does a typical data platform modernization project take?
Timelines vary widely by scope, from a few months for a single data domain to over a year for enterprise-wide programs. Buyers should ask each prospective partner for a realistic timeline to the first production workload rather than the full program end date.

3) Should we choose a global systems integrator or a boutique specialist?
Global integrators suit buyers needing multi-region delivery scale and broad industry accelerators. Boutique specialists often move faster on a defined scope and bring purpose-built migration accelerators, but buyers should verify delivery bench depth before committing to either type of partner.

4) What certifications should a data platform modernization partner have?
Look for certifications specific to the buyer's target platform, such as Microsoft Solutions Partner (Data & AI), Databricks Consulting Partner, or Snowflake partner status, rather than general cloud certifications alone.

5) How do we evaluate case studies from prospective vendors?
Ask for named clients and specific, quantified outcomes, such as a percentage cost reduction or a specific processing-time improvement, rather than general claims like "faster" or "more efficient."

6) Is nearshore delivery a good fit for data platform modernization work?
Nearshore delivery can reduce time-zone and cultural-alignment friction compared to fully offshore delivery, while often costing less than fully onshore teams. It suits buyers who need close collaboration with data architects during design phases.

Define Done Before you Build a Task Agent

Improving — Tue, 22 Sep 2026 11:49:39 +0000

All the best advice won't mean anything unless you know what progress looks like. You're using AI for your work, maybe getting some wins, but the results feel inconsistent. Sometimes the AI nails it; sometimes it misses completely so you keep adjusting your prompts and try different approaches. You're vibe coding, with one-off prompts that work once but don't scale.

For AI to be useful, it needs to be consistent before it can be trusted. That consistency starts with us being consistent in how we prompt AI.

Before we go further, let's align on terms:

Your whole SDLC is your process.
Within the SDLC process, you have workflows. Think role-specific work within phases, like "write code for a requirement."
Within workflows, you have tasks. Specific segments of work like "write unit tests" or "create acceptance criteria."
Within tasks, you have steps. How that task actually gets done.

We're focusing on the task level because that's where task agents live, and it's the fastest path to value.

The trick is drawing a box around a task and defining what we mean by "done" for that task before we ask someone else (AI) to do it. If you can't tell me what "done" looks like, you shouldn't start.

This isn't new thinking. It's just process discipline. In Scrum, we have the Definition of Done. Done ought to be binary. It is either done, or it is not. We all must speak the same language for "done" to have any meaning. The same principle applies to AI task agents.

When you define a task agent, you're answering one question: How do I know I'm done? Take "write code for a requirement" as your task. When are you done coding? When it passes the coding standards. When it builds. When tests pass. When it's approved in PR. Those are your exit criteria.

How to Create a Reusable Task Agent With a Clear "Done" State

Pick one task you currently use AI for. Keep it specific, not something like "build a feature" but "write unit tests for a function" or "create API documentation."

List the measurable criteria that tell you this task is complete. Don't let AI tell you it's done. If you can't articulate what done looks like, you don't know either. For example, you can test the coding agent's output by several things:

Does it pass linting?
Does it follow team coding standards?
Does it include required documentation?
Does it pass existing tests?

Build your task agent prompt with four components:

Role: What expertise frame do you need? "You are an expert in Python testing and pytest."
Task: What specifically are you trying to accomplish? "Write comprehensive unit tests for the provided function."
Context: Examples, existing patterns, output formats. "Follow the testing patterns in tests/example_test.py."
Constraints: Boundaries for the work. "Use pytest fixtures. Test both happy path and error cases. Achieve 90%+ coverage."

AI, like toddlers, doesn't understand NOT well. So put your constraints in the form of "DO X" or "Only use Y," and avoid things like "Do NOT do Z."

Build an independent checklist you can run against the AI's output. This is separate from the prompt. It'll start as your manual verification. Things like "All functions have corresponding tests," "Tests follow team naming conventions," etc.

You can see a full example here.

Now, run your task agent. Check the output against your validation checklist. Does it pass or fail? If it fails, identify which criterion it missed. Then refine your prompt's constraints or context.

Just orchestrating AI calls without quality gates is easy. But doing it right, with clear criteria and validation, separates a weekend of hacking from reliable tools.

You can build task agents for most of your common development tasks in about twelve weeks. You'll see your prompts get longer initially as you bake in constraints. But then they'll stabilize. As you refine your prompts, you'll be able to shift models from heavy to lighter ones, which will impact your token usage too. Your token usage will spike initially, and over time, as you refine and simplify your prompts, your costs per task will decline.

Managers should expect fewer one-off prompts in chat logs and more workflow invocations. You'll see reusable prompts, and their criteria start appearing in team repositories. These are the signals that developers are moving from vibe coding to intentional task agents.

Begin With the End in Mind

Start by building from a real finish line. Apply what we know about prompt engineering to create the foundation for trust with your AI tooling. This is the end of Stage 2 in AI maturity: codified prompts with manual validation. Stage 3 is where those validation checklists become automated tests. But you can't automate validation until you first know what you're validating against. Define done first. Everything else builds on that.

Improving's AI Maturity Model maps AI adoption across three waves, from zero AI usage to full agentic operations. Early stages focus on building trust with human-approved AI assistance. The middle stage extends AI into full workflows, where governance becomes essential, and most organizations stall. But before you can enter the middle stage, you must master defining done in ways the agent can accomplish, and the system can validate.

Pick one task you use AI for today. Write down three exit criteria that define "done" for that task. That's your first step. You'll know it's working when you can run the same prompt twice and get consistent results that pass your criteria. This is exactly how Improving's AI consultants are leading Fortune 500 development organizations to apply AI to their SDLC at scale.

AI Pipeline Reliability Governance for Multi-Step Accuracy Failures

Improving — Tue, 22 Sep 2026 11:48:19 +0000

If every step in your pipeline hits 95% accuracy, what does the whole pipeline hit? Many engineers might answer, "about 95%." That answer is wrong, and it's wrong in a way that costs real money once the pipeline is in production.

First of all, it depends on the number of steps in the pipeline. Here's what actually happens across a ten-step pipeline, each step at 95%:

Step 1: 0.95
Step 2: 0.95 × 0.95 = 0.9025
Step 3: 0.9025 × 0.95 = 0.857
Step 5: ... = 0.774
Step 8: ... = 0.663
Step 10: 0.95^10 = 0.599

By step 10, the pipeline is right about 60% of the time end to end. Four runs out of ten produce a wrong answer somewhere along the chain, even though every individual step is hitting the number an engineering team would happily put on a dashboard. Accuracy doesn't average across a chain. It multiplies. And numbers just under 1, multiplied enough times, fall well below 1 regardless of how good any single one looked alone.

In the 1940s, Robert Lusser diagnosed why German rocket programs kept losing rockets built from thousands of individually reliable parts: a chain's reliability is the product of its links' reliabilities, not their average. That's become Lusser's law, and it's the same math running through every multi-step AI pipeline today.

Push the same pipeline to twenty steps at 95% per step and the effect compounds again: 0.95^20 is approximately 0.36. Roughly one run in three completes correctly.

Understanding AI Pipeline Reliability Governance

AI pipeline reliability governance is the set of checks, gates, and ownership structures that sit between the steps of a multi-agent workflow. It is the machinery, automated or human, that catches an error at step four before it reaches step ten. Without it, per-step accuracy and end-to-end reliability are two different numbers, and only one of them is the number that ships.

Postmortem Gets the Diagnosis and Fix Wrong

We worked with a general counsel's office covering an entire company's legal work with one person on staff. We built an extraction pipeline that reads contracts and legal materials, pulls out clauses and risk flags, and populates a knowledge graph she can query instead of rereading source documents by hand every time a question comes up.

Every stage of that pipeline writes its output to both the production database and a parallel test database, and a rating system compares the two on a rolling basis.

A few weeks after a routine model upgrade, that comparison caught something a person skimming outputs one at a time would have missed entirely. The pipeline had started failing four of eighteen defined risk constraints on incoming contracts. Every individual clause of extraction still looked plausible in isolation. The regression only showed up in aggregate. It was a case of a successful diagnosis, and it gets generalized.

The usual failure looks different. A team ships an autonomous pipeline that works in the pilot and gets deployed against real volume. Then it hits an edge case nobody modeled for and produces a wrong result that is expensive to trace and worse to explain upward without parallel structure in place to catch the regression. The conclusion in the room is almost always some version of "autonomous AI isn't ready yet."

Teams fix the model instead of the chain

That conclusion is wrong, in a specific and fixable way, because the agents were operating at their specified accuracy the entire time. The problem was the pipeline architecture that assumed 95% per step meant 95% end-to-end, a category error, not a capability gap.

Common mistake: The postmortem on the legal pipeline traced the four-of-eighteen regression to a model upgrade that had quietly shifted diagnostic sensitivity in one narrow risk category, not to the model getting generally worse at legal work.

Teams almost always chase the wrong fix here: they swap in a better model, tune the prompt, add a few examples, and improve the per-step number modestly while leaving the compounding structure completely untouched. Going from 95% to 97% per step looks like a small win. Run it through the same multiplication (0.97^10) and end-to-end reliability moves from 60% to about 74%. Better, but still a coin flip's worth of risk sitting inside a quarter of every run, because a 2-point improvement per step can't undo what ten multiplications did to the first number.

Improving's AI strategy and roadmap assessment work is built to close this exact gap before a pipeline reaches production volume, not after.

Why the Curve Gets Worse as Organizations Mature

Organizations do not stay at ten-step pipelines. As agentic AI programs mature, past task agents into workflow agents and eventually into coordinated agent teams, the natural instinct is to chain more steps together, because chaining is exactly what autonomy is supposed to buy.

A team that succeeds with a ten-step pipeline at 60% reliability and responds by adding ten more steps to capture more of the workflow does not get a marginally worse number. It gets 0.95 to the twentieth, which is 0.36, less than half the reliability of the pipeline it started with.

Autonomy Paradox: The pipelines that look the most autonomous on an architecture diagram, the longest, with the fewest human checkpoints, are frequently the least trustworthy in production.

When nobody owns the whole chain

Once an organization has several agent-driven workflows running, outputs from one team's pipeline start feeding into another team's pipeline as input, often across a department boundary, sometimes across a vendor boundary. Nobody owns the full chain anymore.

Our consultants see this pattern constantly during assessment work. One group's reconciliation or extraction agent hands its output downstream to another team's summarization or reporting agent, which in turn feeds a third system maintained by a different group entirely. Each team can honestly report that their own segment runs at 95% or better. Nobody has computed, or can compute, the reliability of the composed chain, because no single person or system has visibility into the whole thing.

Stacking errors stop being a pipeline design problem and become an organizational visibility problem, which is worse, because the math still applies whether or not anyone is tracking it.

Importance of closing the reliability gap

The gap between per-step accuracy and end-to-end reliability determines whether an autonomous deployment is a capability or a liability. Skip the gate and the failure shows up downstream, at the point where it is most expensive to trace: a wrong risk flag on a contract, a bad lead assigned to a sales rep, a transaction sent on faulty data. Close the gap with a real quality gate at each transition, and the same pipeline architecture holds up as volume, step count, and the number of teams touching the chain all grow at once.

What Governance Buys Back

The instinctive framing for governance is risk management, adding oversight because AI can go wrong. However, that treats governance as friction paid against a risk that might never materialize. The stacking errors math says something stronger.

Without a quality gate between steps, a ten-step pipeline at 95% per-step accuracy is a 60% end-to-end system.
With a quality gate that catches and corrects errors at each transition, the effective step accuracy approaches the reliability of the gate itself, and the pipeline's end-to-end number improves.

The author notes he goes deeper on what these gates need to look like at the organizational level in a companion piece on building governance in from day one, and on the mechanical pattern that keeps a gate from sliding backward once it exists in a piece on the ratchet pattern.

We worked with Lakeshore Learning on a pipeline that crawls the web for funding opportunities, scrapes the relevant pages, and maps the results into Lakeshore's application system. Three AI steps chained together formed exactly the kind of chain the compounding math warns about.

Design Principle the Math Implies

The stacking errors curve suggests preferring shorter, well-bounded chains with a real gate at every transition over long chains that minimize human touchpoints for their own sake.

A twenty-step pipeline that runs end to end with no checks looks the most impressive on a slide and delivers 36% reliability.
A five-step pipeline with a quality gate at each handoff, run four times in sequence to cover the same twenty steps of total work, delivers the same output with a fraction of the failure rate.

Two objections come up whenever the author walks a technical audience through this math, and both deserve a direct answer.

Objection 1: Steps don't actually fail independently

A bad input tends to fail at several steps at once, and a well-built downstream step can sometimes absorb an upstream mistake.

Independence is a simplifying assumption, and what survives the simplification is the shape of the curve. Reliability decays as chains lengthen whether the exponent is exactly 0.95 or something else entirely. Nobody who has operated a long pipeline in production argues with the direction of the decay, only its slope.

Objection 2: Self-correction replaces the need for governance

You can enable the agent to check its own work, or have a second model verify the first, and the quality gate becomes unnecessary.

Counterintuitively: The author doesn't disagree with this one. A verifier model is a quality gate, and a self-consistency check is a confidence threshold. The case was never for committees and sign-off meetings layered onto an agent's pipeline. It is for checking machinery sitting between every transition, whether that machinery is a rule, a second model, or a person, as long as something with different failure modes than the step it checks is actually there.

Wrap Up

If you have an autonomous pipeline running today, or one on the roadmap, the exercise worth doing this week is simple: count the steps, multiply their reported accuracy rates together, and see what number actually comes out the other end. Then check whether a real quality gate sits at each handoff, or whether the pipeline is running on the assumption that per-step accuracy is the same thing as end-to-end reliability.

What does your own pipeline's real number look like once you do the multiplication? If you want a second set of eyes on that math, reach out and let's talk.

FAQ

Does every step in a pipeline need its own quality gate?
Every step in the pipeline does not need its own quality gate. Gates belong at the transitions where an error is expensive to catch late or hard to reverse, not evenly spaced across every step.

What if we don't have the resources to build parallel test infrastructure like the legal pipeline example?
A lighter version will work. Even a periodic manual sample comparison against expected output catches regressions that a per-step accuracy number will never show you.

How do we estimate our own pipeline's real end-to-end reliability?
Multiply the reported accuracy of each step together. It's a rough estimate since steps aren't fully independent, but the direction of the number is the point, not the fourth decimal place.

Does adding a quality gate slow the pipeline down?
Quality gates add latency at the step, so it slows the pipeline a little bit, but it's a fraction of what a downstream failure costs to trace and fix after the fact.

AI Code Review Isn't Code Review Yet

Improving — Tue, 22 Sep 2026 11:46:37 +0000

Modern AI code review tools have become remarkably good at automating parts of code review. They catch common mistakes, enforce standards, and reduce reviewer workload. But code review automation isn't the same as understanding the code. The critical issues slip through the gap between detection and comprehension.

In this article, we'll explore where AI code review delivers real value, where its blind spots begin, why context remains the missing piece, and how engineering teams can build review workflows that combine AI-driven automation with human judgment.

What AI Code Review Does Well

AI-powered code review has genuine strengths, and here are several in detail:

1. Pattern Recognition at Scale

Most modern AI reviewers are highly effective at identifying coding mistakes that follow predictable patterns and language-specific anti-patterns. Unused variables, unreachable code, and potential null reference issues are all caught consistently.

A code review tool can scan thousands of lines and recognize when similar code patterns appear multiple times, flagging refactoring opportunities that humans might miss simply due to scale. Inefficient implementations that have well-known alternatives are recognized instantly. This is particularly valuable in large teams where consistent implementation patterns matter.

2. Security and Compliance Validation

AI detects hardcoded secrets, credentials, and tokens reliably. Common vulnerabilities such as SQL injection, XSS, and insecure API usage are flagged automatically. AI tools verify adherence to organizational coding and security policies and act as an additional security checkpoint before code reaches production. In companies managing complex compliance requirements, AI compliant verification becomes a meaningful security layer.

3. Consistency and Code Quality Enforcement

Enforcing style guides and coding conventions across rapidly growing engineering teams is tedious for humans but trivial for machines. AI reviewers standardize pull request feedback regardless of reviewer availability. They help maintain consistency across rapidly growing codebases and reduce time spent on low-value review comments.

AI reviewers don't get tired or irritated when checking the hundredth indentation error of the day. This consistency reduces review bottlenecks, helps developers receive faster feedback, and makes it easier for new engineers to follow established coding standards. For organizations onboarding new developers, AI reviewers provide clear, repeatable guidance that accelerates learning and improves overall code quality.

4. Faster Developer Feedback Loops

AI reviews code immediately after a pull request is opened, surfacing issues before human reviewers even look at it. It means developers get faster feedback loops; human reviewers handle already-filtered requests, and teams can scale up their review processes without hiring proportionally more engineers. Reduced review cycle times and reviewer workload enable teams to move faster without proportional growth in engineering headcounts.

But here's where the story becomes complicated. These genuine strengths are all fundamentally about pattern matching and automation. They're solving a real problem, but it's not the entire problem of code review.

Context Gap: What AI Code Reviewers Cannot Review

Most probably, the last significant bug you found in production wasn't caught by static analysis or pattern matching. Identifying that bug might have involved understanding why a decision was made, how multiple systems interact under specific conditions, or what assumptions were baked into the architecture years ago.

This is what AI fundamentally cannot see: context. Here are a few things where AI code reviews are not good enough yet:

1. Limited Understanding of Architectural Intent

The architectural intent behind a change is nearly invisible to AI tools. While AI can analyze implementation details, identify coding patterns, and verify syntactic correctness, it has little awareness of the architectural objectives guiding the system. It cannot reliably determine whether a change aligns with long-term design principles or understand the tradeoffs that shaped previous decisions.

Architecture is built on compromises. Teams constantly balance scalability, maintainability, reliability, cost, and delivery speed. Without that context, AI may recommend technically correct changes that conflict with the architectural direction the team intentionally chose.

2. Missing Historical Context

Design decisions in mature systems are often shaped by previous incidents, outages, and expensive lessons learned. AI rarely understands why specific workarounds or constraints exist because that reasoning is seldom documented alongside the code.

Legacy code may appear unnecessary when viewed in isolation while actually protecting against known production failures. A seemingly awkward implementation could prevent cascading failures discovered years earlier. Much of this historical knowledge lives within engineering teams through experience and institutional memory rather than repositories that AI can access.

3. Incomplete Repository and Dependency Awareness

Most AI code review tools operate within the boundaries of a pull request diff. As a result, hidden dependencies between services, shared libraries, internal platforms, and data pipelines are easily overlooked. A change that appears isolated can trigger downstream effects across multiple systems that are never referenced directly in the modified code.

Cross-repository relationships remain particularly difficult to evaluate. Modifying an internal library can affect dozens of consuming services, while changes to shared APIs or data pipelines can ripple throughout an entire platform. Without visibility into these relationships, AI reviews remain inherently incomplete.

4. Lack of Runtime Understanding

Static analysis also provides little insight into how software behaves after deployment.

AI has limited visibility into production traffic patterns, system behavior under load, and the operational characteristics that determine reliability. Without runtime context, it cannot accurately assess whether a change introduces operational risk.

Observability requirements, rollback complexity, and known failure modes frequently exist outside the scope of code review. Performance implications often depend on real workloads, infrastructure conditions, and production traffic patterns rather than source code alone.

5. Weak Business Context Awareness

Finally, technical correctness does not guarantee business correctness. A change may look perfectly valid from a software engineering perspective while violating domain rules, breaking compliance requirements, or conflicting with customer expectations. Business logic errors often appear indistinguishable from correct implementations when viewed purely through code.

Human reviewers frequently identify these issues because they understand what the product is supposed to do, not because they detect syntax or implementation mistakes. That understanding of intent, customer needs, and business outcomes remains one of the biggest advantages human reviewers bring to the review process.

Mistaking Detection for Understanding

As AI code review becomes more common, teams increasingly treat detection as understanding. The misunderstanding leads to the following dangerous situations:

1. False Confidence in Automated Approval

The most immediate risk is false confidence. When a pull request receives few or no automated comments, teams begin perceiving it as low risk. Engineers may approve changes simply because the AI did not flag anything.

The mental shortcut is understandable but dangerous. An AI not finding issues does not mean issues do not exist. The actual issue may involve a different pattern, context, or failure mode that the AI has not encountered or learned to identify, causing it to be missed. As teams begin treating AI feedback as a substitute for engineering judgment, automated approval signals can gradually weaken critical review practices. Over time, review quality declines as engineers become increasingly reliant on automated assessments.

2. High Signal, Low Context

AI excels at identifying patterns but not necessarily their significance. A detected issue may be technically valid while being operationally irrelevant in your specific environment. Conversely, review comments often lack awareness of broader architectural constraints, business priorities, or operational tradeoffs that influenced the implementation.

Developers must still determine whether a recommendation should actually be applied rather than assuming every suggestion adds value.

3. Critical Issues Stay Invisible

Some of the most important engineering risks simply cannot be inferred from static code analysis. Some failures only emerge during runtime when multiple parts of a system interact. Distributed systems failures frequently involve multiple services and infrastructure components that are invisible within a pull request. Data consistency issues, retry storms, and cascading failures similarly arise from interactions across systems instead of individual implementations.

Architectural regressions can also pass review because each code change appears reasonable in isolation, even though the combined effect introduces long-term technical risk.

4. Noise and Reviewer Fatigue

Excessive low-priority comments from AI tools can actually decrease review quality. When developers encounter dozens of style suggestions mixed with a handful of meaningful findings, important signals become diluted. Engineers spend valuable time addressing formatting or stylistic recommendations instead of evaluating critical risks. False positives increase review overhead rather than reducing it.

As comment quality becomes inconsistent, trust in automated review systems gradually declines, turning AI from a helpful assistant into another source of engineering friction.

How to Build Better AI Reviewers

We need to fundamentally rethink how AI is integrated into the engineering workflow. Here are several ways to optimize AI code reviewers for better outcomes:

1. Expand Context Beyond Code

To produce more meaningful reviews, AI should have access to architecture diagrams, Architecture Decision Records (ADRs), technical documentation, incident reports, service ownership information, and dependency maps. Infrastructure artifacts such as Kubernetes manifests, CI/CD pipeline definitions, API contracts, and configuration changes should be analyzed alongside application code rather than separately.

Techniques such as Retrieval-Augmented Generation (RAG) and knowledge graphs can further enrich reviews by connecting AI to system-wide context and historical engineering knowledge. The more context available, the fewer blind spots the reviewer develops.

2. Connect AI to the Engineering Ecosystem

Context should come directly from the systems where engineering work happens. AI should integrate with source repositories, issue trackers, observability platforms, deployment systems, and internal documentation. Protocols such as the Model Context Protocol (MCP) enable real-time access to engineering tools and operational data, allowing reviews to be informed by live system state rather than static assumptions.

Instead of guessing which components are affected, AI can identify impacted services, understand deployment history, and incorporate operational information from the software delivery lifecycle. However, access should be deliberately scoped. AI should generally have read-only visibility into the broader engineering ecosystem, with write or modification permissions granted only where they are explicitly required and controlled. Without these boundaries, an agent acting on contextual information from one system could inadvertently make changes in another system where it should have no authority.

3. Impact- and Risk-aware

With richer context available, reviews should evolve from file-level analysis to change-impact analysis. Rather than cataloging issues within the modified files, AI should identify affected services, APIs, databases, and downstream dependencies. Production telemetry, deployment history, logs, metrics, and previous incidents provide valuable signals for assessing operational risk that static analysis alone cannot capture.

Feedback should be prioritized based on reliability, security, performance, and architectural impact instead of maximizing the number of review comments. The objective is to surface the changes that matter most, not every possible improvement.

4. Combine Review with Intelligent Validation

Review should become the starting point for automated validation rather than the final step. AI findings can automatically trigger targeted tests, security scans, policy checks, and environment validation based on the risk introduced by a change. Instead of merely identifying potential issues, the review process should answer practical engineering questions:

What systems are affected?
What could fail?
What needs to be validated before deployment?

In this model, AI becomes an engineering copilot that provides context-rich risk analysis and guides validation, while human reviewers remain responsible for architectural judgment, business correctness, and final decision-making.

What Developers Are Actually Saying About AI Code Reviews

"Silence is better than noise. In 71% of the reviews, Copilot code review surfaces actionable feedback. In the remaining 29%, the agent says nothing at all." (Source)

Developers frequently report that AI flags code that was written intentionally. Performance optimizations, defensive programming patterns, compatibility workarounds, and domain-specific logic are often identified as unnecessary complexity because the AI lacks the historical or architectural context behind those decisions. A recent large-scale empirical study of 54,791 AI-generated code review comments found that the two most common reasons developers ignored AI feedback were incorrect suggestions and intentional design decisions, reinforcing that technically plausible recommendations often fail when architectural intent is missing.

Another recurring theme is context blindness. Engineers we talked to describe AI making suggestions that ignore architectural boundaries, cross-service dependencies, previous production incidents, or business requirements that are never visible within a pull request. In a GitHub Community discussion on improving Copilot code review, developers describe Copilot as a "review assistant" rather than an enforcing reviewer, noting that AI can explain potential issues but still depends on human judgment and complementary validation tools.

Many teams also mention review fatigue. Reddit discussions around GitHub Copilot Reviews describe developers spending more time filtering repetitive or low-value suggestions than evaluating meaningful engineering risks.

Common complaints include AI generating technically correct but contextually irrelevant comments, missing the broader application flow, and creating a loop of increasingly minor recommendations that slows reviews instead of accelerating them.

Interestingly, GitHub itself acknowledges this challenge. In its engineering blog, the Copilot team explains that "Silence is better than noise" and describes ongoing work to reduce low-value comments while improving signal quality. Their recent updates focus on retrieving more repository context, reasoning across pull requests, and prioritizing actionable findings instead of maximizing comment volume.

Where Do We Stand on AI Code Reviews?

AI code review is not mature enough to replace human code review, and pretending otherwise creates risk. These tools still lack architectural judgment, historical memory, runtime awareness, and business context. But that does not mean teams should abandon them. Used wisely, AI code review can still be a powerful accelerator: it can catch repetitive issues early, enforce standards consistently, surface security concerns faster, and free engineers to focus on the decisions that require deeper judgment.

Clear review guidelines, defined approval boundaries, contextual documentation, risk-based validation, and human accountability are what turn AI code reviews from a noisy automation layer into a useful engineering assistant. That is the approach we take at Improving, helping organizations adopt AI in practical, responsible ways that improve engineering outcomes without weakening the judgment, trust, and governance that strong software teams depend on.

I'd love to hear your thoughts on this article. You can share your perspective, feedback, or experiences with AI code review with me on LinkedIn.

Category: AI