Use the model to find the method, then encode the method

The operating thesis

The way I think about these tools borrows from how the brain handles a skill. You learn something slowly and deliberately, and then, once the method is proven, it gets myelinated into something fast and automatic that no longer requires conscious attention.

This changes what "good output" means. A great Claude session doesn't end with an answer; it ends with something reusable: a script, a runbook, a ticket template, a check that now runs in CI. If a session produces only an answer, I got the smaller half of the value.

Brief before you prompt

I reviewed a week of my own sessions once, sorted by how much back-and-forth each took. The efficient ones and the painful ones weren't distinguished by prompt wording at all. They were distinguished by how much context existed in the first message.

So I standardized the opening. Before anything non-trivial, I fill in five fields:

I need to [GOAL: the end state, not the first step].

Where:      [repo / service / resource, with a path]
Auth:       [which profile or credential, and where it lives]
Scope:      [every expected step, numbered]
Constraints:[what's already been tried, what must not change]
Starting:   [one sentence of current state, or the key error line]

It takes about ninety seconds and it routinely saves ten minutes of clarification. The Constraints line does the heaviest lifting. It's the one that prevents the model from confidently proposing the thing you already ruled out last week.

What actually wastes a session

Five patterns account for nearly all of the wasted turns I've observed in my own transcripts:

• Sparse openers. A one-line question that turns out to be step one of six. The model plans for the question you asked, then has to re-plan five times.
• Hidden constraints. Rejecting suggestions mid-session with "we already did that." You knew that before you started.
• Raw error dumps. Pasting 400 lines of terminal output. One sentence of summary plus the actual error line is faster and produces better answers.
• "It's in my config somewhere." Making the model search for a value you could have pasted. Every search is a turn you paid for.
• Hidden multi-step goals. Revealing the real objective one step at a time, which prevents any planning at all.

The common thread is that all five are information you already had. This is the same principle as writing requirements as desired state: vague inputs produce unverifiable work, whether the worker is a person or a model.

Give it a role and a format

Two cheap adjustments that consistently improve technical output:

• Assign a role. "Act as a senior SRE reviewing this pipeline for failure modes" produces materially different output than "review this pipeline." The role sets the failure modes it looks for.
• Specify the output shape. A table of options with trade-offs, a diff, a numbered runbook. Say which. Unspecified format defaults to prose, which is the least useful form for operational work.

For anything involving infrastructure, I also name the exact environment: region, service names, tool versions. Generic prompts get generic answers, and a generic answer about AWS is usually wrong in the specific way that matters.

And for anything that touches a live system: "explain what this command does before running it." That single clause has caught more mistakes than any other habit on this page.

Guardrails

I give agents real access: cloud read APIs, CI systems, ticket systems, repositories. That only works because the boundaries are drawn before the access is granted, not after something goes wrong.

• The five-minute rule. If an action can't be reversed in five minutes, a human approves it. This is the same threshold I use for deployments, and it maps cleanly onto agent permissions.
• Read wide, write narrow. Most of the value is in correlation and triage, which needs broad read access and almost no write access.
• Everything is a draft. Agent output is a proposal. A human owns every decision that reaches production.
• Log the tool calls, not just the answers. When an agent gets something wrong, the reasoning is rarely the interesting part. The sequence of calls is.
• Track success rate as a metric. An agent quietly degrading is worse than one that fails loudly, because you keep trusting it.

Agents that run on a schedule

This is where the myelination idea becomes concrete. Once a workflow is proven interactively, it becomes a scheduled agent with a fixed prompt. I group mine three ways:

Notice the split in permissions. Reporting agents are read-only and can run unattended forever. Loop agents write only to low-stakes destinations: a ticket comment, a daily note. Nothing on that list can take production down, which is exactly why I'm comfortable letting them run without watching.

Each agent gets a named owner, an explicit list of context sources, a permission scope, and a review date. An agent nobody owns is one tooling change away from silently producing garbage. The ticket schema changes, the API renames a field, and it keeps running.

Runbooks as a byproduct, not a project

Documentation loses to urgency every time. Nobody writes the runbook during the incident, and afterwards the details are gone.

But a session transcript is already a complete record of what was done, in order, with the actual commands. So the last step of any operational task becomes:

Generate a runbook from this session.

Format:      numbered steps, exact commands, expected output per step
Include:     the failure mode that started this, and how to confirm the fix
Exclude:     the dead ends we backed out of
Assume:      the reader is on-call at 2am and has not seen this before

The runbook is written while the context is still loaded, at close to zero marginal cost. And the next time that failure class appears, the runbook is the prompt, which is the point at which the work stops requiring a person at all.

MCP: giving it real context

The Model Context Protocol is what turns a model from something you paste into, into something that can actually see your systems. It exposes tools (cloud APIs, CI servers, ticket systems, databases, local files) that the model discovers and calls on its own.

The practical effect is that the expensive part of a prompt disappears. Instead of describing the state of a cluster, the agent queries it. Instead of pasting logs, it fetches them. Most of what made prompting tedious was manual context transfer, and this removes it.

• Scope each server's credentials to the minimum it needs. An MCP server is an access grant, and should be reviewed like one.
• Prefer read-only servers for anything touching production.
• Keep a registry of which servers are approved and who owns them; unmanaged tool sprawl here is a genuine security problem, not a tidiness problem.

Where I don't use it

Being useful about this requires being honest about the boundaries:

• Irreversible production actions. Not because the model is bad at them. It is that the downside is unbounded and the upside is a few saved minutes.
• Decisions that need organizational context. What to prioritize, what to deprecate, who needs to be in the room. The model has the facts and none of the politics.
• Anything where I can't evaluate the output. If I couldn't tell a good answer from a confident wrong one, I have no business shipping it. That's a signal to go learn the thing, not to delegate it.
• Work that's already deterministic. If a script can do it, a script should do it. Paying a model to re-derive a solved problem is the failure mode this whole page is arguing against.