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

> Prompts matter less than people think. The leverage is in what you hand the model up front, and in turning a proven workflow into something that runs without you.

Source: https://christwentyfour.com/working-with-claude

## The operating thesis

Use the model for the slow work of finding a method. Then encode the method in a script, a pipeline stage, or a scheduled agent with a fixed prompt.

If a model re-solves the same problem every morning, you are paying for it twice.

A good session ends with something reusable: a script, a runbook, a check in CI. An answer alone is half the value.

## Brief before you prompt

I reviewed a week of my own sessions. Prompt wording did not separate the fast sessions from the slow ones. The context in the first message did. So I standardized the opening with five fields:

**session brief**

```text
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 ninety seconds and saves about ten minutes of questions. The **Constraints** line matters most. It stops the model proposing what you already ruled out.

## What wastes a session

**Don't:**

- **Sparse openers.** A one-line question that is really step one of six.
- **Hidden constraints.** "We already tried that." You knew that before you started.
- **Raw error dumps.** One sentence plus the error line is faster.
- **"It's in my config somewhere."** Paste the value. Every search costs a turn.
- **Hidden multi-step goals.** Revealing the real objective one step at a time blocks planning.

All five are information you already had.

## Give it a role and a format

**Do:**

- **Assign a role.** "Act as a senior SRE reviewing this pipeline for failure modes" finds different problems.
- **Specify the output.** A table, a diff, a numbered runbook. Unspecified output defaults to prose.

For infrastructure, name the region, service names, and tool versions. For anything that touches a live system, add: *"explain what this command does before running it."* That clause has caught more mistakes than any other habit here.

## Guardrails

Agents get real access: cloud read APIs, CI, tickets, repos. That works because the limits come first.

**Do:**

- **The five-minute rule.** If an action cannot be reversed in five minutes, a human approves it.
- **Read wide, write narrow.** Most of the value is correlation and triage.
- **Everything is a draft.** A human owns every decision that reaches production.
- **Log the tool calls.** When an agent is wrong, the sequence of calls explains it.
- **Track success rate.** A quietly degrading agent is worse than one that fails loudly.

## Agents that run on a schedule

Once a workflow is proven interactively, it becomes a scheduled agent with a fixed prompt. I run three types:

| Type | Trigger | Examples |
| --- | --- | --- |
| **Loop** | On a schedule, during working hours | Watch CI for new failures and open or update a ticket; hourly digest of production deploys; cost-anomaly checks |
| **Workflow** | Human-triggered, one task | Set up a workspace for a ticket; deep-triage one pipeline failure |
| **Reporting** | Periodic, read-only | Pull requests with no activity in three days; tickets aging in review; weekly opened-vs-closed snapshot |

Reporting agents are read-only. Loop agents write only to low-stakes places. None of them can take production down, which is why I let them run unwatched.

Every agent has a named owner, a list of sources, a permission scope, and a review date. An unowned agent keeps running after an API changes and starts producing garbage.

## Runbooks as a byproduct

Nobody writes the runbook during an incident. But the session transcript already records every command, in order. So the last step of any operational task is to ask for the runbook while the context is loaded.

**after the work is done**

```text
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 next time that failure appears, the runbook is the prompt.

## MCP: giving it real context

The Model Context Protocol lets a model call your systems directly: cloud APIs, CI servers, ticket systems, databases, local files. The expensive part of a prompt goes away. The agent queries the cluster instead of you describing it.

**Do:**

- Scope each server's credentials to the minimum. Review an MCP server like an access grant.
- Prefer read-only servers for anything touching production.
- Keep a registry of approved servers and their owners. Unmanaged tools are a security problem.

## Where I don't use it

**Don't:**

- **Irreversible production actions.** The downside is unbounded and the upside is a few minutes.
- **Decisions that need organizational context.** The model has facts and no politics.
- **Anything I cannot evaluate.** If I cannot tell a good answer from a confident wrong one, I should learn the subject first.
- **Work that is already deterministic.** If a script can do it, a script should.

The model brings breadth and speed.

I bring judgment about which answer is right in this system.