Owned, cloud, edge: our compute philosophy
Every AI-driven company eventually asks the same question: where should this workload actually run? Magora's answer is a deliberate hybrid AI compute strategy — hundreds of owned, cloud, and edge nodes, each task routed to whichever tier gives the best balance of cost, control, and privacy, scaling capacity up or down the moment demand shifts.
The right node for the right task
A hybrid AI compute strategy is not a compromise — it is a deliberate design choice. Instead of betting an entire business on one cloud vendor or one data center, Magora runs hundreds of compute nodes spread across three tiers: hardware we own, cloud GPU capacity we rent, and edge nodes positioned close to where work actually happens. Every task — a virtual employee drafting a contract, a video render, an embedding job, a real-time chat response — gets scored against its own requirements and routed to whichever tier satisfies them at the lowest cost.
That sounds simple. In practice it is the difference between a company that scales gracefully and one that either overpays for idle GPUs or grinds to a halt the moment traffic spikes.
Owned compute: the steady-state backbone
Owned hardware is the cheapest compute we have, once it is paid for — no per-hour markup, no egress fees, full control over the stack down to the driver version. We run our own GPU boxes for the workloads we know will run every single hour of every single day: the embedding pipelines that keep the corporate knowledge Brain current, the always-on inference for virtual employees mid-shift, and any workload that touches sensitive company or customer data we'd rather never leave our own walls.
Where owned wins
- Predictable, 24/7 workloads — steady utilization makes owned hardware cheaper than renting the same capacity by the hour.
- Data residency & privacy — client and employee data that must never leave a controlled environment.
- Long-lived models — fine-tuned or cached models that would be expensive to keep warm in the cloud.
"Own the steady demand. Rent the spikes. Push latency-critical work to the edge — that's the whole philosophy in one sentence."
Cloud: burst capacity on demand
Owned hardware has a ceiling. When a launch, a marketing push, or a new virtual employee squad multiplies demand overnight, cloud GPU capacity is what absorbs the spike without a multi-week hardware order. We treat cloud providers as elastic overflow — spun up in minutes, torn down the moment the surge passes, billed only for what we actually use.
Where cloud wins
- Bursty or seasonal load — campaign launches, batch reprocessing, one-off large training runs.
- Geographic reach — spinning up capacity in a region we don't have owned hardware in yet.
- Trying new model families — testing a new premium or open-weight model before committing owned capacity to it.
This is also where multi-LLM routing matters most: a router decides, per request, whether a local open-weight model on owned hardware is good enough, or whether the task genuinely needs a premium hosted model — see our related piece on multi-LLM harmony across the Brain.
Edge: latency and locality
Some workloads simply cannot tolerate a round-trip to a central data center. A virtual employee typing in real time, a voice interaction, a mobile session on a slow connection — these need compute physically close to the user. Edge nodes handle the last mile: lightweight inference, caching, and pre-processing that shaves hundreds of milliseconds off the interactions people actually feel.
Where edge wins
- Real-time interaction — chat, voice, and live collaboration where latency is the product.
- Bandwidth-constrained users — mobile and low-connectivity environments (see our team working run-from-anywhere, beach included).
- Local-first privacy — pre-processing sensitive input before anything is sent onward.
How we route hundreds of nodes
None of this works without a routing layer that treats compute the way a good operations team treats staffing: match capacity to demand, continuously. Every task carries metadata — privacy sensitivity, latency budget, expected cost — and a router evaluates current load across owned, cloud, and edge nodes before dispatching it. Capacity scales on demand in both directions: idle cloud instances shut down within minutes of load dropping, and a fresh burst of demand triggers new instances before a queue ever forms.
The result is a fleet that behaves like one system, even though it spans physically separate infrastructure owned by different parties in different locations. Nobody outside the platform needs to know — or care — which of the hundreds of nodes actually ran their request.
Key takeaways
- Run owned hardware for predictable, always-on, and privacy-sensitive workloads — it's the cheapest tier at steady utilization.
- Use cloud capacity as elastic overflow for bursts, new regions, and experimenting with new models.
- Push latency-critical and bandwidth-constrained work to edge nodes close to the user.
- A routing layer — not a fixed assignment — decides per-task where compute runs, scoring cost, control, and privacy together.
- Hundreds of nodes across three tiers scale on demand, both up and down, without manual intervention.
Tying it to the Magora model
This isn't infrastructure trivia — it's core to how Magora runs fully virtual-managed business divisions. Every virtual employee, every playbook run, every chat in the universal console consumes compute somewhere in this fleet. Getting the hybrid strategy right is what lets us offer clients real compute economics: owned nodes keep the baseline cost low and data in-house, cloud absorbs growth without capital risk, and edge keeps every interaction feeling instant. Read more about how the pieces fit together in how we work.
Independent research on cloud elasticity from NIST's cloud computing program and infrastructure cost analysis from the Cloud Native Computing Foundation both point the same direction we've landed on: the companies that win on compute cost are the ones that treat "where does this run" as a live decision, not a one-time architecture choice.
FAQ
What is a hybrid AI compute strategy?
A hybrid AI compute strategy runs workloads across owned hardware, cloud GPU capacity, and edge nodes, routing each task to whichever tier delivers the best balance of cost, latency, control, and data privacy — instead of committing everything to a single provider or location.
Why not just run everything in the cloud?
Cloud-only compute is simple but expensive at sustained volume and can raise data-residency and vendor-lock-in concerns. Owned nodes cut steady-state cost and keep sensitive data in-house, while cloud absorbs burst demand — hybrid gets the best of both.
How does Magora decide where a task runs?
A routing layer scores every task against privacy sensitivity, latency needs, and current load across hundreds of owned, cloud, and edge nodes, then dispatches it to the tier that satisfies the constraints at the lowest cost, scaling capacity up or down automatically.
Related posts
Curious how our compute fleet powers your division?
See how owned, cloud, and edge compute come together with the Brain and virtual employees.
