Most first agents die the same way: someone opens a builder, types "You are a helpful assistant that handles my marketing," attaches five tools, and then wonders why the thing rambles, invents facts and never finishes. The problem isn't the model. It's the blank page.
My name is Artem, and I run the Writingmate blog. I've built and broken a lot of custom agents over the past year, mostly for research and content work, and the pattern is boringly consistent: the agents that survive have a narrow job, a written stop condition and a test. So instead of another theory piece, this post gives you three blueprints you can copy today. I already wrote about the full build workflow and how to choose a platform. This one is template-first.
First, do you even need an agent?
The honest answer is often no. If you do a task once, or the steps change every time, a good prompt in a normal chat beats an agent. An agent earns its keep when the same job repeats, the inputs look similar each time, and you're tired of pasting the same instructions.
Andrew Ng made the useful distinction years ago when he described how an agentic workflow differs from a one-shot prompt:
"Instead of having an LLM generate its final output directly, an agentic workflow prompts the LLM multiple times, giving it opportunities to build step by step to higher-quality output." — Andrew Ng on X
His talk (embedded above) is worth the 13 minutes if you want the idea behind drafting, critiquing and revising. For a no-code builder, the practical version is simpler: write instructions once, give the agent reference files, and reuse it.
Situation | Use a plain prompt | Use an agent |
|---|---|---|
One-off task | Yes | Overkill |
Same job every week | Gets tedious | Yes |
Needs your policies or style guide every time | Paste fatigue | Yes, with knowledge files |
Output format must be identical each run | Drifts | Yes, with a fixed format block |
Task changes shape constantly | Yes | Will fight you |
How I tested these blueprints
I checked the field list against the Writingmate custom agents documentation as of October 2026: name, model, a required description, required instructions, response settings (temperature and context length), knowledge files up to 10 MB each, optional integrations, and conversation starters. Each blueprint below maps onto those fields, so you can fill the form straight from this page.
For every blueprint I use the same pass/fail test: five realistic inputs, one deliberately bad input, and three yes/no checks (stayed in scope, followed the format, stopped when it should). I haven't included benchmark numbers because none of this needs them. You'll know within ten minutes whether it works. Treat the instruction blocks as starting points and edit the bracketed parts to match your situation.
Blueprint 1: the weekly research digest
Job: turn a pile of links or notes about one topic into a one-page digest every week.
Knowledge files: a short "what I care about" document (your market, competitors, three questions you want answered) and last week's digest so the agent can skip repeats.
Model pick: a mid-size reasoning model with a long context window. You're paying for careful reading, not flashy writing. Turn temperature down toward the precise end.
Instruction block:
Role: You are a research analyst for [my team/market]. Job: each time I paste sources, produce a one-page digest. Rules: use only the pasted sources and the knowledge files. Never add a claim that isn't in a source. Format: 1) three-sentence summary, 2) five bullets, each with the source name, 3) "What changed since last week," 4) "Open questions." Stop condition: if fewer than three sources are pasted, or a source is unreadable, say exactly what is missing and stop. Do not guess.
Pass/fail: paste five real sources plus one fake claim of your own. Pass if every bullet traces to a source, the fake claim is flagged or ignored, and the "what changed" section isn't just last week's text reworded. Fail if you see a statistic you can't find in the sources.
Blueprint 2: the customer-reply drafter
Job: draft replies to common customer emails in your voice, for a human to approve. Draft, not send. That one word matters.
Knowledge files: your refund and shipping policy, a tone guide with five example replies you're proud of, and a list of things the agent must never promise (discounts, delivery dates, legal statements).
Model pick: a fast, inexpensive model is usually fine because the answers come from your policy file. Upgrade only if replies feel stiff. Keep temperature low so the same question gets the same answer.
Instruction block:
Role: You draft replies for [company] support. Audience: customers who are mildly annoyed. Rules: answer only from the policy file. If the policy doesn't cover the question, write "NEEDS HUMAN: [one-line reason]" instead of a reply. Never promise refunds, dates or exceptions. Tone: match the example replies. Format: subject line, reply under 120 words, one line listing which policy section you used. Stop condition: one draft per email, no follow-up questions unless the email is missing an order number.
Pass/fail: run five typical emails and one trap: a customer asking for a refund outside your window. Pass if the trap returns "NEEDS HUMAN" and the other five cite the right policy section. Fail if the agent is generous on its own. Keep tools off for this one. A drafter that can't send can't embarrass you.
Blueprint 3: the content repurposer
Job: take one long piece (a blog post, webinar transcript, podcast notes) and produce a fixed set of derivatives.
Knowledge files: your brand voice guide, three past posts that performed well, and a banned-phrases list.
Model pick: a model strong at writing, since style is the product. This is where trying two or three models on the same input pays off, which is easy to do in a multi-model tool like Writingmate. Medium-to-higher temperature is fine here.
Instruction block:
Role: You repurpose long content for [brand]. Input: one source text. Output, always in this order: 1) a LinkedIn post under 200 words, 2) five short social posts, 3) a three-email sequence outline, 4) one pull quote copied word for word from the source. Rules: every fact and number must come from the source. Follow the voice guide and avoid the banned phrases. Stop condition: if the source is under 400 words, ask for more material instead of padding.
Pass/fail: give it a piece with three specific numbers. Pass if all three numbers survive unchanged, the pull quote matches the source exactly (search for it), and no banned phrase appears. Fail if a number shifts or the quote was "improved."
Why first agents fail (and how the blueprints dodge it)
Three causes show up again and again. A thread in r/AI_Agents puts the third one bluntly:
"Biggest beginner mistake is going straight to multi-agent galaxy brain stuff before you can make one agent do one job reliably." — u/averageuser612 on Reddit
- Vague scope. "Handle my marketing" has no edges. "Turn one transcript into five posts" does. Every blueprint above opens with one sentence describing one job.
- No stop condition. Without a written rule for when to quit, agents guess. Each blueprint ends with what to do when input is missing, and the customer drafter has a literal "NEEDS HUMAN" exit.
- Too many tools. Every integration is another way to go wrong. The documentation itself says to enable only what the agent needs and to test with non-sensitive data first, since enabled integrations can change connected data. None of my three need any tools to start.
For each tool, ask yourself: can I name a specific moment this agent would use it? If not, switch it off.
The pass/fail test, in one table
Same test for every agent. Run it before you share anything with a teammate.
Check | How to run it | Pass means |
|---|---|---|
Five real inputs | Use actual past material, not toy examples | At least four need no edits beyond taste |
One trap input | Missing data, out-of-scope ask or fake fact | Agent flags or refuses instead of guessing |
Format check | Compare output to your format block | Same order and length limits every run |
Source check | Spot-check three claims or numbers | All three trace to your files or input |
Repeat run | Run one input twice | Differences are wording, not substance |
If an agent fails, change one thing at a time. Tighten the instruction, shrink the knowledge file, or switch the model, then rerun the same six inputs. Changing three things at once tells you nothing.
Walkthrough: building Blueprint 1 in Writingmate
Here's how I'd set up the research digest in about ten minutes, following the creating custom agents docs:
- Open the Agents section and start a new agent from the Add New Agent form.
- Name it plainly: "Weekly Research Digest." Add the required description in one sentence.
- Pick one model. The agent uses a single model, limited by your plan and workspace. Start with a mid-size reasoning model.
- Paste the instruction block from Blueprint 1 and edit the brackets. Never put passwords or API keys in instructions.
- Set response settings. Temperature toward precise. Context length controls how much conversation and reference material the model considers, and it isn't permanent memory, so keep last week's digest as a file rather than relying on the agent to remember.
- Upload knowledge files (10 MB each maximum): your "what I care about" doc and last week's digest.
- Leave integrations off for the first version.
- Add two conversation starters, for example "Digest these sources" and "What changed since last week?"
- Create it and run the pass/fail test. New agents are private by default, so nobody sees your rough first draft.
If the digest drifts, compare the same input on a different model without rebuilding anything. Model switching is one of the reasons I build agents in a multi-model workspace; the model-picking guide covers how I choose.
What to do after it passes
Run it for two weeks before you add anything. Keep a short log of every correction you make by hand. Those corrections are your next instruction edits: if you keep deleting the same sentence, ban it; if you keep adding a source name, require it. Only after the agent is boring and reliable should you consider a tool or a second agent.
That's the whole approach: one job, one stop condition, no tools, a test. Pick the blueprint closest to something you did last week, fill in the brackets, and run the six inputs. If it passes, you have an agent. If it fails, you've learned exactly where the instructions were vague.
See you in the next one!
Artem
Frequently Asked Questions
Sources
Written by
Artem Vysotsky
Ex-Staff Engineer at Meta. Building the technical foundation to make AI accessible to everyone.
Reviewed by
Sergey Vysotsky
Ex-Chief Editor / PM at Mosaic. Passionate about making AI accessible and affordable for everyone.
