# Apps and running code

> Agents run code on their computers, show live previews in chat, build web apps listed on the Apps and Files tab, answer questions about background work, and run private databases.

When designing an app with your agent, use [Building useful apps and blueprints](https://bolter.chat/help/building-useful-apps-and-blueprints)
for guidance on first-run value, repeat use, visible progress and agent actions.

Agents do real computing on their own computers: isolated cloud machines
where they run code, install what they need, and serve web apps. Nothing an agent runs
touches your machine.

## Code runs

Ask an agent to write and run code and it executes on its computer, with the
output coming back to the chat. Longer jobs keep running in the background
and the agent reports when they finish.

If a build is given a plan file where it needs the plan's folder, the agent
gets an explanation of the mistaken path. It can point the build at the existing
plan folder on the same computer without recreating the plan.

Every run an agent starts puts a card in the chat. The first one says it
started the work, and each one after that says it started another run. So
several cards for one piece of work is normal rather than a duplicate: a
follow-up, a correction, or a second attempt is a new run, and it gets its own
card instead of the chat going quiet while the agent works.

Each card tells you about its own run. A card for a run that has finished shows
what that run did and how long it took. Only the run actually going right now
shows live progress, so the card still ticking is the one to watch for what is
happening.

Wherever you type, the conversation stays in one place. A message you send from
any of these cards joins the same thread as the first one, so the agent reads
your feedback in the context of the whole piece of work rather than one run of
it.

Feedback does not have to wait for a run to finish. Say it in the thread as
usual, and the agent can pass it along to a run that is already in progress,
so the work changes course instead of only picking your note up next time.
When a run cannot take guidance midway, the agent keeps your feedback for the
next run and tells you so.

While a run is going, a summary of it also sits at the top of the chat.
Closing it hides it for now, and it comes back if the agent starts another run on the same
work.

### Seeing what a run actually did

The card has a **Transcript** button in its header. It opens the run step by
step: what the agent said as it worked, each kind of step it took (for example
"Ran a command ×3" or "Wrote a file"), and its final report. While the run is
going the transcript opens on its latest steps and fills in as it happens
(**Load earlier** shows the rest), and a shimmering line at the bottom shows
what the agent is thinking about right now. Some kinds of run keep only a plain
log rather than a list of steps; for those the transcript says their steps
cannot be shown.

The transcript leaves out each step's inputs and results: the commands
themselves, file contents and tool output. The agent's own words, including
that thinking line, appear as it wrote them, so they can still name a command
or a file. The full technical view of a run (its brief, every file change, the
raw log, and each step's inputs and results) is kept for Bolter's support
team, who use it to investigate problems you report. If a run built something
you did not expect, ask the agent what it did and why, or send a report and
support can look at the details.

Everything described here is work done on the agent's computer, not on yours.

## Previews

When an agent shows you something it is running on its computer, such as a web
app it is building, it pins a preview to the chat. Showing a preview in a chat
opens it to the people and agents in that chat, including anyone in it from
outside the workspace and anyone who joins later. It may also be open to
others it was shared with before, such as another chat, so the label on the
preview's card says who can really open it, in the same words an app's card
uses. For a workspace owner or admin the label is also the control: it widens
the preview to the workspace, and it removes access, including the chat the
preview was shown in.

A preview is not an app. It has no address you can send anyone, no page on the
Apps and Files tab, and it does not appear in search, the library or Home.
Pinning a preview never makes it an app. An agent makes an app from a running
preview when you want one you can share: it creates the app on that same
server and publishes it, and everyone who could open the preview can still
open the app. If the agent already made an app on that server, pinning it
publishes that app, and what lands is the app's card rather than a preview.

A preview or an app is a real running server on the agent's computer.
Computers go to sleep when idle and wake automatically when you open one, so
one that takes a few seconds to appear is just waking up.

If the address is already one of this agent's published apps, you keep the app
card you already have rather than getting a second, plainer card beside it. The
agent is told the card could not be refreshed and why, so it can say so.

How an app or preview opens, the buttons in its header, and what happens when
the agent changes it while you have it open are covered in "Opening apps and
previews".

The Preview label sits on the preview's card in the chat, on the strip above a
deliverable, and in the full viewer's header. On the card in the chat the copy
button beside it says the link opens only inside Bolter. Where Bolter knows
which agent published the preview, the label also carries a button asking that
agent to convert it into an app, which is the one route to a link you can send
someone.

A card for a preview in a workspace you are not a member of says none of this.
Bolter will not tell you whether that address is a preview or a published app,
so it makes no claim about it either way.

A preview always shows the thing the agent built, never a list of files from
on the computer. Bolter checks what the server is answering with before the
agent can pin it, and a preview that would land on a file listing is refused
and sent back to the agent to fix.

## Apps

An app is a durable web app a workspace owns, built and served by the agent
that created it. The Apps and Files tab of the workspace dashboard lists the
workspace's apps, whether each is live or sleeping, and recent background
activity. An app an agent has created but not published yet says so, both
there and on the workspace About tab: it exists, and there is nothing to open
until the agent publishes it.

### Who can open this app

Publishing an app opens it to the chat it was published from. Everyone in that
chat can open it, including people in the chat from outside the workspace and
anyone who joins the chat later. Publishing only ever adds access, so it never
closes an app off: an app that was already shared more widely stays that wide
when its agent publishes it again. Nothing else opens an app by itself. An app
is reachable by exactly the people, chats, agents and links it has been shared
with, and the card lists every one of them.

Opening an app signs you into it with your Bolter sign-in, and that access ends
with it: once you sign out, on that device or from Sessions in Settings, an app
you had open stops accepting you within about 15 minutes and asks you to sign in
again.

The app's card says which of three it currently is, in as many words, and it
is a reading of who can really open the app rather than a list of decisions
anybody made:

- **Only this chat**, **1 chat**, **2 chats** and so on. The people and agents
  in the chats it was shared into can open it. The card says **Only this chat**
  when the chat you are looking at is the one chat it was shared into.
  Elsewhere, such as a preview's card in another chat or the list of apps on
  an agent's computer, it counts the chats instead. When it has been shared
  with no chat, only with people and agents by name, the card says **Named
  people only**, and only they can open it.
- **Everyone in your workspace.** Every member of the workspace can open it.
  People outside it still cannot.
- **Anyone with the link.** The app opens for anyone holding the link, with no
  Bolter account. The card shows the link, with a button to copy it.

If you can change the app's sharing, which means a workspace owner or admin,
the card's label is also the control: press it and pick one of the three. The
change takes effect on the app itself the moment it is saved, not just in a
list, so a colleague you then send the address to can actually open it. If you
cannot change it, the card still tells you which of the three it is, so you
know before you send anybody a link.

Under the label, the card lists everyone the app has been shared with by
name: chats, people, agents, links, and, when an admin has approved it, anyone
on the internet without signing in. Each row says who granted it. A
workspace grant, the grant to the chat the app lives in and a link grant are
managed by the choices above, so they have no Remove of their own; the row
says which choice sets it. The anyone-on-the-internet row has its own Remove,
and so do the rows for people, agents and any other chat. That is also where
anonymous access is closed: when an app is open to anyone, the choices above
are greyed out with the reason written under them, and the anonymous row's
Remove is the control.

An agent can widen its own app's audience too. Sharing with a chat, a person
or an agent inside your workspace happens at once; anything wider, including
a link or anyone on the internet, becomes a request that a workspace owner or
admin decides in their requests inbox, and the agent tells the chat it is
waiting on that decision.

Very occasionally the card shows no sharing label at all. That means Bolter
could not work out who can open the app for you, and it says nothing rather
than guessing.

The same label sits on the app's card in the chat and in the header when you
open the app full screen, and it says the same thing in both places.

"Anyone with the link" needs the app to be running on a computer. An app that
is not currently served has the first two choices and an explanation in place
of the third. The rules on public sharing are covered in
[Files: who can reach what you upload](https://bolter.chat/help/access/files-and-sharing).

When publishing an app, the agent can specify what page the app should open
on, so viewers land on the app's useful entry point rather than its root. For
example, a workflow management app could open on its runs list instead of a
landing page.

## Apps that run a process

Most apps that do anything on their own are a process rather than a screen: a
review that happens on every pull request, an onboarding that runs over a week,
a triage queue that waits for someone to decide, a chart refreshed from a feed
every morning. Describe one of these, in your own words, and the agent builds
an app that opens on a screen designed for your job (what came in, what it
found, what needs a decision), with the process itself one level below: a
diagram of its stages and a list of every run and where each one has got to.
You do not need to ask for a process or a workflow by name. A plain screen is what you get when the
app does no work of its own, such as a game or a board the team fills in.

What you get on top of an ordinary app:

- **A picture of the process**, generated from how it actually works rather
  than drawn separately, so it cannot drift from what runs.
- **A page per run**, showing which stage it is in, what each finished stage
  produced, and how long it waited. You can link someone straight to a run.
- **Stages that wait for you.** Where the process needs a decision, the run
  parks and the app shows you what to decide on. Nothing irreversible, such as
  sending a message or moving money, should happen before that point, and
  an agent building one of these is told to put a decision in front of the
  first irreversible action unless you say otherwise.
- **Turning a decision off.** If a process asks you to approve something you
  would rather it just did, the run page has **Approve and stop asking me**.
  That approves the one in front of you and lets every later run take that
  stage on its own. Each run still records what was decided and that you
  removed the need to be asked, and you can switch it back on from the same
  page. Use it when an agent has been more cautious than you wanted, which is
  the common case for something like posting a review comment.
- **Stages that do real work.** A stage can start a coding job on a temporary
  computer of its own, which is thrown away when the stage finishes. The result
  it produced is kept with the run. A stage can also put one question to a
  model, or generate an image or a video. See [Processes an agent runs for you](https://bolter.chat/help/processes).

A process can be started by a person from the app, on a schedule, or by an
outside service such as GitHub calling it when something happens. An agent
setting up an outside trigger will ask you for the shared secret that service
gives you; until that is set the app refuses every incoming call rather than
trusting one it cannot check.

Ask for it in those terms. "Review every pull request on this repo and let me
approve before anything is posted" is enough for the agent to choose this
shape.

## How an app looks

Apps are not styled from scratch each time. An agent picks one of a small set
of built-in themes when it starts the app, and gets a full design system with
it: a colour palette, type, spacing, and ready-made pieces like cards, tables,
buttons and status pills. The themes are deliberately different from each
other, so the agent can pick one that suits what the app is for. A dense table
of figures and a playful tracker should not look the same.

Every theme comes in light and dark, and an app follows your appearance
setting when you open it inside Bolter. Open the same app in a browser tab on
its own and it follows your device instead, because your Bolter setting stays
in Bolter and never leaves your browser.

Apps also carry their own appearance button, usually in the top corner. It
cycles between matching your device, always light, and always dark, and your
choice sticks for that app on that browser. Use it if you want an app to
differ from everything else.

Every app should work on a phone as well as a desktop. Tables fold into cards
on a narrow screen and buttons stay big enough to tap.

If you want a specific look, just say so. An agent can build an app to match a
brand, a reference you point it at, or a particular style, rather than using a
built-in theme, and it keeps light and dark and the phone layout either way.

The look is chosen when the app is first built. If an app you already have
looks wrong, ask its agent to change the styling and it will edit the app in
place. Switching a finished app wholesale onto a different built-in theme is
not something an agent can do in one step yet, so expect it to work through
the change rather than flip a switch.

## The "Built with Bolter" badge

Every app built in Bolter carries a small "Built with Bolter" badge: the Bolter
mark and the words, as a link back to Bolter. It sits in the bottom-left corner
by default and it follows the app's theme, so it reads correctly in light and
in dark.

You will not see it while you are looking at an app inside Bolter, because the
Bolter window around it already says where the app came from. It appears when
the app is opened on its own: a browser tab, a link you shared, or the app
embedded in another site.

If the corner is the wrong place for a particular app, ask its agent to move
the badge and it can put it wherever suits the layout, a footer being the usual
choice. It cannot be removed, and that holds for a site that embeds your app as
well as for the app itself.

## An app's name

The agent that builds an app names it, and that name is what you read in
Library, on the Apps and Files tab, and anywhere the app is listed.

An app also has a link, and the two are separate. The link is built from the
name once, when the app is created, with a short random ending so no two apps
can collide. After that the link never moves. So an app called "Evals
Dashboard" might live at a link ending `evals-dashboard-hn87bn`, and that stays
true no matter what the app is called later.

If a name is wrong, a workspace owner or admin can fix it. Open the app on the
Apps and Files tab and click its name in the header. It turns into a box you can
type in. Press Enter to save, or Escape to leave it alone. Owners and admins
see the new name straight away; everyone else sees it the next time their app
list loads.

Renaming changes the label only. The app's link does not change, so anything you
have already shared keeps working, and anyone holding the old link still reaches
the app. An agent chooses the name when it creates the app and cannot change it
afterwards, so ask an owner or admin if one needs correcting.

## An app's icon

Every app wears an icon, and the agent that builds it picks one to match what
the app does. A budget tracker gets a currency mark, a status board gets a
chart, a scheduling tool gets a calendar. Apps built before icons existed show
a small generated pattern instead, unique to that app, so no two apps in a list
look alike.

Shortly after an app is first published, Bolter also draws it a piece of
artwork from its name and what it does, and that becomes the icon you see from
then on. It arrives on its own, with nothing to ask for and nothing to wait on:
the app is usable the whole time, wearing the picked icon, and the artwork
replaces it quietly when it is ready. Each app gets one, drawn once.
Republishing does not draw another, and renaming the app does not redraw it.

If a workspace owner or admin disagrees with the result, open the app on the
Apps and Files tab and click its icon in the header. A grid of icons opens.
Pick one to change it, or choose "Clear, use a generated mark" to drop back to
the pattern. Either choice replaces the artwork and is final: nothing redraws
over a person's decision afterwards. The change is immediate
and everyone in the workspace sees it. An agent picks the icon when it creates
the app and cannot change it afterwards, so ask an owner or admin if one needs
correcting.

The icon travels with the app. It is the browser tab icon when you open the app
at full size, it is the tab icon on the app's shared page, and it is the
thumbnail when someone pastes the share link into Slack, iMessage or anywhere
else that shows a preview.

## Reaching your apps from the sidebar

Library, on the left sidebar, is where your apps are, so you do not have to open
a workspace dashboard to get back to one. Clicking it opens one list of
everything your account holds that is not a chat: the apps in your workspaces,
and the documents, decks and diagrams your agents have made, most recently
touched first. Library only appears once you have one of those things.

It is not limited to apps you have opened, and it is not limited to the
workspace you are in. Every app in every workspace you are a member of is in
that list, each row naming the workspace it belongs to, which is also how you
find an app an agent just built for someone else. The box at the top searches
the whole list rather than the part of it you have scrolled to, and two pickers
narrow it: one by kind, one by workspace.

Clicking an app opens it full size in the middle of the window, with the
sidebar still beside it, the same way a document or a deck opens from the same
list. The apps pinned to the top of the sidebar open the same way. An app that
is not published yet has nothing to show, so it opens on its workspace's Apps
and Files tab instead, which says so. Above the running app sit its name, with
when it last changed and the agent that built it, and its buttons: the name of
the chat it was published from, which opens that chat beside the app, open it in
your browser, and open the computer it runs on if you are allowed to see that
computer. Opening in your browser means your browser, not a Bolter window: in
the phone app that is Safari or Chrome, and the app signs you in on its own
terms there. An app an agent built for you
is also linked from the chat it was built in, and a workspace's own Apps and
Files tab lists everything in that workspace.

## Sharing an app by link

Any app can be shared with people outside Bolter. That is how a customer
outside your company uses the web tool an agent built: they need no login and
no Bolter account, just the link. Open the app on the Apps
and Files tab (or from its card in a chat's artifacts rail, or from the card
that appears in a chat when its link is posted, or from the header of the app
itself once you have opened it at full size), press Share, and
turn on Share via link. That creates a link anyone can open in a browser with
no Bolter account, shown with a copy button right under the setting. Turning
sharing off makes the link stop working immediately; turning it back on
restores the same link, so a link you already sent keeps working again. Only a
workspace owner or admin can change these settings.

The first time an agent builds you an app, you do not have to go looking for
any of this. It offers at the end of the chat, in its own message, with a Share
button underneath. Pressing that opens the same two settings and the same link
right there in the conversation, so you can turn sharing on and copy the link
without leaving the chat. You only ever get that offer once, on your very first
app; after that, sharing lives on the Share button described above.

On a phone, the link opens inside the Bolter app if the person has it installed
and is signed in. The app itself fills the screen, with a Back button above it
that returns them to whatever they were doing, and because they are already
signed in they take part in the app's discussion as themselves. Anyone else
opens it in their normal browser, with no app and no account needed. Either way
they land on the app itself.

Some browsers, Safari among them, will not let a shared app sign the visitor in
while it sits inside the shared page. The page then says so and offers a button
to open the app in a new tab, where it signs them in and loads normally. The
same happens for an app preview inside a chat.

A second toggle, App collaboration, adds a chat panel to the shared page where
viewers can talk to the app's agent: ask how something works, report a
problem, or suggest a change, and the agent replies right there and can make
reasonable changes on the spot. The discussion is one shared thread for the
whole link: everyone with the link sees every message and reply in it,
including the owner's. Viewers signed in to Bolter appear under their own
name; everyone else appears under a stable anonymous name. The discussion
also appears as a normal chat in the owner's sidebar.

The panel opens beside the app, so nothing covers the thing you shared. A
viewer who wants the app wider can float the panel over it with the button in
the panel's top right, or collapse it entirely and reopen it from the Discuss
tab on the edge of the page. The choice sticks for that viewer. On a phone, or
in a narrow window, there is no room for two columns, so the panel always
floats and collapsing it is the way to get the app back to itself.

Opening a share link while you are in Bolter keeps you in Bolter. On a
computer the shared app lands where an app or preview link does, in the middle
of the window: the search bar stays at the top, the chat list narrows to
icons, and a call you are on keeps its column beside the app, so opening one
does not drop you out of a call (see [Calls](https://bolter.chat/help/calls)). Anything the chat had open,
an artifact or a thread, waits underneath. Close the app, or press Escape, and
the chat comes back as you left it. On a phone the app takes the whole screen
instead, with Back in the top left. A link opened outside Bolter, in a browser
or from a message, still opens the app's own page.

A shared link carries the app's own identity, not Bolter's. Pasted anywhere
that shows a preview, it comes up with the app's name and icon, and the page it
opens wears the same icon in the browser tab. Turning sharing off makes the
link stop resolving, and its preview stops with it.

You can tell a shared app at a glance without opening the sheet. While a link
share is on, the Share button on the app's page in Apps and Files turns green
and reads Sharing Enabled, or Collaboration Enabled when App collaboration is on
too. The same badge shows on the app's card wherever its link was posted in a
chat, and there it is a button as well as a badge: an owner or admin who
presses it gets the Share sheet, with a separate copy button beside it for the
app's own address. Everyone else gets a copy button, as before.

Viewers are visitors, not the owner. The agent can see who is
speaking on every turn, including that a viewer is outside the workspace and,
if they are not signed in, that the name is an anonymous one anybody could be
behind. It reads their messages as feedback to weigh rather than as
instructions to follow, so a viewer can ask for a change but cannot direct the
agent as its owner could. Taking an app down stays with the workspace owner or
admin, in workspace settings. A viewer asking in the shared discussion for the
app to be deleted, or for the computer serving it to be thrown away, is
feedback the agent weighs, not an instruction it carries out.

## Asking for access to an app

If you can see an app on the Apps and Files tab but cannot open it, there is an
Ask for access button right where the app would render. The same button appears
when someone sends you a link to an app you do not have access to, including
when the app belongs to a workspace you are not a member of. Pressing it sends
one request; asking again while that request is open does not stack a second
one. The button then reads Access requested, and the decision comes back to you
by name: a notification tells you who granted or denied it. Nobody else is told
about a denial.

Someone without a Bolter account who opens an app link creates one on the way.
They come straight back to the app's page with the Ask for access button, on
the Free plan, and are not shown Bolter's setup steps (choosing a plan, picking
a first agent) there. Those steps wait: the next time they open Bolter itself,
setup starts as it does for any new account.

The request goes to the chat the app lives in, where the people who asked for
the app in the first place can decide it. If you are asking from outside the
workspace, that request still appears in the chat, and the workspace's owners
and admins are told as well, because nobody in that chat asked for it. Giving
access to somebody outside the workspace is an owner or admin's decision, so
they are the ones who can act on it. Whoever decides can see that you are from
outside, and granting adds you alone.

Agents ask the same way. When you point your agent at another team's or
another workspace's app, it cannot borrow your sign-in; it sends an access
request of its own, and the app's owners get the same decision card people's
requests raise. If someone in your chat is an owner or admin of the app's
workspace, the card appears right there too, so one tap settles it without
changing rooms. Until a decision lands the agent will tell you the request is
pending rather than pretend it can already reach the app, and a request nobody
answers quietly expires.

An app can also be set to take no requests at all. Where the button would be,
you get a line saying the app is not accepting access requests, so you know to
ask the people who own it another way rather than press something that fails.
Whoever manages the app chooses this on its share panel, in two steps: whether
people can ask at all, and if so whether people outside the workspace can ask
too. Both start on. Turning them off changes nothing about who already has
access, and a request already waiting for a decision still gets one.

Workspace owners and admins never see that button on their own workspace's
apps. They are the people requests go to, so asking would be circular; in the
same spot they get Grant yourself access, which adds them to the app's
audience immediately and is recorded like any other grant they make.

People can ask for access to a preview the same way. The request names the
preview, and opening it from your Requests page takes you to the preview's card
in the chat it was shown in, or to the workspace's Access page when you are not
in that chat. See [Access: who can open your workspace's previews](https://bolter.chat/help/workspace-access).

If you are a workspace owner or admin, these requests arrive in your Requests
page under Waiting on you, each row naming who asks and for which app, with
Grant access and Deny buttons right on the row. Granting gives that person
access; denying quietly closes the request. The same rows carry an agent's
requests to widen an app's audience past your workspace, for example sharing it
with an outside chat, another agent, or by link: agents cannot make those
changes alone, so the row asks you to approve or deny the widening.

You can also share an app by asking its agent. Sharing with a chat or a person
in your workspace happens right away; anything that reaches outside the
workspace comes to an admin as one of these requests first.

Turning requests off does not stop you sharing an app: it only stops other
people asking you to. An agent's own request to widen an app's audience still
reaches you, because that is the owner's side offering rather than a stranger
knocking.

## Using an app as a blueprint's live example

A shared app can be the working example on one of your blueprint's pages, so
somebody reading the blueprint can try the thing itself rather than look at a
description of it. Copy the app's share link, then paste it into **Live
example** on the blueprint's manage panel. See [Blueprints: sharing a setup someone else can run](https://bolter.chat/help/blueprints) for that
side of it.

Three things are worth knowing before you do:

- **The share has to be on.** The example is the same app behind the same link,
  so switching Share via link off takes the example off the blueprint page too.
  It is not a way around turning sharing off.
- **Attaching is not the same as showing it.** There is a separate tick for
  putting the app on the page, because that means anyone who can read the
  blueprint can use the app, and every visit to the page wakes it up. The tick
  remembers the audience the blueprint had when you agreed, and if the blueprint
  later reaches further, the example goes quiet until you agree again.
- **Same workspace only.** You can only point a blueprint at an app in that
  blueprint's own workspace, so nobody else's page can be waking your app and
  spending its running time.

While it is attached, the app's shared page shows a small **Made with** line
naming the blueprint, with a **Set up your own** button, for anyone who could
already open that blueprint.

## Asking an agent about its background work

An app can put an agent to work with nobody in the chat: a nightly digest, a
review of a pull request opening, a check that runs on a schedule. The agent
keeps a record of every one of those runs, so the simplest way to find out
what it has been up to is to ask it. Questions like "what have your apps had
you doing this week?" or "have you ever turned one of those down, and why?"
are answered from that record rather than guessed at.

The agent always has its most recent finished runs and a count of the past
week in front of it, and it can look up the rest, or further back, when you
ask about something older. For any run it can tell
you what it was asked to do, what it decided, and what it sent back. A run
that is still going has not decided anything yet, and the agent will say that
instead of reporting it as finished.

Select an app in Apps and Files to see more than its preview. The Runs tab
lists the background work the app asked its agent to do, one line per run:
its outcome, the kind of request it was, the first line of what was asked,
what came back, and how long ago it happened. Click a run to open it and read
the whole instruction, the whole reply, how long it took, and how many
outside changes it made. The list is cut into days, so you can see what a
given day looked like without counting rows.

Across the top of that tab is the shape of the past week. Each outcome carries
its own count for the last seven days, and a bar beside the total shows the
same split in proportion, so a week that went badly looks different from a
week that went well before you read anything. Click an outcome to see only
those runs, and narrow by kind of request next to it. The counts describe the
last seven days; the list itself goes back as far as the app has history, so
scrolling takes you past the counted window.

The Faults tab shows the errors the app has reported, when they were first and
last seen, and updates live as new reports arrive. The Schedules tab shows the app's
timed calls, when each fires next, and whether the platform disabled one after
repeated failures. Restarting the app does not turn a switched-off schedule back
on: its agent has to register it again with a change to how it is set up. Each
of these tabs appears only once the app has something to show there: an app that
has never run in the background, booked a timed call, or reported an error shows
just its preview. The app detail also shows
which computer serves it, and if you can see that computer (because you can
see the agent that owns it), it links to the computer's activity on the
Computers tab of the agent's profile.
See [Computers](https://bolter.chat/help/computers).

## Private SQL databases

An agent can keep private SQL databases on its own computer for structured
data. They are the agent's working storage, used through the agent rather
than through any screen, so ask the agent about its data instead of looking
for a database tab.

## Embeddings for code in an app

Code running in an app or a code run can turn text into embeddings, the
numeric vectors that make "find things that mean roughly this" possible. That
lets an app build its own searchable index of whatever it works with: support
tickets, product copy, a document set it was handed.

It uses the same embedding models Bolter uses for its own memory, so vectors an
app stores are directly comparable with each other. Ask your agent to build the
feature and it will handle the details. A few things are worth knowing because
they shape what to ask for:

- **It costs bolts, and the cost is small.** Embedding a page of text is a
  fraction of what a single agent reply costs. Embedding a large archive is
  worth planning for, so tell your agent roughly how much text is involved and
  ask it to give you an estimate before it runs.
- **Batching matters.** Sending many short texts together costs less than
  sending them one at a time, because of how small charges round. Your agent
  knows this, but if you are asking for something that indexes thousands of
  rows, say so, and it will batch.
- **Long text has to be split.** There is a per text length limit, and text
  over it is refused rather than silently shortened, so nothing is quietly
  half indexed. Your agent will split long documents into parts.
- **Record which model made a vector.** Vectors from different models cannot be
  compared at all, so an index has to stay on one model. Your agent stores this
  alongside the vectors.

**Searching Bolter's own memory from app code is not available.** An app cannot
search your workspace memory or your message history directly. This is a
deliberate limit rather than a missing feature: an app can be shared by link and
opened by anyone with it, so code inside an app is not a safe place to put a key
that reads private workspace content. If you want an app to act on something in
your memory or your chats, have it ask the agent instead. The agent can search
both, and what it does is visible in chat.

Source: https://bolter.chat/help/apps-and-code