Part II — THE EXECUTION LAYER

4.Cogs: Accountable AI Workers

5 min read

the unit at which AI work becomes assignable, governable, and auditable. Assumes: Section 3 (Frames).

Organizations do not employ "intelligence." They employ workers: bounded roles with a job description, defined tools, defined permissions, and a name that can appear in an audit trail. This is not bureaucratic habit. It is how accountability is manufactured. "Who did this, under what authority, with access to what?" only has an answer because work is assigned to defined units rather than to a general pool of capability.

AI, as commonly deployed, has no such unit. A model endpoint answers whatever it is asked by whoever reaches it, and the question "what did the AI do last quarter?" dissolves into a pile of undifferentiated API calls. The whitepaper's execution layer starts by restoring the unit. It calls the unit a Cog.

Anatomy

Anatomy of a Cog

Cog — the atomic unit of AI work

Model

  • general or specialized weights

Context

  • Frames (base)
  • + retrieved docs
  • + memory slices
  • + task instructions

Tools / APIs

  • what it may call

Governance

  • data access,
  • allowed actions,
  • approval rules

A Cog is drawn as one bounded unit containing four parts: a model (possibly specialized), a context founded on one or more Frames that orient the model to the organization, the tools and APIs the Cog may use, and governance parameters — what data it may access, what actions it may take, and what requires human approval. The Cog, not the bare model, is the unit at which AI work becomes auditable and governable.

View as text diagram
            ┌─────────────────────────────────────────────┐
            │                     COG                     │
            │  ┌─────────────┐  ┌──────────────────────┐  │
            │  │    Model    │  │ Context              │  │
            │  │ (general or │  │  Frames (base)       │  │
            │  │ specialized │  │  + retrieved docs    │  │
            │  │  weights)   │  │  + memory slices     │  │
            │  └─────────────┘  │  + task instructions │  │
            │                   └──────────────────────┘  │
            │  ┌─────────────┐  ┌──────────────────────┐  │
            │  │ Tools/APIs  │  │ Governance           │  │
            │  └─────────────┘  │  data access,        │  │
            │                   │  allowed actions,    │  │
            │                   │  approval rules      │  │
            │                   └──────────────────────┘  │
            └─────────────────────────────────────────────┘

The paper is emphatic that the second compartment is where Cog quality is actually decided. A Cog's working context is assembled at invocation time: its Frames provide the durable, governed foundation, around which the system layers retrieved documents, relevant slices of organizational history (the memory substrate Section 7 describes), recent conversation, and task-specific instructions. Deciding what the model sees, in what order, under what constraints, is a first-class engineering discipline, and the paper gives it the section's pull quote:

"A well-constructed Cog is, in large part, a well-managed context."
— whitepaper, §4.4

What the unit buys you

The payoff is the restored question. Instead of "what did the model do?", an organization can ask: what did this Cog do, with what inputs, under which Frames, and what was the outcome? Every noun in that sentence is now a versioned, inspectable thing. The paper's claim, which regulated industries will recognize as the actual bar for deployment, is that this specificity is what makes AI workers deployable where auditors live. Section 2's evidence base carries over directly: the NBER mechanism (codified best practice, distributed to every worker) is precisely what a Frame-oriented Cog operationalizes, with the addition that the codification is now governed rather than folkloric.

On the word "agent"

Readers will have noticed that a Cog sounds adjacent to what the industry calls an AI agent, and the paper addresses the term head-on, calling "AI agent" "increasingly overloaded" and noting that it "carries significant risk connotations" (§4.2). In practice the label stretches from a chatbot with tools to an autonomous system pursuing goals unsupervised, with the risk clustered at the autonomous end. The architecture deliberately unbundles it. A Cog is the worker: it performs discrete cognitive tasks and is not normally an end-to-end autonomous loop (the paper allows simple standalone use, mostly for debugging and one-off work). Coordination, sequencing, retries, goal-seeking, and human oversight live one layer up, in the construct the next section introduces. Keeping the worker separate from the workflow is what lets governance attach to each at the right altitude. The agent frameworks of the mid-2020s drew a version of this line in code, separating workers from the orchestration that coordinates them; what neither side of that line became in those libraries is a governed, versioned, installable artifact with declared validation and human checkpoints, which is where the paper locates the actual gap (§9).

The governance context makes the design choice legible:

The unit is deliberately incomplete: deciding what happens with a Cog's output, sequencing it alongside other work, and placing humans at the right checkpoints all live one layer up, in the Op.