Make apps and agents on your Mind fast

What the Mind already does for you

Your Mind is your team's shared Mensara workspace for saved information and work. An installed app is a program that does a defined job there on a schedule, with its own access and model budget. People and installed apps share the same server, so the Mind keeps them apart in four ways. You do not need to set any of these up.

• People go first. Installed apps are served by a separate, lower-priority process. When someone on your team is active, background work waits briefly so their reads, searches and approvals are answered first.
• Apps can share the scheduler safely. The scheduler runs one app at a time unless your Mind's operator allows more. When it does, a built-in governor lowers that number while the server is busy, while people are waiting and during working hours. This is a server setting, not part of an app's own settings.
• Saving answers quickly. When an app proposes a change, the Mind replies as soon as the change is accepted. The feed and review cards can update a moment later.
• A spent allowance pauses catch-up work. If a model call is refused because the model allowance is used up, extra catch-up runs pause for a short time instead of failing again and again.

These behaviours are in Mind release 0.20.12 and later. Check your version if you are not sure which release your Mind runs.

Read in fewer calls

Most slow agent sessions spend their time on many small round trips: one search, then one read per file, then one check per change. Ask your connected agent to work in batches instead.

• Find, then read many. Use find to list the records that match a name, email, ID or filter, then read_many to read up to 20 of them in one call. Use mode: "head" when the first part of each record is enough.
• Name the zone. A zone is an area of your Mind with its own access rules. A search limited to one zone is much faster than one across the whole Mind.
• Search for words, not fragments. Search patterns should contain a word of at least three characters.
• Review in a batch. Fetch up to 25 proposals with one get_proposal call, and ask the review queue to include their content, instead of opening each one separately.

Save in fewer calls

A proposal is a suggested change to saved information. Each proposal goes through the Mind's checks once, so one proposal with several files is faster than several proposals with one file each.

• Put up to 20 file changes, up to 1 MiB in total, into one propose_write.
• Collect the facts a conversation produces and save them together at the end, rather than checking and saving each one as it comes up. check_write is a dry run; you do not need it before every save.
• Say what kind of change each file is: create, edit or append. A change that replaces a whole existing file can need the owner's review, which is slower to land.

Make an installed app finish its work quickly

Build installed apps with the app-engineer skill, as described in Build a governed AI agent. These are the speed habits that matter most once the app works.

• Run model calls side by side. An app can have several model calls in flight at once; four is the usual limit. Give each concurrent call its own gateway connection. Calls that share one connection wait for each other, even if your code starts them on separate threads.
• Always set a maximum response length. The Mind only starts a model call when the worst case of every call already in flight still fits the app's budget. A call with no max_tokens reserves a very large worst case, so other calls queue behind it. Set a realistic limit and size the budget so the calls you want can overlap.
• Prepare the next item while the model works. Read and prepare input on the main thread while model calls run on worker threads, so neither waits for the other.
• Keep going while there is work. The scheduler normally starts an app every few minutes. When a run stops with work still waiting, the app can ask for another run straight away. The scheduler limits how many extra runs it starts, so a busy app cannot take over the server.
• Stay well inside the time limit. A single run is stopped after 120 seconds and counts as a failure. Work in small pieces, save your place after each one and stop with time to spare. The next run continues where this one finished.
• Write cards in batches. Group results into proposals of up to 20 changes, and save the app's own progress file at most every few seconds rather than after every item.
• Use events instead of polling. When one app's result should start another, post an event and give the second app an event trigger. It then runs when there is something to do, not on a timer that mostly finds nothing.

Measure before you change anything

Time a call on its own before deciding it is slow. Calls made at the same moment share the Mind's processing time, so each one's measured time includes the work of the others. A parallel test can make a fast call look slow.

Compare the same job before and after a change, on the same data. Check that the result is still correct, not only that it arrived sooner. Usage, budgets and costs explains where an app's model spending is recorded.

Limits that still apply

Speed changes nothing about access or review. An app reads only what its permissions allow, a held proposal still waits for its reviewer, and a model call still counts against the app's budget. Running more calls at once uses that budget faster, so set limits you are content to spend.

Ask the owner to raise an app's budget if a faster app reaches its limit sooner than planned. Control agent autonomy, budgets and access explains who can change these limits.

Related

Build a governed AI agent · Control agent autonomy, budgets and access · Understand usage, budgets and costs