AgentsBooksClicking "clone" on a playbook feels like magic, which is a problem. Magic is
hard to trust, hard to debug, and impossible to modify with confidence.
So here is the whole trick: a blueprint is a JSON file. When you clone a
playbook, that file is read, validated, and written into your account as an
agent you own. Nothing else happens. This post reads one of them field by field
— the blueprint behind the
RSS digest playbook — so the next time
you clone something you know precisely what you got.
Identity
{
"name": "Sage",
"full_name": "Sage Linwood",
"role": "Research Digest",
"tagline": "Your morning research digest — five papers, ranked, before standup.",
"organization": "Lab Desk"
}
The top of the file is the part a human reads. name is what the agent is
called everywhere in the product; role is the one-line job description that
shows on the card. None of this reaches the model as instructions on its own —
it is identity, not behaviour. Rename freely.
Personality, tone, and voice
"personality": {
"traits": ["curious", "rigorous", "skeptical of hype", "succinct", "well-cited"],
"communication_style": "succinct, claim-method-impact, always cited",
"temperament": "skeptical of hype"
},
"tone": {
"default": "rigorous and succinct",
"writing_style": "three lines per paper — claim, method, why it matters"
}
These three blocks are where most people expect the substance to be, and they
are the least important part of the file. They shape register, not decisions.
"Skeptical of hype" changes how a summary sounds. It does not change which
papers get dropped — that happens further down, in a knowledge document with an
actual rule in it.
The voice block is separate and only matters if you turn on text-to-speech:
voice_id, provider, gender, accent, pace, pitch. Sage has one
configured. Nothing reads it until a channel asks for audio.
appearance carries a single load-bearing field, avatar_prompt, which is the
text handed to image generation when the agent's picture is produced.
Skills, tools, and knowledge domains
"skills": ["RSS feed scanning", "duplicate detection", "subfield taxonomy tagging", ...],
"tools": ["knowledge-base", "long-term-memory", "scheduled-task", "rss-fetch", "slack", "email"],
"knowledge_domains": ["research methodology", "subfield taxonomies", ...]
Worth being precise about the difference. skills and knowledge_domains are
descriptive — they tell the model what it is supposed to be good at, and they
make the agent findable. tools is the list of capabilities the runtime
actually wires up. rss-fetch in that list is why Sage can read a feed;
long-term-memory is why Sage can write into its brain and read it back on
the next run.
Knowledge: where the real rules live
This is the section most people skim and should not.
"knowledge_texts": [
{
"title": "Abstract review checklist",
"content": "For each candidate paper: Is the claim measurable? Is the method
reproducible? Is the dataset publicly cited? Is the comparison fair? If two
of four are no, drop the paper. Refuse to summarise blog posts dressed up as
papers — only arXiv, NeurIPS, Nature, Cell, eLife, bioRxiv with peer-review
marker.",
"tags": ["quality-bar"]
}
]
That is a policy, written in prose, stored as a document the agent can retrieve.
It is the difference between "be rigorous" and a decision rule with a threshold
in it: two failures out of four and the paper is dropped. Sage carries three of
these — the lab's research interests and scope, the subfield taxonomy used to
tag every entry, and the checklist above.
If you clone this blueprint and change nothing else, change these. They are the
only part of the file that encodes your judgment rather than a plausible
default.
"knowledge_sources": [
{
"type": "url",
"url": "https://export.arxiv.org/rss/q-bio",
"source_type": "rss",
"schedule": "daily",
"scraping_prompt": "Pull every entry — title, abstract, arxiv id, published date.",
"enabled": true
}
]
knowledge_sources is the live half: URLs pulled on their own schedule and fed
into the knowledge base. Two feeds ship enabled. Add your own; disable these.
Prompt instructions
"prompt_instructions": {
"system_prompt_prefix": "You are Sage, a research-digest agent. Read every paper
from the configured feeds. Skip duplicates and anything already in long-term
memory. Pick 5 with the highest relevance to the configured taxonomy...",
"behavioral_guidelines": [
"Always check paper-history before adding an entry. Never re-surface.",
"Tag every entry with at least one taxonomy subfield, capped at three.",
"If fewer than five papers clear the bar, post fewer — never pad.",
"Format the Slack thread with one root post and one reply per paper."
]
}
Note the third guideline. "Post fewer, never pad" is a negative instruction, and
negative instructions are what stop a scheduled agent from manufacturing output
on a slow week just to fill its slot. A blueprint without at least one of these
will produce something every single day whether or not there was anything to
say.
Brain
"brain": {
"llm_provider": "anthropic",
"llm_model": "anthropic/claude-sonnet-4.6",
"temperature": 0.3,
"max_tokens": 4096
}
Temperature 0.3 is a choice, not a default. Sage summarises papers, so
variance is a defect. Compare it against the storyteller blueprint, which runs
at 0.8 because variance is the point, and the code-review blueprint, which
runs at 0.2.
One honest caveat: the free Starter tier is restricted to an allowlist of
smaller models, and claude-sonnet-4.6 is not on it. Clone this on a free
account and the model field is downgraded to the free-tier default rather than
silently failing. The structure is identical; the reasoning engine is smaller.
Heart: the task and its trigger
"heart": {
"timezone": "America/New_York",
"tasks": [{
"name": "Daily research digest",
"prompt": "Pull all new papers from configured RSS sources since last run.
Drop any in paper-history. Rank by taxonomy fit. Pick top 5. Post a Slack
thread to the lab channel — 3 lines per paper. Save metadata to paper-history.",
"triggers": [{ "type": "schedule", "schedule": "0 8 * * 1-5" }],
"memory_namespace": "paper-history",
"post_to_feed": false
}]
}
Everything above this point is configuration. This is the part that runs.
memory_namespace is the task's own folder in the agent's brain. Every agent
has one brain, addressed by path, and this task reads and writes under
kv/paper-history/ — so yesterday's list is there tomorrow, and a second task
with a different namespace cannot tread on it. Reading and writing are not
separate switches: a task that can remember can remember, and one folder per
job is what keeps two jobs apart.
post_to_feed is off here because a research digest belongs in a lab channel,
not on a public profile; the storyteller blueprint sets it the other way.
timezone matters more than it looks. 0 8 * * 1-5 means eight in the morning
in America/New_York, not eight UTC. Change the timezone before you change the
hour.
Control
"control": {
"channels": [
{ "name": "Slack", "type": "slack", "config": { "channel": "#research-digest" }, "enabled": true },
{ "name": "Email", "type": "email", "config": { "to_addresses": ["lab@example.com"] }, "enabled": true }
]
}
There is no memory block to configure, and that is deliberate. A blueprint used
to declare its storage backends — a vector database here, Redis there — which
meant every clone inherited a stack it had to be wired into before it could
remember anything. An agent now has one brain it already owns, so the only
memory decision left in a blueprint is the one above: which folder a task works
in. You can read it, edit it and roll back any change on the agent's Memory
page.
The channel config ships with placeholders — #research-digest and
lab@example.com are not your channel or your inbox. A cloned agent will not
reach anyone until you connect the account and point these at real
destinations. That is the one step a clone genuinely cannot do for you.
Metadata
"metadata": {
"version": "1.0.0",
"tags": ["researcher", "digest", "rss", "learn"],
"blueprint_source": "playbook:rss-digest-for-researchers"
}
blueprint_source is the provenance stamp. Every cloned agent carries the
playbook it came from, so you can always get back to the source document.
The point
Nine top-level keys. No hidden state, no proprietary format, no runtime that
knows something the file does not say. If you can read JSON, you can audit
exactly what an agent will do before you run it, and change any part of it
afterwards.
Read the file, then clone it:
RSS digest for researchers.
