Frequently asked questions

BM Studio is the canvas. You build and orchestrate agents on it by dragging nodes into place, a Leader Agent decomposes each task and directs the specialist agents under it, and the workflow runs from the same place you designed it. It is built so that the person who understands the work can assemble it, with no machine learning hires required. Where it is the wrong tool is a single call into a model: if that is the whole requirement, a canvas for multi-agent workflows is more machinery than the job needs.

BM Architect is the other way onto that canvas. Describe a workflow in plain language and Blue Mesh designs, tests and deploys it, then generates a demo page and test keys so stakeholders can try the thing rather than read a deck about it. It exists because the usual place an AI initiative dies is the gap between a described use case and something a stakeholder can click. Skip it when you already know precisely what the workflow should do and would rather lay it out by hand, in which case go straight to Studio.

BM Oasis fine-tunes models on your own data, inside your own environment, and the weights that come out are yours rather than licensed back to you. Training teaches a model your domain, your formats and the shape of a good answer in your organization. It does not teach it today's facts, so when what you need is answers grounded in documents that keep changing, start with Enterprise RAG and keep the training budget. Fine-tuning also needs GPU capacity on your side of the boundary, which is a precondition worth settling before anything else.

Enterprise RAG is the capability and Privy AI is the engine behind it. Ask a question and it retrieves the passages that answer it from your indexed data, grounds the reply in what it retrieved, and names the source in the answer. The index is the ceiling: it cannot answer what nobody wrote down, and a wrong document produces a well cited wrong answer. What the citation buys you is that the fix becomes a document edit rather than an argument with a model.

Voice Agents carry real phone calls: low-latency, real-time voice over SIP, with speech-to-text, text-to-speech and speaker separation running as one pipeline on models you own. The agent holds context across calls, so a caller who rings back does not start over, and every decision it takes lands in an audit trail you keep. Routine high-volume call work is carried continuously and your people work the exceptions. What this is not is a metered public speech API you call per request, and if that is the shape you want, we are not it.

No. The modules come apart: you can run Enterprise RAG across your document estate without building agent workflows, or put voice on a line without training a model. Most first deployments are a single workflow, because that is the honest way to find out whether any of this works on your data. What does not come apart is the governance layer, since role-based access and the audit trail are how the platform runs rather than an option on top of it.

Three modes: private cloud, on-premises, air-gapped. What changes between them is not a pricing tier, it is how much of the outside world can reach the system. In a private cloud, Blue Mesh deploys into your own VPC and model weights and inference stay inside your network boundary, with updates on a schedule you agree to. On premises it runs in your data center on your hardware, so your existing physical and network controls apply unchanged, and air-gapped means it runs with no path to the internet at all.

BM in a Box is the platform pre-configured on NVIDIA DGX hardware, racked inside your boundary and running with no outbound connection required. Agents, voice, retrieval and training all run on it. It is the right answer when the data genuinely cannot leave: classified and defense work, regulated finance, healthcare records, national infrastructure. If your data can sit in a private cloud, that is cheaper and easier, and we will tell you so rather than sell you a box.

No. Nothing about an on-premises or air-gapped deployment requires an outbound connection to us for the platform to run. The trade-off is worth stating plainly, because it is the whole decision: an air-gapped install gets no automatic updates and sends no telemetry home, so new models and platform versions arrive as a deliberate, scheduled, reviewable change, and when something misbehaves we diagnose it with your team rather than from a dashboard on our side. A private cloud deployment keeps the same property inside your own VPC.

It depends on the workload, and we would rather specify it with you than publish a figure that turns out to be wrong for your case. Inference for agent and retrieval workflows is the modest end of the range. Fine-tuning is the demanding one, because training runs where your data lives and therefore needs GPU capacity on your side of the boundary. If you do not have that capacity, BM in a Box arrives with it, specified against the workloads you actually plan to run.

You do, and the deployment model is what makes that more than a promise. Your data stays inside the boundary you deploy into, under your own retention rules, and the platform indexes and reads it in place rather than copying it to a vendor cloud. There is no step in which your content has to arrive on our infrastructure for the product to work.

You do. Fine-tune with BM Oasis and the resulting weights are yours, not licensed back to you, and they stay inside the boundary they were trained in. Put this question in writing to every vendor on your shortlist, because the quiet failure mode of enterprise AI is discovering two years in that the model trained on your data belongs to someone else.

In an air-gapped deployment there is no telemetry path and no automatic update channel, which also means we cannot see your usage, your prompts or your failures. On premises and in your own VPC, the same architecture applies to your data and your models: indexing, retrieval, inference and training all run inside the boundary you deployed into. What does cross that boundary is whatever your workflows deliberately call out to, such as a third party API you chose to connect. That distinction is worth being precise about with your security team, because an outbound call from a workflow is an egress path you configured rather than one we added.

Yes, and the unglamorous detail matters more than the principle. Data exports in CSV or through APIs, and configured or custom code is accessible in a Git repository, with the exception of code the platform generates. Because the deployment already runs in your environment, leaving is not a migration out of somebody else's cloud.

Every decision and result, recorded for compliance audit: what ran, what it read, what it did, and who approved it. The log lives in your environment under your retention rules, which is the difference between an audit trail and a view into a vendor's dashboard. On an air-gapped appliance it is written locally and it does not leave.

Attributable, timestamped records of what the system did, retained under your rules inside your environment. Whatever framework you answer to, that is the raw material: when a regulator or a customer asks what happened and why, the answer is on record rather than reconstructed afterwards from memory. We do not claim the log discharges your obligations by itself. It gives the person doing the discharging something solid to work from.

Who can build, who can run, who can approve and who can read are role assignments rather than conventions written on a wiki. The practical test is the question an auditor asks first: who could have triggered this action. With roles the answer is a list, and without them it is a round of interviews. Access applies to what the agents can reach as well as to the platform itself, so a workflow is bounded by the same credential discipline your team already enforces.

Consequential actions pause for a person before they execute, at thresholds you configure. The honest framing is that most serious platforms have an approval gate now, so the presence of one differentiates nobody; what genuinely differs between vendors is how finely it can be scoped. Here that is per action and per workflow, so a refund above a limit you set can pause while everything under it runs, and an engineer can gate the one step that touches the network while triage carries on unattended. Ask every vendor on your shortlist about the granularity rather than about the feature.

Yes. The platform brings the controls those audits test, running inside your own environment: role-based access, encryption in transit and at rest, change management, and an attributable record of every decision. Your auditor assesses them where they already assess the rest of your estate, so certification is a deployment question rather than a rewrite.

No platform can do that for you, and a vendor who says otherwise is selling you a problem. What Blue Mesh provides is the material those regimes ask for: the workload running inside a boundary you control, role-based access, encryption in transit and at rest, and an attributable record of every decision the system took. Your obligations remain yours, and keeping the record does not discharge them by itself. We will tell you which controls we can evidence and which ones sit on your side of the deployment boundary.

Yes, in writing, and against the specific claims on our trust page rather than in the vaguest language that would pass. If a question has an uncomfortable answer for us, we would rather you find it in the questionnaire than after signing. Where the honest answer is that a control sits on your side of the boundary, we will say that too, because in a platform you run yourself a fair number of them do.

300+ existing systems and tools, and that figure is a catalogue rather than a promise about yours in particular. The question worth asking is whether the specific systems you run are in it, which we will check against your list before you spend an evaluation finding out. Agents work through the tools you already operate, under the credentials your team already governs, rather than asking you to rebuild anything in our image.

Yes, and that is usually the interesting half of a deployment. Your own APIs plug in as reusable tools that agents can call, incoming webhooks let your systems trigger workflows on real events, and Model Context Protocol is supported for tools that speak it. Studio deployments also expose an OpenAI compatible API, so an application already written against that interface can point at your own deployment without being rewritten.

Yes, and it is the default rather than an option you negotiate for. Voice, retrieval and agent workflows run on models you own and serve from your own infrastructure, fine-tuned with BM Oasis when you want them shaped to your domain, with OpenRouter connectivity there for reaching hosted models through one interface. A tuned private model is usually a good deal smaller than a general purpose one for the same task, and it runs against capacity you already pay for instead of metered public API tokens.

A working session on a real workflow of yours, not a slide review. You bring a workflow your team runs today, and we build an agent for it live and show you exactly where your people stay in control of it. If retrieval is the point, that means indexing a slice of your own content and putting real questions to it, so you can see what was retrieved and what each answer stood on. It is deliberately concrete for a first meeting, because a demo on our data proves nothing about yours.

One workflow described in enough detail to be real, including where it currently goes wrong. Someone who knows how the work is actually done, which is rarely the same person who owns the budget. A sense of which systems the work touches, plus a representative slice of documents if retrieval is the point, or examples you already hold if training is. Nothing needs cleaning up first, and if the data cannot leave your side even for a first session, say so early: that changes what we bring, not whether we can start.

By engagement, and there is no published price list because the two things that set the cost are the deployment mode and the workload, and neither is knowable from a web form. An air-gapped appliance and a workflow running in your existing VPC are not the same purchase. We scope it after the working session, when both sides know what is actually being deployed. If the answer is that a deployment is not worth it for you, we would rather say that than sell one.

None of the three, and that is a deliberate shape rather than a gap on a roadmap. Blue Mesh deploys into your environment, so a first deployment starts with a conversation about that environment rather than with a signup form. There is no public sandbox either, because a sandbox on our infrastructure holding our data would answer none of the questions you are actually asking. If you need an API key this afternoon, we are the wrong shape, and it is better to learn that here than three meetings in.

Teams who want to call a hosted API and pay per request: there is no metered public API and no self-serve tier here, and a vendor built for that motion will serve you better and sooner. Organizations with no appetite for running infrastructure, since the entire proposition is that the platform runs in your environment rather than ours. And anyone whose real need is one narrow feature rather than a governed platform, because governance machinery you never use is cost without benefit. We would rather say all of that early than win the deal and disappoint you in month four.

Probably, if that is genuinely the whole requirement. A hosted assistant product will be live sooner and cost less, and here you would be paying for deployment control, an audit trail and model ownership that public website chat does not need. The question worth asking before you decide is what the assistant will eventually be allowed to do. Once it can act on a customer record, move money or touch a production system, the governance stops being overhead and becomes the reason you bought anything.