Where the platform runs is a business decision, not an IT default.
Deployment topology sets your data position, your operational burden, your upgrade cadence and your exit cost. This page covers the four topologies we deliver, what isolation between environments actually means, and the contract terms you should read carefully.
Four topologies
Hosted, dedicated VPC, on-premise, hybrid
Isolated environments
Dev, test and production genuinely separated
Canary release
Small traffic first, then full rollout
Local ecosystem
Adapted for domestic infrastructure stacks
Most platforms are bought. The topology is argued about far too late.
The first question in any serious evaluation should not be "which model is behind it" but "where does the data live, who operates it, and what does it cost us to change our mind in three years". These are the questions that decide the contract.
Deployment decisions age badly in a specific way: they are made against today's data classification, today's regulatory position and today's application architecture, and then they outlive all three. A platform that sits entirely inside your network is comfortable on day one and painful the day a business unit wants to iterate quickly. A platform entirely in the cloud is fast on day one and blocked the day a regulator asks where the records are.
Our default recommendation is the least complex topology your constraints actually require. That is not a hedge — a private deployment for a workload that never left your network adds operational cost and slows every subsequent change, and it buys nothing. The discipline is to write down the constraint that forces the complexity, and to make sure it is a real constraint.
- Name the driver. Data sovereignty, isolation, latency, procurement policy, or a regulator's instruction. Different drivers justify different topologies.
- Price the operations, not the licence. Private deployment moves part of your platform estate onto your engineers, on your hardware, on your change calendar.
- Decide the split before you build it. In hybrid, the boundary is drawn by data classification. If nobody owns classification, the boundary will be drawn by accidents.
- Keep an exit path open. Environment isolation and exported definitions exist so that changing your mind later is a project, not a rebuild.
The cost curve nobody shows in the tender
The operational load of a topology falls on whoever is closest to the problem, and it is rarely the person who chose it.
| Topology | Who carries the operational load |
|---|---|
| Hosted | The provider carries the platform; you carry configuration and content. |
| Dedicated / VPC | Shared responsibility. Your network boundary, their platform operation. |
| On-premise | Your infrastructure team carries the platform estate on its own change calendar. |
| Hybrid | Both — and the boundary between them becomes a thing to operate and audit. |
We will show you the operational work each option implies before you sign, not after. If a topology is wrong for you, hearing that early is cheaper than discovering it during a change freeze.
Deployment in numbers
Each commits you to something different
Argued in week one, not after the contract is signed
Low code, high code, and the seams between them
The most expensive change in the project
Four deployment shapes, and what each one commits you to
The starting point for selection. Every row has a cost consequence attached, and the cost scale between them is significant.
| Topology | What it suits | Where the data lives | Who operates it | Cost shape |
|---|---|---|---|---|
| SaaS public cloud hosting |
Fastest path to production; workloads with no residency or isolation constraint; teams who want the platform's own operational discipline | Provider infrastructure, in a region you select | The provider operates the platform; you operate your content, configuration and access model | Lowest fixed cost, recurring subscription; no hardware, no cluster to size |
| Dedicated cloud / VPC | Organisations that need a network boundary and isolation they can see, without taking on infrastructure ownership | Your virtual network boundary, dedicated to you | Shared responsibility — your network and controls, their platform operation | Mid-range; you pay for a dedicated environment rather than for hardware |
| Cloud-hosted private deployment | Regulated or sovereign workloads where the platform must run inside infrastructure you control: defence, banking, public sector | Entirely within your environment, including inference | Your infrastructure and platform teams, with our delivery and support practice alongside | Highest fixed cost: hardware, environment build and a permanent operations commitment |
| Hybrid | Mixed estates where regulated knowledge and inference stay local while the rest of the workload uses the hosted tier | Split deliberately, by data classification | Both sides operate, and the boundary itself becomes something to monitor and audit | Highest total cost, and the most complex to govern — the price of not choosing |
Choose hosted when
The work is not sensitive in a way your security team has written down, and speed of iteration matters more than the location of the compute.
Choose dedicated when
You need a boundary you can point at in an audit, but not a cluster you have to maintain.
Choose on-premise when
Sovereignty is a hard constraint, and the organisation is genuinely prepared to carry the operating load.
Choose hybrid when
Two data classifications genuinely coexist and you have an owner for the boundary — not when you are avoiding a decision.
Four deployment shapes, and what each one commits you to
Most organisations pick by default and discover the commitment during an incident. Pick deliberately, in week one, with us in the room.
| Shape | What it looks like | What it commits you to | Choose it when |
|---|---|---|---|
| Managed | The vendor runs it; you consume the service | A dependency on their operational and roadmap decisions | You want speed and have no platform team to own it |
| Dedicated instance | Single-tenant, sized for you | You own the sizing, and the cost of being wrong about it | Isolation matters and your volume is predictable |
| Private cloud | Your cloud account, our deployment | You own the cloud bill, the network, and the patching regime | Data residency or regulatory constraints require it |
| On-premise | Your infrastructure | You own the hardware refresh and the whole operational burden | A regulatory or sovereign requirement genuinely demands it — not a preference |
What running it yourself actually involves
Official image distribution with container orchestration, elastic scaling, self-healing, and per-execution sandboxing. This is real engineering, and it is a permanent commitment.
Images and orchestration
Private deployment is distributed as official container images and orchestrated with Kubernetes. The platform assumes a mature orchestration layer rather than trying to be one — which is why it inherits service discovery, elastic scaling and self-healing behaviour from that layer.
In practice, this means your team needs cluster administration skills. That is not a criticism of the platform; it is the nature of the choice, and it is the single largest determinant of whether a private deployment succeeds or becomes an orphan project nobody wants to own.
Sandboxed execution, per call
Agent code and tool calls execute inside isolated container sandboxes, with each system call running in its own sandbox context. The consequences are worth being explicit about: data can be masked before it reaches the execution boundary, risky operations can be intercepted before they commit, and the complete execution record is retained for review.
Isolation per execution is what turns a compromised prompt or a faulty plugin from an incident into a contained event. It is also why performance characteristics differ from an unisolated runtime — a trade we would rather explain now than have discovered in a latency review.
On sizing. We are deliberately not publishing a minimum cluster specification or a concurrency figure on this page. Those numbers are a function of your workload shape, your model serving configuration and your latency target, and a number printed on a website is a number that was true for someone else's workload. We size the environment against your own use cases, and we will show you the basis of the recommendation.
What running it yourself actually involves
Self-hosting is not free. It is a trade: more control for a named operational burden. We will help you decide honestly which side of that line you are on.
- Capacity planning for a workload whose demand is genuinely variable
- A patching and upgrade regime with a named owner and a calendar
- Certificate, secret and credential rotation on a schedule
- Backup and restore, tested rather than assumed
- Monitoring and alerting that someone is actually responsible for
- A documented runbook for the failure modes you have actually seen
- Someone on call who has run it in a real incident, not in a drill
- Model deprecation watch — with a migration plan, not a policy
Adapting to domestic infrastructure
Adaptation across mainstream domestic CPU and GPU architectures, operating systems and databases — so a deployment is not quietly dependent on a foreign supply chain.
For organisations operating in Xinchuang (信创, domestic technology innovation) environments, compatibility is not a preference. Procurement rules, supply-chain reviews and internal architecture standards can each independently disqualify a platform that only runs on a specific foreign hardware and database stack.
The platform is therefore adapted to mainstream domestic CPU and GPU architectures, domestic operating systems and domestic databases, and is used in Xinchuang (信创) deployment scenarios. The practical effect is that a private deployment can be hosted on infrastructure you already own and are permitted to use, rather than requiring a parallel stack that nobody operates well.
Questions to ask any vendor claiming compatibility
- Which specific combinations are certified? "Supports domestic hardware" is not a list. Ask for the matrix of CPU, GPU, OS and database versions actually tested together.
- Is inference local too? Adaptation of the platform does not help if the model call still leaves the network. Ask where inference runs.
- What is not supported? Every platform has unsupported combinations. A vendor who lists them is a vendor who has tested.
The operational pain point most vendors treat as a checkbox
Development, test and production are not three tabs. They are three estates with different data, different risk and different change authority — and a platform that blurs them will eventually train an agent on production data and ship it to a test environment where nobody was looking.
Multi-environment isolation in the platform separates networks and data completely: a project in a test environment cannot see production traffic, and production data does not appear in a test context. Within that separation, the behaviour is deliberately not uniform, and this is the detail that matters operationally.
Content-level assets are maintained independently per environment. Knowledge files, the detailed data in data tables, and variable assignments each exist and are maintained separately in each environment — because a test environment holding a stale or truncated copy of a corpus produces false confidence, and a production environment holding test fixtures produces real incidents. The knowledge engine binds a project to a single space, so content does not cross environments by accident.
What does synchronise fully is the structure: the workflow orchestration content and the plugins are covered and synchronised across environments. The reasoning is sound — orchestration logic and tool definitions are versioned code, and duplicating them invites drift between what you test and what you run. The split is therefore: structure synchronised, content isolated, with the migration path handled explicitly by metadata rather than by copy-paste.
What is isolated, what is synchronised
| Asset | Across environments | Reason |
|---|---|---|
| Network and traffic | Fully isolated | Test traffic must not reach production systems |
| Knowledge files | Maintained independently per environment | Corpora change on different cycles; stale test copies mislead |
| Data table contents | Maintained independently per environment | Real data in a test estate is a disclosure risk |
| Variable assignments | Maintained independently per environment | Endpoints, credentials and thresholds differ by environment |
| Knowledge space binding | One project maps to one space | Prevents content crossing between environments by default |
| Workflow orchestration | Fully covered and synchronised | It is logic, not content; drift here breaks the test's meaning |
| Plugins | Fully covered and synchronised | Tool definitions must match between test and production |
| Migration | Metadata import and export | Explicit, reviewable transfer of definitions between environments |
Ask any vendor to show you where their "test" environment gets its content from. Most environments differ in name only.
How changes get in, and what that rhythm costs you
Canary release, pinned model versions, verification in test before production, and a scheduled upgrade cadence. The cadence is a feature — and also a recurring obligation you must be able to absorb.
Canary before full release
A proportion of traffic is served by the new version first, with behaviour observed before the change reaches everyone. The part most vendors omit: the canary window should span a business peak. A release that looks clean on a quiet Tuesday afternoon tells you very little about what it does when volume, urgency and edge cases arrive together.
Pinned model versions
Production runs against a fixed model version. Versions are not allowed to drift underneath a working deployment, and upgrades are rehearsed in the test environment first — against the same agent definitions and your own regression set, not a vendor demo.
A quarterly release rhythm
Within the contract term, minor releases arrive quarterly and major releases annually, and version upgrades are included at no additional charge. The benefit is that the platform does not strand you on a frozen build. The obligation is real and should be written into your selection criteria.
The cost you must accept
A quarterly cadence means four times a year your organisation has to absorb a change, verify it against its own test set, and decide whether to promote it. If your team has no capacity for that, quarterly releases become the thing everyone dreads. Select for a change rhythm your organisation can actually carry — that capability, not the release calendar, is what determines whether the calendar is an advantage.
How changes get in, and what that rhythm costs you
This is the same loop as evaluation, applied to the estate rather than to one agent. It is the difference between an estate that improves and one that drifts.
Change is proposed
A prompt, a context change, a tool version, a model swap. Four different things, one gate.
Authored and peer-reviewed
The change is a versioned artefact with a named author and a named reviewer.
Regression suite runs
Full test set against the candidate, per-case diff against live baseline.
Staged rollout
Canary to a small share, then progressive. Automated rollback if the live rate breaches threshold.
Observed and archived
Post-release observation window, then archived as a governance record.
Low code, high code, and the seams between them
Mixed development modes in one platform: business teams prototype with prompts, knowledge and workflow; engineering teams build the parts that need real engineering, and the two integrate through SDKs and APIs rather than a migration.
No code and low code
Business users assemble prototypes from prompts, knowledge bases and workflow, and iterate without waiting for a release train. For validating an idea this is the fastest route to a working shape.
High code
Professional developers build complex interaction interfaces, intent recognition, retrieval operators and recall strategies, high-availability architectures, and proprietary tool plugins — the parts where the behaviour needs to be engineered rather than configured.
Full-code entry points
A code-level entry point lets you create agents programmatically through the interface, which is the only sane way to stand up a large cohort of agents, and a command-line path for publishing an agent to a named environment — so release is a scripted, repeatable operation rather than a console click.
Integrating the two halves
Low-code components are designed to be embedded into code-engineered applications through SDK and API access, and the SDKs extend to evaluation, observability and data optimisation for high-code applications — so a component built by a business team can be tested and monitored by an engineering team in the same toolchain, rather than living in a second system with no telemetry.
Agent construction is also modular: capabilities are split into modules that can be copied and reused across scenarios, which is what stops every new agent from being rebuilt from scratch — and what makes a well-designed agent something other teams can adopt without re-authoring it.
Who builds what
| Need | Mode |
|---|---|
| Validate a use case quickly | No code / low code |
| Custom interaction and intent handling | High code |
| Retrieval operators and recall strategy | High code |
| Availability and scaling design | High code + platform architecture |
| Proprietary internal tool as a plugin | High code |
| Stand up a cohort of agents | Code interface, batch |
| Release to a named environment | Command line |
| Reuse a proven capability elsewhere | Modular agent construction |
Low code, high code, and the seams between them
The seam is a real engineering artefact and deserves the same discipline as a service boundary in any other system. Treating it as a detail is how it becomes an incident.
Low code
The right choice for the majority of enterprise workflows, because they are documented and stable. A supervisor can see what the agent will do, which matters more than speed.
High code
For logic that genuinely requires it — unusual computation, custom algorithms, precise numerical work. Written, tested and versioned like any other production code.
The seams
Low code calls high code through an interface. That interface needs its own contract, its own tests and its own versioning. Most estates fail at the seam, not in either half.
What we commit to, and what you should read line by line
SLA and technical support are standard service items, and the private-deployment terms vary by version. Both of those sentences deserve a careful reading before you sign anything.
Support
Service-level commitments and technical support are standard service items rather than optional extras, with remote technical support available around the clock. In practice this means an escalation path that exists before an incident does, and a support relationship with the delivery team that built your environment — not a generic queue.
The honest note on rollback
Canary release is documented and real. A customer-visible version rollback mechanism is not clearly documented in the product material, and we will not pretend otherwise. The practical implication is direct: if you cannot roll the platform version back, then your own release process becomes the recovery path, and that is a reason to keep your agent definitions under your own version control rather than relying on the platform's history.
Our recommendation. Keep your agent definitions, prompts and workflow configuration as code in your own repository, and promote them through your own pipeline using metadata import and export. If the platform version moves forward, your estate moves with it deliberately — and if it does not, you are not dependent on a rollback button we cannot demonstrate.
What to confirm before you sign
| Item | Why it needs checking |
|---|---|
| Hardware and environment specification | Minimum cluster, node types and storage requirements differ by version and workload. Confirm the exact list for the edition you are buying, in writing. |
| SLA wording | Availability commitments, exclusions, measurement method and remedy are version-specific. Read the clause, not the summary. We do not publish figures on this page. |
| Support scope | Which environments, which hours, and whether on-site presence is included or separately scoped. |
| Upgrade obligations | Quarterly minor and annual major releases, and what your team must do to verify and promote each one. |
| Commercial terms | Pricing varies with scale and deployment form, so we do not publish a price list. Ask for the quote structure and what changes it — this is a normal and important part of selection. |
We would rather you ask these questions before signature than discover them during implementation. Every one of them is easier to answer in a workshop than in a dispute.
What we commit to, and what you should read line by line
Every line here is falsifiable. If a proposal you receive cannot show you these six, it is describing a pilot rather than an operating capability.
| We commit to | Read this line carefully |
|---|---|
| One workflow in production by week 7 | One. If your plan requires three in a quarter, we will tell you that is not realistic before you sign, not after. |
| A named human approver and a decision log | The approver is named. It is a person, not a role, and not a committee. |
| Training delivered before go-live | Operators and supervisors, with completion recorded in the LMS as evidence. |
| Evidence accepted by your risk function | Accepted, not merely provided. We sit in the room when it is reviewed. |
| Your team can operate it without us | If we cannot achieve that, we have built something you are locked into. That is not a good outcome for either of us. |
| Cost per task, measured and modelled | Measured, not estimated. And we will show you the routing that reduces it. |
Five questions that settle whether you need this
Five yes-or-no answers. If you cannot answer the first three, the capability is not your bottleneck yet.
- Can you name the specific workflow this serves — not the department?
- Can you name the person accountable when it is wrong?
- Can you show me historical cases where a human did this task, so we can build an evaluation set?
- Can you tell me what this capability explicitly will not do?
- Can you tell me what it costs per task, and how you would reduce that cost?
What the first ninety days look like
The same shape on every capability. The content differs; the checkpoints do not.
| By day 30 | By day 60 | By day 90 |
|---|---|---|
| Baseline captured on your metric | Workflow running with a named approver | Metric moved, against the baseline you did not choose |
| Scope boundary documented — including what it may not do | Evaluation harness re-running on every change | Decision log reviewed by your risk function |
| Historical cases assembled for testing | Training delivered, completion in the LMS | Next workflow scoped from what we learned |
| Data lineage for every source the agent reads | Cost per task measured and modelled | Evidence pack complete and accepted |
Where this capability lands, by industry
Depth is our own 0–3 assessment of how strongly this capability matters in that sector today.
| Financial services | Manufacturing | Healthcare | Telecoms & tech | Public sector | Professional services | |
|---|---|---|---|---|---|---|
| Workflow documentation | ||||||
| Data readiness | ||||||
| Regulatory intensity | ||||||
| Value at stake | ||||||
| Learning dependency | ||||||
| Time to first workflow |
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Give us the constraint, and we will argue about the topology with you.
A working session using your real data classification, your infrastructure estate and your regulatory position. You will leave with a recommended topology, the operational work it implies, and an honest view of what it costs to run — before anyone signs anything.