-
-
Cloud-Route
Inspiration
Moving apps to a new cloud in the wrong order breaks them. A bank's loan service cannot run before the ledger it depends on. AI models explain plans well, but when the same model was asked to plan the order on its own, the answer came with no guarantee. A wrong plan reads exactly like a right one. That gap inspired cloud-route: let code decide, and let the AI only explain.
What it does
cloud-route reads a live Kubernetes (K3s) cluster, builds the dependency graph, and computes the migration plan in ordinary code:
- safe phases, with cheaper services first inside each phase
- batch caps and rollback sets
- data-residency flags
- five security checks
- right-sizing suggestions from real CPU and memory use
An NVIDIA Nemotron 3 Super model, served through Nebius Token Factory, restates those results for an engineer, a PM or a client, and answers questions such as "what can go wrong?". It never decides, never invents, and never applies a change. A person does that.
How it was built
- Engine: Python and networkx. Topological generations become phases, and a cycle is an error, not something quietly fixed.
- Agent: a Strands agent with five tools. Tool output is the only source of facts the model may use.
- Notes search: twelve failure-mode notes, found by keyword and by meaning (BM25 plus Qwen3-Embedding-8B), then printed word for word by code.
- Grounding scan: checks every response against what the tools returned.
- Demo: bank-easy, a seven-service bank (Node/Express) running on K3s.
The overhead figure used to compare batch caps is a simple heuristic, not a measured cost:
$$\text{overhead}=\sum_{i=1}^{n}\text{cost}(P_i)\,(n-i+1)$$
where $P_i$ is phase $i$ and $n$ is the number of phases.
Challenges
- Prompts were not enough. Two rounds of careful wording did not stop the model from rewriting the notes, so printing them verbatim is now enforced in code.
- A false claim of our own. The project stated that a smaller batch cap never lowers overhead. The tests showed it does on 33 of 550 graphs. The claim was removed, and only the relations that hold are kept.
- Checks that could not fail. Each evaluator is run against deliberately broken copies of the code. Twice a broken copy slipped through, because the random data never reached that case. Adding the case fixed both.
- The grounding scan. On 48 real responses, hand labeling found 0 unsupported facts, but the scan raised 5 false alarms. A planted-fault test then showed what the scan misses, and four added checks closed most of those gaps. Two kinds are still missed.
What we learned
- Asked directly, the same model gave a complete, safe plan for 43 of 55 graphs. Four wrong plans came with no warning, and eight ran out of room. The engine got 55 of 55 under the same checker.
- A check proves little until it has been shown to fail on something broken.
- Report what a result does not show. This is a small test: one model, two prompts, mostly synthetic graphs, and one author.
Results
- 550 of 550 generated graphs pass, and 337 tests pass.
- The security scan agrees with Checkov on all five rules the two share.
- Hybrid search finds the right note first for 12 of 12 plain questions and 8 of 12 reworded ones.
What's next
Discovering dependencies from environment variables or a service mesh, right-sizing over time instead of one snapshot, and checking explanations with entailment models.
Built with: Python, networkx, Strands Agents, NVIDIA Nemotron 3 Super, Nebius Token Factory, Qwen3-Embedding-8B, K3s, Docker, Node.js and Express, Checkov.## Inspiration
Built With
- agents
- checkov
- docker
- express.js
- k3s
- kubernetes
- llm
- node.js
- nvidia
- pytest
- python
- qwen3-embedding
- rag
