MIFY Templates: Starting From Something That Already Works

The blank canvas is where beginners lose their first week. MIFY ships 149 pre-built workflows precisely so you do not have to meet it, and the fastest operators barely do — they start from a template that already works and bend it toward the problem in front of them.

This guide covers what the categories actually contain, which to reach for, and how to turn a template into something you can sell.

Data Notice: Template counts and categories come from MIFY’s public documentation at time of writing and change as the library grows. Treat docs.mify.com as authoritative.

What is in the library

Category	Count	What it does
RAG	9	Answer questions from your own documents
LLM	12	Text tasks — summarise, translate, classify
Logic	17	Decisions, routing, batch processing
HITL	8	Pause for a human to approve
I/O	24	Read from and write to outside services
Platform demos	60+	Connect to other tools — Flowise, Dify, n8n, WordPress, Supabase and more
Multi-agent	5	Plan-and-Execute, Reflection, Supervisor, Swarm
Showcase demos	13	End-to-end examples — customer support, research crew, voice IVR

The showcase demos are worth knowing about separately: several can be run without signing in at all, from the starter template URLs. That makes them the cheapest possible way to see whether the platform does what you need — no access conversation required first.

The four categories that carry most real work

RAG is the one clients ask for by describing rather than naming. “Can it answer questions about our handbook / our product catalogue / three years of support tickets?” Upload documents, ask in natural language, get answers with references back to the source. This is the single most commercially requested shape of AI work, and there are nine starting points for it.

LLM covers the tasks that are boring, constant and individually small — summarising inbound email, translating documents, classifying tickets by type. The value is never in one run; it is in the thousandth.

Logic is the unglamorous category that makes the others deployable. Real workflows need to route by rules, handle batches, and behave differently when something is missing. A workflow with no logic blocks usually means the happy path was the only path considered.

HITL is where approval gates live, and it is the category to learn early if you intend to sell anything. See your first workflow for why a human gate is frequently the difference between a project that ships and one that stalls in review.

Multi-agent: what the five strategies actually mean

Reach for these when one model call genuinely cannot do the job — not because “agents” sound impressive. Each is a different way of splitting a problem:

Plan-and-Execute — one pass writes the plan, another carries out each step. Good when the work has stages that are obvious only after thinking.
Reflection — the output is fed back for critique and revision. Good when quality matters more than speed.
Supervisor — a coordinator delegates to specialists and assembles the result. Good when subtasks need genuinely different skills.
Swarm — several agents work in parallel and results are combined. Good for breadth, coverage and search.

The honest guidance: try the single-model version first. Multi-agent costs more, takes longer and fails in more interesting ways. Use it when you have watched the simple version fail for a reason a second perspective fixes.

Turning a template into a product

If you intend to sell solutions, the gap between “a template ran” and “somebody paid for this” is smaller than it looks — and it is made of unglamorous work:

Pick a problem, not a capability. “RAG over documents” is a capability. “Answer a property manager’s tenant questions from their lease documents” is a product. The template is the same; only one of them sells.
Handle the unhappy paths. What happens when the document is a scan? When the question is out of scope? When the AI is not confident? A template demonstrates; a product survives contact with real input.
Add the approval gate. See above. It is what makes a buyer comfortable.
Write the description as the buyer would search for it. People search for their problem, not for your architecture.
Version it before anyone depends on it. Publish, then keep the version history clean, so a bad change is one restore away.

The workflow-as-API consequence

Every published workflow is automatically exposed as a stable HTTP endpoint with an OpenAPI description, an MCP tool, and an A2A agent.

For selling, this is the most important sentence in the platform. Your client does not need to adopt MIFY, learn the canvas, or hold an account. They call an endpoint. What you sell is the result, and the platform is your workshop rather than a dependency you have to talk them into.

A working method

Find the nearest template to the problem. Nearest, not perfect.
Run it unchanged and read the execution end to end.
Change one thing, run again, compare.
Swap in the real input — the client’s actual document, the real message format. This is where most templates break, and where the actual work turns out to be.
Add logic for the unhappy paths you just discovered.
Add the approval gate if a person needs to stand behind the output.
Publish and version.

Steps 4 and 5 are the job. Steps 1 to 3 take an afternoon; steps 4 and 5 are what somebody pays for.