Roadmap

Drift detection and import will run on a recurring schedule through a managed queue, in addition to running on demand from a session. Teams will learn that live infrastructure has diverged from its code, or that unmanaged resources have appeared, as soon as the next run completes.

Today both operations run on demand; see Remediate drift and Import infrastructure.

Kumoss will bring existing cloud infrastructure under management from scratch: it will discover the resources in a scope, generate the compliant Infrastructure as Code that describes them, and create the repository that holds it. Infrastructure built outside code will get a governed, version-controlled starting point in one step.

Starting from an application repository, Kumoss will analyze the application to identify the infrastructure it needs, then generate that infrastructure together with its state configuration. An application and the platform it runs on will move to a running deployment along one reviewed path.

Kumoss will render a diagram of the infrastructure a project manages and highlight how a request changes it before the change is merged. Reviewers will see the impact of a plan visually, alongside the code diff.

Any request will be able to run against all projects or a selection of them, instead of one project at a time. A platform team will be able to ask, for example, to update the tags of all storage accounts, or to apply a new security baseline, and Kumoss will run the request in every targeted project. Each project goes through the usual generation, validation, and reporting phases, and the outcome reaches reviewers as one pull request per project with a summary of what changes where, so the team can approve, adjust, or reject the change project by project.

A single request will be able to target several projects at once. A team will be able to ask, for example, to add a new database to a list of projects, and Kumoss will run the generation, validation, and reporting phases for each project, tailoring the code to the conventions and compliance rules of each one. Progress and results will be tracked per project, so a failure in one project does not block the others.

Today a session works on a single project; see Follow a session.

An evaluation harness will score generated code, plan outcomes, and the accuracy of compliance verdicts against a versioned set of reference scenarios for each operation and cloud. Together with automated tests that run on every change, it will catch regressions in prompts, orchestration, and services before they reach a release.

Kumoss will publish benchmark results showing how supported language models perform on its own tasks, measuring the quality of generated code, compliance accuracy, cost, and latency. Operators will choose the models in their configuration based on evidence; see LLM providers and models for the models Kumoss supports today.

Kumoss will evaluate every plan against deterministic policies written in Rego with Open Policy Agent, including policies an organization already maintains outside Kumoss. These checks will run alongside the existing language-model compliance audit, adding a rule-based layer that returns the same result every time.

A governance overview will give administrators a single view of the resources and projects across every connected cloud, showing which are managed as code and how many comply with or violate the active policies. Platform and security teams will see their compliance posture at a glance and move from a finding straight to the session that fixes it.

Cost estimates for each plan will come from cloud pricing data instead of a language-model approximation, and will cover usage-based resources where pricing allows. Teams will set cost thresholds per project or environment that send a change for review before it is applied when the threshold is exceeded.

Today the estimate is an approximation for comparison; see Follow a session.

A cost overview will show what each resource, project, and cloud costs, combining billing data with the infrastructure Kumoss manages. Administrators will spot idle or oversized resources and turn them into a request that fixes them, in the same view as the governance overview.

Kumoss will exchange cost data with external FinOps platforms and AI-based FinOps assistants through an open contract, using the FinOps Open Cost and Usage Specification (FOCUS) where possible. FinOps tools will be able to ask Kumoss for a cost-saving change as a reviewed pull request, and Kumoss will use their recommendations as context when it generates code.

Kumoss will expose its capabilities through the Model Context Protocol, so that MCP-compatible assistants and IDEs can request compliant infrastructure directly. The same guardrails and review flow will apply to every request, whichever client sends it.

Support for the Agent2Agent protocol will let other AI agents discover Kumoss and delegate infrastructure tasks to it. Kumoss will then act as a specialized agent within larger multi-agent workflows.

An official Helm chart will deploy Kumoss and its sidecars on Kubernetes, with production-oriented defaults for configuration, secrets, and scaling. It will complement the Docker Compose stack, which remains the quickest way to evaluate Kumoss; see Deploy to production for the options available today.

A guided installation wizard will walk operators through the first setup of models, identity provider, Git, cloud credentials, and storage, validating each step as it goes. Operators will reach a working deployment without editing configuration files by hand.