# Blueprints: sharing a setup someone else can run

> A whole setup in one place: the agents, their standing jobs and schedules. A blueprint starts private, publishing needs a person's approval, and its page lists the jobs it creates before installing.

Design guidance: [Building useful apps and blueprints](https://bolter.chat/help/building-useful-apps-and-blueprints).

A blueprint is one file describing a working setup: agents, their chat,
standing jobs, schedules and what they produce. It records a setup that
already works so somebody else can install it.

Ask an agent to "write this room's blueprint out to a shareable file" and it
produces one. Paste one into a chat and ask an agent to set it up, and it
rebuilds the setup here.

## What travels, and what never does

A blueprint carries the shape of a setup, never its contents. Agents, their
personalities, their standing jobs and the schedules those run on all travel.
The things they produced do not: no rows from a tracker, no messages, no
documents. Data is not part of a blueprint.

Anything specific to your workspace becomes a **question** instead. That is
why installing one asks you a handful of things before it builds: whose inbox,
which market, which morning. Some of them will already be filled in when you
see them, from what Bolter can see of your workspace, and you can change any of
those.

A running app is the one thing that travels as itself: a blueprint written from
a setup with a working app carries that app, so an install gets the same app
rather than a rebuild. You do not have to ask for it, it happens as part of
writing the blueprint. The app's stored data stays behind. If the app cannot be
carried as it is (a credential or a colleague's name in it that the agent could
not lift out), the agent hands over the description instead and tells you what
blocked it.

## Who can change a blueprint

A blueprint belongs to the workspace it was written in. Its owners and admins,
plus whoever published or wrote it while still a member, can change its
audience, edit it, take it down and bring it back.

Leaving the workspace ends it. If you published a blueprint and later left, the
publication still records your name, but you can no longer change it.

## Publishing needs a person

An agent cannot publish a blueprint on its own. It asks, and a card appears in
the chat for one of those people to decide.

You do not have to be in that chat. An agent raises the card wherever it happens
to be working, which is often a direct conversation between it and one person,
so every open request also appears under **Consents** in the dashboard of the
workspace that owns the blueprint, with the same card and the same decision. The
Admin tab carries a count of what is waiting there, and the same requests sit in
a "Needs your approval" panel on that workspace's About tab, so you meet them
without opening Admin at all. That listing is for owners and admins of the
workspace, and it is theirs whether or not they have ever seen the chat the
request was made in. Deciding it in either place is the same as deciding it in
the chat.

The Consents listing is for owners and admins. Someone who wrote or published a
blueprint without being one of those does not see that listing, but they can
still decide their own blueprint's requests on the card itself, in the chat where
it was raised. They manage it everywhere else too, on its own page: they can
change its audience, edit it, take it down and bring it back.

Before that card is created, the blueprint needs a headline, a short summary
and a few highlights, since a publication becomes a page strangers read before
installing. Without all three the publish is refused and the agent is told
which are missing.

Every blueprint gets its page when it is created. The story comes first, then
the walkthrough, team cards, FAQ and closing note; until all of them are there
it is a draft, and the refusal names what is missing. Ask for any part in your
own words and your agent writes just that part. The check runs again at
approval.

A public blueprint in the gallery is also open to search engines: its page is
in Bolter's sitemap, and its headline and summary are what a search result
shows. A link-only blueprint stays reachable only to people who have its
link: it is not in the sitemap, and its page tells search engines not to index
it, so it does not turn up in results even if someone posts the link somewhere
public.

It is also scanned for things that must not leave your workspace: colleagues'
names, email addresses, keys and tokens. If any are found the publish is
refused outright and the agent is told what to fix, so nobody is asked to
approve something that was never checked.

Softer things are not blocked; they are shown on the card for you to judge. A
figure like "deals over $50k" is usually fine in a sales blueprint and
occasionally is not, and that is a call for a person rather than a rule.

The card describes the publication, not the blueprint, so it also has a **View
blueprint** button. That opens the same read-through anyone installing it would
get: the agents it creates, the questions it asks, what it runs on a schedule.
It always opens on the version you are being asked to approve. Where there is
already a published version to compare against, a **Proposed / Published**
switch at the top of that view lets you read the current one instead, labelled
so the two cannot be confused. You do not have to be the one deciding in order
to read it, but a blueprint that has not been published yet is readable only by
the people who can administer it, and the card being in your chat does not
make you one of them. If the blueprint has been edited since the agent asked,
the view says so, and the publish is refused until it is requested again.

When you approve, you pick two separate things:

- **Who can read it.** Just your workspace, or anyone with the link.
- **Whether it is listed.** Listed blueprints turn up when someone searches or
  browses blueprints. Link-only ones never do, for anyone, including the
  workspace that published them: publish a blueprint as link-only and even
  browsing your own workspace's blueprints will not find it. A link is the
  only way to reach one.

A public blueprint you choose to list is checked by the Bolter team before it
appears in browse and search. Its link works straight away. You'll get a
message in your assistant chat when it's listed, or a note on what to change,
and until then its page tells you it is in review for the gallery. Sharing by
link, or within your workspace, needs no check.

Link-only is not privacy. Anyone who has the link sees everything either way.
It limits how far a blueprint travels, not what it shows.

Once approved, the blueprint's link is posted into the chat. Wherever that link
is later shared or pasted, anyone who can see the blueprint gets a card showing
the headline, what it sets up and who published it, with a **See more** button
that opens the blueprint's own page. If the blueprint has since been unpublished,
or the reader does not have access, the link stays a plain link. No card, no
error.

## Sending one to someone

Every blueprint page has a **Copy link** button in the row at the top, next to
**See more blueprints**. That is the whole of it: copy, paste it wherever you
are talking to the person, and they get the page you were looking at. Pasted
into a Bolter chat it becomes the card described above rather than a bare
link.

If you administer the blueprint, the panel that says **You manage this
blueprint** carries the same link written out in full, with a line underneath
saying who can actually open it. That line matters more than it looks. The page
is per-reader, so a link that works for you opens for nobody else when the
blueprint is private, when it has never been published, or when it has been
withdrawn. The line names which of those you are about to send, and the
audience picker directly below it is where you widen it first. Change the
audience and the line changes with it.

The button is there for readers too, not just the people who administer the
blueprint. Passing one to the colleague who should actually install it is the
commonest way a blueprint travels. A blueprint you cannot open has no button to
copy, so a link you were given is always a link that worked when it was sent.

## Changing one that is already published

Once a blueprint is published, changing its content and publishing the change
are the same act. Every edit, whether an agent makes it or you do, saves a
draft and raises the same approval card, run through the same checks at the
audience the blueprint already has. Readers keep seeing the current version
until someone approves the card, and a change that fails the scan is refused
before anything is saved at all.

A second check applies when an **agent** changes a published blueprint: the file
has to be fully wired. A setup question whose answer nothing uses, a blank left
in the text that no question fills, a job with no agent named to do it. None of
these break the page, which is exactly why the agent is stopped here rather than
you being shown them: the blueprint would look finished on the card and quietly
drop what it asks for at install time. This applies whether the loose end is new
or was already there, so an agent asked to make a small change to an older
blueprint sometimes tidies up more than you asked for. A blank the blueprint can
work out for itself, rather than ask you about, is fine as long as the file
says where it comes from. Your own edits are not held to this, on the grounds
that you have the file open in front of you, and neither are private
blueprints.

One more check is worth knowing about, because it is the one most likely to
stop an edit you thought was finished. If a blueprint builds a web app, the app
has to be listed as an app in its own right. Describing it in passing is not
enough, and neither is listing it alongside the documents and reports the
blueprint keeps up to date. A blueprint that gets this wrong will not save:
installing it would create the agents and the schedules but no app, and leave the
agent with instructions for a page that does not exist. An agent that hits this
fixes the blueprint and tries again, so usually you will just see it take an extra
step.

The same check protects the resources a blueprint says it needs. If its app,
computer or connection requirements are written in a form Bolter cannot read,
the save stops with a correction. Your agent can repair the declaration and
retry while keeping those requirements. This also applies when editing an older
private blueprint.

This also protects the agents, apps and standing jobs it declares. If the file
would make those parts disappear when read, Bolter asks the author to correct
the format and keep the declared work before saving.

A captured app's reference also needs to be in the right place. If a blueprint
puts the capture hash under `digest` rather than `blueprint`, saving asks the
author to move it; if both fields are present, saving says which one to keep.
Apps described only as a written specification do not need a capture.

The check is about work that would go missing, not about tidiness. A section
left empty, or one whose entries are all commented out, declares nothing and
saves fine. Notes an author leaves in the file are read as notes wherever they
sit, including after a value on the same line, so they never end up inside the
value they were describing.

An update card asks a narrower question than a first publication. The
audience and the listing are already settled and do not change; the card says
which version it updates and adds a **View changes** button showing exactly
what changed against the version readers see now. That view counts the lines
added and removed, wraps long lines by default, and can be flipped between a
single **Unified** column and **Side by side** panes. Approving publishes the
new version; declining leaves the published version as it was, with the draft
still saved for another try.

Changes to a public blueprint listed in the gallery are checked again by the
Bolter team. Until approved, everyone sees the version already listed, and its
page says it's in review. You get a message in your assistant chat
either way. Set it to link only meanwhile and a change still in review goes live
on the link; a declined one does not. If Bolter edits it while your
change waits, you're asked to publish again.

If the blueprint is edited again while a card is waiting, the newest edit wins.
The older card retires itself and reads "Replaced by a newer draft", so you are
only ever asked once, about the draft that is actually current. It stops
counting towards the approvals waiting for you, and drops off the About
tab's panel. This holds for a run of edits from the same place: an agent
redrafting in a chat, or you saving twice from the manage rail. An agent's draft
followed by your own save leaves a card in each place, because they are asked in
two different rooms; the older one refuses when clicked, and says why.

A blueprint set back to private, or taken down, is readable only by the people
who administer it, so its edits save directly again. The checks run again on
the way back out, whichever door reopens it.

## Your own blueprints

A blueprint does not have to be published at all. One that has been written but
never shared is **private**: it is readable only by the people who can
administer it, it has no public link, and it appears nowhere anyone browses or
searches. That is where a blueprint starts, and it can stay there.

Because a private blueprint has no link, there is one place to find it: the
**Mine** tab under Blueprints. That lists everything you can administer across
all your workspaces, published or not, and it is the only surface that shows a
private, link-only or withdrawn blueprint. It also flags a blueprint whose latest
edits are still waiting on an approval card, so you can tell what visitors are
currently seeing from what you have since changed.

Sharing one from there runs the same checks the agent's request does. The
headline, summary and highlights still have to be there, and the same scan
still runs, so publishing something yourself is not a way around the gate. What
you may overrule are the softer findings; keys, tokens and colleagues' details
are refused for you too.

## Taking one down

There are two ways to stop sharing a blueprint, and they are not the same.

- **Narrow who can read it.** Setting it back to private keeps the blueprint,
  keeps its link, and keeps it readable by the people who administer it. Widen
  it again whenever you like.
- **Withdraw it.** This takes the publication down for everyone, including you:
  its page stops opening and its link goes dead. Anyone who already installed
  it keeps what they built, since installing copies the setup rather than
  borrowing it.

Withdrawing is not permanent. A withdrawn blueprint still appears in **Mine**,
marked as withdrawn, with a control to bring it back. Restoring re-runs the
scan, because it is a publication like any other.

## Finding one

Browse blueprints and search by what you want one to do rather than what it
might be called. "Keep an eye on what our competitors ship" finds a blueprint
headlined something else entirely, because the search reads for meaning, not
for matching words. Public blueprints appear in the gallery once the Bolter
team has checked them.

If nothing matches, you get nothing back. A search with no results means no
shared blueprint covers that yet, not that you phrased it badly, so there is no
point rewording the same idea. Earlier this returned every blueprint it could
see whenever it could not find a real match, which read as a list of
suggestions when it was really a shrug.

You do not have to go looking yourself. Describe what you want to an agent,
and it can check the shared blueprints first and offer one that already does
it, along with what it sets up and how many workspaces run it, instead of
designing something from scratch. It searches the same listed blueprints you
would see browsing: the public ones and the ones published in your workspace,
never another workspace's. If it finds nothing it says so and builds instead.

## A blueprint's page

Every published blueprint gets a page. It leads with the headline sentence and
short summary the publisher wrote, so the first thing you read is what the
blueprint does rather than what it is called. The page also carries a **What
this blueprint does** list, the same highlights that had to exist before the
publish was allowed, along with who published it and which version you would
be taking. Once enough workspaces have installed a blueprint, the page says how
many; a new blueprint stays quiet on that count rather than reading as
unpopular.

### What the page shows

A blueprint's page is written for someone deciding whether to install it. Below
the headline it walks through the whole picture: a short story of what you
provide, what the blueprint does with it, and what comes back, played out as a
one-minute chat scene with the example app running beside it. Then it lays out
how it works step by step, what you get, what stays yours, the questions you
will be asked when you set it up, and a short list of common questions and
answers.

That copy is written by the blueprint's own agent, or by a Bolter admin for the
blueprints Bolter publishes. You can ask an agent to change it the same way you
ask it to change anything else about a blueprint. If the blueprint is already
published, a change to its page waits for a person's approval before visitors
see it, exactly like any other change to a published blueprint.

### Built by Bolter

Some blueprints are written by Bolter rather than by a workspace. Those are
credited to **Bolter** with a verified mark beside the name, wherever the
blueprint appears: on its page, on its card in browse, and on the card you get
when someone pastes a link into a chat. It means the blueprint came from us,
and it is the only place that mark is used.

Everything else about the blueprint reads the same. An official blueprint still
lists every standing job it would create, still asks its questions, and still
requests access to a connected account separately and with your approval. The
mark says who wrote it, not that it needs less reading.

Only Bolter can apply the mark. A workspace cannot mark its own blueprint, and
publishing a blueprint never gives it one.

It also lists **every standing job the blueprint would create, in full**. That
is deliberate. Installing a blueprint is not like opening a document: it
creates agents and recurring work that keep running afterwards, on their own
schedule. Read that section before you install something a stranger wrote,
the same way you would read a script before running it.

Anything that needs access to a connected account, like your email or your
calendar, is requested separately and needs your approval at that point. A
blueprint cannot quietly gain access to anything by being installed.

Every published blueprint wears an icon made of its crew: the agents it
installs, with the icons they wear once installed, in front of a small app
window showing what you get (a table, a feed, a checklist, a chart, a board, a
gallery, a receipt, a conversation, a document or code). You see it when
browsing, on its page, and in the preview when its link is pasted.

The icon is worked out when the blueprint is published. Whoever writes the
blueprint can choose each agent's icon and the window, and anything left out is
chosen for it. Ask an agent to change either and it edits the blueprint, the
same as changing the headline. Until the icon is ready, the blueprint shows the
simpler icon it had before.

## Showing a live example on the page

A blueprint's page can carry a working example: not a screenshot, but one of
your workspace's own apps, running, that a reader can click around in before
deciding whether to install anything.

To add one, share the app by link first (see [Apps and running code](https://bolter.chat/help/apps-and-code)), copy that
link, then open the blueprint and paste it into **Live example** on the manage
panel. The app has to be in the same workspace as the blueprint, and you have to
be able to administer both. One app can be the example for one blueprint, so if
it is already the example somewhere else you are told.

**Attaching it does not put it on the page.** That is a second, separate tick:
**Show it running on this page**. The two are kept apart on purpose, because
turning it on means anyone who can read the blueprint can use the app, and every
visit wakes it up. Until you tick it, nothing about the page changes.

### The tick remembers what you agreed to

When you tick it, Bolter records the reach the blueprint had at that moment:
both who could read it, and whether it was listed in browse and search. Those
are two different ways of reaching more people, and widening either one is a
bigger audience than the one you agreed to. So if you later make the blueprint
public, or list it, the example goes quiet by itself and the panel asks again.
The app is not shown to the wider audience until you say that audience is fine.

It also stops showing on its own, with a note saying why, if you switch sharing
off for the app or the app stops running. Switching sharing back on, or getting
the app running again, brings it back with no further decision from you.

**Remove** takes the example off entirely and forgets the agreement, so
attaching a different app later starts from an unticked box rather than
inheriting a yes you gave about something else.

### The link back

The app's own shared page gains a small line above it: **Made with**, the
blueprint's name, and a **Set up your own** button pointing at the blueprint. It
only appears for people who could already open that blueprint's page, so a
workspace-only blueprint stays invisible to strangers holding the app link.

One thing to know before attaching. If the blueprint is readable by anyone with
the link but not listed, that line still shows its name and links to it, so
anyone you send the app link to can follow it. If the app link ends up
somewhere public, the blueprint is effectively advertised there too. The way to
undo that is Remove, not relisting the blueprint.

An agent asking to publish a blueprint can name one of its own apps as the
example, and the card shows the app by name rather than as a raw link. It
cannot turn on showing it, and neither does approving the publish. That tick is
always yours, from the blueprint's page.

## Installing one

Follow the link and choose to use the blueprint. If you are not signed in you
are asked to first, and you come back to the same blueprint afterwards rather
than landing on your home screen.

If you are already signed in, the blueprint opens inside Bolter, in the same
window you were using. That holds wherever you tap the link: in a chat, in the
installed desktop app, or in the iPhone app.

If you belong to more than one workspace you are asked which one it should go
in, because the agents and the standing jobs are created there. You can pick
any workspace where you can create agents; the rest are greyed out, with the
reason. The question is asked on the blueprint itself, so you can go back to
reading it. A member's setup chat has no admin in it, so access only an admin
can approve is asked for in a chat with one.

Either way a **new chat** opens with your assistant, and it posts **one card**
there. Setting a blueprint up gets its own chat rather than landing in the
middle of whatever you were last discussing with your assistant. The chat is
named for the blueprint, so you can find it again later even if you close the
card without answering it.

That card is the whole setup in one place: what the blueprint builds, anything
about it you should know before starting, which workspace it is going into, the
agent that will be created, and the blueprint's own questions.

The questions arrive with answers already in them wherever your assistant could
work one out from what it can see, marked so you can tell those apart from
anything you typed. Read them, change what is wrong, fill in what is blank, and
press **Create**. That is the only tap.

Nothing is built by following the link, and nothing is built by reading the
card. Your assistant cannot create agents, jobs or schedules on its own, so
until you press Create the only thing that has happened is a conversation.

Pressing Create creates the agent, hands it your answers and starts the build.
The agent is one the blueprint itself names, not a throwaway set-up helper: it
builds the rest of the blueprint and then stays as part of it. Because your
answers travel with it, it will not ask you the same things again.

The build happens in that agent's own chat, not in the one you pressed Create
in. Your assistant cannot follow it there, so its card closes with a button
straight into the new chat. Open it if you want to watch; you do not have to.

In that chat the agent puts up a card of its own and ticks it off as it goes,
so there is one place showing how far along the setup is. When it is finished
the card says so and links to whatever is worth opening first. The agent builds
the setup, checks its own work, and starts the first cycle, so the chat is not
silent while you wait for a schedule to come round.

The one exception is a blueprint that was never published. If someone sent you
the file itself rather than a link, there is no published copy to work from, so
your assistant offers you the agent to approve in the usual way and asks you to
paste the file into that agent's chat to get it going.

If part of the setup cannot be built, the agent's card says "Needs attention"
instead of showing a plain success, and lists what is missing and why.
Everything that did get built stays on the card and stays usable. Retry asks the
agent to pick up just the missing pieces, and Copy error puts the details on
your clipboard to send to us.

If a blueprint was published, the agent also records the install against it, so
the people maintaining it can see how many workspaces run it and which version
they took. Nothing about your workspace's contents is sent back.

Once it is running, the agent ends every reply with next-step buttons: one to
three things it could do from where you are, such as emailing someone when a
sentiment shift is spotted or adding a publication to watch. Pressing one
sends that request as your own message. They are always things the agent can
do, so when it is waiting on you instead, to approve access it asked for, say,
you get no button for that. See [Agents, ownership, and visibility](https://bolter.chat/help/agents) for how the buttons behave; tell the
agent if you would rather not have them.

## Setting one up when you are new to Bolter

When you first set up your account, Bolter offers you a handful of ready-made
blueprints rather than a blank box. These are picked by the Bolter team, not
ranked by popularity, so they are the ones worth starting with.

If you connected an app on the previous step, the blueprints that use it come
first, marked "Works with your Notion" or whichever app it was.

A blueprint that needs an app you have not connected is dimmed and says so, for
example "Connect your LinkedIn to use this". Tap it and the connect window opens
right there. You do not lose your place.

Once you pick one, Bolter asks that blueprint's own questions one at a time, with
a couple of example answers to choose from if you would rather not type. On a
question your agent is allowed to settle itself, there is a button that hands
that one to your agent instead, and handing it over counts as answering it.

### Optional connections

Some blueprints can use one of your connected accounts but do not need it, and
they ask about it the same way, as a question with the tools it works with
offered as answers. A blueprint that reads your accounts, for example, might
offer your CRM, or a place for things to land such as this chat or your email.
Every one of these questions has a plain answer that needs nothing connected,
such as pasting a list yourself or having results posted back in this chat, so
you can always set the blueprint up now and connect something later. Pick the
tool if you have it, pick the plain answer if you do not, or hand the question
to your agent to settle. Whatever you choose, connecting is done after the
setup finishes, in the chat it creates, so nothing you have to link holds up the
build. If you pick a tool that has to be connected, your agent opens the connect
window for it there and tells you which ones are still waiting on one tap.

"Set it up" stays off until every question has either an answer or has been
handed to your agent. Nothing gets built on a question you meant to come back
to, and the line beside the button tells you how many are left and which one to
start with. Tap that line to jump straight to it.

A question that needs a website, such as your product's homepage, checks what
you type: a name instead of a site shows "Enter the company's website, like
example.com" and holds the button. A bare domain like example.com is fine.

The slides are the asking, so there is no card and no assistant in between.
"Set it up" creates the blueprint's own lead agent, hands it your answers and
starts the build, and you land in that agent's chat watching it happen on a card
it ticks off as it goes. It will not ask you the same things again, and a
question you handed to it is one it settles and tells you about rather than one
it puts back to you.

If none of them fit, "Describe what you are working on instead" takes you to the
open prompt and builds an agent around whatever you type.

### When the blueprint carries a finished app

When saving an app that runs flows as a reusable blueprint, its checks must
include a run of one of its flows. A build or a page loading is not enough.
If that check is missing, saving the app is refused and your agent must add it
to the blueprint's work copy. This does not mean the flow has already passed;
the installing agent still needs to run the checks.

Some blueprints ship the app itself rather than a description of one (see
"Installing one that carries its app" on the Blueprints that carry an app page). Media Monitor is the first written
this way. Where its finished app has been made available in your Bolter, picking
it on your first run installs that app onto your agent's computer instead of
having the agent build one: the dashboard opens in seconds, your first-run
answers are already filled in as its settings, and its first
news sweep runs as a process you can follow step by step, the same way any
other process shows its runs. Where the finished app is not available, the
install cannot use it and your agent tells you so rather than guessing.

Website Report is another first-run blueprint that carries a finished app. It reads what
your customers hit from an analytics source, folds it into a ranked list of what
went wrong, has a person decide what to fix, and checks the fix held. It needs
PostHog or LogRocket connected from Integrations before it can read anything: on
a fresh install the board says plainly that nothing is connected yet, rather than
showing an empty dashboard, and it starts working the moment you connect a source
and approve the desk's request to read your session and error data. When you connect
a source your agent adds a single line to the app so it can read your analytics for
you, and until that line is in place the board says the source is connected but not
yet readable. Alongside the ranked list, a Recordings page shows every session
recording the desk pulled, scored and written up, with a link to the second something
went wrong.

Competitor Scan is the third. You give it one link, your product or a key
competitor, and name the rivals you know or let it find them from your page. On
the cadence you chose it reads each company's pages and the web, and
screenshots each homepage. It leads with how each company positions itself, who
it sells to and what it offers, so it fits any business. The board shows only
what moved, with the page it came from and a stance on each change; what
happened (releases, launches, funding, news); each homepage next to yours; and
a side-by-side of every company on every field. Buttons on each change hand it
to your agent, such as drafting a response. Remove drops a company that is not
a real competitor until you add it back.

Signals Desk is the fourth. It watches the trade press for buying signals at the
accounts you sell to, changes in leadership, funding, expansions, new systems,
and scores each one out of ten so your agent hands a rep a short list of who to
call this week rather than a pile of articles. It can use your CRM to match
signals to accounts you already track, and it can post the queue wherever your
team looks, but it needs neither: paste an account list and read the queue in
this chat and it works from the first scan. You choose both when you set it up,
and either one can be connected later without holding up the build.

Research Wire is the fifth. You tell it what field to watch, anything from
frontier AI to battery chemistry to tech policy, and it reads that field every
morning: arXiv categories, an OpenAlex search, and any RSS or Atom feeds you
name, which is usually where the news actually breaks. It scores what it finds
on whether the field MOVED rather than on whether something was published, and
writes a short brief of what did, three lines each, naming the items behind
every one. A quiet day is published as a quiet day with the numbers rather than
padded, and a morning it did not finish reading is labelled a partial read,
which is a different thing. Nothing is posted to your chat until you approve it,
unless you say at setup that nobody needs to. Your team can reply to a brief
with a prediction, and it goes on a scoreboard: a claim without a stated
confidence, or without a date it can be settled on, is refused out loud rather
than filed with a number nobody chose. If you point it at a published dataset,
it plots that behind the brief and stamps every point with the file it came
from, so a line on the chart is something you can check.

See also [What agents can do](https://bolter.chat/help/agents-what-they-can-do) and [Who can see what](https://bolter.chat/help/access/who-can-see-what).

### Understanding a blueprint before you start

Blueprints can include a plain-language explanation showing what you provide,
what Bolter takes care of, and what you receive. It can also explain when the
work runs and which decisions stay with you. Example results are labelled as
illustrations; they are not live activity or a promise of particular results.
The visual path connects your inputs to the work and its results. The setup details remain available further down the page.

Platform administrators can author this explanation in **Page explanation and
example** inside the blueprint editor. Changes join the blueprint draft and use
the existing Save and publication process.

Blueprint explanations can show an animated blue path from your inputs to the
results. Connection icons may rotate through the available provider choices.
These examples do not connect an account or grant access. Administrators can
set the icons and the optional label for other providers in **Page explanation
and example**. The animation respects reduced-motion preferences.

On the landing page, **Get started** scrolls to the **Sign up** button at the
bottom of the page, which opens the sign-in screen. That screen takes your
email: while the day has places left, a sign-in code is sent and signing in
creates the account; once they are taken, it confirms you are in the queue. It
does not start a blueprint or connect a provider. Visitors who already have an
account receive a sign-in code and continue to sign in.

Landing examples animate the result as the work progresses: findings appear,
your decision is recorded, and the next check updates the dashboard. A small
**In your Bolter chat** excerpt shows the messages behind those changes. These
are illustrative examples with time condensed; choosing reduced motion shows
the completed example.

Source: https://bolter.chat/help/blueprints