A free pre-build checklist for AI agent automation: eight checks to run before you write code, covering scope, trigger, output format, stop condition, error path, logging, limits, and a human checkpoint. Below the checklist you'll find a guardrails box and four labeled opinions. The checks are generic mechanics; they apply whether you call a model API from a script or run a framework.
Run these eight checks before you build
Copy this list into your spec or a ticket. Each check is one decision, written down while it's cheap to change.
Scope it to one task. "Draft a reply to a support email" is one task. "Handle the support inbox" is a roadmap. Name the single job a run does and write it at the top of the spec; everything else is a later project.
Define the trigger. What starts a run: a cron schedule, an inbound message, a new file in a folder, a webhook. Record it with the exact input it delivers, because the trigger is where malformed input gets in.
Specify the output format. Decide the shape of a successful run before the first one: JSON with named fields, markdown with fixed headings, a row appended to a sheet. If you can't write the empty template, the task isn't defined yet.
Write the stop condition. A run needs to know it's finished: one call, or a loop with a maximum number of turns. Looping agents with no stop condition are how a small task becomes a large bill.
Write the error path. What happens when the API call fails, the output is malformed, or the result comes back empty: retry how many times, then skip, alert, or park for a person. Without this, failures surface in production or nowhere at all.
Plan the log line. One line per run: timestamp, input reference, output reference, duration, cost. When something goes wrong, that line is the difference between debugging and guessing.
Set limits before the first run. A rate limit (runs per hour) and a cost cap (per day) go in before launch, in config you can tighten without a redeploy. Both are cheaper than the first runaway loop.
Pick the human checkpoint. Decide which outputs a person reads before they go anywhere: every run at first, then a sample once you know the error rate. Don't ship unreviewed output you haven't watched the system produce.
Guardrails box
Three guardrails cover most of the damage a misbehaving run can do. Each one does one job, and none of them checks output quality:
Rate limit. Caps how fast runs fire. Protects your API quota and whatever sits downstream. It won't catch a wrong answer that arrives politely.
Cost cap. A hard daily ceiling, enforced outside the agent's own logic. When a bug loops, this is what stops the spend. It won't tell you the output was wrong, only that it stopped being free.
Human checkpoint. A person reads outputs before they reach anyone else. Catches the mistakes the other two can't see. It doesn't scale, and that's the point: it's the brake you keep until the error rate is measured, not assumed.
Four opinions
These are opinions from running small automations this way, not rules. Disagree with any of them once you have your own logs.
Boring LLM calls are fine. Most single tasks need one well-specified call and a parser, and a plain script is easier to debug than an orchestration layer. Add a second agent when a measured problem asks for one, not before.
One task per agent. A run that drafts, sends, and files will eventually do one of the three wrong. Separate runs give each step its own error path and its own log line, which is what you'll want the day one of them misbehaves.
Run the workflow by hand first. Execute your checklist manually ten times: trigger, output, log. The failures you find by hand are exactly the ones the error path should cover, and they're cheap to find this way.
Read every output for the first week. Whatever sample rate you plan later, read all of it early. The strange cases show up in week one, and they define your error path better than any brainstorm.
What this page is
This checklist is educational: generic mechanics for building agent workflows, written to be useful before you pick any tooling. It is not a review, ranking, or comparison of agent frameworks, and it isn't affiliated with any of them. Nothing here promises a workflow will succeed; the checks make failures cheaper to find when they happen.
The paperwork, pre-structured
The Agent-OS Template Pack is 20 markdown templates for this kind of work: specs, system prompts, eval checklists, runbooks, onboarding docs, and the support macros around them. You fill in the [BRACKETS], delete the headings you don't need, and the templates make no assumptions about your stack, model, or platform. The product README lists the contents verbatim:
Product specs (3): full v1 spec, single-feature spec, launch spec with success bar
System prompts (4): general agent, support agent, research agent, workflow automation — each with boundaries, refusal lines, and example blocks
Support macros (2): seven common-ticket replies, six hard-conversation replies
According to the same README, index.md maps all 20 templates to the moment you need each one, and searching for `[` in any template surfaces every placeholder. The templates structure decisions and docs; the technical content stays yours.
If you'd rather not structure that paperwork from a blank page, the Agent-OS Template Pack ships all 20 templates in plain markdown that opens in any editor or repo.