Agentic Work Systematization

Sources#

• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog
• Enable on-demand expertise with Agent Skills in Genkit Go
• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained
• The New Physics of Business — Garry Tan, Y Combinator
• The Shift to Agentic AI: Evidence from Codex

Summary#

One of three "how" margins OpenAI's Codex usage study uses to measure whether agentic AI is moving beyond one-off assistance: systematization — the shift from ad hoc delegation (describe a task, the agent does it, the interaction ends) to reusable workflow infrastructure that lets similar work be delegated repeatedly without re-supplying context each time. In Codex, this happens through skills (a SKILL.md workflow spec) and plugins (an installable bundle of skills + integrations). The paper's framing: without systematization, "users must repeatedly supply task context, procedural guidance, and instructions, limiting the extent to which work can be handed off." Systematization is therefore a precondition for deep delegation, not a power-user nicety. This is the measured, empirical counterpart to Loop Engineering's skills primitive and to Agent Context Files's "intent written down outside" — Osmani's intent debt argument, now with adoption curves.

Evidence note. empirical — skill-source invocation measured from Codex logs over weekly windows; OpenAI-internal usage is a frontier preview, not a population estimate (see Conversation-to-Delegation Shift's evidence note).

Skill use is common, rising, and uneven#

In the 7-day window ending June 11, 2026:

Population	Share invoking ≥1 skill
Individual users	25.7%
Organizational users	30.4%
OpenAI workers	96.2%

And it is climbing fast: the share of weekly-active Codex users invoking any skill rose from 5.4% (Mar 1, 2026) → 26.6% (Jun 11, 2026) — roughly a 5× increase in three months. Within OpenAI, systematization is effectively the default mode of use; among external users it is a minority practice but a growing one.

The skill taxonomy, and what custom skills reveal#

The paper distinguishes five skill sources, ordered from product-provided to user-authored:

1. Preinstalled — capabilities bundled with Codex (e.g. image generation).
2. Curated — standalone OpenAI-distributed skills not tied to a plugin (e.g. PDF handling).
3. Plugin skills — bundled inside a plugin (e.g. Google Drive document workflows).
4. Custom plugin skills — associated with a recognized plugin but not matching the curated catalog.
5. Custom skills — standalone, user/org-authored, not distributed by OpenAI (team data-viz guidelines, a research workflow).

Growth comes especially from plugins and custom skills — the two ends of the systematization spectrum. Plugins extend general capability into recurring artifact domains (docs, spreadsheets, slide decks); custom skills encode local procedural context — team writing standards, recurring reports, organization-specific workflows, user preferences. The rise of custom skills is the load-bearing signal: users value not just the model's general capability but the ability to attach persistent procedural context to repeated, too-specialized-to-standardize tasks.

The organizational gradient#

Plugin and custom-skill use is highest at OpenAI and substantially higher among organizational than individual users. The paper reads this as variation in the returns to systematization: custom skills pay off most when repeated tasks depend on shared conventions, internal procedures, or team-level standards — conditions far more common in organizational settings than in solo individual use. So systematization concentrates where persistent procedural context reduces coordination cost across repeated tasks. (Appendix detail: 50.9% of OpenAI collaboration conversations invoke a skill — systematization has diffused past code into knowledge work internally.)

This is the same logic as compounding context: the value isn't the one invocation, it's that the encoded workflow is reused and shared across people and time. A skill is the authoring format; a plugin is the distribution unit — the mechanism by which one person's systematization spreads across an org (the same skill≠plugin distinction Loop Engineering draws).

The normative version: "never do one-off work" (Garry Tan, July 2026)#

What this page measures as an adoption curve, Garry Tan states as a discipline (practitioner-opinion): after any successful agent task, "skillify it" — turn the finished interaction into a reusable skill file before moving on, because "if you have to ask for something twice, you failed." His organizational stake: "The organization that captures what it learns like this gets smarter every single day. The one that doesn't wakes up every morning with amnesia, no matter how good the model is." He reports the practice extending past engineers at YC — media, events, and finance staff authoring skill files — which, if representative, is the organizational-gradient claim above playing out inside a single high-complement institution (AI-Native Organization).

Skills as a cross-vendor distribution channel for methodology#

A step past org-internal systematization: in June 2026 Google shipped its agent-quality evaluation methodology as installable skills (npx skills add … from skills.sh, two packages) designed to be driven by whatever coding agent the customer already uses. The taxonomy above runs product-provided → user-authored within one product; this is a third position — vendor-authored methodology distributed in the skill format across agent products. The skill is becoming not just how orgs encode local procedural context but how vendors ship expertise into other vendors' harnesses.

The mirror arrived a month later. Genkit (Daniela Petruzalek, 2026-07-31, vendor-claim) has Google implementing the loading runtime for the same format in its own SDK across TypeScript, Go, Dart and Python — SKILL.md discovery by metadata injection, a use_skill activation tool, bundled scripts and references. Taken together the two posts put one vendor on both sides of the format: authoring skills for other companies' harnesses, and consuming other companies' spec in its own. That is a stronger form of the convergence than either alone, and the reason to read the skill format as a cross-vendor convention rather than a distribution trick. Mechanics and evidence caveats on Agent Context Files — the Genkit post asserts progressive disclosure's token benefit and measures nothing.

What happens after adoption: the skill lifecycle, measured (Gao et al., July 2026)#

The Codex telemetry above measures adoption. The first large-scale study of skills as engineered artefacts (From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained, empirical: 18,463 skills.sh registry skills + 23,199 personal-use skills from 5,876 GitHub repos, 3,709 recovered reuse links, 444 hand-coded diffs) measures what happens after — and the answer is mostly "nothing."

Reuse is a one-time copy, not a dependency. Of 2,462 SE-classified reuse pairs, 1,841 (75%) were adopted near-verbatim (body similarity ≥0.99); only 621 were altered on entry. Across all linked pairs, 70.3% sit at similarity ≥0.99. After adoption the copy goes quiet: only 47.4% of reused skills ever received a local commit, and 53% are never modified at all. Worse for the supply-chain framing — among reused skills never locally updated, 40.2% had their upstream counterpart updated at least once, changes the local copy never received; and among those that were locally updated while upstream also moved, 62.3% diverged independently rather than re-incorporating the upstream change. Skills behave like a copy-paste snippet with a registry attached, not like a version-pinned dependency.

Maintenance is additive. Excluding in-place modifications, additions outnumber removals 2.7:1 overall — 6.1:1 for locally authored skills evolving over time (customisation at adoption is near-balanced at 1.1:1, since adopters prune). Skills grow; the only content frequently deleted is the registry's licence and authorship metadata. This is the complexity ratchet (Ambrosino: models add, rarely delete) showing up in the context layer rather than the code layer.

Customisation re-grounds; evolution accretes. The two settings diverge in what they touch. Customisation (registry → repo) is dominated by reformatting layout (48.9% of diffs), repointing references and resources (34.6%), stripping provenance/licence metadata (17.6%), adapting environment setup (16.0%), and re-scoping to the host project (14.9%) — e.g. an android-data-layer skill swapping Hilt for Koin to match the project stack; repackaging to the host platform occurs exclusively during customisation (12.2% vs 0.0%, the sharpest divergence in the data), typically stripping Claude-specific frontmatter for a platform-neutral layout. Evolution (locally authored, over time) instead expands the procedure: reshaping the workflow (38.4%), revising inline domain knowledge (32.5%), hardening constraints (27.8%), and chasing renames and tooling substitutions (24.3% vs 5.3%) as the surrounding project restructures.

The behavioural contract is inherited, not reviewed. The rules governing how a skill talks to the user, monitors runtime state, and recovers from failure are the least edited content in both settings: user interaction 1.6%/1.2% of diffs, runtime-state monitoring 0.5%/0.0%, failure handling 5.9%/7.1%. Adopters take these near-verbatim from the registry and never revisit them. The authors' implication: these are the parts a skill author must get right at creation, because downstream nobody will — a supply-chain concentration of risk that mirrors dependency-inherited defects, but in prose that no linter reads.

Registry vs. local skills split by knowledge area — independent corroboration of the Codex "custom skills encode local procedural context" claim above. Software Construction dominates both (28.3% registry / 22.1% personal-use) with the other 17 SWEBOK areas a long tail, but registry skills over-index on generic capability (Design 4.3% vs 2.5%, Architecture 3.2% vs 1.9%, Security 3.8% vs 2.3%) while personal-use skills over-index on project-bound lifecycle work — Configuration Management 9.4% vs 4.1%, Testing 6.4% vs 4.9%, Quality 5.7% vs 3.8%, Maintenance 3.9% vs 2.6%. Two independent datasets (OpenAI telemetry, GitHub mining) landing on the same division of labour: the registry supplies general coding capability, local authorship supplies the project-specific procedural context that has no external market.

Packaging discipline. Registry skills are longer and more sectioned than personal-use ones (median 1,678 vs 1,114 tokens, 19 vs 13 headers; Mann-Whitney p<0.001, small effect). Both populations satisfy the mandatory Agent Skills spec provisions at ≥99% (SKILL.md present, valid YAML, description typed and ≤1024 chars), but the optional fields are near-dead: license 16.1%/9.1%, metadata 13.1%/10.4%, allowed-tools 15.0%/12.5%, compatibility 4.0%/3.2%. references/ is the most common optional subdirectory (31.0%/17.0%). Personal-use skills also drift from the spec's name == parent-directory rule (91.2% vs 97.7%) — the kind of break that silently prevents activation. Content-wise a thematic analysis of 180 SKILL.md files yields six themes: scoping and orchestrating (100% of skills), running the execution lifecycle (89%), grounding domain knowledge (85%), governing agent conduct (81%), ensuring output quality (69%), user/agent coordination (68%).

The sharper-than-documentation point. The authors' framing for why this matters more than README rot: "a human reading an out-of-date README can identify and bypass the discrepancy, whereas an agent consumes a SKILL.md and acts on its environment, so stale guidance is executed rather than read."

Tension with the compounding-context framing#

Tan's "the organization that captures what it learns gets smarter every single day" (practitioner-opinion, above) and this page's compounding context framing both assume the encoded workflow stays current. The measured lifecycle says the median skill is written once, copied verbatim, and left — 53% never touched, 40.2% of quiet copies sitting on stale upstreams. Weighting by evidence tier (empirical over practitioner-opinion), systematization compounds only under a maintenance discipline that most adopters do not practise; absent it, a skill library is a snapshot of conventions at the moment of copying, degrading silently while the agent keeps executing it. Note the scope limit: Gao et al. sample public GitHub repositories with ≥10 stars, not the high-complement orgs (OpenAI at 96.2% skill use, YC) where Tan's and the Codex study's claims are strongest — the two populations may genuinely differ rather than contradict.

Connections#

• Crystallizing Agent Work into Workflows — the same externalize-what-you-re-derive instinct pushed one stage further: not "write it down so the agent re-reads it" but "compile it so no agent runs at all", with evidence-gated promotion and automatic demotion on regression
• Harness Build-vs-Buy — rung 3 of OpenHands' customization ladder: skills and plugins give the agent "your organization's expertise without creating a permanent fork delta" — the same artifacts this page measures, argued for as fork-avoidance rather than as leverage
• Loop Engineering — the practitioner-discipline source for the same primitive: skills as the third of five loop primitives, "intent written down on the outside" so the loop doesn't re-derive the project each cycle; this page is its measured, adoption-curve counterpart
• Systems Thinking Over Specialization — the org-design mirror at Netflix: "solve problems once with a core set of capabilities" (paved paths, source-of-truth data) is the systematization margin stated as a hiring thesis rather than measured in telemetry
• Agent Context Files — skills/SKILL.md as externalized, reusable project context; systematization is the usage-data evidence that this primitive is being adopted at scale
• Conversation-to-Delegation Shift — systematization is one of the three "how" margins (with concurrency and runtime) by which that study measures depth of delegation
• Parallel Agent Orchestration — the sibling margins from the same study; systematization is what makes parallel/repeatable delegation tractable
• Compounding Data Moat — custom skills are encoded org-specific procedural context that compounds and is shared; the returns-to-systematization gradient is a moat-from-context argument
• Harness Shrinkage as Models Improve — skills/plugins are harness capability being absorbed into the product as named, shareable primitives rather than hand-maintained scaffolding
• MCP and Computer Use — plugins bundle MCP/connector integrations alongside skills; the tool-reach half of systematization
• Agentic Technical Debt — un-systematized agent use is the re-derive-from-zero / intent-debt failure mode; skills are the persistent-context antidote, here shown being adopted — and now shown to become a debt surface themselves: 53% of reused skills are never modified after adoption and local maintenance runs 2.7:1 additive, so the skill library ratchets in size while drifting out of sync with the project
• Agent Supply Chain Risk — skills are a supply chain of prose: 70.3% of reuse links are near-verbatim copies with no update channel (40.2% of quiet copies sit on a changed upstream), and the behavioural contract (user interaction, runtime monitoring, failure recovery) is the least-edited content, so an author's defect propagates unreviewed to every adopter
• Ticket-Driven Agent Orchestration — board/ticket state is the other durable externalization; systematization via skills is the procedure side, tickets are the work-graph side
• OpenAI — the lab whose Codex telemetry this is
• Codex — the tool whose skill/plugin system this measures
• Agent Quality Flywheel — vendor-authored methodology shipped in the skill format across agent products; the cross-vendor extension of the systematization spectrum
• AI-Native Organization — Tan's org thesis built on this margin: skills as the org's encoded roles, with "never do one-off work / skillify it" as the compounding discipline
• Owning Your Externalized Cognition — the ownership question this margin creates: the same act that makes an individual compound (writing judgment down as a reusable file) is what makes that judgment appropriable by whoever holds the repo. This page's telemetry is also the sharpest available test of that doctrine's compounding premise — 53% of reused skills are never modified and maintenance runs 2.7:1 additive, which is a one-time copy, not a library that improves with age
• Standardize the Infrastructure, Not the Tools — the same standardize-the-substrate instinct one level up: skills systematize how an individual works, a central LLM proxy systematizes how the org buys and meters model access

Open Questions#

• The 5.4%→26.6% curve is three months. Is this a durable behavior change or a novelty spike following a Codex skills-feature push? (Cf. the OpenAI-internal training campaigns the paper notes.)
• Custom skills encode org-specific context — but who maintains them as the codebase and conventions drift? Systematization could itself become a debt surface (Agentic Technical Debt) if skills rot. #oq/source Partially answered: From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained (empirical, 2026-07) measures the drift directly on public GitHub — 53% of reused skills are never modified after adoption, 40.2% of never-updated copies sit on a changed upstream, and local maintenance is 2.7:1 additive (6.1:1 for locally authored skills), with rename/tooling-substitution chasing the single largest evolution activity (24.3%). So skills do rot and the ratchet is real. Still open: the consequence side — no study yet links skill staleness to degraded agent task outcomes, and the sample (public repos ≥10 stars) excludes the high-complement orgs where the adoption curve is steepest.
• Does systematization cause deeper delegation or merely correlate with already-intensive users? The paper shows the association, not the direction. #oq/source (Not addressed by From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained — it mines artefacts and their diffs, never observing the user or the delegated task, so it can say nothing about direction.)
• Does a stale skill measurably degrade agent task outcomes, or do models increasingly route around outdated instructions (Harness Shrinkage as Models Improve)? Gao et al. establish that staleness is widespread and argue stale guidance is "executed rather than read", but never measure the downstream effect; SkillsBench-style evaluation could settle it.

Sources#

• The Shift to Agentic AI: Evidence from Codex — §5.3 "Systematization of Agentic Work"; §6 Conclusion; footnote 13 (skill vs plugin definitions); Appendix Figure A8 (skill use by task area)
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog — Google's eval methodology distributed as skills.sh packages for any coding agent (vendor-claim)
• Enable on-demand expertise with Agent Skills in Genkit Go — Daniela Petruzalek, Google Developers Blog, 2026-07-31 (vendor-claim): the runtime half of the same vendor's relationship to the skill format — Agent Skills support in Genkit for four languages, implementing the agentskills.io spec. Cited here for the cross-vendor-convention argument only; the post contains no measurement
• The New Physics of Business — Garry Tan, Y Combinator — Garry Tan, AI Engineer talk (2026-07-17, practitioner-opinion): the "never do one-off work / skillify it" discipline
• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained — Gao, Lulla, Lin, Baltes, Treude, Zahedi, arXiv 2607.00911 (2026-07-01, empirical): §IV SWEBOK KA distribution; §V-A packaging and spec conformance (Table I); §V-B content taxonomy (Table II); §VI-A modification at adoption; §VI-B edit taxonomy (Table III); §VII-A additive-maintenance and stable-behavioural-contract analysis