{"slug": "first-autonomous-agentic-system", "title": "First Autonomous Agentic System", "summary": "Cloudgeni announced it is now a fully autonomous cloud platform, with an agent that scans AWS, Azure, GCP and OCI, selects the next improvement to make, writes the fix, validates it with `terraform plan` and opens a pull request without a human pointing it at a finding. The company said its earlier dashboard-with-a-button model cut customers' time to close a compliance gap by up to 90% and moved them from click-ops to full infrastructure-as-code in about four weeks, and that the new autonomous step runs on Opengeni, its open-sourced runtime for long-running agents with durable sessions, approvals, scoped credentials and an audit trail.", "body_md": "# Cloudgeni is now the first truly autonomous cloud platform\n\nWe started with dashboards, then an agent behind a button, then guardrails. Now the agent finds the next improvement, does the work and gathers the evidence, and leaves you with one decision.\n\nWe started the same way everyone in this space starts: connect the cloud account, pull in the resources and the findings, and put it all on a dashboard. Then we added an agent, then we added guardrails, and now we're shipping the thing we actually set out to build two years ago. This post is about what that means, and why it took three steps to get here.\n\n## Step one: a dashboard with a button\n\nThe first Cloudgeni scanned AWS, Azure, GCP and OCI, normalized findings from Security Hub, Defender and Prowler, ran Checkov over your Terraform and Bicep, and compared what your code says with what your cloud actually does. Next to every finding was a button, and when you clicked it an agent picked up that finding, wrote the fix in your repository's style, validated it with `terraform plan` and opened a PR.\n\nIt worked well. Customers went from click-ops to full IaC in about four weeks, and the time to close a compliance gap dropped by up to 90%.\n\nBut look at who is still doing the work in that model. Someone has to open the dashboard, read through the list, understand each finding and decide which one deserves an agent today. We added prioritization and the list got a better sort order, but the cognitive load of deciding what to work on stayed exactly where it was.\n\nThat model is not so different from the old tools. If the job is \"a human reads a finding and points an agent at it\", you can already do that by pasting the finding into Claude Code or Copilot and getting a patch back. A dashboard with a remediate button is a better version of the old tool, but it is not a new kind of tool.\n\nI wrote about this last year: with most coding agents the engineer guides the agent, and what we wanted was the other way around, where the agent guides the engineer.\n\n## Step two: context and guardrails\n\nBefore an agent can decide for itself what to fix, two things have to be true. It has to know enough about your environment to make a good call, and you have to be able to control how far it goes.\n\nContext was the first half. We built repository discovery that maps your root modules and Bicep scopes, a cloud inventory that captures the relationships between resources rather than a flat list, and compliance mappings on every finding. You can write custom policies in plain English and they are enforced next to CIS and SOC 2. Organization memory means the agent remembers your standards, your runbooks and why that one exception exists, instead of relearning all of it every session.\n\nGuardrails were the second half, and this is where Opengeni came from. We needed a runtime for long-running agents with durable sessions, approvals, scoped credentials and an audit trail, so we built it, open-sourced it, and now Cloudgeni runs on it. We have written about that elsewhere, but the short version is that an agent loop on its own holds credentials, forgets everything on restart and stops whenever the model feels done, and the runtime is everything around the loop that makes it safe to leave running.\n\nWe did not build the guardrails so we could market them. We built them because without them the next step would have been reckless.\n\n## Step three: it runs on its own\n\nHere is what Cloudgeni does now once you turn it on. The scans keep running across security, compliance, drift, observability and cost, which was always true. What's new is what happens after a scan: the agent looks at everything it found across all of those areas and picks the next improvement worth making.\n\nThat is not simply the top of a severity list, but the change that is highest value, lowest risk and actually fixable in code today. A public storage account in production comes before a missing tag, a security group somebody opened by hand in the console comes before a cosmetic policy violation, and an alert rule that would have hidden the last incident gets fixed before the next one happens.\n\nThen it does the work. It researches the fix, writes it in your repository's conventions, runs the validation and the tests, gathers the evidence, and opens a PR that contains the reasoning, the finding it addresses, the validation output and the cost delta. You review it like anything else from a teammate, and it never pushes to main.\n\nIt does this across four areas, which it treats as one backlog because that is how infrastructure actually breaks, and the expensive resource is often also the drifted one.\n\n**Security.** Compliance findings and your own custom policies are turned into code fixes that are validated against your real environment before you see them.\n\n**Monitoring.** The observability loop ingests signals, correlates incidents, checks them against live state and proposes the remediation from your runbooks, and it treats missing or noisy alerts as findings like any other.\n\n**Cost.** Every PR carries a cost estimate before it merges, and oversized or idle resources show up in the same backlog as improvements worth making.\n\n**Drift.** Anything that was changed by hand in the console is either reconciled back to code, or imported into code if it was never there in the first place.\n\nIt works in your PRs too. The same agent reviews every pull request your team opens, reads the diff against your live cloud and your policies, and comments before merge, and when the fix is obvious it proposes the fix instead of just pointing at the problem. What you accept and what you reject goes into memory, so the next PR is closer to what you would have written yourself.\n\n## Autonomous means you choose the level\n\nPeople hear \"autonomous\" and assume it means handing over the keys. That is not what we mean, and it is not how it works. Autonomous means the agent is capable of doing the whole job by itself, and you decide how much of that job you want it to do.\n\nAt the lightest level it observes and suggests: it runs continuously, looks at your environment, and tells you what it would change and why, without creating a single branch. One level up it proposes, which means it proactively does the work and opens pull requests, and nothing merges without a person. At the governed level it acts inside policies you have defined, for the categories of change where you are comfortable with that, and every action is recorded and reversible. There is also a kill switch that stops everything in the workspace regardless of the level you set, and any session that is already running loses its write access immediately.\n\nWhatever level you pick, the point is the same. The agent does the finding, the prioritizing, the research, the evidence gathering and the testing, so that what reaches you is not a list of forty findings to triage but one decision: do I accept this change or not? Everything you need to make that decision is already attached to it.\n\nThat is also what separates this from most of what gets called autonomous today. A dashboard with a chatbot still waits for you to ask the right question, and a scheduled job that opens the same PR every Monday is not deciding anything.\n\n## What changes for your team\n\nYour platform engineers stop being the queue. Findings no longer wait for someone's free afternoon, and drift doesn't pile up until the audit. Review becomes the job, and reading a PR with a clear rationale and saying yes or no takes a senior engineer a few minutes, which is a good use of a senior engineer.\n\nYou also pick the pace. Most teams will start by letting it observe for a couple of weeks to see what it would have done, move to proposals once they trust the output, and then allow governed changes for the categories where they are comfortable.\n\n## Try it\n\nIf you are already on Cloudgeni, open your workspace settings and set the autonomy level, starting with Observe. The first report of what it would have changed is usually the most convincing thing we can show you. If you are new, connect a cloud account and a repository, and the first proposals will be waiting before your next standup.\n\nWe started like everyone else, and we just kept going.", "url": "https://wpnews.pro/news/first-autonomous-agentic-system", "canonical_source": "https://blog.cloudgeni.ai/cloudgeni-first-truly-autonomous-cloud-platform/", "published_at": "2026-09-24 10:44:21+00:00", "updated_at": "2026-09-24 11:02:03.659832+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "mlops", "developer-tools"], "entities": ["Cloudgeni", "Opengeni", "AWS", "Azure", "GCP", "OCI", "Security Hub", "Prowler"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/first-autonomous-agentic-system", "markdown": "https://wpnews.pro/news/first-autonomous-agentic-system.md", "text": "https://wpnews.pro/news/first-autonomous-agentic-system.txt", "jsonld": "https://wpnews.pro/news/first-autonomous-agentic-system.jsonld"}}