Seed-Stage DevOps SaaS Built an AI Cloud Operations Agent

Skionis is a DevOps AI agent for cloud infrastructure teams. It turns natural-language infrastructure requests into validated cloud templates and applies them to live AWS accounts. The promise to its users is a tall one: describe what you need in plain English, get back production-ready infrastructure on your own account, with a full record of what changed and why.

Cloud changes sit in an awkward middle. They are too routine to deserve a senior engineer's afternoon and too consequential to hand to someone junior with a template. So they queue. Someone writes the config, someone else reviews raw YAML they did not write, and the request that started it is three tickets back by the time anything ships.

The obvious fix — have a model write the config — fails in a specific and instructive way. A raw model asked to generate cloud infrastructure invents resource types and properties that do not exist. It ignores account quotas and region limits. It reaches for services the account has disabled. And when one of those templates fails, the stack can take minutes to roll back, so a generate-then-apply loop is not slow, it is unusable.

Underneath that sat a cleanup problem the team already had. Resources created by hand were poorly tagged and effectively untraceable, so nobody could say which project, tool or conversation had produced what. Cost attribution was archaeology. So was deciding whether anything was safe to delete.

And underneath that sat the real blocker, which was not technical at all. Engineers want infrastructure automation. They will not let an agent touch production without guardrails they can see. Any version of this product that asked for trust up front was going to be refused, correctly.

• Produce the same infrastructure twice, rather than a script that drifts on every run

• Plan against the real account, its actual limits, quotas, regions and existing resources

• Prove a change is valid before applying it, not discover it during a rollback

• Leave a record afterwards that says who owns each resource and which request created it

We built Skionis as a closed loop rather than a one-shot generator. A planning agent turns a free-form request into a structured spec and an explicit chain of tools, then works through it: read the account, generate the template, validate it, show the engineer what will exist, and only then apply.

One rule shaped the whole architecture, and it is the reason the product got adopted: the agent is treated as untrusted. Every step it takes is either something the system can verify or something a human can review. Nothing depends on the model being right.

That inverts how most AI infrastructure tools are sold. The usual pitch asks an engineer to believe the model is good enough. This one assumes it is not, and builds the checks that make the question irrelevant. It is a slower thing to build and a much easier thing to adopt.

The review surface is the clearest example. Before anything is touched, the agent renders a diagram of the proposed change. Approving a change stops being a matter of reading raw templates and becomes a matter of looking at what will exist — which is a review a team lead can actually do, at the speed the work arrives.

Design decision: the agent plans against your real account rather than against a general idea of AWS. A template that is theoretically correct and violates your quota is not a smaller problem than a malformed one.

An engineer describes what they need

In plain English, at the point they need it — not as a ticket that waits for someone who knows the template language.

The agent reads the account first

Live limits, quotas, regions and existing resources, before it plans anything. It is working against the reality of your account rather than a guess about it.

It validates until the change is clean

The template is checked and refined in a loop until it is structurally correct and valid for the provider. Most errors die here, before AWS ever starts a change.

An engineer approves a picture, not a file

The agent renders the proposed architecture. Review becomes a glance at what will exist rather than a close read of config someone else wrote.

It applies safely and labels its work

Changes go out through controlled change sets with retries, so a failed run does not strand half-built resources. Everything created is tagged with its owner, environment, tool and originating request.

What the agent is allowed to do

It never receives open authority over the account. Live account checks, deterministic templates, provider validation, the architecture review, controlled change sets and mandatory tagging each bound what a change can be. The diagram is the human gate; the tags are what survive after execution.

What runs, in what order

Inspect the account, plan, generate, validate, revise anything invalid, render the architecture, apply the change set, then inspect the result. Retries exist both before and during provider execution, specifically so a partial failure does not leave orphans behind.

What you can see afterwards

One record connects the original request to the account facts it was planned against, the template, every validation failure and revision, the architecture preview, the provider's response, the retries, and the resources that now exist. That is what lets an operator answer the four questions that actually get asked: what changed, why, who owns it, and is the cloud in the state we asked for.

Skionis became a product engineers trust with real infrastructure rather than a demo that presents well. The validation loop cut template errors before deploy from around 10% to 4%, and account-aware planning stopped quota breaches and unsafe configurations — unencrypted storage, mis-scoped security groups, accidental public exposure — before they could reach production.

The adoption change mattered more than either number. Engineers went from refusing to let an agent near production to letting it own routine cloud changes. Nothing about the model made that happen; the review surface did.

• Template errors before deploy fell from ~10% to 4%, with the loop catching most failures before AWS starts a change

• Guardrails that hold, cutting quota breaches and unsafe configurations off before production

• Every agent-created resource traceable to an owner, environment and request, delivered as a working product in about four months

What is directly demonstrable in the product: live account inspection, the validation loop, the architecture preview, controlled change sets, resource tagging, and a working system we still run against a real AWS account.

The figures are our own. The 10%-to-4% error change and the four-month delivery are internal records from the build, not client-audited results. The tagging claim is the one to treat most carefully — our record says every agent-created resource is tagged, and we would want that re-verified on current traffic before anyone quotes "100%".

For your own estimate: cloud changes per month × current engineer handling time, plus what a failed change and its cleanup actually cost you, minus review and exception time. For most teams the failed-change term is the one that dominates and the one nobody measures.