What is the Sedai IaC Mapping Agent and what problem does it solve?
The Sedai IaC Mapping Agent is a tool that eliminates Infrastructure as Code (IaC) drift by making every optimization part of your IaC workflow. When Sedai identifies an optimization (such as rightsizing a deployment or adjusting a memory limit), the Mapping Agent determines the exact file, line, and field in your repository and raises a pull request (PR) to update it. This ensures your IaC remains the source of truth, preventing configuration drift that can occur when CD pipelines overwrite live optimizations. Note: The initial mapping review can be time-consuming for large environments. Source.
How does the IaC Mapping Agent work?
The IaC Mapping Agent uses a two-step process: (1) Conventions Extraction, where it scans your IaC repository to learn how your infrastructure is organized and surfaces these conventions for your review and approval; (2) Resource Mapping, where it maps every resource Sedai manages to its exact file and line in your repo. Once approved, every optimization becomes a PR against those paths. Human review is required at each step, and PR auto-merge is not enabled by default. Note: For teams with thousands of microservices, the initial mapping review is a known limitation. Source.
What types of resources and formats does the IaC Mapping Agent support?
The IaC Mapping Agent supports both Kubernetes and non-Kubernetes resources. For Kubernetes, it manages CPU requests, CPU limits, memory requests, memory limits, and replica counts across Deployments, StatefulSets, and DaemonSets, including multi-container pods. Supported formats include Helm, Terraform, and Kustomize. For non-Kubernetes resources, it supports serverless functions (Lambda), ECS services, and other compute types. Repository integrations include GitHub, GitLab (using project_id), and Bitbucket. Note: Some advanced or custom resource types may require manual mapping. Source.
How does the IaC Mapping Agent ensure safety and human oversight?
The agent is designed with human-in-the-loop controls: all extracted conventions and resource mappings are surfaced in plain language for review and approval before any changes are made. PR auto-merge is off by default, so every change requires explicit human approval. You can edit mappings at any point, and the system is designed to earn trust before enabling full autonomy. Note: For teams seeking full automation, auto-merge can be enabled after sufficient validation. Source.
How does the IaC Mapping Agent relate to Sedai's Guardrails as Code?
The IaC Mapping Agent complements Guardrails as Code. Guardrails as Code define the constraints and boundaries for what Sedai is allowed to optimize (such as architecture families, min/max ranges, node constraints). The Mapping Agent determines where in your IaC those decisions are written back. Both are used together: guardrails to set policy, the Mapping Agent to ensure every optimization is reflected in code. Note: Using only one without the other may limit the effectiveness of autonomous optimization. Source.
What are the main benefits of using the IaC Mapping Agent compared to manual mapping or traditional optimization tools?
The IaC Mapping Agent automates the process of mapping optimizations to your IaC, eliminating manual CSV or tag-based resource mapping. It ensures that optimizations are surfaced as PRs in your repo, so CD pipelines apply them and live state stays in sync with code. This reduces configuration drift, minimizes manual onboarding effort, and makes drift impossible when IaC is always the source of truth. Note: Initial mapping for large environments can require significant review time. Source.
What are the limitations of the IaC Mapping Agent?
The main limitation is that the initial mapping review can be a significant time investment for teams with thousands of microservices or large, complex repositories. Bulk approval flows and smarter grouping are being explored to reduce this toil. Additionally, PR auto-merge is not enabled by default to ensure safety, and some advanced or custom resource types may require manual mapping. Source.
How does the IaC Mapping Agent fit into Sedai's broader platform and cloud optimization capabilities?
The IaC Mapping Agent is part of Sedai's autonomous cloud optimization platform, which delivers up to 50% reduction in cloud costs, up to 75% latency reduction, and up to 6X productivity gains for engineering teams. It ensures that optimizations made by Sedai are reflected in your IaC, keeping code and live state in sync and eliminating drift. For more on Sedai's platform, visit Sedai's platform page. Note: The Mapping Agent is most effective when used alongside other Sedai features like Guardrails as Code and Release Intelligence. Source.
Technical Requirements & Implementation
What repository integrations are supported by the IaC Mapping Agent?
The IaC Mapping Agent supports GitHub, GitLab, and Bitbucket repositories. For GitLab, use the project_id as the repository path; for GitHub and Bitbucket, use the standard owner/repo format. This allows the agent to raise PRs directly against your infrastructure code. Note: Integration with other version control systems is not currently documented. Source.
How long does it take to implement the IaC Mapping Agent?
Initial setup for the IaC Mapping Agent can be completed in minutes for smaller environments. For large-scale environments with thousands of microservices, the initial mapping review may require a significant time investment from your SRE team. Sedai is actively exploring ways to streamline onboarding, such as bulk approval flows and smarter grouping. Note: The agent already automates authoring; review time is the main bottleneck for large deployments. Source.
Pricing & Plans
How is Sedai priced and is there a free trial?
Sedai uses a resource-based pricing model, where you pay based on the resources optimized and the value delivered. For Kubernetes environments, tailored pricing is available. Sedai offers a free Proof of Value and a 30-day free trial, allowing you to evaluate the platform before committing. All costs are transparently outlined on the Sedai pricing page. Note: For specific pricing details, contact Sedai's sales team. Source.
Security & Compliance
What security and compliance certifications does Sedai have?
Sedai is SOC 2 certified, demonstrating adherence to stringent security requirements and industry standards for data protection and compliance. For more details, visit the Sedai Security page. Note: Additional certifications are not publicly documented; contact Sedai for specifics. Source.
Support & Documentation
Where can I find technical documentation for the IaC Mapping Agent and Sedai?
Comprehensive onboarding resources, including getting started guides and detailed documentation for Kubernetes, Databricks, and GPU optimization, are available at docs.sedai.io/get-started. These resources help users set up and optimize their environments effectively. Note: For advanced use cases or troubleshooting, contact Sedai support. Source.
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.
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.
Ready to try it in your environment?
Book a Sedai demo to speak with a technical expert.
