Persistent Agents: Why a Skill Pack Does No Work

Choose a real taskSet the triggerProvide working filesVerify each run

A job needs instructions, a trigger, and proof of its result.

Teams that install AI skills still need to turn those instructions into real jobs. This guide shows how a task gets a trigger, working files, and a check that proves the work happened. Use it to move from owning a skill pack to running a task with a clear result.

This guide is part of How We Build and Maintain AI Agents. Next, explore A Skill Is How. A Routine Is When., or How Our AI Agents Share Memory and Coordinate Work.

Where this task fits in the Content Factory

This task supports work across the Content Factory (our four-stage process for using real content). Its inputs and next handoff determine which stage uses it.

1. ProduceCapture real work

2. ProcessTurn sources into useful assets

3. PostPublish and connect approved assets

4. PromoteShare proven work and measure results

Follow the numbered stages from Produce to Promote. Each stage links to its part of the Content Factory guide.

Start, finish, and next step

Start when

A documented task should run on a real trigger without someone remembering to start it.

Have ready

One documented skill and its acceptance checks
Authorized runtime and schedule
Persistent working state
A verified output and failure destination

Follow the steps

Write the task standard
Choose and configure a real recurring trigger
Give the job a working folder
Read the previous state before acting
Verify the outcome from the outside
Record failures and feed learning back

Use the detailed instructions in this article for each step.

Finish with

One configured job with retained state and an observed, independently checkable run or failure.

Measure the result

The trigger exists in the runtime
A firing leaves timestamped evidence
Output is checked where its reader receives it
A failed or missing result is visible to the owner
The next run can read the previous state

Hand off next

Deliver the result or honest error to the configured destination, then write the run’s meta record and review useful changes.

Before closing the run, name the actual next task, receiving owner, and trigger in the execution record. The assignment and findings determine that handoff.

Reference material for the inputs

Open this article’s tasks in the Task Library (our directory of tasks and recipes; see current Task Library). The library connects the current recipe, its smaller tasks, and the records of work performed.

Close the learning loop. Write a meta article: the record of this execution with the starting state, recipe version, result, checks, failures, and next owner. Link it back to this recipe and register the run under the same Task Library task. Reuse one execution ID for revisions and retries. A partial or failed run stays labeled that way. Public release follows the recorded publication authority; writing the run record is part of doing the task. Writing and revising that record belong to the original execution; they do not start another meta-article task. Use the findings to propose and verify a recipe improvement. See how recipes and execution records work together.

We publish a broad Task Library plus smaller curated skill packs. For four straight weeks one of those packs did no work at all — and every status report said it was fine. Inventory is not execution.

Office Hours proof · 27 August 2026

Sean Fay, on the call: “I built 5 using your same prompt that you use with Joe. And those 5 agents, like, do stuff for me every day, and it’s very productive, and I know exactly how they’re helping.” Later he walked through what a three-minute dictation produced after he rewrote it for a CEO: a weekly scorecard, a morning ops brief, a Fathom action harvester, and an inbox sentinel. Dennis asked to quote him on the call; Sean said yes (“Of course you can… Por supuesto”).

Same hour, the method: supervise digital marketing, do not do it as worker labor; a fleet without a GCT (the goal, source material, and audience) reward loop is noise; colliding humans need a shared GitHub, which is why new agents start here is public how, not a second set of keys. This is extra proof on the page that already owns the job — not a competing article. Named wall: dennisyu.com/mentions.

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.

The five execution rungs

The full system starts with user-owned context: facts, goals, evidence, decisions, and working state in Markdown, Obsidian, Drive, or Git. Once that foundation exists, these five execution rungs turn context into accountable work. Every public page in the system links across the ladder so you can land anywhere and see where you are.

Skill One task, written to a runnable standard so an agent can execute it without you in the room. The Task Library is the live inventory; atomic skills map to a parent definitive concept when one applies.
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 execution produces a written meta article (a record of one task run) linked to the task, run ID, and evidence. Substantive organization work also leaves the private internal receipt. Publish the meta article only within the existing authority and privacy boundary; writing the execution record is required even when it remains private. Reusable evidence is reviewed into the canonical skill, distributed, and canary-tested.

The full map of how context and these execution rungs fit together is The System. The cross-model operating-system map shows how Claude, ChatGPT/Codex, and Grok wrap the same owned knowledge and methods. 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 incidents, and the standing rule

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

SOMBA pack off the learning loop (June 28–July 28). 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.

July 28 dashboard zip vs badge. 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. Keep the hash ledger, run logs, pre-edit backups, and learnings inbox in the working folder. Keep credentials in the approved secret store; the job uses the authorized connection without copying secret values into notes. 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 a run finds a reusable lesson, propose it at the canonical skill or standard source, review and validate it, rebuild the distribution, then sync and canary-test each target. Installed copies do not inherit a source change merely because it was committed.
Write the receipt. Record what shipped, what broke, and what changed in the private internal job note. Add a public meta article only when the run is approved and useful; the next run loads the current method from the canonical skill, not from publicity.
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, and the report still says success. Fix the generator.

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)
Does each execution have a written meta article linked to its task and evidence, with public or private visibility stated? (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 (Metrics, Analysis, Action: results, meaning, and next steps) 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. Grok Bot’s routine is the schedule leg on that runtime. It still needs the QA cycle and the working files, or it is a clock attached to a costume.

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.
Propose the reusable lesson at the canonical skill source, review and validate it, rebuild the distribution, canary-test activation, and publish a meta-article only when appropriate.

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.
What do vendors call the schedule?: Claude Cowork says scheduled task. Grok Bot says routine (one Bot owns it; schedule or event; Test run is real work). Cursor says Automation. ChatGPT says Scheduled tasks. grok.com Build still has a 7-day /loop — that is not Grok Bot, and it is not a production host. Same rung, three product names. Glossary: skill is how, routine is when. Desk SOP: Grok Bot.
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. Batch article nights belong on a local Qwen via the overnight content worker, not on a frontier chat. The ticket that pays the frontier model is a separate map: four lunch tickets. Grok Bot (the named roster) is not grok.com chat and is not Heavy’s four-at-once reply — desk SOP. See the head-to-head that decided ours.
Can I see one of these running?: The Skill Pack Library carries a dated manifest, but a date proves only that the artifact was built. Verify its source commit, sync it to the target runtime, run a fresh-chat canary, and inspect the job receipt. The overnight worker is the same idea for YouTube-to-article drafts: schedule, QA, working files, and receipt at how we put the factory on night shift.

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 Skill vs routine See the whole system Have us run it with you

Where this sits in the system

Context is what the worker knows. A skill is the method it follows. A pack is a folder of methods. None of them does any work alone. Work happens when a job runs the right skill against the right context on a schedule, checks its output, and leaves a receipt the next worker can inspect.

Context — the verified facts, goals, evidence, decisions, and working state kept in user-owned Markdown, Obsidian, Drive, or Git so any authorized model can pick up the same work.
Skill — the written method for a task; use the linked Task Library for its current tasks and state.
Pack — a selection of skills; follow the current installation guide for setup and access.
Agent — the person or AI worker carrying out an authorized task with the required access and tools.
JobYOU ARE HERE — an authorized execution with a trigger, inputs, checks, and a saved result; recurring work also needs an actual configured schedule.
Proof — a written meta article for every execution, including partial or failed runs; public release follows recorded authority, and verified lessons improve the recipe.

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