Part II — THE EXECUTION LAYER

5.Ops: Jobs You Can Install

5 min read

the unit of AI work that maps to business outcomes, and the properties that make it distributable. Assumes: Sections 3–4 (Frames, Cogs).

Ask a knowledge worker what they do and the answer comes back in jobs, not tasks: close the books, onboard this customer, qualify this lead, run the quarterly compliance review. Each job bundles many cognitive tasks, some judgment calls, several systems, and at least one point where somebody senior has to sign off.

Notice what you cannot do with a job today: buy one. The software industry sells tools that help with fragments of jobs, and the AI industry sells capability by the token, but the job itself, the orchestrated, supervised, end-to-end unit, exists only as tribal knowledge plus habit. When an organization wants AI to do a job, it hires integrators to hand-build the workflow, which then exists exactly once, unversioned, unrepeatable, breakable by any change in the systems underneath.

The whitepaper's third execution primitive packages the job itself. An Op is an installable, versioned program of AI-driven work, invoked by a human, that orchestrates Cogs toward a named outcome under declared oversight.

Composition

Composition of the quarterly-compliance-review Op (v2.3.1)

op: quarterly-compliance-reviewv2.3.1

workflow Frames:company-policyregulatory-2026

doc-collectorpolicy-checker
exception-summarizer
human review

An Op named quarterly-compliance-review, version 2.3.1, drawn as one installable package. It applies two workflow Frames: company-policy and regulatory-2026. Inside, a Cog named doc-collector feeds a Cog named policy-checker, while a Cog named exception-summarizer runs in parallel; both paths converge at a human review checkpoint. A supervising model handles sequencing, retries, and escalation. The Op declares a validation strategy (detailed in Section 6) and ships with a manifest of dependencies, environment, and configuration. The example is illustrative, not a shipped product.

View as text diagram
  OP: "quarterly-compliance-review"                    v2.3.1
  ┌───────────────────────────────────────────────────────────────────┐
  │  workflow Frames: company-policy, regulatory-2026                 │
  │                                                                   │
  │  [Cog: doc-collector] → [Cog: policy-checker] ─┐                  │
  │                                                ├→ ◊ human review  │
  │  [Cog: exception-summarizer] ──────────────────┘                  │
  │                                                                   │
  │  supervising model: sequencing, retries, escalation               │
  │  validation strategy: declared (see Section 6)                    │
  │  manifest: dependencies, environment, configuration               │
  └───────────────────────────────────────────────────────────────────┘

Two structural facts matter more than the parts list. First, supervision is interior to the design: an Op is not an autonomous system with oversight bolted on, but a workflow whose human checkpoints are declared components, as much a part of the artifact as its code. Second, the manifest makes the whole thing a package: self-contained, versioned, installable into any deployment that implements the standards, exactly the way a software library installs into any compatible environment.

The property that creates a market

One consequence of this design carries most of the economic weight. Because an Op declares the Frames it requires rather than hard-coding any organization's specifics, the same Op adapts at install time to whoever installs it.

Invocation is deliberately mundane: an icon in a launcher, a command in a terminal or chat, a button inside a business application, a scheduled job. The paper's design goal is that running serious AI-driven work should feel like opening an application, not like operating infrastructure.

The market context, for the record:

The paper's reading of that evidence is explicit: Ops, it says, are "designed to be exactly this kind of redesigned end-to-end primitive" (§4.5), a mapping between product and research finding that the reader is now equipped to judge.

There is one open question this section has deliberately deferred, and it is the one everything commercial depends on. An Op that can be installed from a marketplace is an Op written by a stranger. Before any organization runs a stranger's workflow against its own data, under its own name, somebody has to answer: how do we know the work this thing produces is any good?