Salesforce Engineering has published how it rebuilt an AI agent that rewrites production infrastructure settings so that it could be trusted. The post is dated 9 June 2026 (updated 11 June), and this article reflects what I read on 13 October. The conclusion: adding more prompt text or more agents did not make the agent consistent; it became dependable when the team gave ambiguous investigation to the AI and handed the calculations that must give the same answer every time to a solver.
First, what the post does not say. It contains no results such as money saved, number of changes made, or hours cut. The "millions of dollars" is described as potential savings, not an amount achieved. It says reliability "improved dramatically", but gives no figure for how much. This article therefore covers only the architecture and the reasoning that can be confirmed.
What the AI was asked to do
The target is the CPU configuration of thousands of production services on Salesforce's Hyperforce infrastructure. According to the post, 86% of containers ran at under 20% of their requested CPU, leaving roughly half of the provisioned capacity idle (from cloud economics data). Reducing that waste was the goal.
The hard part was that there was no single source of truth for those settings. CPU values were scattered across Terraform, Helm and Structured Configuration systems, with environment- and region-specific overrides on top. One service could hold several CPU values with different precedence rules, and the value that controlled production was often not the one that looked like it did. The post says the team was not automating a process humans had mastered; it was asking the agent to solve a problem engineers themselves often struggled with, and then to generate the production infrastructure change based on its answer.
Two approaches that did not work
- ▸First: bigger prompts. The first version gave the model repository access, utilization data and instructions for discovering and changing CPU settings. It worked on simple repositories and struggled as they got more complex. In one repository the Helm chart value looked right, but an environment-specific override actually controlled production. Each discovery added instructions, examples and exceptions until the prompt "resembled software written in English", and reliability did not improve.
- ▸Second: splitting into agents. The team divided the work across agents for repository discovery, optimization planning, pull request generation and verification. Yet the same repository, utilization data and goal could produce a different plan or pull request on each run. Upgrading models, refining prompts and adding reviewer agents did not remove the inconsistency.
The post says this is where the team changed its view. The question became: "were we asking the model to solve problems that should never have been assigned to a model in the first place?"
The rebuilt architecture (as far as the post shows)
- ▸1. Investigate (AI): an agent examines the repositories and produces a structured description of where settings are defined and which ones actually control production.
- ▸2. Compute (solver): that output goes to an integer linear programming (ILP) optimization engine. It treats configuration layers as decision variables and optimizes several goals at once: reduce wasted CPU while keeping configuration complexity low. What the post values most is that the same input always produces the same answer.
- ▸3. Make the change (AI): the result is passed to another agent that applies the changes and generates the pull requests. The post calls this "Reasoning, then deterministic computation, then reasoning."
- ▸4. Check (machines): builds, compilers, linters, validation scripts and CI pipelines evaluate actual system behavior, not model confidence.
The five principles the post draws
- ▸1. Separate reasoning from computation. Language models suit ambiguity; deterministic software suits precision. "If the logic can be expressed as a deterministic algorithm and validated with tests, it probably shouldn't live inside the model."
- ▸2. Use deterministic systems for deterministic problems. Optimization, scheduling, allocation and arithmetic go to established solution methods rather than repeated LLM reasoning.
- ▸3. Treat context management as a reliability problem. Every instruction and example competes for the model's attention. "Skills" kept instructions dormant until needed, and sub-agents isolated specialized work from the parent's context. The post says skills improve instruction relevance and sub-agents improve context isolation.
- ▸4. Build verification into the architecture. The team added reviewer agents, but "explanations are not evidence." They occasionally caught mistakes but gave no guarantee for production infrastructure changes. A hierarchy of deterministic checks (builds, CI and so on) decides: an agent counts as successful only when objective validation confirms it is correct.
- ▸5. Improve the harness, not just the prompt. Ask "what change would make this mistake harder to repeat?" Arithmetic mistakes point to missing deterministic computation; context confusion points to poor context isolation.
How to read the numbers (our view)
- ▸"86%" is the starting condition, not a result. "86% of containers run at under 20% of requested CPU" explains why the team took on the problem; it is not an amount the agent reduced.
- ▸"Millions of dollars" is an estimate. The post says "potential" savings and does not state what was actually recovered.
- ▸Reliability "improved dramatically" is all it says. The post gives no success rate or variance figure.
- ▸The five principles come from one system. The post does not say they were tested in other domains.
What I could not confirm
- ▸The human approval flow. The post covers up to generating pull requests, not who reviews them or when they reach production.
- ▸The model or agent framework used. Not published.
- ▸The solver's exact formulation and performance. The post explains only the variables and goals.
- ▸Realized savings, number of services covered, failure rate. Not stated (only the estimate of potential savings in the millions of dollars is given).
- ▸Whether it has been extended to other uses inside the company. The post does not say.
What to take from this case (our view)
- ▸Splitting what you give to AI is useful beyond infrastructure. Ambiguous reading goes to the AI; calculations and tallies that must be identical every time go to ordinary programs. Dividing work by type is what the post credits for the steadier results.
- ▸Do not accept "the AI checked it" as the check. The post says having one AI watch another is not enough. A mechanical check that actually runs (build, tests) works well as the last gate.
- ▸When it fails, look at the system before adding more instructions. The post describes how adding instructions made things harder to manage.
- ▸This case alone does not show how large the benefit is. With no published results, try it on a small scope and measure with your own numbers.