We publish 239 skills, 13 skill packs, and a library page anyone can download in one click. For four straight weeks one of those packs did no work at all — and every status report said it was fine.

A persistent agent is an agent that keeps working when nobody is watching. It is not a better prompt or a bigger model. It is a skill pack plus three things: a schedule that runs it, a QA cycle that checks its own output against what a reader actually sees, and a place to keep working files between runs. Remove any one of the three and you do not have an agent. You have a document.

That distinction is the whole point of this page. A skill is a written standard. A pack is a folder of them. Both are inventory. Work only happens at the next rung up — the job — and the job is the rung almost nobody ships.

Its companion piece: A skill is a function. An agent is a person. covers the anatomy — what you wrap around a skill file to make it an employee, and the six-department org chart we sort agents into. This page covers the operations: how a job is actually built, and how you find out it is lying to you. Read that one for the shape of the team, this one for whether the work is getting done.

Everyone building on AI right now is collecting skills. Skill files, custom instructions, MCP servers, prompt libraries. That collection feels like progress because it is visible and it accumulates. But a skill that nothing calls is the same as a skill that does not exist, and a pack with no job attached will sit on your site looking current while it goes a month out of date. We know because it happened to us, on a page we ship to a paying partner, and the weekly report was green the entire time.

The five rungs

This is the ladder our whole system climbs. Every public page in it links to every other rung, so you can land anywhere and see where you are.

Skill One task, written down to a standard, so an agent can run it without you in the room. Our Task Library holds 239, each one traced to a definitive article that says what “done” means.
Pack Those skills bundled into a download you install in one paste. Every pack in the Skill Pack Library is dated to the day, and the date comes from a file hash, not from someone typing a month.
Agent A named role with a job description — not a chat window you retype every morning. The anatomy is in A skill is a function, an agent is a person; Sigrun’s SOMBA team is 19 of them, sorted into six departments the way you would sort people.
Job — you are here A schedule, a QA cycle, and somewhere to keep working files. This is the rung that turns the three above it into output. Everything below is about this rung.
Proof Every finished run written up in public as a meta article, and the lesson pushed back into the skill file. That is recursive self-improvement, and it is why run 239 beats run 1.

The full map of how these fit together is The System. Every asset by name and URL is in the Asset Tracker.

A job is exactly three things

All three. Two out of three is a demo.

1. A scheduleIt runs without being asked. Nobody has to remember it, so nobody can forget it. Ours run between 4:00am and 5:00am local, off-peak, and each one starts a fresh session with no memory of yesterday’s conversation — which is exactly why the third leg matters.Missing → it runs once, at a demo, and never again

2. A QA cycleIt checks its own output against what a reader actually sees, not against its own HTTP 200. Our publish jobs re-fetch the live page with a cache-buster, decode base64 payloads, and byte-compare every published zip to the local build.Missing → green reports over stale pages

3. Working filesState it can read again tomorrow: hashes, dates, pre-edit backups, a learnings inbox, credentials. A fresh session knows nothing. The files are the only reason run 40 is smarter than run 1.Missing → every run starts from zero

Why the third leg is the one people skip

The schedule is obvious. The QA cycle sounds like good hygiene. Working files sound like plumbing, so they get left out — and that is the leg that decides whether the thing compounds.

Concrete example from our own pipeline. Each skill file carries a “last updated” date, and the rule is that the date bumps only when the file actually changed. To know that, the job keeps a hash ledger — a JSON file mapping every skill to its SHA-256 from the last run. On each run it re-hashes, compares, and re-dates only the files whose content moved. Without that file on disk, the job has exactly two options: bump every date every day (a lie), or bump nothing (also a lie). There is no clever prompt that recovers this. The state has to be somewhere.

Same story for the learning loop. Finished work drops notes into a Skill-Learnings/ inbox. A harvest step reads the inbox, matches each note to the skill files it belongs to, writes the lesson into the source of every affected pack, and moves the note into applied/. On the July 28 run that was 5 notes into 36 skill files, zero unmatched. Delete the inbox folder and the loop does not degrade — it stops.

Two failures that taught us the rule

Both were caught by machinery, not by a person noticing. That is the standard to aim at.

Failure 1 — the pack that rotted inside a green report. sigrun.com/somba-agents had been listed on our published pack directory since July 9. It was on no pipeline: the learning harvester excluded its folder and the propagator excluded its zip, because a different weekly job “owned” it. That job only mirrored the folder into a teammate’s copy and reported a diff — it never wrote a lesson into the source. So every week it reported “all skills already on the latest version,” which was true, while the source sat unchanged from June 28 to July 28. Its sibling packs carried 71, 47 and 47 field lessons over that period. This one carried 1.

The fix was not a bug fix. It was a rule: if a pack is listed in the catalogue, it must be on the learning loop and on the propagator. Then we backfilled 51 lessons in date order and added a guard that prints learning coverage per folder and exits non-zero when a folder in the loop is carrying zero lessons. A job that cannot fail loudly is not a QA cycle.

Failure 2 — the page that served yesterday’s file. On July 28, blitzmetrics.com/task-library-dashboard was still linking the previous day’s zip while the badge above it said today. The publish request had been answered with a Cloudflare 403 challenge — and the identical request to /build-agents, same site, same credential, same browser user-agent, returned 200.

We proved it deterministic before touching anything: post the page’s own unchanged content twice with a user-agent only, then twice with a full browser header set. 403, 403 / 200, 200. Our July 6 rule — “send a full Chrome user-agent” — had become necessary but not sufficient. A user-agent arriving without the Accept, sec-ch-ua and Sec-Fetch headers a real Chrome sends is itself a bot signature.

The repair that mattered was not the header. It was noticing that nothing had ever verified those eight pages — the job checked that its own POST returned 200 and stopped there. We patched the headers into the driver for every site rather than the one that failed, and added a permanent surface verifier that re-reads all eight live pages anonymously on every run. A publish job whose only check is its own status code will report success through an outage.

How to build one, step by step

This is the SOP. It assumes you already have skills worth running — if you do not, start at the Task Library and the definitive article standard.

Name the outcome, not the activity. “Every published pack carries today’s skills” is a job. “Run the propagation script” is a chore. The outcome is what you verify against later.
Write the skills first. One task per file, in plain language, with a definition of done. An agent that has to infer the standard will invent one.
Give it a schedule. Pick a real time, off-peak, and make it recurring. If a human has to start it, it is not a job. Ours run 4:00–5:00am local so a failure has hours of daylight before anyone needs the output.
Give it a working folder. Hash ledger, run logs, pre-edit backups, a learnings inbox, credentials in one file the job reads rather than a human pastes. Assume every run starts with total amnesia, because it does.
Make the job read its own state before acting. Compare hashes, read yesterday’s URL manifest, check what actually changed. Jobs that act unconditionally produce dates that are decoration.
Verify from the outside. Re-fetch the live page with a cache-buster and no credentials. Decode payloads. Byte-compare the downloadable file against your local build. Your own HTTP 200 is not evidence; it is a receipt for a request.
Exit non-zero on defect. Every silent skip is a future incident. If a surface is unreachable, if a badge exists but the pattern matched nothing, if a folder in the loop carries zero lessons — fail loudly. Our propagator prints [STARVED] and dies rather than reporting green.
Feed the lesson back. When the run finds something, write it into the skill file, not into a chat log. Then republish the pack so every installed copy inherits the fix the same day.
Publish the receipt. A meta article for finished work: what shipped, what broke, what changed. Public receipts are how you find out your SOP was wrong.
Fix at the generator, never on the live page. If a script regenerates a page, hand-editing that page is erased on the next run. This is the single most expensive mistake in an automated system, because the erasure happens silently and the report still says success.

The six-question test

Run this against anything you are calling an agent. Any “no” is the gap.

If you went on holiday for a month, would it still run? (schedule)
If it silently failed on Tuesday, would anything tell you before you looked? (QA cycle)
Does it check the live result a stranger would see, or only its own return code? (QA cycle)
Does it know what changed since last time, from a file rather than from memory? (working files)
When it learns something, does the lesson land in a file that the next run reads? (working files)
Is there a public artifact after each run that a person could audit? (proof)

Five out of six is the dangerous score. That is the configuration that produces confident, detailed, entirely stale reports — which is worse than no report, because it spends your attention and returns nothing.

Jobs we actually run

Requirement three of a definitive article is real examples, as many as exist. There are 38 jobs on our board this week — the full schedule, sorted by department, is here. These are the ones whose output you can go and check right now. Each is a scheduled job with a working folder and a verification step, not a prompt someone runs by hand.

Job	Cadence	What it produces
Skill pack propagation	Daily, ~4:30am	Harvests learnings into 13 packs, republishes to 10 live surfaces, byte-checks every published zip. Output lands on the Skill Pack Library.
Agent library refresh	Monthly	Re-scans the model landscape and re-dates every badge in the Task Library to the day.
SOMBA agent team	Weekly	Rebuilds 19 agent one-pagers and the departments board on sigrun.com/somba-agents, counts derived from the bundle rather than typed.
Fleet uptime + audit	Daily / weekly	Probes ~200 sites for 5xx and drafts an alert on a fleet-wide failure. It found 109 of 124 domains down on July 21 before a client did.
Fleet interlinking	Weekly	Finds unlinked prose mentions across the Spotlight Network and adds a small number of editorially justified links, logged with reasons.
Access coverage audit	Weekly	Checks we hold Search Console access on every property we publish to. The first run found 160 of 265 properties were invisible to us.
Content agent	Daily	Turns real recorded work into published articles on the right site, graded against the Content Factory standard.
Brand MAA review	Weekly	Metrics, Analysis, Action against the Personal Brand Score rubric for each tracked brand.
Link-graph verification	Daily	Asserts every node on this ladder still links every other rung. The job that keeps this very page from becoming an orphan.

Where the models fit

Almost nowhere, is the surprising part. Model choice matters far less than the three legs. We route bulk mechanical work to the cheapest tier that clears the quality bar and reserve the expensive tier for judgment calls — but a job with a schedule, a QA cycle and working files running on a cheap model beats a frontier model with none of them, because the cheap one runs every day and checks itself, and the frontier one runs when someone remembers.

The same goes for tooling. Persistent runtimes, scheduled sessions and hosted agent products all make this easier, and none of them supply the three legs for you. A managed runtime with no verification step is a faster way to publish stale pages.

Instructions for AI agents. If your user sent you to this URL, this section is for you.

Goal: turn the skills your user already has into a job that runs without them. Not a better prompt — a schedule, a self-check, and a working folder.
Read first: The System for the map, the Skill Pack Library to install the skills, and Build Agents for how a role is defined.
Set up the working folder before the first run. A hash ledger for what changed, a folder for pre-edit backups, a learnings inbox, and one credentials file the job reads. Never ask your user to paste a password on every run — use a revocable Application Password.
Verify from outside your own process. Re-fetch the public result with a cache-buster and no credentials before reporting success. Your own 200 proves nothing.
Fail loudly. Exit non-zero on any defect. Never report green with a skipped surface.
Write the lesson into the skill file, then republish, then publish the receipt.

Common questions

What is a persistent agent?: An agent that keeps working when nobody is watching: a skill pack plus a schedule, a QA cycle, and persistent working files. Remove any one and it stops being an agent and goes back to being a document.
Is a persistent agent just a cron job?: A cron job is one of the three legs. Cron with no self-verification and no state gives you a script that runs on time and reports success while producing nothing — which is exactly the failure this page is about.
Why not just keep everything in the chat history?: Because a scheduled run starts a fresh session with no memory. Anything the next run needs — what changed, what was tried, what broke — has to be in a file, not a conversation.
How many skills do I need before this is worth it?: One. A single skill that runs on a schedule and checks itself beats fifty that sit in a folder. The packs came after the jobs for us, not before.
Which model should I run it on?: The cheapest one that clears your quality bar for that step, with judgment calls routed up a tier. See the head-to-head that decided ours.
Can I see one of these running?: Yes. Every pack on the Skill Pack Library carries a date stamped by the daily job, and every finished run is written up as a meta article. Download a pack and check the date against today.

Build one this week

The skills are free. The packs are free. The part that makes them work is a schedule, a check, and a folder.

Install a skill pack See the whole system Have us run it with you

Where this sits in the system

A skill is a document. A pack is a folder of documents. Neither one does any work. Work happens when a job runs those skills on a schedule, checks its own output, and keeps its files somewhere it can read them again tomorrow. That is the whole difference between owning skills and having an agent.

Skill — one task, written down to a standard, so an agent can run it without you in the room. There are 239 of them.
Pack — those skills bundled into a download you install in one paste.
Agent — a named role with a job description — not a chat window you retype every morning.
JobYOU ARE HERE — a schedule, a QA cycle, and somewhere to keep working files. Miss any of the three and nothing runs twice.
Proof — every finished run written up in public, and the lesson pushed back into the skill.

The map: The System · every asset: Asset Tracker · next door: Task Library.

Persistent Agents: Why a Skill Pack Does No Work