The Scope Guard Caught 6 of 9. Name the Keys That Carry the Bill.

Becoming Forward Deployed Engineer published lesson 05 this morning, and it's the first one in the course that gives the agent commit access. Week two, someone else's repository, four other teams on call for it, and an agreement about what you may change that was a sentence somebody said on the kickoff call.

The lesson turns that sentence into a file, builds a guard, scores it, and then says exactly where the guard stops. I think it stops one check too early.

The short version

Lesson 05 of Becoming Forward Deployed Engineer gives an FDE a scope policy as a file (paths you may edit, paths you never touch, no deletes, no new dependencies, a cap on files per change, and forbidden strings) and a guard that checks every proposed change against it. On ten labeled changes it catches six of six mechanical violations and zero of three changes that break no rule and would still end the engagement. The lesson's claim is that this is not a gap you close by adding a check, because what was asked and what arrived can only be compared by a person. For two of the three misses that's right. The third, raising top-k from 5 to 20 inside an allowed file, is a cost change, and cost-bearing keys are a finite list the course's own lesson 04 already named. Add a seventh field, cost_bearing_keys, report any added line that sets one of them as a re-quote, and route it to the name on the cost line of the handshake. Six of nine becomes seven of nine. The other two stay a person's job.

What the lesson built

The policy has six fields, and the lesson's design notes on them are the best part.

The two path lists overlap on purpose, and never_touch is checked first and wins, so broadening a may_edit pattern can never unlock billing or infra. The deletion and dependency switches default to False, because a policy nobody has finished writing should refuse more than it allows; the opposite default fails silently, since an unfilled policy that allows everything looks exactly like one that passed. The guard has no early return, so a change that touches a forbidden path and adds a dependency reports both. And the content check reads added lines only, because flagging the removal of a leaked key is how you train people to stop reading the guard's output.

Then the measurement. Ten proposed changes, each labeled by a person before the guard runs. Six break one written rule each. One is exactly what the ticket asked for. Three break no written rule at all.

The run prints 6 of 6 on the mechanical classes. The lesson calls that boring on purpose: paths, delete operations, dependency files, file counts, and forbidden strings are things a program can see, and a program that sees them never gets tired at five o'clock.

Zero of three on the other column. Each of those is one file, inside the allowed paths, no delete, no dependency, and each does something nobody asked for.

The lesson's conclusion: "This is not a gap you close by adding a sixth check. The difference between 'add a log line' and 'add a log line and restructure the answerer' is a comparison between what was asked and what arrived, and only the second half of that is in the diff. The guard buys you the six. A person still owes you the three."

The miss I'd argue with

Look at the three misses separately, because they aren't the same kind of thing.

"Add the log line, and restructure the answerer while there." Pure scope creep. Nothing in the diff says the restructure wasn't wanted. Agreed, a person's job.

"Speed up the answer path," where a validation was removed inside an ordinary edit. No DELETE operation, because the lines came out of a file that still exists. The guard's deletion rule is about files; nothing in it is about behavior. Also agreed, with a note below.

"Fix the timeout, and raise top-k from 5 to 20." Three added lines in one allowed config file: the timeout the ticket asked for, a top-k of 20, and a cache flag. The lesson's own commentary on it: "Line two changes how much every question costs, which is the number lesson 4 spent a day establishing."

That sentence is the seventh check.

Lesson 04 measured a claims assistant at $60.19 a month for 120 adjusters and then built a sensitivity table: an agent that takes eight steps is 8x, ten times the context is 3.5x, retries on a flaky quarter is 1.2x, and all three together is 35x. I wrote about it yesterday in Approved on the Sixty, and the point there was that those multipliers get switched on by three sensible decisions that nobody prices.

Top-k from 5 to 20 is "ten times the context" in miniature. It's a multiplier being switched on inside a change labeled "fix the timeout." The guard can't read intent. It doesn't need to. It needs to know which keys carry the bill.

The layer rule says the same thing

I've already argued the structural version of this in Same Model, Twice the Bill: The FDE Codebase Contract. Every change an FDE makes belongs to one of three layers.

The customer layer: prompts, rules, thresholds, connector settings, the customer's eval rows. The FDE changes it the same day, no review, as long as it's versioned and diffs against the shipped default.

The harness: the tool set, the loop, context assembly, guardrails, model choice. The FDE changes it only by pull request, and the PR carries the cost per case before and after, because a harness change is a cost change.

The core: engineering only.

Top-k is context assembly. It's a harness change. The fact that it sits in the same config file as a timeout doesn't move it to the customer layer; it just means the file path can't tell you which layer you're in. The key name can. That's the whole reason to list the keys instead of the paths.

The agent drop: a seventh field

Here's the addition, in the shape of the lesson's own policy.

cost_bearing_keys = [
    "TOP_K",              # context per call
    "MAX_STEPS",          # steps per task
    "MAX_RETRIES",        # retries
    "CACHE_ANSWERS",      # caching
    "MODEL",              # model choice
]

One rule in the guard, in the same style as the others: for every added line in a change, if it assigns one of these keys, report a violation of kind re-quote, with the key and the new value. Added lines only, same as the content check, so removing a stale setting doesn't trip it.

Two things about the shape.

The list is the output of lesson 04, not a guess. The keys that belong on it are exactly the ones that moved the number in the sensitivity table, plus model choice, because a model swap moves the per-token rate under everything else. If your lesson 04 equivalent found different multipliers, your list is different. The point is that the list exists before the agent has commit access, and it's written by whoever measured the cost.

The violation routes somewhere specific. A re-quote isn't a block. It's the change going to the name beside that multiplier on the handshake, the one Approved on the Sixty says has to be there. Whoever owns "ten times the context" sees the top-k line, and the number gets re-quoted before the change lands rather than discovered in month eight.

Run the lesson's ten scenarios again with that rule and the top-k change flips from "nothing" to "re-quote." Six of nine becomes seven of nine. The restructure and the removed validation still pass, and they should still pass this guard, because they aren't this guard's job.

The two that stay human, and one of them is half a checker

The restructure is a person's call. There's no list that says "don't also refactor," and if there were, every useful change would trip it.

The removed validation is a person's call too, but it's the kind where a different instrument helps. A permission check that disappears inside an edit won't show up in a diff guard. It will show up in a test that asserts the check runs. That's the argument in Agents Read the Design System. Read Is Not Checked.: the lines that hold are the lines with a checker, and a scope policy is a reader's instrument, not a checker. The lesson's own suite does this for the labels, with a test that fails if a scope-creep scenario trips any mechanical rule. The same move, pointed at the permission check, is a test the customer's team probably already owns.

So the honest tally is: six mechanical, one cost key, one behavioral test that lives elsewhere, and one that is, and will stay, a person reading what was asked next to what arrived.

Why I'd ship this before the guard says no in front of a customer

The lesson's next installment is about the first time the guard refuses something with the customer's engineering manager on the call. I'd want the cost rule in before that call, for a reason I learned the expensive way.

Number 10 in 10 AI Agents I Built That Failed. The Honest Retrospective. is a four-agent content pipeline that cost 12 times a single agent and ran 8 times slower. Nobody approved a 12x. I approved "let's split this into specialists," which sounded like architecture and was a price. The keys that carried that bill had names. Nobody had written them down.

The scope guard is the right first instrument for an agent in someone else's repository. It should also know which three or four keys in that repository are the customer's bill, because those are the lines an agent will change for a perfectly good reason, inside an allowed file, while fixing a timeout.

This post is a standalone companion to The FDE Transition, and part of the AI Product Management argument that the parts of the job nobody trained for are the ones that remain. Knowing which config keys are a price is one of them.

This week: open the config file your agent edits most. Mark every key that changes cost per task. If you can't name them, that's the day of measurement lesson 04 describes. If you can, they're a seven-line list, and the guard can read it tomorrow.

Related answer: Can a scope guard catch a coding agent's cost changes?

Sources: Becoming Forward Deployed Engineer (author unnamed), "Lesson 05: Working Fast in a Repository That Is Not Yours," October 14, 2026, read in full; the scenario table, the 6 of 9 result, and the quoted conclusions are from the lesson's published run. Same publication, "Lesson 04: What the Working Half Costs," October 10, 2026, read in full, for the cost figures and the sensitivity table. 10 AI Agents I Built That Failed. The Honest Retrospective., falkster.com, May 4, 2026, for the four-agent pipeline.