• Shape — One session per activity. Start a fresh one when the subject changes.
  • Placeholders — Anything in ‹angle marks› is yours to fill in.
  • The rule underneath — The agent runs commands. You decide what they mean.
  • Read alongside — Each session names the phase it belongs to in the cost runbook.

How these sessions are meant to run

An agent with shell access and a cloud credential is a fast, tireless analyst with no memory of your company and no instinct for which of its own answers are shaky. It will produce a confident table on request every single time. Almost everything below is structured to counteract that.

Keep three things constant across every session. Work from a read-only credential until you have decided to destroy something specific. Make the agent show the command and its output rather than summarising, so you can see what it actually looked at. And keep a durable notes file outside the conversation — the analysis is worth having in a month, and a chat window is not where it survives.

Survey the system before you know anything about money

Phase I.

Do this first and separately, so that the architecture picture is formed without the bill influencing it. You want to be able to compare the two afterwards and see the gap.

Bring

  • Every repository checked out locally
  • Any architecture notes that exist, however stale

Leave with

  • A service inventory: what runs, what it talks to, which managed services it depends on
  • Saved into your notes file, not just the transcript

Example prompt

Survey the repositories under ‹path›. For each one tell me what it is, what it talks to, and which managed cloud services it depends on. Build a dependency picture across all of them.

Do not recommend anything yet and do not guess at cost. If a dependency is referenced but you cannot tell what it is for, say so explicitly rather than inferring.

Judge the reply by whether it names concrete services and connections, and whether it admits to at least one thing it could not work out. A survey with no gaps in it has been smoothed over.

Introduce the bill and look for what the code did not contain

Phase I.

This is the highest-value conversation in the whole exercise. Everything the code survey got wrong becomes visible here, and the most expensive thing you own may be something no repository mentions.

Bring

  • Last full month’s cost export, grouped by service and by region
  • Ideally the same data by usage type, not only by service
  • The survey from the previous session

Leave with

  • The baseline total, written down and dated
  • A per-service breakdown you will reconcile against later
  • A list of charges you cannot yet attribute to anything

Example prompt — attach the cost export

This is last month’s bill. Reconcile it against the architecture survey above.

Three questions, in this order. First: what appears on this bill that did not appear anywhere in the code? Second: for the largest lines, is the cost coming from capacity, from request volume, or from stored data — because those have completely different fixes. Third: which of your earlier conclusions does this bill contradict?

Do not skip the third question. An agent will happily fold the new data into its previous story rather than admit the story was wrong. Asking directly for the contradiction is what turns the bill into a correction instead of a confirmation.

Strip out the charges that are not engineering problems

Phase I.

Short session, disproportionate payoff, no technical risk at all. Do it before anything that requires thought.

Bring

  • The full bill, including the small lines nobody reads

Leave with

  • A short list with a named owner against each item

Example prompt

Go through every line of this bill and separate them into two lists.

One: charges that no code change will ever fix — fees, penalties, support plans, commitments covering retired capacity, idle addresses and endpoints, anything administrative.

Two: everything else.

For the first list, say who would have to act and roughly what it is worth to stop paying it.

Sweep every region for things that are already dead

Phase II.

Run this against every region that shows any charge at all, not just the one you work in. The second prompt matters more than the first: an inventory is easy, and the judgement about what is safe to remove is where the risk lives.

Bring

  • A read-only credential covering every region on the bill
  • The code checkout, for reference-checking

Leave with

  • A kill list, each entry carrying its evidence and its date
  • An explicit note of anything being kept as a fallback, and what retires it

Example prompt

For every region with a charge on this bill, inventory: running and stopped compute, volumes and their attachment state, snapshots, queues and streams with their traffic in the last thirty days, load balancers with no healthy targets, and anything registered to a cluster that has stopped reporting.

Show me the commands and their raw output, not a summary.

Example prompt

Now for each candidate: what is your evidence that it is dead, and what evidence would change your mind? Check the code for references before you answer. Rank them by how confident you are, and tell me which ones you would not delete without asking a human who was here at the time.

Judge the reply by whether it distinguishes “no traffic for thirty days” from “no code references it” from “someone told me it was deprecated”. Those are three different strengths of evidence and only the third is really conclusive.

Establish the break-even before changing any billing mode

Phase II.

The failure here is subtle: reserved capacity that looks lightly used gets moved to pay-per-request, and the request charges turn out to exceed what the reserved capacity cost. Ask for the threshold, not the recommendation.

Bring

  • Metrics read access, with at least sixty days of history
  • Current published prices for both billing modes

Leave with

  • Utilization per resource, and the break-even utilization as a number
  • A separate list of resources that sit above the break-even and must not be switched

Example prompt

For every ‹resource type› on reserved capacity, pull consumed versus provisioned for the last sixty days.

Then work out the break-even: at what utilization does pay-per-request stop being cheaper than the reserved capacity it replaces? Derive it from current prices and show the arithmetic. Do reads and writes separately, since they price differently.

Split the resources into those clearly below break-even, those clearly above, and those close enough that the answer depends on load staying where it is.

The third group is the dangerous one. Anything near the break-even is a bet on load not changing. Before switching those, ask what would make their traffic increase, and put an alarm on the request volume rather than on the monthly total — the monthly total tells you in arrears.

Resize, then verify from the other end

Phase II.

Split this across two sessions with the change in between. The second one is the part that gets skipped, and it is the only reason you would find out that the saving cost you something elsewhere.

Bring

  • Utilization history, plus whatever latency data you have from before
  • Knowledge of which fleets are frozen and which are actively developed

Leave with

  • A recorded before-and-after for latency and error rate
  • A note of every other service whose load changed as a result

Example prompt

Here is the utilization history for ‹fleet›. Propose a target size.

Before you do: tell me what this measurement cannot see. Specifically, how much of the current memory is doing cache work that will simply move to the database if I shrink it, and what latency objective I should record now so I can tell afterwards whether this was a mistake.

Example prompt — days later, after the change

The resize is live. Compare p99 latency and error rate against the figures we recorded beforehand.

Then look at the whole bill, not just the compute line: did request volume or cost rise anywhere else in the same window? I want to know whether this saving simply moved.

Price a migration honestly before committing to it

Phase III.

Use the agent adversarially here. It is naturally inclined to be encouraging about a plan you have already half-decided on.

Bring

  • The current cost of the service being replaced
  • Realistic pricing for the replacement, at your actual data volume
  • An honest estimate of who is available to do the work

Leave with

  • A written decision record whose justification is not primarily financial
  • A list of consumers that will each need migrating

Example prompt

I am considering replacing ‹service› with ‹replacement›. Price it as a project rather than as a line item: the running cost of the replacement at our real data volume, the engineering time, and the risk.

Then argue against it. If the saving alone had to justify the effort, would this be approved? If the answer is no, tell me what the non-financial case is — obsolescence, capability, portability — or tell me there isn’t one.

Judge the reply by whether it is willing to say the migration is not worth it on cost grounds. Most are not, and the honest ones proceed anyway for different reasons.

Compare old against new, exhaustively, as the main activity

Phase III.

This is where the weeks actually go. Expect to run dozens of these, and expect most of the real findings to be behaviours of the old system that nobody had written down.

Bring

  • A configuration switch already in place, so consumers can move one at a time
  • Both systems reachable, with real data in each
  • Whoever built the original, on hand for the odd question

Leave with

  • A running log of every difference found and its resolution
  • A written list of undocumented behaviours the old system provided

Example prompt

Run ‹query› against both the old and the new system. Page both to completion rather than comparing the first page, and show me every record present in one and absent in the other.

Example prompt

For each difference, classify it: a bug in the new implementation, a bug in the old one we have been living with, or a behaviour the old system provided that we never specified anywhere.

The third category is what I care about most. List those separately — they are the requirements nobody wrote down.

Expect this to find real bugs in production. Comparing two implementations of the same thing surfaces defects that have been live for years and that neither system’s tests cover. Budget time to fix them; they are not a distraction from the migration, they are its main return.

Establish who is still calling, from traffic rather than from source

Phase III.

Run this immediately before deletion, not weeks earlier, and cover a full traffic cycle so that the weekly job at four in the morning is included.

Bring

  • Access logs from every load balancer or gateway, including the ones you forgot exist
  • Request metrics for the service itself

Leave with

  • A caller inventory with a last-seen timestamp against each
  • Confirmation of whether the deletion can be undone

Example prompt

I want to delete ‹service›. Do not rely on the code search — I have already done that and I do not trust it.

Use access logs and request metrics from the last full week to tell me what is still calling it, when each caller was last seen, and whether anything only appears at a particular hour or day.

Also confirm: can this service be restored after deletion, and if it is recreated does it come back at the same address?

Judge the reply by whether it checked more than one log source. Traffic that shifts between gateways looks exactly like traffic that stopped, and reading only one of them produces a confident and completely wrong answer.

Reconcile the claims against a real invoice

Phase IV.

Book this session before you start cutting. It is the one that converts a list of expectations into a result, and the interesting part is always the changes that did not land.

Bring

  • The baseline breakdown from the second session
  • A full invoice from after the changes settled
  • Your list of claimed savings with dates

Leave with

  • A per-service comparison marking each claim as confirmed, partial, or failed
  • A cause for every failure, traced to a specific event and date

Example prompt

Here is the baseline and here is the current invoice. Compare them per service.

For each saving I claimed, mark it confirmed, partial or failed. Then spend your effort on the failures: for each one, break the service down by usage type and tell me which component moved in the wrong direction, and find the date it started.

Also list any service that got more expensive, whether or not I touched it.

Example prompt

Take the one that failed hardest. Pull the daily series for the underlying usage metric and correlate the inflection date against everything else that changed around then — deployments, resizes, migrations, traffic.

I want the cause, not a plausible story. Tell me which parts you have evidence for and which parts are inference.

This is where the real finding usually is. A saving that did not materialise is rarely an accounting error. It normally means something else changed in the same window — often another one of your own changes — and the reconciliation is the only place that connection becomes visible.

Leave the guardrails and the unfinished list behind

Phase IV.

Last session. Its entire purpose is to make sure the next person, who may be you in a year, does not start from nothing.

Bring

  • Every deferred item still outstanding
  • Anything still running purely as a fallback

Leave with

  • Alarms on the variables you uncapped, not only on the total
  • A dated cleanup list stored in the repository, not in a conversation

Example prompt

Write up everything still outstanding as a checklist I can commit to the repository: items deferred, resources kept only as a fallback with the condition that retires each one, and anything we decided not to do and why.

Then propose the smallest set of alarms that would have caught each problem we found in this exercise, including the ones we found by accident.

Prompts that keep the agent honest

Drop these into any session. They cost one line and they are the difference between analysis and a well-formatted guess.

  • Label each claim: measured, inferred, or assumed. Forces the confidence tiers that a summary table flattens out.
  • Show me the command and its raw output. Lets you see what was actually examined rather than what was reported.
  • What did you not check? Surfaces the regions, log sources and time windows that were quietly out of scope.
  • What would change your mind? Converts a recommendation into a testable claim before you act on it.
  • This looks suspicious. Re-derive it. Use it whenever a number feels too tidy. Being wrong is recoverable; being confidently wrong for two months is not.
  • Which of your earlier conclusions does this contradict? New evidence gets absorbed into the existing story unless you ask for the conflict directly.
  • Argue the other side. Particularly before any migration, deletion, or anything else you cannot undo.

Documentation that has to outlive the conversations

Everything below belongs in version control alongside the code. A transcript is not documentation: it cannot be searched by the next person, it does not survive a cleared history, and nobody will read it.

  • baseline.md — The starting invoice, dated, broken down per service and per usage type. Every later claim is measured against this one file.
  • changes.md — What was changed, when, by whom, and the evidence it was safe. This is what you read in three weeks when something looks wrong.
  • deletions.md — Anything destroyed irreversibly, with the verification that preceded it and where the backup went, if there was one.
  • fallbacks.md — Everything still running only as an escape hatch, each with the condition that retires it. Without this file the overlap becomes permanent.
  • reconciliation.md — Claimed against actual, per service, per invoice. Including — especially including — the claims that failed.
  • undocumented-behaviour.md — Anything the old system did that nobody had specified, found by comparison during a migration. The most valuable artifact produced by the whole exercise, and the easiest to lose.

Companion to the cost runbook. The sessions are in working order; the traps are in the order they were discovered.