Function-level AI integration underperforms because it never maps work at the task level
Most AI integration programmes produce productivity improvements that are smaller than projected. The tools are effective. The deployment is complete. Adoption metrics are acceptable. And yet the measurable change in output quality, throughput, or workforce capacity falls short of the business case.
The cause is almost always the level of abstraction at which AI was integrated. The programme identified a function — finance, legal, marketing, HR — and deployed AI tools at the function level. Individuals in the function use the tools for the tasks they find them most convenient for. Some tasks are well-suited to AI assistance. Others are not. The programme has no way to distinguish between them because it never mapped work at the level of individual tasks.
The named failure mode this framework addresses is function-level AI integration without task decomposition: the condition where AI tools are deployed into a function without a map of what the function's work actually consists of at the task level. This produces inconsistent AI adoption patterns, because individuals make their own task-level decisions about where to apply AI without a shared design logic. It produces underperformance against the productivity projection, because the projection was modelled at function level using average adoption assumptions rather than at task level using task-specific AI contribution rates. And it produces an inability to improve systematically, because without task-level mapping there is no diagnostic basis for understanding where adoption is working and where it is not.
The Work Units Framework resolves this by making the Work Unit the primary design object: the level at which AI integration is specified, evaluated, and improved.
The Work Units Framework makes the bounded task the primary design object
The Work Units Framework is a decomposition model for knowledge work. It defines the grain at which AI integration should be designed: not at the job level, not at the department level, not at the process level, but at the level of individual Work Units — discrete, bounded tasks with defined inputs, a defined process, a defined output, and measurable quality criteria.
A Work Unit is the smallest meaningful unit of professional work that can be designed, optimised, and measured independently. Writing a first-contact message to a technical audience based on a company research brief is a Work Unit. "Business development" is not. Summarising a set of meeting transcripts into a structured decision log is a Work Unit. "Knowledge management" is not.
The framework sits within the Digital Worker & Workspace dimension (D5) of DQ's 6xD transformation logic: the dimension that asks who delivers transformation and how they work. D5 covers individual capability, workspace design, and the human-machine collaboration patterns that determine how knowledge work is performed. The Work Units Framework operates at the intersection of workspace design and collaboration pattern: it provides the unit of analysis at which AI-augmented work is designed rather than assumed.
Four components turn a task into a measured, AI-augmented design
Work Unit Definition is the starting point. For a given role or team, Work Units are enumerated — each discrete task is named, its inputs specified, its process described, its output defined, and its quality criteria stated. This is not a job description exercise. It is a task-level map of what knowledge workers in this role actually spend time on, at the grain of specificity that makes AI integration designable.
A complete Work Unit specification includes: the trigger (what initiates this task), the inputs (what information or material the task starts with), the process (the steps from input to output), the output (the specific deliverable produced), quality criteria (what makes the output acceptable), and the human judgement points (the steps in the process that require professional discretion rather than information processing).
AI Contribution Mapping applies to each Work Unit once it is defined. For each step in the Work Unit's process, AI Contribution Mapping asks three questions: can AI perform or assist with this step reliably? If yes, what does reliable AI assistance look like, and what does the human verify before accepting the output? If no, why not — is it a judgement requirement, a data access requirement, or a quality standard that current AI cannot consistently meet?
The output of AI Contribution Mapping is a Work Unit-level collaboration design: for this task, performed in this way, this is where AI assists, this is what the human does, and this is how quality is assured. This is the specification that most AI integration programmes skip.
Work Unit Performance Baseline establishes the pre-AI measurement for each Work Unit: how long it takes, what quality level it produces, and what the error or rework rate is. Without a baseline, there is no valid measure of AI contribution. Claims of productivity improvement that are not anchored to a Work Unit baseline are estimates, not evidence.
Iteration Protocol governs how Work Unit designs are improved over time. Once an AI-assisted Work Unit is running with a defined collaboration design and a performance baseline, the Iteration Protocol specifies: how often is the design reviewed, what triggers a redesign (persistent quality gap, new AI capability, process change), and who has authority to revise the collaboration design for a given Work Unit. AI capabilities change. Work Unit designs need to change with them. The Iteration Protocol makes that adaptation systematic rather than ad hoc.
Define the Work Unit first, then map, baseline, and iterate in fixed order
The Work Units Framework is read as a design sequence with a fixed starting point: Work Unit Definition always comes first. You cannot map AI contribution before you have a specific, bounded work unit to map it against, and you cannot establish a performance baseline before the unit is defined and the collaboration design is specified. The sequence — Define, Map AI Contribution, Baseline, then Iterate — is not flexible on order, though the scope can be progressive.
Architects applying this framework should understand that the granularity of Work Unit Definition is the critical design decision. Units defined too broadly produce generic AI Contribution Maps that cannot be implemented. Units defined too narrowly produce an unmaintainable map. The test is whether the unit has a specific, observable output and at least one step that clearly benefits from AI assistance and at least one human judgement point. Units that fail that test need to be redefined before the framework's subsequent steps can produce useful design specifications.
Defining units too broadly, skipping the baseline, and dropping iteration are the recurring failures
The most frequent mistake is defining Work Units at the function or role level rather than at the specific task level. "Marketing communications" is not a Work Unit. "Writing a first-contact message to a technical audience based on a company research brief" is. Work Units defined too broadly produce AI Contribution Maps that are too generic to implement — you cannot specify where AI assists in "marketing communications" because that description covers dozens of different tasks with different AI contribution profiles. The Work Unit Definition must be specific enough that the process can be mapped step by step.
A second common error is skipping the Performance Baseline and measuring AI contribution only after a period of use. Without a pre-AI baseline, there is no valid before-and-after comparison. Teams deploy the AI-assisted Work Unit, observe that outputs seem faster or better, and report productivity improvement. Without a named measurement — cycle time, quality score, error rate — at the Work Unit level before AI assistance was introduced, the observation is an impression, not evidence. The Baseline must be established before the AI-assisted design goes live.
The third misapplication is treating the Iteration Protocol as optional once the initial collaboration design is working well. AI capabilities evolve continuously. A collaboration design that was optimal six months ago may now be under-utilising available AI capability or maintaining human review steps that AI can now handle reliably. The Iteration Protocol is what makes the Work Unit a continuously improving asset rather than a fixed configuration that degrades in value as the AI landscape changes.
Designing for the Work Unit changes the brief, lifts adoption, and makes improvement diagnosable
When transformation architects apply the Work Units Framework to an AI integration programme, the first change is in the design brief. The programme stops specifying which teams get which tools and starts specifying which Work Units are designed for AI assistance and how. That shift changes both what is built and what is measured.
The second change is in adoption. Work Units that have been explicitly designed for AI assistance — with a defined collaboration pattern and quality assurance step — are adopted more consistently and more effectively than functions where AI use is left to individual discretion. The consistency is not cultural; it is architectural. The design makes the expected use pattern clear.
The third change is in the improvement cycle. When Work Unit baselines exist, the programme has a diagnostic basis for improvement. If a Work Unit is underperforming against its baseline even with AI assistance, the AI Contribution Mapping can be revisited: is the step where AI is assisting well-specified? Are the quality criteria clear? Is there a human judgement point that has been incorrectly classified as a process step? These are solvable problems. Without a Work Unit map, they are invisible.
Start with one team, ten Work Units, one AI Contribution Map, one baseline
Select one team in your current AI integration scope. Map ten Work Units for that team — ten specific tasks that team members perform regularly. Use the full specification format: trigger, inputs, process, output, quality criteria, and human judgement points.
Then apply AI Contribution Mapping to one of those Work Units. Document where AI can assist reliably, what the human verifies, and what quality standard the output must meet. Establish the pre-AI baseline for that Work Unit before any AI assistance is introduced.
That process — one team, ten Work Unit definitions, one AI Contribution Map, one baseline — takes two to three working days. The output is a design specification that the AI integration programme can implement and measure against. It is the minimum viable application of the framework and the starting point for scaling to the full team or programme scope.
D5 (Digital Worker & Workspace) is the 6xD dimension that covers individual capability, collaboration patterns, and the workspace conditions that enable effective AI-augmented work. The Work Units Framework operates at the intersection of D5's workspace design and collaboration pattern components — it provides the unit of analysis at which human-AI collaboration is explicitly designed rather than assumed. D5 requires that AI integration be designed, not just deployed; the Work Units Framework is the design instrument that makes that requirement operational at the task level where actual work is performed.
