How 80 Saved Workflows Became an Inventory Engine

Summary

My AI coding agent's skills menu said it had 173 capabilities. I did not remember building most of them. An evidence-first audit found that the largest single family, 79 entries, was never hand-authored at all: they were saved multi-agent workflow scripts left behind by earlier working sessions. This is a case study in how agent work quietly compounds into reusable capability, how adversarial verification catches your own drift, and why the governance that produced this very article stops at a human gate instead of a publish button.

Key Points

• Capability accumulates as a byproduct when session artifacts persist and stay discoverable.
• A live tool menu and the files on disk are two different truths, and an inventory has to reconcile both.
• Independent adversarial verifiers caught errors the author made, including one caused by the audit itself.
• In this audit, the generated capability family looked far safer than the hand-authored conveniences, which carried the real risk.
• Human approval gates belong between draft and publish, per artifact, and this article is the pilot proof.

The menu said 173. The disk had to explain why.

The starting point was mundane: before designing any new automation, take stock of what already exists. My agent environment reported 173 enabled skills. Some I recognized as things I had deliberately built: publishing helpers, audit checklists, research pipelines. Many I did not.

Counting files on disk gave a different picture, and it took five separate truths to reconcile one number. First, user-level skills: 75 directories, each a documented capability authored deliberately at some point. Second, project-level skills: exactly one, living inside the project it serves. Third, slash commands: 20 active command files, a thinner format. Fourth, the surprise category this article is about: 79 saved workflow scripts. And fifth, a set of built-in skills that ship inside the agent's own binary and exist as no file at all, at least on this machine.

The arithmetic only closed after two more wrinkles surfaced. Two names existed as both a skill and a command, so the menu deduplicated them: 75 + 1 + 20 + 79 minus 2 duplicates lands exactly on 173. And the reconciliation exposed quirks in both directions: the live menu also listed almost every active command a second time under a different rendering (19 of the 20), and one skill that existed on disk never surfaced in the session's live menu at all. None of this was visible from either surface alone. The menu is what the agent believes. The disk is what actually exists. An inventory that trusts only one of them is a guess.

Reconciling the live menu against disk truth: five surfaces, two duplicate names, one exact match.

The interesting number in that equation is the 79.

Where the 79 came from

None of those 79 entries were written as skills. Each one is a saved orchestration script from a past working session: a one-time multi-agent job that fanned out parallel workers, verified their findings, and reported back. Pre-merge review gates. Adversarial verification passes. Read-only discovery scouts. Acceptance checks against a checklist.

Each was built for one bounded task on one day. But because the harness persists them as named, re-invocable scripts, they never disappeared. Over successive sessions they accumulated into the largest capability family in the whole environment, a library of field-tested orchestration patterns nobody ever sat down to design.

That is the operational lesson in one sentence: if your agent's work products persist and are discoverable, capability compounds whether you plan it or not. The only question is whether you know what you have.

Anatomy of a saved workflow

It helps to see what one of these scripts actually is, because the pattern is simple enough to steal.

A saved workflow here is a small deterministic program that orchestrates agents instead of being an agent. It declares metadata (a name, a description, named phases), then spawns workers with explicit prompts and collects structured results. The shape, reduced to pseudocode, is usually some variant of this:

meta: name, description, phases [Find, Verify]

phase: Find
  results = run_in_parallel(
    worker("catalog source A, write to bounded path, return JSON summary"),
    worker("catalog source B, ..."),
    worker("catalog source C, ...")
  )

phase: Verify
  verdicts = run_in_parallel(
    skeptic("recount everything from the raw source, try to prove the catalog wrong"),
    skeptic("scan every output for secrets, fail on any hit"),
    skeptic("re-derive sampled claims from primary evidence")
  )

return results + verdicts

Three properties make this shape durable. The control flow is deterministic: loops, phases, and fan-outs are decided by the script, not improvised turn by turn, so a rerun does the same thing. The outputs are bounded: each worker writes to a designated path and returns a structured summary, which is why these scripts later audited so cleanly. And the verification is adversarial by construction: a second wave of workers is prompted to attack the first wave's results rather than summarize them.

A conversational agent can do any single one of these steps. What it cannot do is guarantee the same steps in the same order next month. The script can, which is exactly what turns a one-off session into a reusable capability. The cost of keeping one is close to zero: it is a text file. The cost of not keeping one is re-deriving the orchestration from scratch, without the fixes the first run taught you.

The inventory engine run

The audit itself used the same mechanism it was auditing. One orchestration script spawned 13 agents: 10 catalogers working sources in parallel (user skills in shards, commands, agent definitions, the saved workflows, session-data surfaces, memory tooling), followed by 3 independent verifiers whose only job was to attack the result. Around 2.1 million tokens and 358 tool calls later, the output was 284 catalog entries, each backed by cited evidence, most down to file and line.

The rule that mattered most: classify by capability, not by promise. A tool that says "I always ask first" but holds unrestricted write access is a write-capable tool. Prose is not enforcement. This one rule did more to shape the findings than any other design decision, because it forced the catalog to record what each tool could do to the world, not what its documentation hoped it would do.

The verification architecture

The three verifiers were not three copies of the same reviewer. Each held a different lens, and each lens caught something the others could not.

The counts verifier re-derived every total from the raw source: it re-listed every directory, re-counted every file, and ran name-by-name set comparisons between the disk listings and the catalog entries. It is the least glamorous lens and it caught the most embarrassing class of error: numbers that had been true an hour earlier and were not true anymore.

The secrets verifier swept every produced file for credential-shaped patterns and high-entropy strings that fit no known pattern. It found nothing real, which is exactly what you want from the lens whose job is to find nothing, loudly.

The claims verifier sampled classifications and tried to refute them from primary evidence. It opened the actual tool definitions behind sampled catalog entries and checked whether the recorded capabilities matched the file contents. This is the lens that caught the deepest problem: a semantics gap. The audit's rubric defined "writes externally" to include editing files outside your own working area, but several catalog entries had applied a narrower reading, external meaning live sites and remote pushes only. Seven entries were technically defensible under the narrow reading and wrong under the rubric's letter.

The fix for that class of error mattered as much as the catch. The corrections went in as explicit supersessions: a dated correction block at the top of the catalog, stating the two semantics, naming the seven re-flagged entries, and leaving the original text intact underneath. Future readers see both the error and the correction, in order. Deleting the wrong text would have been tidier and worse, because the correction itself is evidence of how the audit method behaves under stress.

What the verifiers caught

Beyond the semantics gap, three more findings stand out.

First, the observer changed the count. Mid-run, the harness saved the inventory workflow itself into the same directory it was counting, moving the truth from 79 scripts to 80 and the total from 173 to 174. The counts verifier caught the drift, and the fix was honesty rather than cleverness: report both numbers with timestamps.

Second, a misfiled entry: one menu item I had confidently listed among the saved workflows turned out to be a built-in with no file on disk. Confidence is not evidence.

Third, a plumbing bug fed every worker agent the literal string "undefined" where an output path should have been. All ten stopped, reasoned about where output actually belonged, and adapted without writing anywhere unsafe. Verification later confirmed zero stray writes. Resilience is nice, but the fix that followed was still to make the script validate its inputs and fail loudly, because resilience you have not tested is just luck you have not spent.

The safety inversion

Here is the finding I did not expect. The generated family of 80 saved workflow scripts came out of the audit looking remarkably tame: the audit found none that pushed, published, or posted anywhere, and the write-capable minority wrote to designated, bounded output paths. Two honest caveats belong next to that: all of the verdicts came from inspecting the scripts rather than running them, most resting on metadata and pattern scans alone, and under the audit's own strictest reading, one estate-maintenance workflow does reach into other repositories' generated files (dependency rehydration), which the final classification flags rather than excuses.

The sharper risk lived in the hand-authored conveniences, and they cluster into three recognizable classes.

The first class skips consent. One agent definition carried a configuration flag that suppressed permission prompts for shell operations, including repository pushes. Every other safeguard in the environment assumed a human sees a prompt before an external write. This one flag quietly deleted that assumption for the tool most likely to touch many repositories at once.

The second class ends in an unconditional side effect. Several session-wrap-up helpers finish their checklist with a push to a remote, not as an option but as a documented step. Each was written to make an evening ritual faster. Each also means that invoking a "tidy up my notes" tool is, at the end of its script, a publish action.

The third class edits the live world in place. One utility updates already-published web content directly through an authenticated session, with no approval step documented anywhere in it. It exists because re-publishing a whole article to fix a footer is annoying. It is also, capability-wise, a remote-write tool wearing a convenience costume.

None of these were malicious, and that is the point. Each was written by a person optimizing for friction, and each quietly holds more blast radius than anything the agents generated for themselves. The generated scripts inherited tight boundaries from their bounded tasks. The conveniences inherited my impatience.

Convenience, it turns out, is where the ungated writes hide.

The compounding loop, formalized

Stepping back from the specific numbers, the mechanism that produced the 80-script library is a loop, and in my experience it is worth drawing plainly:

work happens in a session. The orchestration that did the work persists as a named artifact. The artifact is discoverable the next time the menu is read. The next session reuses or imitates it, and the reuse produces new artifacts.

Every link in that loop is a place where the compounding can silently die. If artifacts do not persist, the loop never starts. If they persist but are not discoverable, they are archaeology, not capability. If they are discoverable but unbounded, reuse becomes risk instead of leverage.

The environment this audit examined had, without anyone designing it, settled into three cooperating engines. An operating-system engine: the protocols, gates, and verification habits that keep work inside boundaries. A knowledge engine: the surfaces that turn finished work into recallable memory. And a publishing engine: the tools that turn internal progress into external material. The most useful structural reading I took from the audit was simply making that three-engine shape visible, along with the rule that connects them: the knowledge engine may feed the publishing engine, but only through human gates.

I would not claim this exact shape generalizes to every setup. I would claim the loop does: persist, discover, bound, reuse. The engines are just what the loop grew into here.

What We Learned

1. Inventory before building. The environment did not need new content skills. It needed to know what it already had. Much of the pipeline I was about to design already existed.
2. Persist the orchestration, not just the output. The 80-script library exists only because saved workflows survive their session. That is one of the cheapest capability investments I know of: keep what already worked, named and bounded.
3. Verify adversarially, even against yourself. Every consequential error in this story was caught by an independent checker re-deriving truth from disk, including an error the measurement itself introduced.
4. Audit the convenient things first. Generated tools mostly inherited tight boundaries from their tasks. The hand-written shortcuts inherited my impatience.
5. Numbers need timestamps. In a live environment, even a count of your own tools is only true as of a moment.
6. Treat session transcripts as the radioactive surface. The complete record of agent work is also the one place where a credential can end up verbatim. The audit's session-data survey rated transcripts the highest-risk extraction source and put a mandatory secret-scrub in front of anything derived from them. Curated artifacts first, raw transcripts only behind a scrubber.

Why Gates Matter

The audit found real, live paths from a casual prompt to an external effect: pushes without approval, published content editable in place, one agent that will not even pause to ask. None of these are hypothetical: in one earlier session, sensitive material reached a transcript and had to be treated as a credential-rotation event.

So the content pipeline this audit fed into is designed around one principle: being in the queue is not authorization. Every boundary crossing, publish, post, live edit, or durable memory write, gets its own human decision on its own artifact.

The pipeline shape: automated gates do the checking, humans do the authorizing, and each boundary crossing gets its own decision.

This article is the pilot of that discipline, and the pilot run itself is the best evidence I can offer for it. The draft went through two independent gate rounds. The first round rejected it: a grounding reviewer proved that the draft's headline safety claim was stronger than the audit evidence supported, and a privacy reviewer found an internal identifier that had leaked into the metadata. Both were exactly the kinds of defect an author cannot reliably catch in their own work, one flattering overclaim and one invisible leak. The fixes went in, a second independent round passed the corrected text, and the mechanical checks ran three more times as small edits landed. Then the pipeline did the most important thing it does: it stopped. The article sat at a draft marker, gates recorded, until a human said the next word.

The step you are reading it on required a separate human yes.

If you run agent tooling: six practical moves

Everything above reduces to a short list. These are what worked here, offered as experience rather than doctrine.

1. Keep every orchestration script your agent writes. Name it, note what it did, and make sure it lands somewhere the next session can list.
2. Give every generated tool a bounded output path. The single biggest reason the 80-script family audited clean is that each script wrote to its own designated place.
3. Reconcile the menu against the disk on a schedule. The two surfaces drift, and the drift is where surprises live.
4. Schedule a standing pass over your conveniences. Put anything you built to skip a prompt, end with a push, or edit something live on a recurring review, not an ad-hoc one.
5. Put an independent verifier behind anything durable. Not a second read by the same author, but a differently-prompted checker with permission to say the work is wrong.
6. Put a named human gate in front of every external effect. Publishing, posting, live edits, and permanent memory writes each get their own explicit approval, and queue membership never counts as one.

Conclusion

If you work with agents and persist their artifacts, you are likely already accumulating capability. The audit just makes it visible. Count what the menu claims, reconcile it against the disk, let independent verifiers attack the result, and then look hardest at the tools you made for your own convenience. That is where the gates are missing.

One estate, one operator, one audit pass: your numbers will differ. In my experience, the compounding will not.