Platform · Control

Deployment options: where your system runs and where data goes

The Agent Engine is deployed separately for each client, never as a shared service. The same layers can run on accounts we hold for a pilot, on accounts in your name (the default), in a hybrid where sensitive steps use a self-hosted model, or entirely inside your own network. This page compares the data path, model choice, cost drivers and timeline effect of each.

Book a Strategy Call Get an AI Plan

Layer: Control · where it runs

Four deployment shapes, compared
Criterion	Our accounts (pilot)	Accounts in your name (default)	Hybrid	Self-hosted or on-premise
Where the application runs	Accounts we hold for the project	Your Cloudflare, Supabase or Vercel accounts	Your cloud account	Your cloud or servers in your own network
Where model calls go	Model APIs on our keys	Model APIs on keys from your own accounts	Sensitive steps on a self-hosted open-weight model; the rest on model APIs	Open-weight models only, on infrastructure you control
Who holds accounts and pays providers	We pay and re-bill at cost, with no mark-up	You, directly with each provider	You	You, hardware included
Our access	Operator during the pilot	Named, revocable roles, removed at handover	Named, revocable roles	Per-session access that you grant
Operations work on your side	None during the pilot	Low: owning accounts and alerts	Medium: a model server to run and update	High: servers, GPUs, updates and patching
Usually fits	Proving value before you open vendor accounts	Most chatbots, agents and automations	Some documents must not leave your environment	Rules that forbid any external processing
How it is scoped	Sample or limited data agreed in writing; move to your accounts planned before handover	Standard projects at published starting prices	Model chosen by testing on your tasks	Enterprise scope, quoted after a technical review

The problem

Why this layer exists

Where an AI system runs decides three things buyers care about: who can see the data, who holds the keys when the engagement ends, and how much operations work lands on your team. Those answers differ more between deployment shapes than between model providers.

Because the Agent Engine is our delivery architecture rather than a hosted product, there is no multi-tenant service your data has to pass through. Each build is deployed on its own, and the only question is which accounts and which infrastructure it runs on.

We settle the shape during scoping from three questions. Does any data come with rules about where it may be processed? Does your team want to own vendor relationships and bills? And who will run the system day to day after launch?

How it works

The mechanisms, and their alternatives

Mechanism 01
Accounts in your name, by default
Hosting (for example Cloudflare, Supabase or Vercel), model APIs (OpenAI, Anthropic, Google Gemini or Mistral AI), messaging and telephony are registered to your business, and every key is issued from those accounts. We work through named roles you can revoke. The data path is short: visitor or system, your hosting, the model provider under your own agreement with it, and back. Where a provider offers settings that keep API data out of training or reduce retention, we turn them on.
What's the alternative? Everything on the agency’s accounts
An agency holding every account makes setup quick and leaves you dependent: billing, data and keys sit with someone else, and changing supplier means a migration. We use our own accounts only for pilots and plan the move before handover.
Mechanism 02
A short pilot on our accounts
When you want to see a working system before opening vendor accounts, we can run it on accounts we hold for the project, with sample or limited real data agreed in writing. Provider costs are re-billed at cost with no mark-up, and moving to accounts in your name is a planned step with its own checklist: new keys issued, data exported and imported, webhooks re-pointed, our access removed.
What's the alternative? Skip the pilot
Building straight into your accounts avoids a migration and is the better path when the scope is clear. A pilot earns its keep when the main open question is whether the system is worth building at all.
Mechanism 03
Hybrid: sensitive steps on a self-hosted model
Some builds split by data. Contracts, health records or internal financials are processed by an open-weight model from Hugging Face, such as Llama or Mistral, running in your cloud, while public-facing and low-sensitivity steps use model APIs. The router picks the path from the request’s source and classification, and the rule is enforced in code rather than left to the model. Embeddings for sensitive documents come from the self-hosted path as well.
What's the alternative? Self-host every step
Running every step on your own models removes third-party processing entirely. It also puts the hardest steps on whichever open model fits your hardware, so we self-host everything only when the rules require it, and measure the quality cost first.
Mechanism 04
Fully self-hosted or on-premise
Every layer, models included, runs on infrastructure you control: your cloud account or servers in your own network, packaged as Docker containers. Nothing leaves your environment except what you choose to connect. It is an Enterprise scope, priced after a technical review of your hardware, network rules and the team that will run it, because GPUs, updates and security patching become your operations work.
What's the alternative? A dedicated endpoint from a model provider
Some providers offer dedicated or region-specific endpoints under contract. That can meet a residency rule with far less operations work than on-premise, so we check it against your requirements before recommending hardware.
Mechanism 05
Model choice follows the shape
On accounts in your name, any provider in our build stack can serve each step, chosen by evaluation. In hybrid and self-hosted shapes, the open-weight model for the sensitive path is chosen by running the build’s evaluation set on candidates that fit your hardware, and we say plainly where quality drops compared with an API model and what that means for the workflow.
What's the alternative? Pick the model first
Starting from a favourite model and fitting the deployment around it is common. We start from the data rules and the evaluation results instead, because the model is the easiest part of the stack to change later.

Cost and timeline

What each shape changes in cost and timeline

Drivers, not prices: provider prices change, so the proposal estimates them for your volume with the date we checked.

Running-cost drivers and timeline effect per deployment shape
Shape	Main running-cost drivers	Effect on the timeline
Our accounts (pilot)	Model usage and hosting, re-billed at cost	Fastest start; the move to your accounts is added before handover
Accounts in your name	Model usage per message, hosting, messaging or telephony fees, billed to you directly	Standard; account setup and verification run alongside the build
Hybrid	All of the above, plus a GPU or model server sized for the sensitive path	Adds model selection and a model-server setup step
Self-hosted or on-premise	Hardware or reserved GPUs, power and your team’s operations time; few per-message fees	Longest: hardware, network access and a security review come first

Data residency depends on each provider’s regions and on where your own hosting runs. We check it per project against your requirements before anything is promised, and every provider in the data path is named in the proposal.

Defaults

Defaults we ship

A separate deployment per client, with no shared tenant and no shared data store.
Accounts in your name unless a pilot on ours is agreed in writing.
Named, revocable access for us, removed at handover or whenever you ask.
Provider settings that keep API data out of training switched on where offered.
Secrets kept in each platform’s secret store, never in code repositories.
Every provider and processing location in the data path named in the proposal.
Containerised services, so a later move between shapes is a redeploy rather than a rewrite.

Limits

Limits, stated plainly

We do not promise a data region until each provider in the path has been checked for your project; some features are offered only in some regions.
Open-weight models that fit modest hardware are usually weaker at complex reasoning than the largest API models; the evaluation set shows the gap on your tasks before you commit.
On-premise moves security patching, hardware failures and model updates to your team. We document and hand over the runbook, and ongoing support is scoped separately.
A pilot on our accounts is for agreed sample or limited data. Regulated data such as health records goes straight to accounts in your name or a self-hosted shape.
Moving between shapes later is possible but not free: data, keys and webhooks move, and the evaluation set runs again on the new path.

Configuration

What the configuration looks like

deploy.yaml: an illustrative hybrid deployment (Sample data, not a client file).

# deploy.yaml  (Sample data: a hybrid build, illustrative)
shape: hybrid
hosting: { provider: cloudflare, account: client_owned }
paths:
  public_questions:
    model: api                    # provider chosen by evaluation
    provider_settings: { training_opt_out: true }
  contract_review:
    model: self_hosted            # open-weight model in your cloud
    runtime: docker
    data_leaves_environment: false
routing_rule: "source in [contracts, finance] -> contract_review"
access:
  miniai: { role: developer, named: true, revoke_on_handover: true }
secrets: platform_secret_store

FAQ

Frequently asked questions

Do you host client systems on your own infrastructure long term?

Not as a rule. Our own accounts are for pilots, and on a monthly plan we may run supporting pieces for you, always listed in the proposal. Production systems normally live in accounts in your name, so they keep running whoever supports them.

How do we work out which deployment shape we need?

Start from your data rules, not the technology. If nothing you will process is restricted in where it goes, accounts in your name are the simplest choice. If some documents must stay inside your environment, a hybrid usually covers it. Only a rule against any external processing calls for fully self-hosted or on-premise. We settle it in scoping with your security contact in the room.

Can we start on model APIs and move to a self-hosted model later?

Yes. Model calls sit behind one interface and the services run in containers, so the move is a new model endpoint, an evaluation run to confirm quality on your tasks and a routing change. The work that takes time is choosing and sizing the self-hosted model, not changing the application.

What hardware does a self-hosted model need?

It depends on the model’s size, how many people use it at once and how quickly replies must come back. Smaller open-weight models can run on a single modern GPU, while larger ones need several or a lot of memory. We size it during the technical review from your expected volume, including the option of reserved cloud GPUs instead of buying hardware.

Does on-premise mean no internet connection at all?

It can. A fully air-gapped build needs every model, library and update delivered through an agreed process rather than downloaded, and we scope that explicitly. Most on-premise builds allow outbound access for updates only, through your proxy, with no customer data leaving the network.

Who pays the model and hosting bills in each shape?

On accounts in your name you pay each provider directly. During a pilot on our accounts we pay and re-bill at cost with no mark-up, itemised on the invoice. In self-hosted shapes most per-message fees disappear, replaced by hardware or reserved GPU costs and your team’s time.

Next step

Have a workflow in mind? Let’s scope it together.

Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.

Book a Strategy Call Get an AI Plan

Free 30-minute call · no commitment

Send an RFP or security questionnaire

Deployment options: where your system runs and where data goes

Why this layer exists

The mechanisms, and their alternatives

Accounts in your name, by default

A short pilot on our accounts

Hybrid: sensitive steps on a self-hosted model

Fully self-hosted or on-premise

Model choice follows the shape