Private AI · managed operation
We design, deploy, and operate AI environments that can understand digital work, use approved tools, and continue scheduled jobs. Start with one measured workload, then choose local, managed-cloud, hybrid, or air-gapped operation.
Governed runtime
See · act · verify
Operating boundary
The same workflow can use different infrastructure. The right choice follows the data, latency, integration, support, and control requirements—not a preferred vendor.
Model serving and selected data stay on equipment in your environment. Egress, updates, and operator access are configured for that deployment.
Dedicated or shared cloud resources with provider, region, retention, and administrator access agreed before launch.
Keep selected retrieval and tools private while routing approved tasks to chosen external model or voice services.
Isolated operation is available for compatible workloads. Model delivery, updates, integrations, and support follow a separate offline process.
Digital work loop
Each worker executes a repeatable task in a bounded environment with inspectable decisions, controlled actions, and a defined handover to a person.
Interpret approved screens, documents, images, and application state.
Apply task policy, context, and confidence thresholds before selecting a next step.
Use computer control, APIs, MCP servers, and business systems through scoped identities.
Check the resulting state, record tool events, and request confirmation where policy requires it.
Run schedules and durable jobs with bounded retries, alerts, and a defined human handover.
A worker can inspect an approved desktop or browser session and operate software through a constrained environment when direct APIs are not suitable.
Control: High-impact actions can require confirmation; sessions, applications, and credentials remain explicitly scoped.
Connect selected APIs, MCP servers, databases, document stores, and business systems to the task—not to an unrestricted general agent.
Control: Each connector receives the minimum identity, data scope, and tool permissions needed for its job.
Run recurring research, reporting, monitoring, reconciliation, preparation, or support work with observable job state.
Control: Retries, alerts, escalation, stop conditions, and ownership are designed before unattended operation.
Voice and interface
Interface choice and data boundary are separate architecture decisions. Your team can use the experience that fits the job without giving that interface unrestricted access to private tools or data.
01 / LOCAL
Use a suitable local speech stack when measured latency, language quality, hardware capacity, and support requirements fit the workflow.
Candidate models and voices are demonstrated and accepted for the client's language, environment, and device before commitment.
02 / APPROVED CLOUD
A client-approved service such as ChatGPT can remain the conversation layer while the private worker exposes only authenticated, policy-checked actions.
Provider retention, regional processing, permissions, and transmitted fields are reviewed separately from the private runtime.
System design
Each layer has an owner, an access boundary, and evidence. The exact products are selected after the workload and operating constraints are understood.
Entry
The interfaces through which people and systems start approved work.
Policy
The rules that decide what may happen, with which identity, and when a person must intervene.
Runtime
Local or approved cloud inference combined with the execution environment required by the task.
Systems
Only the company systems and data paths needed for the measured workload.
Evidence
Signals that show what the worker attempted, what changed, and who owns an exception.
A reference architecture is not a certification.
Workload sizing
Model memory is only the first constraint. We measure quality, prompt and context size, output rate, concurrent activity, latency, runtime compatibility, power, support, and recovery before recommending a system.
01
32 GB unified
AMD Ryzen AI Max PRO 380-class workstations.
Candidate fit: Private retrieval, speech, screen understanding, and narrow multimodal workflows after task-level testing.
Dated evidence for this tier only
32 GB retail reference02
64 GB unified
AMD Ryzen AI Max+ 395-class compact systems.
Candidate fit: Quantized 27B-class candidates such as Qwen3.8-27B when the selected runtime, quantization, context, and measured latency fit the workload. AMD documents Gemma 3 27B QAT on this memory tier.
Dated evidence for this tier only
64 GB retail reference03
128 GB unified
AMD Ryzen AI Max+ PRO 395-class workstations and compact systems.
Candidate fit: Larger low-bit candidates, longer contexts, multimodal evaluation, and several local services when a workload benchmark supports the configuration.
Dated evidence for this tier only
128 GB retail reference04
128 GB unified
GB10 CUDA desktop development and inference systems.
Candidate fit: NVIDIA publishes support for testing or inference up to 200B parameters and fine-tuning up to 70B. These are capacity ceilings, not latency, context, concurrency, or SLA promises.
Dated evidence for this tier only
DGX Spark retail reference
05
748 GB coherent
GB300 Grace Blackwell Ultra deskside systems, configured and sourced by quotation.
Candidate fit: NVIDIA publishes support for models up to one trillion parameters and up to seven isolated MIG instances. The final checkpoint, precision, context, throughput, site, and support requirements remain quote-time decisions.
Dated evidence for this tier only
Station-class retail referenceCapacity, honestly stated
We size simultaneous responsive work and scheduled duty cycles, then map those measured slots to named workflows. We do not turn a token-rate estimate into a claim about human headcount.
Example only: if the accepted workload sustains 40 output tokens per second and one interactive session needs 10, that is roughly four simultaneous sessions. At a 20% active-duty assumption it may support about twenty assigned routine workflows—but still not twenty human-equivalent employees.
Illustrative platform families reviewed 22 August 2026. Availability and specifications change. Every model/runtime combination is benchmarked before sizing.
Evidence boundary
The links inside the five tiers are dated examples that substantiate the class of system being discussed. They are not a public hardware catalogue, live inventory, or Algovectra offer.
Current price, availability, warranty, delivery, configuration, security hardening, and managed service are confirmed only in a project quotation.
Platform scope
Identity, tools, orchestration, and observability are selected components—not an automatic bundle of platforms or licences.
Delivery sequence
Timing is confirmed after discovery because hardware availability, security review, integrations, and acceptance scope change the work.
Define the task, current system, data boundary, human roles, and acceptance test.
Run the smallest representative workflow and measure quality, latency, failure modes, and cost.
Add only the identities, tools, data paths, monitoring, and controls needed for the accepted workflow.
Document ownership, service targets, updates, recovery, and the agreed managed or client-operated model.
Contact
Define the task, data boundary, tools, human controls, and acceptance test before choosing hardware or models.