Before you self-host an AI agent platform: the questions to ask any vendor

A good vendor answers these plainly. A vendor that dodges is telling you something.

TL;DR — Seven questions to put to any AI-agent vendor before you self-host. They are deliberately vendor-neutral: each one is a property you can check, not a promise you have to accept. Where a vendor cannot give you a straight answer, the silence is the answer. Where we mention EpicStaff below, we mention it honestly — including where the honest answer has an exception.

"Self-hosted" has become a word vendors reach for whether or not it is true. Some platforms run entirely inside your walls. Others run a local front end that still calls a hosted cloud for the parts that matter. Both get called "self-hosted" in the sales deck.

A live demo will not tell you which one you are looking at. The demo is designed to look good. Written questions, answered before the demo, tell you far more — because vendors answer differently in writing than in a meeting, and the questions that produce a long pause are the useful ones.

Here are seven. Send them first.

This is the question that makes every other answer checkable. If you can read the code, every claim below becomes something you verify instead of something you accept. If you cannot, you are relying on the vendor's description of their own product — which may be accurate, but is a weaker kind of assurance, and you should know which kind you are buying.

Ask plainly: is the source available to read, and under what licence?

EpicStaff, honestly: the source is available to read under PolyForm Perimeter 1.0.0. You can read it, run it, and modify it for your own use. It is at github.com/EpicStaff/EpicStaff. (Note: source-available is not the same as OSI "open source" — the difference is a single restriction on using it to provide a competing product. It does not affect your ability to inspect or run it.)

"Self-hosted" should mean the inference happens inside the boundary you control. Ask directly whether the platform can run against models on your own infrastructure, and whether it can use local, self-hosted models rather than only hosted APIs.

Watch for the platform that hosts your orchestration locally but sends every actual model call to a cloud endpoint you do not control. That is a real architecture, and it may be fine for you — but it is a different risk profile, and you should choose it on purpose.

EpicStaff, honestly: it runs inside your own environment, on the model you choose for your agents — including local, self-hosted models.

This is the question most "self-hosted" tools quietly fail, so ask it in two parts, because they have two different answers:

• Does the platform itself make outbound connections?
• Which of the shipped features and tools make outbound connections, one by one?

Vendors frequently answer only the first. Many "self-hosted" tools still call hosted providers for specific jobs — embeddings for document search, voice or realtime endpoints, usage telemetry — even when the core runs locally. Ask for a per-feature list. If nobody can produce one, nobody actually knows.

EpicStaff, honestly: EpicStaff connects out only to the providers you configure keys for. Tools do what you tell them: a tool you build or enable that reaches the internet is your choice and your configuration. One case worth knowing: voice and realtime features call their providers' hosted endpoints and are not currently redirectable to your own. And nothing is egress-free out of the box — the defaults point at providers until you point them somewhere else. Ask us for the current per-feature list; that is exactly the breakdown this question demands.

Not "a region in your country" — a region is still the vendor's infrastructure, under the vendor's operational control, and ultimately under the legal jurisdiction of wherever the vendor is incorporated. Ask whether you can install and run it on machines you own, in your own tenancy, without a vendor-operated control plane and without a vendor account.

Why it matters: if any part of running the software depends on the vendor's cloud staying up and staying willing, you have imported the vendor's jurisdiction and the vendor's uptime into your own risk model.

EpicStaff, honestly: it is self-hosted — you install and run it inside infrastructure you control, on your own models.

Source you can read but not modify is only half of what you need in a regulated environment. Ask whether the licence lets you both inspect the code and adapt it to your own environment. Ask what happens to your existing deployment if the vendor is acquired, changes direction, or shuts down — source availability, data portability, and the right to keep running are separable, so ask about each.

EpicStaff, honestly: PolyForm Perimeter 1.0.0 lets you read, run, and modify the code for your own use. The one restriction is on using it to build a competing product — a limit aimed at competitors, not at you.

Ask two things. First: how is access to agents, tools, and data controlled — and is that control enforced by the platform, or is it just a convention written inside individual agent definitions? Second: what is recorded when an agent acts, and can you export that record into your own systems in a format you keep?

EpicStaff, honestly: the source-available codebase includes role-based access control, in the source-available tier, not the paid one — so you can read exactly how access is handled. Sessions and interactions are persisted, and your data is exportable as JSON or CSV, so the record lives in your systems rather than a vendor console.

Ask where your data physically lives while the platform runs, and what a delete actually does. In a hosted product this is a policy question you have to trust. When you host the platform yourself, it becomes an infrastructure question you can answer directly: your operational data sits in your own datastore, on your own machines — so where it lives is something you can see, not something you have to take on trust.

EpicStaff, honestly: it is self-hosted, so your operational data lives in your own datastore on your own infrastructure.

Send all seven before the demo. Nobody scores a clean seven — including us — and a vendor who claims they do is selling, not answering. "Not applicable to our architecture" is sometimes exactly the right answer; what matters is whether the vendor can say why.

The honesty of the answers is the thing you are really measuring. A vendor who names their own exceptions — as we tried to in question 3 — is easier to trust than one who says everything is perfect. Read the source, self-host it, and check the answers for yourself. That is the whole point of asking questions you can verify.