Navigating the "Jagged Technological Frontier": How Task-Level Decomposition Determines Enterprise AI Success or Failure

Why the Same Model Boosts Output on One Step and Induces Errors on the Next

Imagine a strategy or investment research team preparing a project brief. An analyst asks a large language model to organize competitor arguments from public notes and draft an initial section; within minutes, the model produces a clear text. Encouraged by that speed, the team hands the next step to the same model: synthesizing conflicting interview notes and table figures into a final business recommendation. The fluent output masks a critical factual mismatch, caught only during the review meeting.

This reversal happens when organizations treat a job role or an entire workflow as the unit of AI adoption. Field experimental evidence shows that large language models can perform in opposite directions on tasks of seemingly similar difficulty; implementation should bound model usage at the task-step level, assigning in-frontier steps to model assistance and reserving out-of-frontier steps for explicit rules and human review.

From Rule-Based Substitution to the "Jagged Technology Frontier": Task-Level Evidence

Understanding how technology reshapes work requires moving the unit of analysis from occupations to tasks. Studying how computerization alters skill demands, Autor, Levy, and Murnane (2003) argued that computer capital substitutes for workers in cognitive and manual tasks accomplished by following explicit rules, while complementing workers in nonroutine problem-solving and complex communications tasks^[2]. Using representative data on task input from 1960 to 1998, they found that within industries, occupations, and education groups, computerization was associated with reduced labor input of routine manual and routine cognitive tasks and increased labor input of nonroutine cognitive tasks^[2]. Translating these task shifts into education demand, their model explained 60 percent of the estimated relative demand shift favoring college labor during 1970 to 1998, with task changes within nominally identical occupations accounting for almost half of this impact^[2].

Large language models reach beyond explicit-rule tasks into nonroutine cognitive work, yet their impact remains task-specific. Eloundou, Manning, Mishkin, and Rock (2024) evaluated the potential labor-market impacts of large language models by assessing their relevance to the tasks workers perform in their jobs^[3]. Applying this framework with both humans and a large language model, they estimated that roughly 1.8% of jobs could have over half their tasks affected by large language models with simple interfaces and general training; when accounting for current and likely future software developments that complement model capabilities, this share jumped to just over 46% of jobs^[3]. Crucially, these numbers are task-exposure estimates, not predictions of job losses; furthermore, the jump from standalone interfaces to complementary software shows that workflow engineering governs how model capability translates into practice.

Even within affected knowledge workflows, however, model capabilities do not form a smooth boundary. In a preregistered field experiment with a global management consulting firm, Dell’Acqua et al. (2023) introduced the “jagged technology frontier,” where AI assistance improves performance for some tasks but worsens it for others within the same workflow and at a seemingly similar difficulty level^[1]. The experiment involved 758 knowledge workers from the consulting firm; after establishing a baseline on similar tasks, subjects were randomly assigned to no AI access, AI access, or AI access with a prompt engineering overview^[1]. Across 18 realistic consulting tasks within the AI frontier—ranging from creative to analytical work—subjects using AI outperformed those without AI, completing 12.2% more tasks and completing them 25.1% more quickly on average while delivering solutions of significantly improved quality^[1]. Yet for a complex managerial task selected to be outside the frontier, subjects using AI were 19% less likely to produce correct solutions than those without AI^[1]. Handing an unsegmented workflow to a model allows out-of-frontier errors to erase in-frontier gains.

Encoding Task Decomposition into Architecture: Input Contracts, Batched Evidence, and Human Gates

Navigating a jagged frontier requires decomposing goals into explicit steps and placing human gates where a workflow crosses outside the model frontier. On rlab.works, this design spans the Agent OS and Intelligence modules.

For cross-functional delivery, the skill pack Plan and deliver work (S01) starts from Goal, scope and delivery requirements. In Plan the steps (assisted), the component Goal planning and versioned task graphs (working code by static inspection) generates a task plan with dependencies and execution modes, supporting proposing, diffing, and applying revisions. Execution then pauses at Approve the scope (human review): an assigned reviewer or requesting user inspects the plan, and rejected output is returned for revision and does not advance. Next, Run and collect (assisted) executes bounded tasks and gathers results and runtime evidence. Finally, Review and hand over (human review) requires sign-off before emitting an accepted delivery package and reuse record. Underneath, Auditable workflows, human confirmation and decision review persists versioned workflows, enforces permission checks, pauses for human decisions, and records review outcomes.

For iterative analysis, Continue research (S08) takes Research question, existing material and available time and proceeds through Load research context (assisted, outputting traceable research state and task definitions), Plan follow-up research (assisted, outputting steps and budget for confirmation), Approve and run (human review, returning rejected output for revision and yielding authorized new material and calculations on approval), and Review the changes (human review, outputting accepted evidence, open questions, and a continuation package). The component Persistent research workspace and memory (working code by static inspection) saves watchlists, sessions, observations, decisions, artifacts, and session bundles. For synthesis and drafting, Research and write a report (S24) takes Research question, permitted sources and report outline, assigning Plan the search scope, Collect and extract material, and Organize citations and findings (producing a cited report draft) to assisted steps, then enforcing Review the evidence (human review, returning rejected output for revision) before Format and export (assisted).

Industry adaptation boundaries must be stated plainly. None of these packs has a source-supported industry tag in business and general services, finance, or legal services; they are general patterns or transferable uses requiring adaptation:

• Plan and deliver work (S01) has no tag for business and general services, finance, or legal services. It is a transferable use in manufacturing (breaking equipment maintenance into inspection, material preparation, and review tasks with shift-handoff evidence), orchestrating software tasks and human records only while personnel perform mechanical repairs under configured work permits and checkpoints.
• Continue research (S08) is a transferable use in finance (continuing multi-week research with prior evidence, scheduling follow-ups, and saving confirmed conclusions), but research execution, general search, and enrichment queues still need wiring, and it is not a native financial workflow. It has no tag for business and general services or legal services.
• Research and write a report (S24) is a transferable use in legal services (retrieving approved case files and regulations around disputed issues, keeping citation locations, and forming a report after legal review), but requires replacing paper ingesters and news topic models, verifying regulatory validity and case applicability, and never generating automated legal conclusions. It has no tag for business and general services or finance.

Every skill pack on the site is a proposed composition demonstrated with synthetic data and not yet connected to live services. Component maturity comes from static source inspection rather than production deployment (and a source-supported industry label means only that source data has an explicit industry association, saying nothing about customers, deployments, or outcomes). Auditable workflows, human confirmation and decision review is a prototype whose tool steps are placeholders and records, with agent suggestions coming from inputs or defaults rather than autonomous tool execution.

Pre-Pilot Checks for Executive and Technical Leaders

Before funding an AI pilot, a CEO, CDO, or department head can apply these checks to verify whether the design respects the jagged frontier:

• Are workflows decomposed into dependent steps rather than framed as whole-role automation? Require teams to separate retrieval, extraction, and draft organization inside the frontier from cross-source contradiction resolution outside it.
• Do human gates sit at frontier boundaries with blocking authority? Confirm that scope approval, budget confirmation, and evidence verification pause the workflow and return rejected outputs for revision rather than advancing them.
• Are source boundaries and industry adaptations explicitly scoped? In finance or legal adaptations, verify that permitted sources are restricted, citation provenance is retained, and the system cannot issue automated trading instructions or legal conclusions.