Guide ยท Published August 24, 2026

Print on Demand Automation: Open Source Recipes Your AI Agent Can Run

Print on demand automation in 2026 doesn't mean wiring up a dozen triggers in a workflow tool. It means handing an AI agent a written operating pattern and letting it run the loop: design, build products, draft listings, watch orders, reconcile fulfillment, and report back. The fastest way to get there is to start from a recipe, an open source blueprint that already contains the charter, the memory model, and the safety gates, then change it to fit your business. ApparelHub publishes six of them under the MIT license at github.com/ApparelHub-AI/apparelhub-recipes.

What does print on demand automation actually mean now?

For most of the last decade, automating a POD store meant connecting apps. You'd bolt a design tool to a store, a store to a supplier, and a supplier to a tracking email, then hand-hold every exception the chain couldn't handle. The automation was real but it was shallow: it moved data between systems and left every judgment call to you.

Agentic automation is a different shape. Instead of a fixed chain of triggers, you give an agent access to the whole pipeline and a set of rules about how to operate inside it. The agent decides what to do next, in order, based on what it finds. It reads your open orders before it creates anything new. It notices a listing that hasn't sold in ninety days. It catches a variant priced below your margin floor and fixes it. When it hits something you said it shouldn't do alone, it stops and asks.

If you want the conceptual version of that shift, we wrote it up in agentic commerce explained and covered the practical scope in what an AI agent can actually run end to end. This post is about the on-ramp: how you get from "I have an agent" to "my agent is running my store" without designing the whole operating model yourself.

Why do most POD automation attempts stall?

Almost nobody stalls on capability. They stall on the blank page.

Say you've got Claude Code or a custom harness and you've connected it to your store. Now what? You have to decide what the agent does first, and in what order, and how often. You have to decide what it's allowed to do without asking, which is the question that actually matters, because an agent that can spend money is an agent that can spend money badly. You have to decide how it remembers anything between sessions, since a fresh session knows nothing about last week's run. And you have to write all of that down clearly enough that the agent follows it every single time, not just the first time.

That's a real design job, and it's the reason a lot of people try agentic automation once, get an impressive demo, and never reach a steady state. The demo works because you're supervising it. The steady state needs structure.

A recipe is that structure, already written.

What is a recipe, and what is inside one?

A recipe is a self-contained operating pattern you drop into your agent's working folder. It's plain markdown and one small state file, nothing to install and nothing to compile. Six files do the work:

File Role
constitution.md The charter. Your agent reads it at the start of every run and follows it exactly. This is where the operating loop, the gates, and the guardrails live.
state.json The agent's machine memory: which workspace and store it operates on, its gate settings, its phase, and per-product status.
run-journal.md An append-only, human-readable log. One entry per run, never rewritten, so you can read the history at a glance.
pending-approvals.md The queue of things the agent decided it wasn't allowed to do alone, with the reason and the exact action it would take once you say yes.
BOOTSTRAP-PROMPT.md Run once. The agent discovers your account's anchors and writes its own state.json. Read-only discovery plus a single file write.
KICKOFF-PROMPT.md Run to start, and to run again. This is the normal entry point once you're set up.

The important idea there is that the folder is the memory. Agent sessions are stateless, so the recipe makes the files carry continuity: read everything at the start of a run, do the work, update the state, append to the journal, queue anything gated. A run that fails halfway doesn't corrupt anything, because the next run reads the same files and picks up from what's actually true.

The other important idea is that recipes ship with no account data in them. Nothing is hardcoded. The bootstrap prompt discovers your workspace, your store, your connected channels and providers, and writes them into your own local state file. A check in the repository enforces that on every contribution, so a recipe you pull down is a recipe, not somebody else's configuration.

Which recipes exist today?

Six, and they're deliberately different shapes rather than six variations on one idea.

Recipe What it does Good first pick if
autonomous-storefront Runs a whole store end to end, hands-off, through phases you advance yourself. You're starting a store and want the full loop proven before you go live.
reconciler-restocker Keeps a target catalog present. You list the products you want, the agent rebuilds anything missing as a draft, and never removes anything. You know exactly what your catalog should contain and want it to stay that way.
seasonal-collection-builder Builds a time-boxed themed collection, groups it, then retires it on a deadline. You sell around moments: holidays, drops, events.
review-and-optimize Reads your analytics and applies only changes that can't harm the store, queuing everything else. You already have a store with sales history and want a weekly cleanup pass.
agency-multi-brand Runs a safe operating pass across every client workspace, one at a time, with strict isolation. You run several brands as separate workspaces.
agency-brand-intake Onboards new client brands from a roster, builds their identity and creative, and closes each deliverable with an email approval. You take on new clients over time and need a sign-off trail.

If you're not sure, review-and-optimize is the gentlest way in. It never creates a product, never publishes anything live, and never confirms a paid order. It reads, it flags, it archives dead listings, it corrects prices that fell below your floor, and it queues every discretionary decision for you. You get to watch an agent operate your real store for a few weeks with almost no surface area for it to do anything you'd regret.

reconciler-restocker is the most instructive one to study, because it's built on a pattern worth internalizing. It's a desired-state reconciler: it doesn't track what it did, it checks what's true. Every run it looks at your target catalog, sees what's actually present in the store, and rebuilds the gap. Delete a product and it comes back next run, rebuilt through the same pipeline. That means a failed run costs you nothing, and it means you never end up debugging a queue of half-finished work.

How do you run one?

Four steps, and only one of them involves thinking.

  1. Copy the recipe's folder out of the repository and into the folder your agent works in. Copy it rather than working inside the clone, so your filled-in state stays yours.
  2. Give your agent access to ApparelHub. That's the hosted connector, the local tool server, or an API key, whichever your setup supports. The options are on apparelhub.ai/agents.
  3. Run BOOTSTRAP-PROMPT.md once. The agent finds your workspace, store, channels, and providers, and writes its own state file. Nothing gets built.
  4. Run KICKOFF-PROMPT.md. That's the first real run, and it's the same prompt you use for every run after.

You'll need an ApparelHub account with at least one fulfillment provider connected and a sales channel on the store you want the agent to operate. Printful, Printify, and Gelato are all live as providers. Shopify, WooCommerce, Wix, and TikTok Shop are all live as channels.

What stops an autonomous agent from doing something expensive?

This is the question that should decide whether you trust any of this, so the recipes answer it in the charter rather than in a footnote.

Every recipe ships with two hard gates on by default, and the agent is told in plain language never to cross them on its own:

When the agent reaches either line, it writes the item to pending-approvals.md with what it wants to do, why, what it costs, and the exact action it would take, then moves on with the rest of the run. It doesn't stall and it doesn't improvise.

Underneath the gates there are standing guardrails: zero autonomous spend, a margin floor the agent won't price below, a quality gate that rejects a product whose mockup isn't a crisp photoreal render, a cap on how many products it can create in a single run, and a rule that it archives rather than deletes, since deleting breaks order history and can't be undone.

None of that is locked. The gates and limits live in your state file, so if you want a higher creation cap or a different margin floor, you change a number. What you shouldn't do is turn the two hard gates off because a few runs went well.

How do you make a recipe your own?

This is where it gets interesting, and it's the reason these are published as open source rather than shipped as a closed feature.

A recipe is a written charter, so editing one is just writing. If your brand only ever uses one blank and one provider, say so in the constitution and delete the paragraphs about garment selection. If you want a run summary in your inbox every morning, add an email step to the loop. If your margin floor is forty percent rather than the default, change the number. If you want the agent to check a trends source before it picks a theme, add that as the first step of its create phase.

Bigger changes are just as available. The six published recipes are patterns, not a catalog, and the interesting ones are the combinations nobody has written yet. A reconciler that keeps a wholesale line stocked while a seasonal builder runs drops beside it. An intake recipe that reads from your CRM instead of a spreadsheet. A review pass that reports into a channel your team already watches. The operating loop, the memory model, and the gate queue transfer to all of it, so you're editing an existing pattern rather than inventing one.

That's the actual argument for starting from a recipe. Not that it does the work for you, but that it puts the hard part, the operating model, in front of you as something you can read and change, instead of something you have to invent from a blank page while you're also still learning what your agent can do.

Where ApparelHub fits, honestly

ApparelHub doesn't have its own AI and doesn't run an agent for you. You bring the agent, whatever it is. What the platform provides is the pipeline your agent operates and the interoperability that makes that possible: design generation using leading models, product and variant creation, listing to your channels, order and fulfillment management, margin math, and analytics, all exposed through the same surface a person uses in the browser.

What's live today: Printful, Printify, and Gelato as fulfillment providers, and Shopify, WooCommerce, Wix, and TikTok Shop as sales channels. Sign-up is open to everyone. The agent surface, covering the API, the connector, and the loadable skill, is documented at apparelhub.ai/agents. The recipes are MIT licensed and take contributions.

The honest boundary: a recipe is an operating pattern, not a guarantee of results. It won't tell you what to sell, and no gate will save a store built on a niche nobody wants. What it removes is the operational drag, the part where good products don't get built because building them is tedious. You still own the strategy.

FAQ

Do I need to know how to code to use a recipe? No. A recipe is markdown files plus one small state file. You copy a folder and run two prompts. Editing one means editing plain English rules in the charter, so if you can write a clear instruction, you can customize a recipe.

Which agent runtimes do these work with? Any runtime that can reach the ApparelHub connector. Claude Cowork and Claude Code are the ones we test with, and a custom harness works the same way as long as it can call the tools and read and write the recipe folder.

Can the agent spend my money without asking? Not under the default settings. Confirming a paid order to production is one of the two hard gates, and the guardrails specify zero autonomous spend. The agent queues anything that costs money and waits for you.

What happens if a run fails partway through? Nothing breaks. The recipes are built so a run can be repeated safely: the next run reads the current true state and continues from there rather than replaying what it thought it had done. The reconciler recipe leans hardest on this, since a missing product is simply rebuilt next run.

Can I run more than one recipe on the same store? You can, but start with one and let it reach a steady state first. Two recipes operating the same store will each read the same live data, so it's easy to end up with overlapping actions. Running different recipes against different stores or workspaces is more straightforward.

Start with one recipe

Pick the recipe closest to how you already work, copy it, and run the bootstrap. If you have a store with history, review-and-optimize will show you an agent operating your real catalog within one run and it can't do anything you'd need to undo. If you're building from scratch, autonomous-storefront proves the whole loop in draft before anything goes live.

You can create an account and connect a provider and a channel in a few minutes, then read the connection options on the agents page. If you'd rather understand the pipeline before you automate it, start with connecting multiple print providers to one storefront, which covers the setup a recipe assumes you already have.