by
If you run a business, this guide shows why a file of steps cannot do the work on its own. You need an AI worker, the right tools, and a real job to run. Start with one task and check the result before you set it to repeat.
A skill is a written recipe. An AI agent is the worker that uses it with approved tools and access. The function-and-person comparison below is a teaching example; an AI agent is not a human employee. The dated run evidence shows what was observed in that setup.
The distinction
A skill is a written recipe, often saved as a Markdown text file. It gives the method for a job such as collecting verified mentions of a business. The file itself does not work, remember, or forget. The AI app reads it and uses the tools and information available for that job.
An agent is an AI worker that follows an assigned goal and uses available tools to do the work. It needs the task’s inputs, the right access, and checks for its result. Repeated jobs also need a supported trigger and saved records they can read next time. A one-time job can use an agent without a schedule.
For repeat work, saved records let a worker compare the last checked result with the current one. Useful facts and changes both matter. The worker must be able to read the right records before it can make that comparison.
Teaching example: “You have nineteen verified mentions” describes the current count. “You went from fourteen to nineteen; here are the five checked additions” explains the change. That comparison needs both the prior result and the new source evidence, whether a person or an agent prepares it.
Five things to define for repeat work
| What you add | What it buys you | Why it matters |
|---|---|---|
| Saved context | Past results to compare | Read the relevant current records and check their dates and sources. A model or folder name alone does not supply memory. |
| A repeat trigger | A job can start on time | For work that should repeat, configure a supported trigger, time zone, and runtime. Verify the saved job and its first firing. A one-time task needs no schedule. |
| Handoff | A checked next input | Name the result, its checks, and the next task or owner that needs it. Confirm the destination can use the output; a drawn arrow is not a completed handoff. |
| Tools and access | Ability within a clear scope | Use the tools and account roles needed for the authorized job. Complete actions already covered by that authority. A new action outside it needs the exact missing access or decision before it can proceed. |
| A record | Work you can review | Write each actual attempt, including partial results and failures, with its evidence and checks. Review what should change before claiming an improvement; a written record alone does not prove one. |
Then you stop managing agents and start managing departments
The workshop grouped seventeen roles into six departments to make the work easier to review. That is one example of how to organize tasks and handoffs. It does not mean seventeen workers are installed, that all roles are needed, or that the listed schedules are running.
Workshop example: seventeen roles in six departmentsThis historical workshop example groups seventeen roles into Front Desk, Research, Build, Publishing, Growth, and Quality and Finance. Six links connect the workshop library to the six departments. Five labeled arrows show proposed handoffs from Front Desk through Quality and Finance. A separate measured-results path returns from Growth to Front Desk. Cadence labels and the Friday report are examples, not current running jobs. Quality audits all five is a text responsibility, not an added network edge. Each selected task needs its own inputs, tools, allowed access, checked output, and evidence. Shared project records need scoped access and version checks. Skill files alone install no workers or schedules.
The handoffs are the product
The rail under the columns shows possible handoffs. A reputation gap can guide proof research; verified proof can support page copy; a useful main page can feed related content. Qualified winners may enter a bounded paid test when that action is authorized. Each step needs a checked result and a named next task or owner. The diagram helps plan that work; it does not prove the steps happened.
The shared brain is the part people skip
Shared project records can help different workers use the same checked facts and past decisions. Give each role only the records and write access its task needs. Keep source dates and versions visible, and handle conflicting edits through the supported record system. More saved notes do not guarantee better work; review the results and accept a change only when the evidence supports it.
Protect the records and verify access to the current version. Keep a shared project record with the current facts, source links, decisions, and output checks. Give each agent access to the records its task needs, and verify that it can read the current version. See the shared project memory guide. A folder name alone does not grant access or synchronize apps.
A historical board: 38 recorded jobs
The original article recorded the following 38-job board. It is a historical example of how work was grouped, not a current count or proof that each job is still running. Current claims require a dated schedule and checked run evidence. Client names are omitted.
| Department | Jobs | Cadence | What runs there |
|---|---|---|---|
| Front desk | 5 | Every day | Order forms, new-member registrations, website requests and yesterday’s call recordings get read, sorted and turned into work before anyone opens a laptop. |
| Research | 8 | Weekly & monthly | One agent per client re-pulls rankings, AI-answer citations and audit scores, then writes what moved and why. |
| Build | 4 | Weekly & monthly | Wikidata eligibility, Grokipedia readiness, structured-data sweeps, entity refreshes — the plumbing behind Knowledge Panels. |
| Publishing | 3 | Daily & weekly | Article waves, video cutting, and an editorial interlinking pass that links our sites only where it genuinely helps a reader. |
| Growth | 2 | Weekly | Dollar-a-day performance, and a scan for new opportunities across the network. |
| Quality & money | 14 | Every 3 hours → monthly | Uptime probes, security drift, plugin-licence QA, a Friday audit that re-checks last week’s own decisions, and the job that rewrites the skill files themselves. |
| Reporting | 2 | Friday & Sunday | The weekly MAA into every client dashboard, and the personal-brand build update. |
Notice where the weight sits. The largest department is not the one that makes things — it is the one that checks things. Fourteen of thirty-eight jobs exist only to catch problems and improve the other jobs. The historical board included a job to review skill changes. A downloaded ZIP stays at the version you downloaded. Follow the supported update path for your app, review changes, and check the installed version and one fresh result. A Monday reminder by itself does not update or activate a package.
How to actually set one up
Start with one checked task and its required access. If that work should repeat, use your app’s supported schedule controls. State the time, time zone, runtime, inputs, result destination, and owner. Verify that the saved job exists, then check its first timed run. Natural-language scheduling support depends on the app.
After one task works, a package review can be a useful optional repeat job:
“Help me review updates to my installed skills. First identify my app, current package version, and supported update path. Show the changes and how to recover the old version if needed. After an approved update, check one real task. If I ask to repeat this, agree on a time zone and verify the saved schedule and first firing.”
A possible next job is proof research, if it serves your goal and the needed sources are available. Adapt this example request to the agreed scope, time zone, and sources, then check the actual saved job and first result:
“Every Monday at 9am, find anything new anyone said about me in the last week — reviews, mentions, tags, podcast appearances, comments. Add what is new to my proof library, and write me a short note with only what changed since last Monday. Do not send anything to anyone.”
Name the allowed actions in each job. A research assignment does not grant permission to send messages, publish pages, spend money, or change account access. Complete work within the authority already given. Ask only for the exact missing access, decision, or approval needed for the next step.
The failure you will hit in week one
You will hand an agent three hours of work, come back, and find it stopped after ten minutes to ask whether you wanted A or B. Models are trained to be careful, and careful looks like paralysis when nobody is watching. The fix is one line, stated up front:
“Do not stop for small decisions. Choose sensibly, keep working, and list every choice you made at the end.”
We ship that instruction as its own file, called Boil the Ocean, because it comes up so often it deserved a name.
The test
Test the job in the place it will run. Check one real output or failure, its time, and the access it used. For repeated work, set and verify a supported schedule. A cloud job may continue while a laptop is closed; a job that needs local files or apps may need that computer available. A one-time AI task does not need a schedule to count as real work.
A guide is a start. Verify one real job, then add a tested schedule only if that work should repeat.
The operations half of this argument: Persistent Agents — why a skill pack does no work. This page explains the parts to configure and check before an AI worker can use a skill for a real job. That page is how the job is actually built and how you find out it is lying to you — the schedule, the QA cycle, the working files, the six-question test, and two of our own failures where every report stayed green.
Related
- The System — how skills, definitive articles, meta articles and agents fit together as one loop.
- The Skill Pack directory — the maintained skill list; check the package version you actually use.
- The meta article prompt — the “written record” requirement, as a standard your agents can follow.
- How female experts use AI agents to build authority — the live workshop where this framework was first taught end to end.
Originally published .
Dennis Yu
Dennis Yu is the CEO of Local Service Spotlight, a platform that amplifies the reputations of contractors and local service businesses using the Content Factory process. He is a former search engine engineer who has spent a billion dollars on Google and Facebook ads for Nike, Quiznos, Ashley Furniture, Red Bull, State Farm, and other brands.
Dennis has achieved 25% of his goal of creating a million digital marketing jobs by partnering with universities, professional organizations, and agencies. Through Local Service Spotlight, he teaches the Dollar a Day strategy and Content Factory training to help local service businesses enhance their existing local reputation and make the phone ring.
Dennis coaches young adult agency owners serving plumbers, AC technicians, landscapers, roofers, electricians, and believes there should be a standard in measuring local marketing efforts, much like doctors and plumbers must be certified. He has appeared on 353 podcasts with 619 credited episodes — see the full list of his podcast appearances.