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.

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.

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, and on the Tasks card in the left sidebar. Closing the one at the top of the chat 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 Show technical details switch in its header. Turning it on lists every run on that piece of work separately, each with three views you can open:

• brief, the instructions the agent wrote for the run. This is the one to read when a run built something you did not expect: the agent turns your request into its own brief, and that restatement is where a misunderstanding usually is. Alongside it the run is given standing platform instructions, which are not shown here, so a run can also have decided something on its own that the brief never mentions.
• diff, every file change the run made, added lines and removed lines.
• log, the run's own account of what it did, step by step. It updates while the run is going, so you can watch a long job as it happens.

Anyone in the chat can open these. They describe work done on the agent's computer, not on yours.

Previews

When an agent builds something with a visual result, such as a web app, it pins it to the chat. What lands is a published app, not a preview: Bolter names it from the title the agent gave it, gives it its own address, its own icon and a card you can act on. You are not asked whether to publish it, and the agent does not have to ask either.

Publishing it does not show it to anybody new. A newly published app can be opened by the people and agents in the chat it was built in, and by nobody else, which is the same set of people who could open the preview before. Widening that is your decision, made on the app's card whenever you want it. See "Who can open an app" below.

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

You will still see a plain preview occasionally, when Bolter could not make the running server into an app. The commonest reason is that the address already belongs to an app another agent owns. A preview behaves as described at the end of this section.

If the address is already one of this agent's own 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.

Opening an app or a preview link on a computer puts it where the chat was, in the middle of the window. The search bar stays at the top and the chat list narrows to icons to give the app more room. The app itself runs edge to edge in that space, and everything you can do to it sits in the header above it. For a published app that is its address, which you can read and copy or click to open the app in a new browser tab, a button that opens it in a new tab, Refresh to reload it, Share, and Open in workspace, which takes you to the app's own page on the Apps and Files tab, where it opens with the list of apps and files folded away so the app still has the whole pane. Close it with the X in that header or by pressing Escape, and the chat comes back with the chat list as it was. Anything else you open from a chat lands in the same place, whether you open it from the message or from its card in the artifacts panel on the right: a widget, a document, a text file, a diagram, a presentation. On a phone an app fills the screen, with the same header stacked above it. Presenting a deck still goes full screen, since that is the point of presenting.

You may see fewer of those buttons than someone else does. Open in workspace appears only if you are a member of the workspace that owns the app, and Share only if you can change that app's sharing settings, which means a workspace owner or admin. Refresh is always there.

A preview that is not a published app shows none of the address controls. It carries a Preview label next to its name instead, and only Refresh beside it. This is now the exception rather than the rule: an agent pinning a running server gets an app, and a preview means Bolter could not make one. A preview runs on the agent's own computer and opens only for you, here in Bolter, so its address is not a link you can pass to anyone: sending it to a colleague gets them nothing. Point at the Preview label and it says so, and offers the one route to something you can share, a button that asks the agent in that chat to convert the preview into an app. The agent replies in the chat as usual, and once it publishes the app you get the address, the new tab button, Share and Open in workspace with it. The preview's card in the artifacts panel agrees with all of this: it offers Refresh, but no way to open the preview in a browser tab. A published app's card still does.

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 an 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: if the agent that runs the app is one your whole workspace can already use, the workspace can open the app too, from the moment it is published. Nobody had to decide that and nothing was exposed by publishing, but it does mean an app is not private to one chat just because it was built there.

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. The people and agents in this chat can open it, along with your workspace's owners and admins.
• Everyone in your workspace. Every member of the workspace can open it. People outside it still cannot. An app served by an agent the whole workspace can use says this even if nobody widened it by hand.
• 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, 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.

Sometimes a choice is there but greyed out, with the reason written under it. That is the honest answer rather than a button that would do nothing. The two cases are an app whose reach comes from the agent serving it, where there is no workspace access to remove and narrowing it here would change nothing, and an app that was approved as publicly reachable for its computer rather than shared from this card, which has to be changed where it was approved.

If a change is applied and then cannot be honoured, the card goes back to what is actually true and tells you so. That matters most when narrowing: an app can stay reachable through the agent that serves it even after you remove the workspace's access, and the card says so rather than letting you believe you closed something you did not.

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.

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.

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 the sidebar, 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

Apps you use turn up on the left sidebar's Apps entry, so you do not have to open a workspace dashboard to get back to one. Resting on it opens the list of apps you have opened, and the apps you pinned sit under it as rows of their own, there whether the sidebar is expanded or narrowed to icons.

Only apps you have opened at least once appear there. Everyone in a workspace can reach all of its apps, and plenty of them are scratch builds an agent made while working on something for one person, so a sidebar listing every one of them would be mostly other people's experiments. Open an app once and it stays within reach from then on. Opening it from its link in a chat counts, the same as opening it from Apps and Files. Until you have opened any, Apps is not on the sidebar at all.

To find an app you have not opened yet, including one an agent just built for someone else, go to Apps and Files in the workspace. An app an agent built for you is also linked from the chat it was built in.

Rest on Apps and the list of your recent apps opens beside it. Every app in it is one you have opened before, and the list follows the workspace switcher: you get the apps of the workspace you are in, each row naming the workspace it belongs to. Clicking a row opens the app on the Apps and Files tab, with the list of apps and files folded away so the app itself gets the whole pane. The list comes straight back from the button on the left edge of the tab.

Each row has a pin button. Pin an app and it gets a row of its own under Apps on the sidebar, the same way a pinned chat sits under Chats, so it is one click away from wherever you are. Pin several and they stack, newest pin first. There is no limit: how many shortcuts are worth keeping is your call. Three fit under Apps at a time, and a last row counts the rest and opens the full list. Unpin from the same pin button, or from the pinned row itself: rest on it and an unpin button appears where the app's icon was. These pins are yours alone: they change what your sidebar shows and nothing about the app or what anyone else sees. Pinning here is separate from featuring an app on your Home page, described next.

Featuring an app on Home

One app per workspace can be featured on your Home page. Open the app on the Apps and Files tab and press Pin to Home. It then takes its own column on Home as a live, running preview, so anyone opening the workspace sees the thing itself rather than a link to it. Pinning a second app replaces the first, and Unpin (on the Home card, or on the app's page) clears the feature. Only a workspace owner or admin can pin or unpin.

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.

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). 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: no request in the shared discussion will get the agent to delete a live app or throw away the computer serving it, whoever it appears to come from. Stopping and restarting what the app is running is still something the agent will do on request, because that is reversible.

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.

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.

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.

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

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.