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.

A blueprint is a single file that describes a working setup: the agents, the chat they sit in, their standing jobs, their schedules and whatever they produce. It is how you bundle up your agents and their routines so somebody else can reuse them: written out of a workspace that already works, handed over, and set up again from scratch.

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. Answering those is what turns a generic file into your blueprint. 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.

Who can change a blueprint

A blueprint belongs to the workspace it was written in, and the people who can administer it are that workspace's owners and admins, plus whoever published or wrote it while they are still a member. That is who 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 that is listed 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.

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.

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.

A blueprint can carry the app itself

If your blueprint builds a web app, it can ship the finished app rather than a description of one. Ask your agent to make the blueprint carry the app it built, and it takes the app on your agent's computer, lifts out everything that is specific to your own setup (the market it watches, the list it starts from, the schedule it runs on) into one settings file, and stores the rest as it is.

What changes for the next person is the whole point. Installing that blueprint writes the working app straight onto their agent's computer and applies their answers as its settings, instead of their agent building it again from a description. It takes seconds rather than the best part of an hour, and two people who install it get the same app rather than two interpretations of one.

Two things are worth knowing before you ask for it:

• The app is checked before it is stored, and the check can refuse. Anything that should not travel to somebody else's copy stops it: a password or API key written into the code, an address that only works on your machine, a colleague's name or email. Your agent is told the exact file and line, fixes it, and tries again. This is the common reason it takes an extra step.
• It has not been installed anywhere yet. Storing the app is not the same as proving it works for someone else, and your agent should say so rather than promise more. The first real install is still the first real install.

If the original deliberately left something for each person to fill in, that travels too: the install tells the new agent which file and exactly what it has to do, rather than leaving it to guess.

Installing a blueprint that carries its app starts the app first and lets the rest of its files finish arriving in the background, so the page is up sooner. Your answers from the install questions are applied as the app's settings before it starts. If a schedule you gave is not a real schedule, the install stops and says what to change, rather than setting up an app that never runs.

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.

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.

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 also gets its own mark, drawn from its headline once it is published, and that is what you see on it when browsing, on its page, and in the preview when its link is pasted somewhere that shows one. It is drawn once, on its own, with nothing to choose and nothing to upload.

Before that mark arrives, a blueprint can carry a simple icon instead: the agent that writes the blueprint picks one from the same small set an app chooses from, so a blueprint about watching the news gets a bell and one about research gets a magnifying glass. Ask an agent to change it and it edits the blueprint, the same as changing the headline. A blueprint with neither a mark nor an icon, including anything published before either existed, shows a small generated pattern unique to it, so no two in a list look alike.

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), 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. It used to open a second copy of the app on the desktop, and a browser page on the phone, which meant signing in again to do anything with it.

If you run more than one workspace you are asked which one it should go in, because the agents and the standing jobs are created there. You only see that question when there is more than one answer, and it is asked on the blueprint itself, so you can go back to reading it if you are not sure yet.

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 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.

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

Some blueprints ship the app itself rather than a description of one (see "A blueprint can carry the app itself" above). 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 answers from the first-run questions 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.

Competitive Radar is the third. You give it one link, your product or a key competitor, and name the competitors you already know or let it propose them from your page for you to confirm with one click. On the cadence you chose, your agent reads each tracked company's pages and the board shows only what moved, with the page it came from, a stance on each change, and a side-by-side of every company on every field with you in the first row. A fresh install with nobody tracked yet asks who the radar should watch rather than showing an empty dashboard, and the first sweep starts the moment you track someone.

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 and 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, Request access scrolls to the email box at the bottom of the page. It accepts your email and confirms when the request is received. It does not start a blueprint or connect a provider, and nothing is asked after the confirmation. Already eligible visitors receive a sign-in code and can 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.