What FluidCloud learned building a multi-cloud migration engine, and what it says about where LLMs actually belong.
GOBIGAI Interview Series. In conversation with Harshit Omar, CTO - FluidCloud.
I went into this call with a thesis. I had written it down, sent it ahead, and put it in the first question so it could be knocked over cleanly if it deserved to be.
The thesis: cloud migration at enterprise scale is a multi-agent orchestration problem disguised as an infrastructure problem.
Harshit knocked it over in about thirty seconds. "It's not agentic. The multi-agent orchestration, that is not there."
What follows is the more interesting story I got instead.
The four months they restarted
FluidCloud converts infrastructure between clouds. Point it at any cloud account, it discovers everything inside, and it hands you working Terraform for AWS, Azure, GCP, OCI, or five other providers. A nine-month migration becomes something closer to a week.
Every instinct in 2026 says the hard part of that is a reasoning problem, and reasoning problems go to a model. FluidCloud tried exactly that. Four months building the cross-cloud mapping with AI. Then they restarted all of it.
Harshit's reason:
"If you try to build a conversion network out of it, it will always hallucinate, because transformers by default, the nature is to figure out, bring all those relevant numbers together. And what you should discard, it's not there."
Read the second half again. A transformer is built to find what's relevant. It is not built to be certain about what is irrelevant. For most applications that gap is invisible. For infrastructure conversion it is fatal, because the failure doesn't announce itself. It's a security group that converts cleanly, passes terraform plan, applies without error, and is quietly more permissive than the one it replaced.
So they restarted, and spent the next stretch building the mapping by hand.
What "by hand" actually means
I want to be specific, because "they wrote rules instead" undersells it enormously.
Take the simplest resource there is: a virtual machine.
In AWS you ask for an EC2 instance by family and size. T for general purpose, C for compute, M for memory. Small through 2xlarge. Underneath, each one is just a number of vCPUs and some memory. Go to Azure and it's Standard B1S, D2S, D4S. If you've worked in AWS your whole career, you have no idea what a D4S resolves to. OCI has its own names. GCP has its own.
That's one resource, one dimension. You still have to specify the OS, and each provider has its own OS families. Then networking. Then subnets, firewalls, load balancers. Then the hard ones, IAM and Lambda and Cognito, where the differences stop being cosmetic.
The rule set covers all of it, service by service, attribute by attribute, value by value, three layers deep. Fifteen months. Eight providers.
Here's the detail that changed how I think about this. The rules don't map resources. They map the order you build them in.
To stand up an EC2 instance you create a VPC, attach a subnet, then attach the VPC and subnet IDs to the instance. The mapping captures that sequence and its dependencies, then encodes other cloud-native ways to do the equivalent thing. Most migration tools get the resources right and the wiring wrong. That's the difference between Terraform that names the right things and Terraform that stands up a working environment.
For AI Engineers
When you replace a model with rules, the expensive part isn't the rules you can see. It's the implicit procedure the model was quietly getting right, or getting wrong, without telling you. Encoding order and dependency is most of the fifteen months.
So where did the AI go? Up.
Not away. Up a layer.
The deterministic engine produces what FluidCloud calls the fluid graph: the discovered infrastructure and its dependencies. That graph is the substrate. LIM, their Large Infrastructure Model, sits on top of it.
Harshit framed LIM through a question I liked. Why does a DevOps engineer ever change infrastructure? Three reasons, he says, and only three. Cost, because someone saw the bill. Security, because an audit found something. Performance, because last night didn't scale.
LIM reads which of those three you're trying to do and acts on the graph accordingly. It's intent interpretation over a structure that was built without it. Architecturally, a mixture of experts: several narrow models, controlled inputs, one consolidation step before anything reaches you. His words: it behaves like an LLM but is not one.
The division of labour is the whole point. The layer where a mistake is silent and expensive is deterministic. The layer where a mistake is a suggestion you can decline is where the model lives.
The context window problem it sidesteps
I asked what happens when the graph is too big to fit in a context window. A customer with a hundred-million-dollar bill overflows at step one.
Harshit confirmed the constraint and said they removed those limits internally. Because it isn't one LLM with a token budget but a set of models fed controlled slices, parts of the graph route to specific experts. That's a shape, not a mechanism, and I didn't get further. I'm flagging it as an open question, not an answer.
But the architectural point stands on its own, and it's worth stating plainly. No model ever sees the whole graph, because the deterministic layer already cut it into typed resources and explicit dependencies. The structure decides which fragment matters. The context problem isn't solved at inference time. It's designed away one layer down.
For AI Engineers
If your system needs an LLM to hold the entire problem in context, the problem might not be your context window. It might be a missing structural layer that should have partitioned the problem before the model ever ran.
Where the boundary actually falls
Here's the idea the whole piece is built on, stated as plainly as I can.
The determinism boundary is not a design preference. It's set by what a wrong answer costs, and whether that answer is loud.
Two questions decide it. If this component is wrong, does it fail loudly or silently? And if it fails silently, what does the silence cost before anyone notices?
Infrastructure conversion is the worst case on both. A bad mapping produces valid Terraform. It plans, it applies, nothing complains. The cost shows up later as an outage, a breach, or a bill. That combination is what puts it below the line. Not that it's technical, not that it's complex, and not that models are bad at it. Reasoning about resource equivalence is exactly what a model does well on average. Average is not the standard when the failures you miss are invisible.
Compare what sits above the line. If LIM misreads intent and suggests a cost optimisation you didn't want, you see a suggestion and say no. Loud, cheap, reversible. That's where a model belongs.
For Founders
Most teams draw this boundary by accident, in production, when they find out the hard way which part couldn't take a probabilistic layer. You can draw it on purpose, up front, by asking the two questions above about every component before you build it.
The part I keep thinking about: portability is decided years early
One thread from the conversation generalises further than FluidCloud itself.
Compute services translate easily. A VM is a VM, requires similar attributes such as CPU, memory, and OS, because Infrastructure as a Service offerings are similar on top of the same hardware. Identity and managed services are where the weeks go, because that's where providers deliberately differ. AWS IAM, Azure RBAC, and GCP's bindings aren't three implementations of one standard. They're three different theories of how access should work. And Cognito or SES aren't primitives, they're products, which is exactly why GCP and Vultr have no direct equivalent.
That difference isn't an accident someone will fix. It's the business model. The commodity layer is a price war, so the margin and the lock-in live in the proprietary services. A provider that made those portable would be handing customers the exit.
Which means your stack's portability was mostly decided years before any migration, at design time, by how much of it sits in that second category. Auth on Cognito is lock-in. Auth on OIDC with a portable provider keeps your options open. Same cost on day one, wildly different cost later.
For Founders
If cross-cloud optionality has any value to you, the cheap moment to buy it is when you first choose your auth, email, and queue layers. That's the one moment the portable option and the proprietary one cost the same. Every month you build on the proprietary choice, the price of ever leaving it goes up.
What it doesn't do
Harshit was straight about the limits, and they follow directly from the architecture.
It needs a live cloud account. Everything depends on discovering a running environment through provider APIs with read-only credentials. Point it at a GitHub repo full of Terraform and it can't help, because there are hundreds of ways people write Terraform and the system depends on the regularity a live account guarantees. They know roughly how it would work. It doesn't exist yet.
The mapping is a treadmill. Provider APIs change monthly, sometimes with breaking changes, across eight providers, and every change is maintenance on a hand-built rule set.
And they won't chase coding assistants. Extend into general Terraform authoring and you're competing with Claude and Codex on benchmarks FluidCloud doesn't have. Harshit doesn't think that's where the value is anyway:
"Nobody is having that confidence to give the keys of your infrastructure to these LLMs which can hallucinate at any point in time."
Writing Terraform is loud-failure work. Operating live infrastructure is silent-failure work. The whole company is built on that distinction.
Why he built it
Harshit was a founding engineer at Accurics, a cloud security company acquired by Tenable. Two experiences there became FluidCloud.
First: SpaceX became a customer but wanted the product on Azure. Everything was on AWS. Three months to build and validate the Azure deployment, three months a signed enterprise customer sat waiting and evaluating competitors in parallel. They held the deal on one custom feature the customer specifically wanted.
Second: after the acquisition, everything had to move from the Accurics AWS account into Tenable's. Same provider. Same services. Six to eight months of engineering time on pipelines, artifacts, and deployments, while the roadmap sat still.
"This thing should be automated. This thing should not waste any engineer's time."
AWS to AWS took most of a year. That's the frustration the company came out of.
The one-line version
Everyone is asking where to put the AI. The better question is where a silent error would cost more than the capability is worth, and that question has an answer before you write a line of code.
Part of an ongoing GOBIGAI series on how agentic systems are actually built. Reviewed by FluidCloud before publication. Corrections and pushback welcome - anirudh@gobigai.org
Anirudh Voruganti. GOBIGAI Consulting. gobigai.org