How templates work, and how to build one worth sharing

The model is rarely the hard part of a useful agent. The hard part is everything around it: the instructions that shape how it behaves, the tools it’s allowed to touch, the skills it knows, the tasks it runs without being asked. Getting that combination right takes real iteration, and once you’ve got it, it tends to get stuck. It lives in one agent, and the only way to pass it on is to walk someone through your setup by hand.

Templates fix that. A template turns a working agent into something you can move.

What’s inside one

A template is a folder with two layers, and the split is deliberate. The base is an agent plugin in the open Agent Plugins standard, the vendor-neutral format steered by Vercel alongside Amazon, Cursor, Microsoft, and OpenAI. It holds a manifest, a set of skills, and an mcp.json describing the tools the agent can reach. We built on that standard on purpose: it means a template is portable the moment it exists, not because we bolted an exporter onto it later.

On top of that base sits a NanoClaw extension folder for the things the standard doesn’t cover: the agent’s persona instructions and its scheduled tasks. Keeping the base clean and pushing everything NanoClaw-specific into the extension is what protects that portability. The core travels, the extension stays home.

That’s also why a template isn’t a workspace or a project config file. Those describe a place you’re working. A template describes an agent you can deploy again and again.

What install actually does

We didn’t want anyone thinking about file placement, so they don’t. On install, NanoClaw copies the template into your agent group and injects each part where it belongs inside the agent’s isolated container. Persona instructions layer on top of our default system prompt rather than replacing it, so the agent keeps the safe defaults for credentials, isolation, and tool use, and your instructions extend from there.

One decision I’ll defend specifically: scheduled tasks install paused. A template can arrive with a job set to fire every morning at nine, and it stays dormant until you activate it, which itself goes through an approval step. Handing someone a fully configured agent should never mean handing them one that starts acting before they’ve looked at it.

Why it’s powerful

Two things fall out of this. You can pick a template and get a fully loaded agent in seconds, then change anything you want, because it’s yours from the moment it lands. And you can package an agent you’ve already dialed in and hand it to your team or the community, who get your exact setup running without rebuilding it.

Portability also runs both ways. A plugin authored in another compatible client carries its skills and tools straight into NanoClaw with no rebuild. The client-specific extensions won’t follow, by design, but the portable core will. Work you did elsewhere isn’t trapped elsewhere.

What makes a good template

Having reviewed a few now, the ones that hold up share a pattern:

• They do one job clearly. A template that tries to be everything is hard to trust and harder to adapt.
• Their skills are small and composable, so someone can lift one without swallowing all of them.
• They keep secrets out. Tools go behind MCP, credentials stay with the installer. Bake in a key and you’ve broken portability for everyone downstream.
• They leave scheduled tasks paused and let the installer decide when the agent goes live.
• They’ve been run locally before being shared. Drop the folder in /templates, install it, use it, then submit.

Where this goes

Templates are the first thing you can build and share on top of the standard, not the last. Start from an agent that already works, make it yours, and when it’s good, pass it on. That’s the whole idea.