The Productivity J-Curve: Why Plugging in an LLM Does Not Automatically Make a Company More Productive

Faster Drafts in a Chat Box, Unchanged Throughput on the Floor

Consider a common scenario. An organization deploys an internal chat interface or document assistant; individual employees quickly draft emails, summarize notes, and query internal documents faster than before. Yet when operational leaders review end-to-end metrics—whether cross-functional ticket resolution, plant maintenance scheduling, or contract review handoffs—cycle times and error rates barely move. In such cases, unconstrained text generation upstream can increase the burden on downstream reviewers, who must now verify unformatted drafts without structured data contracts or clear provenance.

In this scenario the bottleneck is not mainly the raw capability of the model; it stems from mistaking API access for production engineering. The economic returns of a general purpose technology materialize only after an organization restructures its business processes, data contracts, and handoff protocols; investments that stop at conversational pilots without leaving behind reusable process assets struggle to climb out of the bottom of the Productivity J-Curve.

General Purpose Technologies and Intangible Capital: The Mechanism Behind the J-Curve

Why do foundational technologies so often coincide with flat or disappointing productivity numbers in their early stages of adoption? Several decades of research on General Purpose Technologies (GPTs) and organizational economics explain the mechanism.

Studying historic engines of growth such as the steam engine, the electric motor, and semiconductors, Bresnahan and Trajtenberg (1995) showed that only a handful of GPTs drive entire eras of technical progress^[2]. These technologies share three defining properties: pervasiveness across sectors, inherent potential for continuous technical improvement, and “innovational complementarities”—meaning that innovation in the GPT itself raises the productivity of research and development in the downstream sectors that use it, generating increasing returns to scale^[2]. Crucially, however, a decentralized economy has difficulty exploiting a GPT to its full potential. When the relationship between technology providers and downstream users consists only of arm’s-length market transactions, neither side can reliably forecast the other’s developments; this coordination failure lowers the rate of technical advance across all sectors and produces innovation that is “too little, too late”^[2]. Buying off-the-shelf model access through a market transaction cannot substitute for the complementary process engineering required inside the adopting firm.

Looking inside the firm, Brynjolfsson and Hitt (2000) synthesized case studies and firm-level econometric evidence to demonstrate two central facts about information technology: first, organizational “investments” exert a large influence on the value of IT investments; second, the benefits of IT investment are often intangible and disproportionately difficult to measure^[3]. Their work noted that the microeconomic link between IT and productivity emerged well before the surge in aggregate productivity statistics, suggesting that the macroeconomic productivity revival partly reflected intangible organizational capital accumulated in the past^[3].

Building directly on this foundation, Brynjolfsson, Rock, and Syverson (2021) formalized the Productivity J-Curve^[1]. When a new GPT such as artificial intelligence arrives, it both enables and requires substantial complementary investments—redesigned workflows, new decision rights, data standards, and workforce retraining. Because these complementary investments are largely intangible and poorly measured in national accounts, resources diverted toward building intangible capital cause measured productivity growth to be under-estimated in a GPT’s early years^[1]. Later, when the accumulated intangible capital begins to yield output, measured productivity growth is over-estimated^[1]. Applying their framework to US macroeconomic data, the authors found that adjusting for intangibles tied to computer hardware and software yields a total factor productivity (TFP) level 15.9 percent higher than official measures by the end of 2017^[1]. It is important to read this number accurately: the 15.9 percent figure is a macroeconomic measurement finding about national statistics, not a firm-level return-on-investment metric.

Industry modeling points to the same organizational prerequisite. In a June 2023 report for McKinsey & Company, Chui et al. (2023) presented model estimates and scenarios—not observed empirical outcomes—suggesting that generative AI could add the equivalent of $2.6 trillion to $4.4 trillion annually across the 63 use cases analyzed^[4]. In their scenarios, the technology could enable labor productivity growth of 0.1 to 0.6 percent annually through 2040, depending on the pace of adoption and how effectively worker time is redeployed^[4]. Yet the report explicitly cautions that realizing these benefits will take time, requiring leaders to rethink core business processes and support workers whose activities shift^[4].

Turning Intangible Capital into Software Engineering: Contracts, Human Gates, and Resumable State

If escaping the trough of the J-Curve requires accumulating intangible organizational capital, what does that capital look like in software architecture? It does not consist of ad-hoc prompt collections saved on individual laptops. In an engineering system, organizational capital takes the form of versioned task graphs, explicit input and output schemas, mandatory human review gates wired into state machines, and auditable handoff records that survive shift changes and runtime interruptions.

Within the Agent OS module on rlab.works, this philosophy is expressed through structured skill packs and atomic components. Consider the skill pack Plan and deliver work (S01), which replaces open-ended chat with a four-stage workflow contract:

• Plan the steps (assisted execution): Starting from an explicit input contract—Goal, scope and delivery requirements—the workflow invokes Goal planning and versioned task graphs (which turns outcomes into plans and dependencies, supporting proposing, diffing, and applying plan revisions) alongside Reusable skill extraction, evaluation and solution packs (which extracts reusable skills from completed work and manages versions and evaluations) to produce a structured task plan.
• Approve the scope (human review): Rather than allowing an agent to act immediately on its own plan, execution pauses at a human gate powered by Auditable workflows, human confirmation and decision review and Collaborative delivery, approvals and evidence gates (approvals and evidence gates). An assigned human reviewer inspects the proposed scope; a rejected output is returned for revision and does not advance.
• Run and collect (assisted execution): Only after human approval does the workflow delegate execution through Persistent goals, bounded subagents and scheduled tasks, Durable governed agent execution, and Sandboxed agent jobs and artifacts, running bounded tasks in isolated environments and collecting execution evidence.
• Review and hand over (human review): At the final human gate, the reviewer evaluates the collected evidence via Collaborative delivery, approvals and evidence gates. Once accepted, Reusable skill extraction, evaluation and solution packs packages the delivery and its reuse record so the organization retains a repeatable asset.

How this pattern applies depends on the industry context and its adaptation boundaries. For general enterprise operations, this skill pack carries no industry tag in the site catalog and serves strictly as a general workflow pattern. In manufacturing it is a transferable use: for example, breaking an equipment maintenance objective into inspection, material preparation, and review tasks, advancing step by step after approval, and retaining shift-handoff evidence. Here, engineering honesty is essential: the software orchestrates digital tasks and human records only. Physical mechanical repairs are carried out by qualified personnel on the shop floor, and work permits and safety checkpoints must be configured before use.

Real-world operations also rarely run from start to finish in a single uninterrupted session; shifts change, approvals wait on external teams, and sessions disconnect. If an interruption forces workers to restart a conversation from scratch, accumulated context evaporates. The skill pack Resume interrupted work (S02) addresses this through a four-step sequence: Recover the history → Confirm the resume point (human review) → Resume execution → Inspect the result (human review). In the capability catalog, this pack is marked as a transferable use only for lifestyle and consumer apps. Its core engineering boundary applies broadly: imported session history is verified as read-only context and must never trigger automatic new execution or billing; resuming work requires either a native checkpoint or explicit human confirmation of a new task.

Finally, architectural transparency requires stating what these capabilities are—and what they are not—today. Every skill pack on the site is a proposed composition demonstrated with synthetic data and not yet connected to live services; domain contract wiring also remains pending. Component maturity ratings reflect static source inspection rather than production deployment, and a source-supported industry label means only that source data has an explicit industry association—it makes no claims about customer deployments or business outcomes. For instance, the component for auditable workflows, human confirmation and decision review is currently a prototype: it persists versioned workflows, pauses for human decisions, and records review outcomes, while its tool steps presently operate as placeholders and records rather than autonomous tool execution.

Three Pre-Pilot Checks for Engineering and Executive Leaders

Before funding another large language model pilot, a CEO or CDO can apply three concrete checks to determine whether the initiative will build durable organizational capital or remain trapped at the bottom of the J-Curve:

• Check the input and output contracts: Does the workflow require a structured initial brief (such as scope, constraints, and delivery criteria) and emit versioned stage artifacts, or does it rely on unconstrained free-text chat? Without explicit schemas, downstream teams pay a hidden verification tax.
• Verify that human gates can block and diff: Are human review points wired into the workflow state machine so that unaccepted plans or outputs are automatically held and returned for revision? A review step without blocking authority, version diffing, and an assigned owner is merely a rubber stamp.
• Inspect what remains after the task finishes: When a workflow completes—or pauses across a shift change—does it leave behind an auditable trail, a safe read-only recovery point, and a reusable task template? Technology investments compound into productivity growth only when each completed delivery lowers the coordination cost of the next one.