AI Agent Templates: The One-Page Spec I Fill In Before Any Build

Search for AI agent templates and you get thousands of downloads. Lead researchers, inbox sorters, content pipelines, customer service bots. Most look finished. Almost none fit your business on day one.

The reason is simple. A build template answers how. It doesn't answer what, for whom, or what happens when things go wrong. That part lives in a spec, and nobody ships the spec with the download.

So this piece gives you the spec. It's the one page I fill in before I build any agent, on any platform. After that, I'll show where to find build templates and how to pick one that matches.

What is an AI agent template?

An AI agent template is a reusable starting point for an agent, and it comes in two layers: the spec, which describes the job and the rules, and the build, which is the workflow or file that runs it. You need both, and the spec comes first.

The build layer is what most people mean. An n8n workflow you import as JSON. A Claude Code subagent saved as a Markdown file. A starter project in an agent framework. These save you hours of setup.

The spec layer is a short document in plain language. It says what the agent does, what it may touch and when a person steps in. It's the same whatever tool you use. Once it exists, swapping platforms is a weekend job, not a rebuild.

What should an AI agent template include?

A complete AI agent template includes eight fields: the job, the trigger, the inputs, the tools and their access, the rules, the human checkpoints, the fallback and the log. Leave one out and the gap shows up in production.

Here is the template. Copy it, fill it in, and keep it next to the build.

The example is made up, but the structure is the one I use. Notice what's missing from it: any mention of a model, a platform or a node. That's on purpose.

How do you fill in the template?

Fill in the template by writing down how the process runs today, by hand, and only then deciding what the agent takes over. The spec describes the work, not the technology.

The steps I follow:

1. Write the job as one sentence. If you need "and" twice, you have two agents. Split them.
2. Collect ten real examples. Real emails, real requests, real records. They tell you which inputs actually show up.
3. List every tool and the smallest access that works. Read-only beats read-write. One folder beats the whole drive. Drafts beat sending.
4. Write the rules as your best employee would explain them. Include the things a new hire always gets wrong.
5. Mark every action that sends, pays, deletes or publishes. Each one gets a human checkpoint, at least at the start.
6. Decide the fallback before anything else runs. What happens when the input is strange, a tool is down or the model is unsure.
7. Define one line of log per run. You'll want it the first time someone asks why the agent did something.

Step 6 is where most specs fall apart. People skip it because the demo never fails. But no plan B tops my list of reasons agents break once they go live, together with no records, no approvals and access nobody bothered to limit. The template forces you to answer those questions on paper, where they're cheap.

Not sure which process deserves a spec? Score your candidates before you write one. Rate frequency, clarity and willingness to let go, each from 1 to 5. A total of 12 or higher out of 15 means build.

Where can you find AI agent build templates?

You can find AI agent build templates in the template libraries of the tools you already use, in shared repositories on GitHub, and from builders who give their work away. The source matters less than whether it matches your spec.

The main places:

• n8n. The official library at n8n.io/workflows holds thousands of free workflows, many with AI agent nodes. I wrote a separate piece on adapting n8n templates if that's your platform.
• Claude Code. Subagents and skills are plain Markdown files, so they're easy to share and read. See the Claude Code files I copy into every project.
• Agent frameworks. Most developer frameworks ship starter projects and example agents in their documentation and GitHub repositories.
• Free collections. I share my own agents, n8n automations, voice agents and Claude Code templates on the free agents page.

When you compare options, hold each one against your filled-in spec. Does it have the trigger you need? Can you limit its access? Is there a place for an approval step? A plain template that matches beats a clever one that doesn't.

How do you turn a template into an agent that holds up?

You turn a template into a reliable agent by wiring the spec into the build: your rules in the prompt, your checkpoints as approval steps, your fallback as error handling and your log as a real record. The template supplies the shape. The spec supplies the judgment.

In practice that means four changes to almost any download:

• Replace the prompt. Paste in your rules field, plus two or three examples of good output from your real examples.
• Shrink the access. Reconnect every account with the access you wrote in the spec, not the access the creator used.
• Add the checkpoint. Put an approval step before every action you marked in step 5.
• Build the fallback and the log. An error route that notifies a person, and one row per run in a sheet or table.

Then test on your ten real examples before you switch on the trigger. Compare each output to what you would have done. If it's wrong more than you can tolerate, fix the spec first, then the build.

This work is not optional. In a June 2025 forecast, Gartner put the share of agentic AI projects it expects to be scrapped before 2028 at more than 40%. The causes it named: costs that escalate, value that stays vague and risk that nobody manages. A spec doesn't guarantee success. It does make value and risk visible before you spend money on a build.

Why do downloaded agent templates fail in real businesses?

Downloaded agent templates fail in real businesses because they were built around someone else's process, data and tolerance for mistakes. The build runs fine. It just solves a slightly different problem than yours.

You can see this pattern well beyond templates. MIT's NANDA initiative found in its 2025 GenAI Divide report that roughly 95% of the corporate AI pilots it looked at produced no measurable return. The researchers blamed tools that never fit into daily work, not the models.

That matches what I see. In the 35+ agents I've built for real companies, the model has rarely been the problem. The gaps were in the process: rules nobody had written down, edge cases nobody had collected, and no answer to "what if it's wrong?"

A spec closes those gaps before they cost you anything. It also outlives the build. Tools change every few months. The page that says what your agent does, what it may touch and when a person decides stays true until your process changes.

When should you skip templates and build from your spec?

Skip build templates and start from your spec once you've adapted two or three agents and know which pieces you need. At that point a template mostly adds parts you have to remove.

That's how I work now. I write the spec, explain the agent to Claude Code in normal words, let it build the workflow, then I review it against the spec. I describe that whole path in my guide to building an agent.

Templates are a fast way to learn what a working agent looks like. The spec is how you make one that works for you.