Eliminate IaC drift Sedai's new IaC Mapping Agent | Sedai

Sedai has always been able to find the right optimization. Now it can eliminate IaC drift at the same time.

The drift problem no one talks about

If you've worked with an optimization or autoscaling tool alongside a GitOps workflow, you've almost certainly hit this wall. The tool makes a good call — right-sizes a deployment, adjusts a memory limit, tunes replica counts. Your cluster reflects the change. Everyone's happy.

Then your CD pipeline runs.

Whatever Argo CD, Flux, or your own Terraform automation has on file is what gets applied. The optimization is silently overwritten. You're back where you started — or worse, now you're chasing an incident that looks like a regression but is actually just config drift.

IaC Drift Problem

The real fix isn't to patch around your IaC. It's to make the optimization part of your IaC. That's what the IaC Mapping Agent does.

What the IaC Mapping Agent does

When Sedai identifies an optimization, the Mapping Agent determines the precise file, line, and field in your repository where that value lives, then Sedai raises a PR to change it. Your IaC becomes the source of truth for Sedai's recommendations, not a system it has to work around.

The challenge we had to solve first: no two teams represent their infrastructure configs the same way. Some companies keep one repo per cluster; others have a repo per microservice. Helm values, Terraform variable files, Kustomize patches — all valid, all different. You can't hardcode a mapping for this.

So instead of prescribing how you should structure your IaC, the agent learns how you already do it.

Every optimization Sedai makes reduces to a single atomic operation: find a specific resource, locate its config file, identify the field, update the value. The IaC Mapping Agent makes that operation reliable and repeatable, regardless of how you've organized your infrastructure code.

How it works: two-step mapping

We built the agent around two sequential phases. The key was designing each phase to be reviewable and correctable by a human, because even the best automated extraction benefits from a sanity check.

Step 1: Conventions Extraction

Point the agent at your IaC repository. It scans the file tree and derives your organizational conventions — how you map clusters to folders, namespaces to files, deployments to config blocks. These conventions are surfaced as plain-language statements you can review, edit, and approve before anything else happens.

Here’s an example of what that conventions extraction looks like:

Step 2: Resource Mapping

Using your approved conventions as a guide, the agent maps every resource Sedai manages to its exact file and line in the repo. For Kubernetes workloads, this means CPU requests, CPU limits, memory requests, memory limits, and replica counts, all mapped to specific paths. You approve the output; from that point on, every optimization automatically becomes a PR.

Here's what an extracted resource mapping looks like in practice.

Once you approve that mapping, it's permanent. Any future optimization targeting that resource goes straight to a PR against those paths.

Human-in-the-loop, by design

We've thought carefully about where automation should stop and human judgment should begin. The answer: at every boundary between "what we inferred" and "what you intended."

The extracted conventions are shown in plain language, not YAML or JSON, because they describe organizational decisions a person made, and a person should be the one to confirm them. The resource mappings are similarly surfaced for review before they're locked in. You can edit either at any point.

PR auto-merge is deliberately not enabled by default. We want the engine to earn your trust before operating autonomously. Once it does, you can open that gate — but the system is designed so you never have to if you'd rather keep humans in the loop on every change.

Before and after

Before	After
Sedai optimizes the cluster; CD pipeline overwrites it next deploy	Optimizations surface as PRs in your repo — CD pipelines apply them
SREs maintain manual CSV or tag-based mappings for each resource	Agent infers mappings from your existing repo structure automatically
Config drift is invisible until something breaks	Drift is impossible: IaC is always the source of truth
IaC and live state diverge continuously	Live state and code stay in sync continuously
Every new resource requires manual onboarding effort	New resources are mapped in minutes, not hours

What's supported today

The initial release covers both Kubernetes and non-Kubernetes resources. We started with Kubernetes because its structure made it possible to validate high-confidence mapping quickly, and that same two-step model — conventions extraction, then resource mapping — now extends to non-Kubernetes resources as well.

Supported managed fields in this release:

Kubernetes Workloads: CPU request, CPU limit, memory request, memory limit, and replica counts — across Deployments, StatefulSets, and DaemonSets, with full support for multi-container pods. Helm, Terraform, and Kustomize formats are all handled.
Non-Kubernetes resources: Support for serverless functions (Lambda), ECS services, and other non-Kubernetes compute is now available. The two-step conventions + mapping model is identical — only the convention taxonomy changes to match the resource type.
Repository integrations: GitHub, GitLab, and Bitbucket are all supported. For GitLab, use the project_id as the repository path. For GitHub and Bitbucket, the standard owner/repo format applies.

How this relates to Guardrails as Code

Recently, we announced Guardrails as Code. If you're using Guardrails as Code today, the Mapping Agent complements it — they're not alternatives. Guardrails encode the constraints on what Sedai is allowed to do (architecture families, min/max ranges, node constraints). The Mapping Agent determines where in your IaC those decisions get written back. You'd use both: guardrails to bound the solution space, the Mapping Agent to ensure every decision within that space lands in the right file.

What's next

The foundation is in place across both Kubernetes and non-Kubernetes resources. Here's where we're taking it.

Auto-merge: Today, every PR the agent raises requires a human to approve and merge. That's intentional — we want the engine to prove itself before you hand it the keys. But the capability is built, and for teams that reach that level of trust, auto-merge will be a configuration option. We'll be rolling that out as customers get comfortable with the system in production.
Streamlined onboarding for large-scale environments: We'll be honest: if you're running thousands of microservices across many repos, the initial mapping review is a real time investment for your SRE team. That's a known limitation, and we're actively exploring ways to reduce that toil — things like bulk approval flows, convention extrapolation across clusters, and smarter grouping to cut down the number of decisions a person needs to make. The agent already does the authoring; we want to make the reviewing faster too.