Mert

本文是 UI 架构系列的第二篇，建议先阅读 第一篇：三层颜色体系与系统化设计方案 了解核心设计理念。

前言

在上一篇文章中，我们建立了一套完整的颜色体系。但颜色只是 UI 的基础，真正让 UI 活起来的是形态和交互。

一个按钮不仅需要颜色，还需要：

• 圆角、描边、阴影
• 按下、禁用、选中的状态变化
• 渐变、透明等视觉效果

这些都需要通过 Drawable 来实现。

贯穿 UI 架构层的一条铁律：颜色、Drawable、Style 等所有资源定义，都不要和业务挂钩；命名表达的是 UI 职能，职能 ≠ 业务。一旦用「登录页按钮」「订单失败红框」这类业务语义去命名或拆分资源，就等于把形态和颜色锁死在某个页面——可复用性会被立刻破坏。Drawable 层只描述形态、色系、交互状态与档位，业务含义由使用它的页面自己承担。

跨平台：Android 的 Drawable/selector 对应 iOS 的 Asset Catalog 状态图、Web 的 design-token + CSS 状态类；命名与分层思想一致。

本文要点：

1. 为什么需要 Drawable 层规范
2. Drawable 层的三层架构设计
3. 统一的命名规范
4. 形态层和组件层的设计要点

一、为什么需要 Drawable 层规范？

1.1 反例：混乱的 Drawable 管理

在我接触过的项目中，经常会看到这样的 Drawable 定义：

<!-- btn_primary.xml -->
<shape>
    <solid android:color="#FF4B00" />
    <corners android:radius="24dp" />
</shape>

<!-- btn_primary_pressed.xml -->
<shape>
    <solid android:color="#CC3D00" />
    <corners android:radius="24dp" />
</shape>

<!-- btn_disabled.xml -->
<shape>
    <solid android:color="#CCCCCC" />
    <corners android:radius="24dp" />
</shape>

1.2 问题分析

1.3 根本原因

这些问题的本质在于：形态定义与颜色、状态过度耦合。当一个 Drawable 文件同时承载了形状、颜色和状态逻辑时，任何改动都会变得非常困难。

二、Drawable 层的三层架构

借鉴颜色体系的设计思路，我们同样采用三层架构来管理 Drawable：

2.1 核心原则

与业务解耦：三层都只表达「UI 语言」，不表达「业务故事」。sel_orange_interact_capsule_emphasis_default 可以在下单主按钮、会员开通按钮、活动页主按钮上复用；若做成 sel_order_submit_primary，换页面就要复制一套 Drawable，主题与形态也无法在全 App 统一维护。

三、命名规范：让每个文件都有明确的含义

3.1 命名公式

{类型}_{色系}_{用途}_{状态}_{档位}

3.2 组成说明

3.3 命名示例

bg_orange_fill_interact_1    // 橙色交互填充背景，主档位
bg_gray_surface_card_1       // 灰色卡片表面背景
sel_orange_interact_outline_emphasis_default  // 橙色描边交互选择器
bg_black_fill_scrim_1        // 黑色遮罩填充

3.4 反例：业务绑定如何毁掉复用

❌ 错误：文件名承载业务，无法跨场景复用
bg_login_page_primary_btn.xml
bg_order_detail_pay_btn.xml
sel_profile_avatar_upload_error.xml

三个文件往往只是圆角、色值、状态略有相似，却无法合并维护。正确做法是共用 sel_orange_interact_capsule_emphasis_default 等职能 + 形态命名，由不同页面的布局或 Style 决定用在哪里。

四、形态层设计：结构 + 功能色引用

4.1 基础形状类型

4.2 形状定义规范

<!-- bg_orange_fill_interact_1.xml -->
<shape xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">
    <solid android:color="@color/func_orange_bg_1" />
    <corners android:radius="@dimen/draw_corner_capsule" />
</shape>

<!-- bg_orange_stroke_interact_1.xml -->
<shape xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">
    <solid android:color="@color/func_clear_1" />  <!-- 透明填充 -->
    <stroke 
        android:width="@dimen/draw_stroke_reg" 
        android:color="@color/func_orange_border_1" />
    <corners android:radius="@dimen/draw_corner_capsule" />
</shape>

关键设计点：

• 使用 @dimen 引用尺寸（由设计师在 dimens 中定义），避免硬编码
• 使用 @color/func_* 引用功能色，支持主题切换；禁止在 drawable 中写 #RRGGBB 或直接引用 t_*、基础色
• 同一套圆角/描边结构可搭配不同色系的功能色，由设计师在 token 层切换映射

五、状态色设计：状态逻辑放在 Drawable 层

在设计这套体系时，我们曾讨论过是否需要添加「禁用态」「选中态」「按下态」等状态相关的颜色到颜色层。

结论：状态色应该放在 drawable 层，而不是颜色层。

5.1 为什么不在颜色层定义状态色？

1. 职责分离：颜色层负责提供「原料」，drawable层负责组合「成品」
2. 灵活性：同一个颜色可以在不同状态下有不同表现
3. 可复用性：一套颜色可以组合出多种状态效果

5.2 状态效果的正确实现方式

<!-- drawable/sel_orange_interact_capsule_emphasis_default.xml -->
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- 禁用态 -->
    <item android:state_enabled="false">
        <shape>
            <solid android:color="@color/func_black_bg_2" />  <!-- 禁用态用灰色背景 -->
            <corners android:radius="24dp" />
        </shape>
    </item>
    <!-- 按下态 -->
    <item android:state_pressed="true">
        <shape>
            <solid android:color="@color/func_orange_bg_2" />  <!-- 按下态用浅色 -->
            <corners android:radius="24dp" />
        </shape>
    </item>
    <!-- 常态 -->
    <item>
        <shape>
            <solid android:color="@color/func_orange_bg_1" />  <!-- 常态用主色 -->
            <corners android:radius="24dp" />
        </shape>
    </item>
</selector>

六、组件层设计：状态组合

6.1 Selector 的规范写法

<!-- sel_orange_interact_capsule_emphasis_default.xml -->
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- 禁用态 -->
    <item 
        android:drawable="@drawable/bg_gray_fill_interact_2" 
        android:state_enabled="false" />
    <!-- 按下态 -->
    <item 
        android:drawable="@drawable/bg_orange_fill_interact_2" 
        android:state_pressed="true" />
    <!-- 常态 -->
    <item android:drawable="@drawable/bg_orange_fill_interact_1" />
</selector>

6.2 状态优先级

Selector 中状态判断优先级（高 → 低）：禁用态 > 选中态 > 按下态 > 焦点态 > 常态

6.3 输入框状态示例

<!-- sel_gray_field_rect_idle_default.xml -->
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item 
        android:drawable="@drawable/bg_gray_field_rect_2" 
        android:state_enabled="false" />
    <item 
        android:drawable="@drawable/bg_blue_field_rect_1" 
        android:state_focused="true" />
    <item android:drawable="@drawable/bg_gray_field_rect_1" />
</selector>

七、常用组件的 Drawable 实现

7.1 按钮组件

7.2 输入框组件

7.3 卡片组件

八、尺寸管理：统一的 Dimen 规范

8.1 圆角尺寸

<!-- dimens_drawable.xml -->
<dimen name="draw_corner_none">0dp</dimen>
<dimen name="draw_corner_sm">4dp</dimen>
<dimen name="draw_corner_reg">8dp</dimen>
<dimen name="draw_corner_lg">12dp</dimen>
<dimen name="draw_corner_capsule">999dp</dimen>  <!-- 胶囊形 -->

8.2 描边尺寸

<dimen name="draw_stroke_thin">0.5dp</dimen>
<dimen name="draw_stroke_reg">1dp</dimen>
<dimen name="draw_stroke_thick">2dp</dimen>

8.3 阴影尺寸

<dimen name="draw_shadow_elevation_1">2dp</dimen>
<dimen name="draw_shadow_elevation_2">4dp</dimen>
<dimen name="draw_shadow_elevation_3">8dp</dimen>

九、与颜色体系的集成

9.1 颜色引用规范

<!-- ✅ 正确：引用功能色层 -->
<solid android:color="@color/func_orange_bg_1" />
<stroke android:color="@color/func_orange_border_1" />

<!-- ❌ 错误：直接引用主题色或基础色 -->
<solid android:color="@color/t_orange_4" />  <!-- 不推荐 -->
<solid android:color="@color/orange_4" />    <!-- 禁止 -->

9.2 夜间模式自动适配

得益于三层颜色架构，Drawable 层无需任何修改即可支持夜间模式：

日间模式：
func_orange_bg_1 → t_orange_4 → orange_4 (#FF4B00)

夜间模式：
func_orange_bg_1 → t_orange_4 → orange_3b (#FF8833)

十、与 View 的集成方式

10.1 通过 Style 引用

<!-- styles_button.xml -->
<style name="Btn.Orange.Capsule.Emphasis" parent="BaseButton">
    <item name="android:background">@drawable/sel_orange_interact_capsule_emphasis_default</item>
    <item name="android:textColor">@color/func_white_text_1</item>
</style>

10.2 在布局中直接使用

<Button
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/sel_orange_interact_capsule_emphasis_default"
    android:text="主操作" />

十一、完整架构总结

十二、总结

Drawable 层是连接颜色和 UI 组件的桥梁，它的设计直接影响到：

• UI 的一致性和美观度
• 代码的可维护性
• 主题切换的灵活性

通过遵循以下原则，你可以构建一套优秀的 Drawable 体系：

1. 与业务解耦：Drawable 只表达形态与交互语义，绝不使用页面名、流程名、业务事件名
2. 分离关注点：形态结构与填色引用分离，状态组合与组件分离
3. 统一命名规范：{类型}_{色系}_{用途}_{状态}_{档位}
4. 复用优先：避免重复定义，提高资源利用率
5. 与颜色体系集成：只引用设计师定义的 func_*，支持主题切换

参考代码：

• Drawable 资源目录
• 样式定义
• 尺寸定义

💡 如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、转发。关注我，获取更多 Android 架构设计干货。

系列文章：

• 第一篇：三层颜色体系与系统化设计方案
• 第二篇：Drawable 层规范与工程实践（本文）
• 第三篇：Style 层如何系统性消除代码冗余
• 第四篇：设计主权回归与团队落地

本文是 UI 架构系列 的第一篇，将深入探讨颜色层的设计。后续文章将依次介绍：

• 第二篇：Drawable 层规范与工程实践
• 第三篇：Style 层如何系统性消除代码冗余
• 第四篇：设计主权回归与团队落地

注：本文以 Android 为例进行说明，但核心思想完全适用于 iOS、React、H5、小程序等任何平台。

前言

在多年的跨平台 App 开发实践中，我发现 UI 资源管理是困扰许多团队的共性问题：

• 颜色定义混乱，同一个色值重复定义几十次
• 组件形态与颜色过度耦合，难以复用
• 样式属性重复书写，维护成本极高
• 主题切换困难，夜间模式适配工作量巨大
• 新同事需要花费大量时间理解混乱的颜色命名

如果你也被这些问题困扰，这个系列或许值得一读——主要面向设计总监、设计师、研发总监与前端工程师。

本文要点：

1. 三层颜色架构的设计理念和核心原则
2. 每一层的具体设计规范和代码实现
3. 如何实现日间/夜间模式的无缝切换
4. 架构的适用场景和扩展方向

架构全景

本系列介绍的是一套完整的 UI 架构体系，其中三层颜色架构是核心基础：

箭头表示引用/依赖方向：应用层引用 func_；func_* 引用 t_；t_ 引用基础色。定义权在设计侧，自下而上配置。*

颜色层依赖关系：func_* → t_* → 基础色（严格单向依赖）

本文聚焦于三层颜色架构的完整设计，后续文章将介绍上层应用层如何基于颜色层构建。

一、传统颜色管理的核心痛点

1.1 真实项目中的反例

在我接触过的多个项目中，经常会看到类似这样的颜色定义：

<!-- 从真实项目中截取的颜色定义 -->
<color name="bg_login">#FFFFFF</color>      <!-- 登录页背景 -->
<color name="bg_home">#F5F5F5</color>      <!-- 首页背景 -->
<color name="bg_profile">#FFFFFF</color>    <!-- 个人中心背景 -->
<color name="text_title">#141414</color>   <!-- 标题文字 -->
<color name="text_desc">#808080</color>    <!-- 描述文字 -->
<color name="text_hint">#BFBFBF</color>    <!-- 提示文字 -->
<color name="button_red">#DB121F</color>   <!-- 红色按钮 -->
<color name="red_button">#DB121F</color>   <!-- 另一个红色按钮 -->

1.2 问题分析

1.3 根本原因

这些问题的本质在于：颜色定义与业务语义、主题逻辑过度耦合。当一个颜色既承载了”背景”的业务含义，又承载了”白色”的具体色值时，任何改动都会牵一发而动全身。

二、三层颜色架构设计理念

针对这些问题，我设计了一套严格单向依赖的三层颜色架构：

2.1 架构核心原则

重要说明：功能色层封装的是 UI 职能（如文本、背景、边框），而非具体业务场景。func_black_text_1 代表黑色系主档文本色，可用于商品标题、页面标题、按钮文字等任何场景，不绑定具体业务。功能色的定义权归属设计师，研发只引用、不新增。

2.2 严格单向依赖规则

为什么必须严格遵守单向依赖？

• 避免循环依赖导致的颜色定义混乱
• 每层只做自己的事，职责清晰，便于定位问题
• 改一处全局生效，维护成本极低
• 多人开发不会互相冲突

三、分层详解：每一层该怎么设计

3.1 第一层：全局基础色层

定位：纯原始色值定义，不做任何主题绑定和业务关联

命名规则：色系_数字 下划线格式，数字按明度/饱和度递增

设计原则：

• 白色系：数字越小越浅（white_1 = 纯白）
• 黑色系：数字越小越浅（black_1 = 浅灰）
• 彩色系：数字越小饱和度越低
• 不参与日夜切换，保持绝对稳定

完整基础色表（与仓库实现一致）：

代码示例：

<!-- ✅ 正确：统一色系_数字命名 -->
<color name="white_1">#FFFFFF</color>
<color name="black_8">#000000</color>
<color name="red_4">#DB121F</color>
<color name="black_1">#F0F0F0</color>
<color name="white_1_alpha20">#33FFFFFF</color>

3.2 第二层：主题适配层（t_）

定位：唯一的日夜模式映射层，只做色值代理，不承载任何业务语义

命名规则：t_基础色名，与基础色一一对应

设计原则：

• 只引用基础色层变量，绝对不写具体色值
• 日间/夜间模式通过 Android 资源限定符自动切换
• 保持与基础色完全一致的命名，便于维护

错误做法（常见误区）：

<!-- ❌ 错误：主题层承载了业务语义 -->
<!-- values/colors.xml -->
<color name="t_bg_page">#FFFFFF</color>
<color name="t_text_main">#000000</color>

<!-- values-night/colors.xml -->
<color name="t_bg_page">#141414</color>
<color name="t_text_main">#FFFFFF</color>

问题：主题层承载了业务语义，破坏了分层原则。新增主题时需要复制所有业务语义的颜色。

正确做法：

<!-- ✅ 正确：只做颜色映射，不关心用途 -->
<!-- values/colors_theme_tokens.xml（日间模式） -->
<color name="t_white_1">@color/white_1</color>
<color name="t_black_8">@color/black_8</color>
<color name="t_orange_4">@color/orange_4</color>

<!-- values-night/colors_theme_tokens.xml（夜间模式） -->
<color name="t_white_1">@color/black_8</color>   <!-- 背景色反转 -->
<color name="t_black_8">@color/white_1</color>   <!-- 主文字色反转 -->
<color name="t_orange_4">@color/orange_3b</color> <!-- 夜间使用较浅的橙色 -->

优势：

• 主题层只做颜色映射，不关心用途
• 新增主题只需要加一个资源目录
• 夜间模式切换完全由 Android 系统自动处理，零代码侵入

3.3 第三层：功能色层（func_）

定位：面向 UI 职能的语义抽象层，不承载业务语义（如「登录页背景」「删除按钮红」）

命名规则：func_{色系}_{职能}_{档位}，档位数字按该职能下的深浅/重要性递增

设计原则：

• 只引用主题层变量，绝对不直接引用基础色
• 采用「色系 × 职能 × 数字档位」模式，保留无限扩展能力
• 由设计师在资源文件中定义与维护；研发在布局/代码中只引用已有 token

为什么我反对固定语义命名？

很多人喜欢这样定义功能色：

<color name="func_text_main">@color/t_black_8</color>
<color name="func_text_sub">@color/t_black_5</color>
<color name="func_text_aux">@color/t_black_3</color>

这在实际项目中会出问题：中间态越来越多，命名很快失控。比如需要一个介于 sub 和 aux 之间的颜色时，该叫 func_text_sub2 还是 func_text_medium？

最佳实践：色系 + 职能 + 数字档位

<!-- 黑色系文本：档位越小越深、越重要 -->
<color name="func_black_text_1">@color/t_black_8</color>
<color name="func_black_text_2">@color/t_black_7</color>
<color name="func_black_text_3">@color/t_black_5</color>
<color name="func_black_text_4">@color/t_black_3</color>

<!-- 黑色系背景：档位越小越浅 -->
<color name="func_black_bg_1">@color/t_black_8</color>
<color name="func_black_bg_2">@color/t_black_7</color>

<!-- 橙色系强调 -->
<color name="func_orange_text_1">@color/t_orange_4</color>
<color name="func_orange_bg_1">@color/t_orange_4</color>

无限扩展能力：

• 需要在 func_black_text_2 与 func_black_text_3 之间加一档，由设计师新增 func_black_text_25 即可
• 不用造 func_product_title 这类业务名
• 规范可长期稳定

职能分类速览（详见第六节完整矩阵）：

四、两个关键争议点的深度解析

4.1 争议1：主题层到底该不该承载业务语义？

我的答案：绝对不应该。

主题层的本质是颜色代理，它的唯一职责是根据当前主题返回对应的基础色。它不应该关心这个颜色是用来做背景还是文字。

如果主题层承载了业务语义：

• 每新增一个主题，你都要复制所有业务语义的颜色
• 业务语义变化时，你需要修改所有主题文件
• 架构的解耦性被完全破坏

4.2 争议2：功能层用数字命名会不会可读性差？

不会，只要约定好规则。

我们只需要在团队内部约定：

• 文本色：数字越小越重要、越深
• 背景色：数字越小越浅
• 边框色：数字越小越深

新人只需要花 5 分钟就能记住这些规则，比记住几十个不同的语义名称要容易得多。

五、核心优势：为什么这套架构能解决问题？

5.1 维护成本显著降低

改色流程对比：

5.2 无限扩展能力

• 新增色系：只需要在基础色层添加
• 新增主题：只需要加一个资源目录
• 新增 UI 职能档位：由设计师在功能层顺延数字编号

5.3 团队协作零成本

• 统一的命名规范，没有歧义
• 新成员 5 分钟就能上手
• 多人开发不会互相冲突

六、功能色层详解：7大色系 × 6种职能

在实际项目中，我们发现一个 App 中常用的颜色职能只需要6种：

而这 6 种职能，组合7大色系，就构成了一个完整的颜色体系。

6.1 为什么是这7大色系？

6.2 完整颜色矩阵

文本色（7色系 × 4档 = 28个）：

背景色（7色系 × 2档 = 14个）：

边框色（7色系 × 2档 = 14个）：

分割线、透明度、阴影色（各7色系 × 2档 = 各14个）：

理论矩阵规模：7 色系 × 6 职能 × 2–4 档 ≈ 84 个 token，可覆盖绝大多数通用 UI 场景。本仓库 demo 仅实现常用子集（见 colors_semantic.xml）；完整矩阵由设计师按产品需要逐步补齐，研发不自行「补色」。

6.3 核心原则：职能无关，业务通用

这套颜色体系是业务无关的。同一个 func_red_text_1：

• 在电商 App 中可以用作「商品下架」提示
• 在社交 App 中可以用作「被拉黑」提示
• 在金融 App 中可以用作「交易失败」提示

颜色本身不承载业务语义，业务语义由使用场景决定。

6.4 反例 vs 正例

反例：业务绑定

<!-- ❌ 错误：业务绑定，无法复用 -->
<color name="func_product_delete_text">@color/t_red_5</color>    <!-- 商品删除文字 -->
<color name="func_order_cancel_text">@color/t_red_5</color>    <!-- 订单取消文字 -->

正例：职能无关

<!-- ✅ 正确：职能无关，业务通用 -->
<color name="func_red_text_1">@color/t_red_5</color>    <!-- 任何需要红色文字的地方 -->
<color name="func_red_text_2">@color/t_red_4</color>    <!-- 任何需要浅红文字的地方 -->

6.5 完整命名规范速查表

命名公式：func_{色系}_{职能}_{档位}

色系前缀：

职能后缀：

七、总结

这套三层颜色架构的核心思想其实很简单：解耦。

• 把色值定义和主题适配解耦
• 把主题适配和 UI 职能语义解耦（职能语义仍由设计师定义，不绑定具体业务页面）
• 每一层只做自己最擅长的事

通过「7大色系 × 6种职能」的设计，我们构建了一套完整、可扩展、业务无关的颜色体系，覆盖 App 所有通用 UI 场景。

参考代码：

• 基础色定义
• 日间主题层
• 夜间主题层
• 功能色定义

💡 如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、转发。关注我，获取更多 Android 架构设计干货。

Originally published at korixinc.com.

Measuring AI ROI requires a 5-layer framework: direct cost reduction (hours saved, errors reduced), revenue acceleration (faster decisions, better targeting), risk avoidance (compliance costs prevented), capability premium (things now possible that were not before), and compound effects (improvements that accelerate over time). Most teams fail at ROI measurement not because AI is not delivering value, but because they only measure the first layer and ignore the rest.

You deployed an AI system six months ago. The engineering team says it is working well. But when your CFO asks “what is the return on this investment?” the room goes quiet. Not because the system is failing — but because nobody set up the measurement to answer that question. This is the most common failure mode in enterprise AI, and it kills more programmes than bad models do.

The problem is that traditional ROI calculation — (gain from investment minus cost of investment) divided by cost of investment — does not map cleanly to AI. AI creates value across multiple dimensions simultaneously: it reduces costs, accelerates revenue, avoids risks, enables new capabilities, and compounds improvements over time. If you only measure direct cost savings, you are presenting perhaps 30% of the actual value to your board. The other 70% is real, but invisible because you are not measuring it.

This article gives you a practical framework for measuring all five layers of AI ROI, with concrete formulas, realistic timelines, and a board presentation structure that translates AI performance into the financial language your executive team already speaks.

3–6 monthstypical timeline to measure meaningful AI ROIKORIX estimate

Why most teams can’t prove AI ROI

ROI feels impossible because traditional metrics do not map cleanly to AI. When your finance team calculates ROI on a new warehouse, the formula is straightforward: increased throughput minus lease cost. When they try to calculate ROI on an AI document processing system, the value is spread across time savings, error reduction, compliance improvement, employee reallocation, and capabilities that did not previously exist. No single metric captures all of it.

Many teams fall back on the “AI is different” excuse. They argue that AI value is too diffuse, too long-term, or too qualitative to measure. This is wrong. AI is not different — it just needs different measurement. You would not measure the ROI of a sales team by counting the number of phone calls they make. You would measure the revenue they generate. The same principle applies to AI: measure outcomes, not activity.

Consider what happened with one operations-heavy client we worked with. They were manually processing several thousand documents monthly with multiple staff members and frequent data-entry errors. The process was expensive, slow, and error-prone — but nobody had ever quantified exactly how expensive, how slow, or how error-prone. After deploying AI extraction, processing time dropped significantly and accuracy improved measurably. The ROI calculation was straightforward: hours saved multiplied by hourly cost, plus error reduction multiplied by cost per error. But it was only straightforward because we had established the baseline before deployment. Without those pre-deployment numbers, the team would have been guessing.

The three structural reasons teams cannot prove AI ROI are consistent across organisations:

• No baseline measurement. They never documented the cost, speed, and error rate of the process before AI. Without a “before” number, the “after” number is meaningless.
• Single-dimension measurement. They measure only direct cost savings and miss the other four layers of value: revenue acceleration, risk avoidance, capability premium, and compound effects.
• Technical language in financial conversations. They present model accuracy and processing speed to a board that thinks in cost per transaction and revenue per employee. The value is real, but the translation is missing.

If you are not sure whether your organisation has the data foundations needed for clean ROI measurement, an AI readiness assessment can identify the gaps before you deploy.

The baseline problem

If you did not measure the process before AI, you cannot prove AI improved it. Before any deployment, document: time per task, cost per unit, error rate, throughput, and headcount involved. These five numbers are the foundation of every ROI calculation that follows.

The KORIX AI ROI Framework: 5 layers

Most organisations measure only Layer 1 — direct cost reduction — and present that as the total AI ROI. This typically captures 20–40% of the actual value. The remaining value is real, measurable, and often larger than the direct savings. But it requires a structured approach to capture it.

The framework works in layers because AI value accumulates over time. Layer 1 is visible within weeks. Layer 5 may take twelve months or more to materialise. Boards that understand this layered timeline make better investment decisions because they are not judging a twelve-month programme by its three-month results.

Layer 1: Direct Cost Reduction

This is the most tangible layer and the one your CFO will scrutinise first. It includes three components: time saved (hours no longer spent on the task, multiplied by the hourly cost of the people who were doing it), headcount freed (staff who can be redeployed to higher-value work), and error reduction (the cost of mistakes that no longer happen).

Direct cost reduction is measurable within one to three months of deployment. It maps directly to operating costs, which makes it the easiest layer to present to a board. The formula is simple: (baseline cost per unit minus post-AI cost per unit) multiplied by volume.

Layer 2: Revenue Acceleration

AI does not just reduce costs — it accelerates revenue by enabling faster decisions, better targeting, and new commercial capabilities. A demand forecasting system that improves inventory accuracy also reduces stockouts, which means more sales. A lead scoring system that prioritises higher-converting prospects means more revenue per sales hour.

Revenue acceleration is harder to attribute cleanly than cost reduction, but it is often the larger number. The measurement approach is A/B comparison where possible: compare revenue from AI-assisted processes against a control group using the old process. Where A/B is not feasible, use before-and-after comparison with controls for seasonal and market factors.

Layer 3: Risk Avoidance

Risk avoidance measures the bad things that did not happen because AI was in place. Compliance violations prevented. Audit findings avoided. Security incidents caught before they escalated. Regulatory penalties not incurred. For organisations in regulated industries — financial services, healthcare, legal — risk avoidance is frequently the largest single layer of AI ROI.

The challenge with risk avoidance is that you are measuring a counterfactual: what would have happened without AI. The most credible approach is to use historical incident rates as the baseline. If your pre-AI compliance error rate was 3.2% and post-AI it dropped to 0.4%, the risk avoidance ROI is the expected cost of the prevented incidents. For governed AI systems with complete audit trails, this calculation becomes significantly more defensible.

Layer 4: Capability Premium

Capability premium captures the value of things you can now do that were previously impossible or impractical. An AI system that analyses customer sentiment across fifty thousand support tickets per month is not just doing what a human team did faster — it is doing something that was never feasible at that scale. The insight it generates has value that cannot be measured as cost reduction because no cost existed before.

Measuring capability premium requires asking: what decisions can we now make that we could not make before? What markets can we enter? What products can we offer? What response time can we achieve? The monetary value is the revenue or cost impact of those new capabilities.

Layer 5: Compound Effects

AI systems improve over time as they process more data. A document extraction model that is 92% accurate in month one may be 97% accurate in month six because it has learned from edge cases. A demand forecasting model gets more precise as it accumulates more historical patterns. This compounding effect means that the ROI measured in month three is not representative of the ROI in month twelve.

Compound effects are measured by tracking the same metrics over time and fitting a trend. If cost per transaction is dropping 8% month over month, that compounding rate is itself a valuable metric to present to the board. It demonstrates that the AI investment is not just delivering returns — it is delivering accelerating returns.

L1Direct Cost ReductionTime saved, headcount freed, errors eliminated — 1–3 monthsL2Revenue AccelerationFaster decisions, better targeting, new capabilities — 3–6 monthsL3Risk AvoidanceCompliance costs avoided, incidents prevented — 6–12 monthsL4Capability PremiumThings now possible that were not before — 6–12 monthsL5Compound EffectsAccelerating improvements over time — 12+ months

How to calculate each layer

Each layer has a specific calculation approach. The key is not precision — it is consistency. A conservative estimate that you track monthly is far more valuable than a precise estimate that you calculate once and never update. Boards trust trends more than snapshots.

Layer 1 formula: Direct Cost Reduction

Monthly savings = (baseline hours per task − current hours per task) × tasks per month × fully loaded hourly cost

Add to this: (baseline error rate − current error rate) × volume × average cost per error. The “fully loaded hourly cost” should include salary, benefits, overhead, and management time — not just the base hourly rate. Most organisations undercount this by 30–50% because they use base salary instead of total cost of employment.

Layer 2 formula: Revenue Acceleration

Revenue uplift = (AI-assisted conversion rate − baseline conversion rate) × opportunity volume × average deal value

Where A/B testing is not possible, use: (post-deployment revenue − projected baseline revenue, adjusted for market factors) × AI attribution percentage. The attribution percentage is a judgment call — be conservative. A 40–60% attribution to AI for improvements in AI-assisted workflows is a credible starting point.

Layer 3 formula: Risk Avoidance

Risk avoidance = (historical incident rate − current incident rate) × average cost per incident

Include in “cost per incident”: regulatory penalties, audit costs, remediation effort, customer compensation, and reputational damage where quantifiable. For industries where a single compliance failure can cost six or seven figures, this layer often justifies the entire AI implementation cost on its own.

Layer 4 approach: Capability Premium

Capability premium does not have a clean formula because it measures net-new value. The approach is to identify each new capability AI enables and estimate its commercial value: new revenue streams opened, market segments now addressable, response times now possible, analysis depths now feasible. Track these as a portfolio of capability-driven outcomes.

Layer 5 approach: Compound Effects

Track any Layer 1–4 metric monthly and calculate the month-over-month improvement rate. If cost per transaction is dropping 5–10% per month consistently, that compound rate is itself a powerful board metric. Project the compound trajectory forward to show the board what the 12-month and 24-month ROI looks like if the trend holds.

The biggest ROI mistake

The biggest ROI mistake is measuring too early. AI systems improve over time as they learn from more data. A system measured at month one will underperform the same system measured at month six. Set expectations with your board for a 3–6 month measurement window before drawing conclusions about long-term ROI.

150–300%estimated ROI range for well-executed AI implementations over 3 yearsSource: industry estimates (McKinsey, 2025)

The board presentation framework

Your board does not want to understand AI. They want to understand what AI is doing to the numbers they already track. The most effective AI ROI presentations never mention model architecture, training data, or inference speed. They present before-and-after comparisons in the financial language the board already uses.

What boards actually want to see

In our experience across multiple client board presentations, executives consistently prioritise three things: how much is this saving us (Layer 1), how much more revenue is it generating (Layer 2), and what risks is it reducing (Layer 3). Layers 4 and 5 are strategic context that supports continued investment — they are important but secondary to the financial headline.

The structure that works is a one-page summary with four sections:

• Headline metric: Total ROI as a single number or ratio (e.g., “3.2x return on AI investment year-to-date”)
• Before/after comparison: Three to five key metrics showing the pre-AI baseline versus current performance
• Layer breakdown: How the total ROI splits across the five layers, showing which types of value are materialising
• Trajectory: Month-over-month trend showing whether ROI is accelerating, stable, or declining

Before/after metrics that work

An e-commerce company we worked with needed AI demand forecasting across hundreds of SKUs. Their data lived in three disconnected systems — sales history in one platform, supplier lead times in another, marketing calendar in a spreadsheet. After building a unified data structure and deploying AI, inventory accuracy improved measurably within three months. Stockouts dropped. Overstock write-offs fell. The board presentation wrote itself: cost per unit of inventory holding before versus after, with clear cost attribution to the AI system.

The before/after format works because it requires no AI knowledge to interpret. Your CFO does not need to understand what a demand forecasting model does. They need to see that inventory holding cost dropped from X to Y, and that the drop is attributed to the AI system deployed in a specific month. That is a financial conversation, not a technical one.

The 1-page AI ROI summary structure

For each AI use case in production, maintain a living one-page document with this structure:

• Use case name and deployment date
• Baseline metrics (pre-AI, documented with date)
• Current metrics (latest month)
• Delta (improvement in absolute numbers and percentage)
• Financial impact (delta translated into monetary value per month and cumulative)
• Total cost of ownership (monthly AI operating cost including infrastructure, monitoring, and staff time)
• Net ROI (financial impact minus total cost of ownership)
• Trend (is the ROI improving, stable, or declining month over month?)

This single page, updated monthly, gives the board everything they need to evaluate and justify AI investment. It takes perhaps two hours per month to maintain once the instrumentation is in place. If you are considering whether your organisation is ready for this kind of structured measurement, check the 7 signs you are ready for AI.

The best board presentation is the one that could be understood by someone with zero AI knowledge. If your CFO needs a glossary to read your ROI report, the report is wrong.

Common ROI measurement mistakes

These five mistakes are not theoretical — they are patterns we see repeatedly in organisations that struggle to justify continued AI investment. Each one is avoidable with the right measurement structure in place from the start.

Mistake 1: Measuring too early

AI systems improve over time. A document processing model that is 91% accurate in week two may be 96% accurate in month four because it has been retrained on edge cases your data surfaces. Measuring ROI in the first month and extrapolating to a year produces an underestimate that can kill a programme that would have delivered strong returns by month six. Set the board’s expectations for a 3–6 month measurement window before drawing conclusions.

Mistake 2: Counting only direct savings

If your ROI calculation includes only Layer 1 (direct cost reduction), you are presenting a fraction of the real value. A compliance AI system might save 2,000 per month in direct processing time (Layer 1). But it also prevents compliance incidents that historically cost 50,000 each (Layer 3) and enables the compliance team to take on new regulatory requirements they previously lacked capacity for (Layer 4). Presenting only the 2,000 makes the investment look marginal when it is actually transformative.

Mistake 3: Ignoring the counterfactual

The counterfactual is: what would have happened without AI? If your industry is experiencing a skills shortage and your manual process was already struggling before AI, the relevant comparison is not “AI cost versus current process cost” — it is “AI cost versus the cost of the process degrading further without AI.” Some AI investments prevent deterioration rather than improve on a stable baseline. That prevention value is real ROI, but you have to measure it explicitly.

Mistake 4: Using vanity metrics

Model accuracy is not business value. A model that is 98% accurate on a low-stakes task generates less business value than a model that is 90% accurate on a high-stakes task. The metric that matters is not how accurate the AI is — it is what the accuracy produces in financial terms. Always translate technical metrics into their financial consequences: “98% accuracy means 2% of transactions require manual review, costing approximately X per month.”

Mistake 5: Not attributing compound effects

When your AI system gets better every month, that compounding improvement is itself a form of value that most organisations never quantify. If processing cost is dropping 6% per month due to continuous learning, that trajectory is worth presenting to the board. It shows that the AI investment is not just delivering returns — it is delivering accelerating returns. A flat ROI justifies maintenance. An accelerating ROI justifies expansion.

The attribution rule

When in doubt, be conservative with attribution. A board that sees a conservative ROI estimate they trust is more likely to approve expansion than a board that sees an optimistic estimate they question. Credibility compounds in the same way that AI accuracy does.

When AI ROI is genuinely hard to prove

Not every AI project has a clean ROI calculation. Some projects deliver value that is real but structurally difficult to quantify. Acknowledging this honestly — rather than forcing every project into a dubious ROI framework — is itself a sign of measurement maturity.

Exploratory AI projects

Research and exploration projects — testing whether AI can solve a problem you are not yet sure is solvable — have uncertain ROI by definition. The appropriate framework here is not ROI but expected value: the probability of success multiplied by the value of success, minus the cost of the exploration. If a three-month exploration costs 30,000 and has a 40% chance of unlocking a capability worth 500,000 annually, the expected value is positive even if four out of ten explorations fail.

Governance and compliance AI

Governance AI is a particular challenge because its primary value is preventing bad outcomes rather than creating good ones. A financial services firm we worked with automated document analysis for loan applications. The ROI was not just processing speed — it was regulatory compliance maintained at scale. Compliance officers could trace every AI recommendation back to the source data and the decision logic. That traceability meant auditors could review decisions faster, audit preparation time dropped from hundreds of hours to a fraction of that, and the risk of audit findings decreased measurably.

That is risk avoidance ROI: the cost of the audit you did not fail, the penalty you did not receive, the remediation you did not need. It is real value, but it requires comparing against a counterfactual — what would have gone wrong without the governed AI system in place.

The honest approach

For AI projects where ROI is genuinely difficult to quantify, the most credible approach is layered honesty:

• Layer 1 (direct savings): Present the hard numbers you can prove
• Layers 2–3 (revenue and risk): Present conservative estimates with clear assumptions stated
• Layers 4–5 (capability and compound): Present qualitative descriptions of the strategic value, without forcing a number

A board that sees honest layering — some numbers you are confident in, some estimates you are transparent about, and some qualitative value you describe without inflating — trusts the entire presentation more than a board that sees a single inflated number they cannot verify.

If you are evaluating whether AI is right for your specific situation, our 21-Day AI Pilot is designed specifically to generate real ROI data from your own processes before you commit to full deployment. The pilot gives you Layer 1 numbers you can take to your board with confidence.

The Bottom Line

Stop measuring one layer.
Start measuring all five.

AI ROI is not a single number — it is five layers of value that materialise at different speeds. Direct cost reduction is the starting point, not the whole picture. Revenue acceleration, risk avoidance, capability premium, and compound effects are where the majority of AI value lives. Measure all five, present them honestly, and your board will see AI as an investment, not an expense.

FAQ

Common questions about

measuring AI ROI.

Have a question not listed here?

Ask us directly →

How long does it take to see ROI from AI?

Most organisations see initial measurable results within 3 to 6 months of production deployment. A well-scoped 21-day pilot can demonstrate validation ROI even sooner. Strategic ROI — competitive advantage and new capabilities — typically emerges at the 6 to 12 month mark. The key is setting realistic expectations for each phase.

What is the average ROI of AI implementation?

Industry estimates suggest 150 to 300 percent ROI over three years for well-executed implementations (Source: McKinsey, 2025). However, this varies enormously by use case. Process automation tends to deliver faster returns than exploratory projects. The most reliable estimate comes from running a pilot on your specific process and extrapolating from measured results.

How do you calculate AI ROI?

Calculate across five layers: direct cost reduction (hours saved × hourly cost + errors reduced × cost per error), revenue acceleration (conversion uplift × deal value), risk avoidance (incidents prevented × cost per incident), capability premium (value of new capabilities), and compound effects (month-over-month improvement trajectory). Sum all five for complete ROI.

Can you measure AI ROI before deployment?

Yes, via a pilot. A 21-day AI pilot gives you real performance data from your own processes. By establishing baseline metrics before the pilot and measuring against them during, you get a credible ROI projection based on actual results rather than vendor estimates. This is significantly more reliable than pre-deployment forecasting based on industry benchmarks alone.

What are the hidden costs of AI that affect ROI?

Hidden costs include: data preparation and cleaning (often 40–60% of project effort), integration with existing systems, staff training and change management, ongoing model monitoring and retraining, governance and compliance overhead, and the operational owner’s time for maintenance. A realistic ROI calculation subtracts total cost of ownership, not just the initial build cost. See our guide on AI implementation costs for a complete breakdown.

Originally published at korixinc.com.

Agent Deployment as a Service (ADaaS) is a delivery model where a specialist firm deploys working AI agents directly into your production environment — no strategy decks, no multi-month discovery phases, no implementation left to you. The shift from traditional AI consulting to ADaaS is the most significant commercial change in the AI services market heading into 2026, and it is being driven by one simple buyer frustration: paying five figures for a roadmap you then have to build yourself.

This article explains what ADaaS is, why the traditional consulting model is breaking down, which buyer profile belongs in each camp, and how to evaluate whether an ADaaS provider is the real thing or just a consultant with better branding.

The Consulting Output Problem

Ask any operator who has hired an AI consultancy in the last two years what they received. The honest answer, more often than not, is a presentation.

Sometimes it is a “strategic roadmap.” Sometimes it is a “technology assessment.” Sometimes it is a detailed implementation guide with vendor recommendations. What almost never comes out of it is a working system sitting inside the business doing actual work.

This is not a failure of intelligence on the consultant’s part. It is a structural feature of how consulting is designed. Consulting firms bill for analysis, frameworks, and recommendations. Execution is a different engagement — often with a different team, a different commercial arrangement, and a different timeline that starts from scratch.

The McKinsey State of AI report has consistently found that the gap between AI ambition and AI deployment remains wide across industries. Organisations report high interest in AI but substantially lower rates of production deployment. That gap has a name: implementation debt. Businesses accumulate strategy they cannot execute.

The pattern is consistent. A company spends three to six months in discovery and design with a consulting firm. They receive recommendations. Internal teams — already stretched — are asked to carry the build. The build stalls. The budget is exhausted. The AI initiative is quietly deprioritised. Eighteen months later, a new consultancy is brought in to “reassess the landscape.”

Buyers in 2026 are starting to refuse this cycle. They want agents in production, not advice about agents.

The “Strategy First” Trap

Some providers use “strategy phase” language to describe what is effectively a paid scoping exercise with no deployment obligation. Before signing any AI services contract, confirm in writing whether the engagement ends with a working system or a document. If the answer is a document, you are buying consulting, not deployment.

What Agent Deployment as a Service Actually Covers

ADaaS is not a rebranded consulting retainer. It is a fundamentally different commercial structure with different inputs, outputs, and risk allocation.

A genuine ADaaS engagement includes:

1. A scoped, time-bounded discovery — typically one to five days, not months. The goal is to identify the highest-leverage deployment target, not to map your entire enterprise AI strategy.
2. Agent build in a real environment — agents are built against your actual stack, your actual data, and your actual workflows. Not a sandbox. Not a demo environment.
3. Deployment to production — the agent goes live before the engagement closes. Deployment is not a future milestone; it is the contractual deliverable.
4. Ownership transfer — you own the code, the logic, and the configuration. There is no ongoing licence fee to access what was built for you.
5. Guardrails and observability — any responsible ADaaS provider builds in monitoring, logging, and override capability from day one. Governed AI practices are not optional extras; they are built into the deployment.

What ADaaS does not cover is enterprise transformation strategy, change management programmes, or vendor evaluation for large-scale platform decisions. Those are legitimate consulting needs — they just belong in a different commercial model.

The distinction matters because it determines where the risk sits. In consulting, the risk of a recommendation not working sits with you. In ADaaS, the risk of the agent not working sits with the provider. That is a fundamentally different incentive structure.

The Deliverable Test

Apply this test to any AI services proposal: what is the deliverable on the final day of engagement? If the answer is a document, a presentation, or a set of recommendations, you are buying consulting. If the answer is a working system processing real data inside your business, you are buying deployment. The deliverable test will save you more money than any due-diligence checklist.

Why 2026 Is the Inflection Point

Three forces converged to make ADaaS commercially viable at scale in 2026, and understanding them helps you evaluate whether a provider is ahead of the curve or still operating on 2022 assumptions.

Agents matured past prototype. The tooling for building production-grade AI agents — orchestration frameworks, reliable API ecosystems, vector databases, observability layers — reached a level of stability in 2024-2025 that makes 21-day deployments feasible where they were not before. The Stanford HAI AI Index 2025 documented the sharp acceleration in agent capability benchmarks across reasoning, tool use, and multi-step task completion. What required a research team in 2022 can be shipped by a focused engineering team in weeks today.

Buyer sophistication increased. The Gartner Hype Cycle for AI noted the market moving through peak inflated expectations. Buyers who went through a failed AI initiative in 2023 or 2024 have scar tissue. They ask sharper questions. They push back on vague timelines. They want contractual milestones tied to working software, not phase completions.

The consulting supply problem. Major consultancies cannot deploy at the speed or specificity that small and mid-size service businesses need. Their commercial model requires large contracts to justify partner-level attention. A 30-person professional services firm does not get the same team as a FTSE 500. ADaaS providers, built specifically for the 20-150 staff segment, can be more responsive, more specific, and more accountable.

“AI is the new electricity. It’s going to transform every industry. But the bottleneck isn’t the technology anymore — it’s deployment.” — Andrew Ng, Founder of DeepLearning.AI

The Deloitte AI Institute has similarly reported that organisations with dedicated deployment capability — as opposed to those relying solely on strategic guidance — show markedly faster time-to-value from AI investments. The pattern holds: advice without execution is the bottleneck, not the ambition.

If you are unsure whether your business is ready for deployment rather than strategy, the AI readiness assessment takes under two minutes and tells you where you actually sit.

The ADCO Framework: Four Stages of ADaaS Maturity

To help buyers evaluate providers and plan their own progression, KORIX uses the ADCO Framework — a four-stage model that maps the maturity of an Agent Deployment as a Service engagement.

1. Assess A time-bounded diagnostic of your existing stack, your highest-friction workflows, and the deployment targets most likely to return value within 30 days. Assessment output is a deployment brief, not a strategy document. The brief names the agent, the trigger, the integration point, and the success metric. Duration: one to five days.

2. Deploy The agent is built, tested, and pushed to production against your real environment. This is the stage that traditional consulting omits or defers. In a well-run ADaaS engagement, Day 1 of Deploy follows immediately after Assessment. Duration: seven to 21 days depending on complexity.

3. Calibrate The first two to four weeks after go-live are calibration, not maintenance. Edge cases surface. Threshold adjustments are made. Monitoring confirms the agent is behaving as designed. Calibration is included in the engagement, not billed as a separate phase. Duration: two to four weeks post-deployment.

4. Own Ownership transfer is explicit and complete. You receive the code, the documentation, the environment configuration, and a handover session. Your team can modify, extend, or replace the agent without returning to the provider. The provider’s engagement ends at Own; there is no lock-in, no licence, no ongoing dependency.

This framework is the commercial inverse of how consulting typically operates. Consulting firms generate recurring revenue from ongoing engagement. The ADCO model generates referrals and reputation from clean exits — clients who got what they needed, own it outright, and come back when they are ready for the next agent.

Agent Deployment as a Service: The 2026 Model That Replaced AI Consulting — at a glance.

ADaaS vs Traditional AI Consulting: A Direct Comparison

The market for AI services in 2026 includes a range of providers, and not all of them are honest about which model they are operating. The table below compares the primary categories on dimensions that matter to a 20-150 staff buyer.

The SaaS route is worth a separate note. No-code AI platforms have made it possible for non-technical teams to build basic automations without engineering support. For simple, low-stakes workflows, that is often the right answer. But when the workflow involves sensitive data, complex integrations, or business-critical decision-making, a platform’s template library hits its ceiling quickly. The build vs buy decision framework explains where that ceiling typically sits.

The Buyer Profile Each Model Serves

Not every business needs ADaaS, and being honest about that matters. The wrong model is expensive regardless of which direction the mismatch runs.

When Traditional Consulting Is the Right Answer

If your business has 500+ staff and is evaluating a multi-system AI transformation across departments, a consulting firm with change management capability is the appropriate choice. The complexity of stakeholder alignment, procurement, and governance at enterprise scale genuinely requires a strategic layer that ADaaS providers are not built to deliver.

Similarly, if your business has not yet identified a specific operational problem — if you are in “we should probably do something with AI” territory — a light-touch advisory engagement to structure your thinking is more useful than jumping to deployment. The 7 signs your business is ready for AI is a practical starting point for that self-assessment.

When ADaaS Is the Right Answer

ADaaS fits a specific and well-defined buyer:

• 20-150 staff service businesses where the founder or ops lead can name a specific, painful, repetitive process
• Existing software stack that works and does not need replacement — the agent connects to what is already there
• Time pressure — the business cannot wait six months for strategy to turn into execution
• Ownership preference — the buyer wants an asset, not a subscription to a capability

The BYOS philosophy — Bring Your Own Stack — is foundational here. Businesses that already run on functional software (CRMs, project management tools, email, document systems) are ideal ADaaS candidates because the integration surface is well-defined. Agents slot in alongside existing tools rather than replacing them.

Anna Mazurowska at Numerology-Matrix is a direct example of this profile. Her business had a clear, painful bottleneck: each client reading took three to four hours of manual work. The process was defined. The inputs and outputs were known. The bottleneck was execution capacity, not strategic direction. The KORIX engagement automated that process to eight minutes per client — a 95% time reduction and an 8x capacity increase — because the deployment target was specific and the existing workflow was understood before a line of code was written.

“They thought like product partners, not just developers.” — Anna Mazurowska, Founder, Numerology-Matrix. [Published Clutch review]

That framing — product partner rather than consultant — is the operational distinction that separates ADaaS from advisory work. A product partner cares whether the thing works in production. A consultant cares whether the recommendation was defensible.

How to Evaluate an ADaaS Provider (And Spot the Fakes)

The term “Agent Deployment as a Service” is new enough that it has not yet been diluted by providers who deliver consulting under the label. But that will change. Here is what to test.

Ask for production evidence, not demos. A legitimate ADaaS provider can show you agents running in production for real clients, not sandbox demos built for sales calls. Ask specifically: “Can you show me an agent you deployed in the last 90 days that is still running in a client’s production environment?” If the answer is a pivot to a demo, that tells you something.

Ask who owns the code on Day 22. The answer should be unambiguous: the client owns the code, the configuration, and the documentation, with no ongoing licence dependency. If the provider hedges, or if ownership is conditional on a continuing relationship, you are looking at a SaaS product dressed as a service.

Ask what happens if it does not work. A provider confident in their deployment capability will have a clear answer to this — either a guarantee structure, a partial-refund policy, or a defined remediation process. Vague answers about “working together to resolve issues” are not guarantees. KORIX’s 21-Day AI Pilot includes an explicit production guarantee: if a working system is not in production by Day 22, the second invoice is not owed and the client keeps everything built. That is a concrete commitment.

Check the stack philosophy. A provider who immediately recommends a new platform you have to purchase, or who requires you to migrate your data to their environment, is not operating an ADaaS model — they are operating a platform sale with services attached. The right provider works inside your existing stack. The BYOS philosophy exists specifically to protect clients from unnecessary platform dependency.

Review their failure literacy. Ask the provider to describe a deployment that did not go as planned and what they did. Providers who have only success stories either have not deployed enough or are not being honest. The common AI failure modes piece covers the patterns that separate avoidable failures from genuine complexity — a good provider will be fluent in all of them.

The partner evaluation guide covers additional due-diligence dimensions if you are shortlisting multiple providers. The AI implementation cost guide sets commercial benchmarks so you can assess whether pricing is consistent with the model being offered.

“ADaaS Is Just a Faster Version of Consulting”

Speed is a by-product of ADaaS, not the definition of it. The structural difference is risk location and deliverable type. A consultant who delivers a roadmap in two weeks instead of six months is still a consultant — the output is still advice you have to implement. ADaaS is defined by what arrives on the final day of engagement: a working system in production, owned by you, built on your stack. The timeline compression is a consequence of that commitment, not the cause of it.

What ADaaS Changes for Your Business Operationally

The commercial model difference is clear. What is less obvious is what ADaaS changes inside your business once an agent is running.

Capacity unlocks compound. The first agent deployed usually reveals the second. Once a team experiences a high-friction process running on autopilot, they immediately identify the next candidate. The AI ROI metrics research consistently shows that time-to-second-deployment shrinks significantly after a successful first deployment — because the organisation’s confidence in what AI can do is grounded in real evidence rather than theoretical potential.

Process documentation improves as a side effect. Building an agent requires specifying a workflow precisely enough for software to execute it. That specification process surfaces undocumented logic, exception handling gaps, and process variation that nobody had mapped before. Businesses often report that the documentation produced during agent scoping is valuable independently of the agent itself.

The AI budget conversation changes. When a business has a working agent in production, the ROI conversation shifts from hypothetical to empirical. Instead of estimating potential value from an investment, you are measuring actual value from a deployed system. That evidence base makes the conversation about expanding AI capability substantially easier — internally with finance, and externally if the business is raising or selling.

For businesses evaluating where to start, the AI agent library provides a structured view of the categories of agents most commonly deployed in service businesses at the 20-150 staff scale, including document processing agents (explored further in the document processing tools guide), lead intelligence agents, and operational monitoring agents.

“The thing that’s been missing is not models — it’s the willingness to actually ship things into production and let them run.” — Allie K. Miller, AI entrepreneur and former Amazon AI Business Development Lead

That willingness — to commit to production, to put a working system in front of real users doing real work — is the defining characteristic of the ADaaS model and the reason it is replacing strategy-first consulting for the service business segment in 2026.

Not sure if you’re ready for AI?Take our 2-minute assessment and get a personalised readiness score.Take the Assessment →

Making the Decision: ADaaS, Consulting, or Neither

The decision is not binary, and pretending it is will lead you to the wrong answer.

Some businesses need consulting first — to develop enough clarity about their AI opportunity to deploy intelligently. If you cannot name a specific process, a specific bottleneck, and a specific measure of success in a ten-minute conversation, you may not yet have the deployment target defined enough for ADaaS to work. A light advisory engagement to sharpen that brief is money well spent.

Some businesses need neither — they need better use of tools they already have. The best no-code AI platforms guide covers where off-the-shelf tools genuinely serve the need without a custom engagement. Do not hire a deployment firm to do what a £50/month platform can do.

And some businesses — particularly those in the 20-150 staff range, with a named bottleneck, an existing stack, and a team that will not learn a new platform regardless of how good it is — need deployment now, not strategy. For that profile, ADaaS is the 2026 answer.

The 2-minute AI readiness assessment will tell you which category you are in before you spend a pound on any external resource.

The Bottom Line

In 2026, buyers are refusing to pay for AI strategy they then have to build themselves — Agent Deployment as a Service replaces the consulting model by making a working agent in production the contractual deliverable, typically within 21 days.

The consulting model produces advice. ADaaS produces agents in production. For service businesses with 20 to 150 staff that have a named bottleneck and an existing software stack, ADaaS is the faster, lower-risk, and more accountable path to AI value. The ADCO Framework — Assess, Deploy, Calibrate, Own — defines what a genuine ADaaS engagement looks like and where responsibility sits at each stage. Before engaging any AI services provider in 2026, apply the deliverable test: what is in your hands on the final day of the engagement? The answer tells you everything.

FAQ

What is Agent Deployment as a Service?

Agent Deployment as a Service (ADaaS) is a commercial model where a specialist firm builds and deploys working AI agents directly into a client’s production environment within a defined timeframe — typically 7 to 21 days. Unlike traditional AI consulting, which delivers strategy documents and roadmaps, ADaaS delivers a functioning system running inside your existing software stack. The client owns the code and configuration outright at the end of the engagement, with no ongoing platform licence or dependency on the provider. The core distinction is that deployment — not advice — is the contractual deliverable.

How is ADaaS different from traditional AI consulting?

The difference is structural, not cosmetic. Traditional AI consulting produces analysis, recommendations, and roadmaps that the client then has to implement, often with a separate team and separate budget. ADaaS produces a working agent in production, built and deployed by the provider, with code ownership transferred to the client. Risk location differs too: in consulting, if the recommendation does not work, the risk sits with the buyer; in ADaaS, if the agent does not work, the risk sits with the provider. The commercial incentive structure is fundamentally different as a result.

What size of business is ADaaS designed for?

ADaaS is most effective for service businesses with 20 to 150 staff that have an existing software stack they want to keep, a specific high-friction workflow they can articulate clearly, and no appetite for a six-month strategy engagement before anything gets built. Businesses smaller than 20 staff often find that no-code tools or simpler automations are sufficient. Businesses larger than 150 staff with complex multi-department transformation needs often benefit from a consulting layer alongside or before deployment work.

How long does an ADaaS engagement typically take?

From initial discovery call to agent in production, a well-structured ADaaS engagement typically runs 21 days or fewer. The assessment phase takes one to five days to define the deployment target and integration points. The build and deployment phase takes seven to 21 days depending on the complexity of the agent and the number of systems it connects to. Post-deployment calibration — adjusting thresholds and resolving edge cases — runs for two to four weeks after go-live and should be included in the engagement, not billed separately.

What happens if the agent does not work as expected after deployment?

A credible ADaaS provider should have a clear, explicit answer to this question before you sign a contract. KORIX’s 21-Day AI Pilot includes a production guarantee: if a working system is not running in production by Day 22, the client does not owe the second invoice and keeps everything built to that point. When evaluating any provider, ask for their specific remediation or guarantee policy. Vague language about “working together to resolve issues” is not a guarantee — it is a description of a conversation you have not had yet.

Can ADaaS work if my business does not have clean, structured data?

Data quality is a real constraint but not always a blocking one. Many agents work with unstructured or partially structured data — document processing agents, email classification agents, and meeting summary agents are common examples. The more important question is whether the inputs and outputs of the target process are clearly defined, even if the data itself is messy. A good ADaaS provider will assess your data state during the discovery phase and tell you honestly whether deployment is feasible immediately or whether a short data preparation step is required first.

How do I know if my business is ready for ADaaS rather than consulting?

Three questions will tell you quickly. First: can you name a specific process in your business that is repetitive, time-consuming, and rule-based enough that you could write down the steps? Second: does your business run on software tools that work and that your team actually uses? Third: do you want to own the resulting system outright, without a recurring platform fee? If the answer to all three is yes, you are likely an ADaaS candidate. The 2-minute AI readiness assessment at korixinc.com/learning-center/ai-readiness-assessment/ will give you a more structured view.