Grow Your “Agentic Prompt” One Section at a Time

This series covers prompt patterns for agents that run in a loop: the agent builds something, measures it, improves it, and repeats the cycle the next day without a person supervising. Across this series I cover:

• How to grow a long prompt without it contradicting itself
• How to keep an agent from damaging the machine it runs on
• How to hand an agent a loop it can run without approvals
• How to let real usage tune an interface
• How to get creative output you don’t have to babysit
• How to make the loop improve its own prompts

These patterns are for builders whose agent work looks like mine. I write prompts for Claude Code and hand them to an agent that works on its own for hours. My agents run across many sessions, so the prompt has to carry everything the next session needs to pick up the work. I patch my prompts constantly, and before I used these patterns each patch made the prompt longer and less coherent. These patterns pay off on the second and later cycles of a loop, so one-shot prompts get little from these patterns.

My daughter is old enough to have a phone so she can keep up with her friends. I’ve come to the conclusion that notifications, infinite scroll, and algorithms tuned for engagement are producing adults with limited reasoning and focus. So I gave her a Light Phone. She can text, take photos, and listen to music, and she skips the cognitive denial of service attack that comes with a modern smartphone.

She also needs to start learning how to make things with AI, so I built her an Omarchy workstation. Then I realized a workstation for learning AI was a bit like putting her on a vegan diet. Veggies are nice and all, but learning needs some fun in it. Quake had an outsized influence on my origin story. Quake is the reason I learned TCP/IP networking, and Quake pulled me into hacking and security. Maybe Quake would do the same for her.

So I set out to build a Quake server she could play on with her friends. The project vends a game server, multiplayer clients that run on Mac, Linux, or a mobile browser, and a nightly SportsCenter-style recap of the night’s games, complete with breakfast awards we review the next morning. I wanted the server to make it worth practicing a few Linux commands every day. I wanted an agent to build, run, and keep improving the whole system, on a home server that already runs a bunch of services my family relies on.

Each pattern in this series is a small trick, usually a paragraph or two of prompt text. The value comes from how the patterns stack on each other. I’ve found these patterns produce productivity acceleration similar to compound interest. A savings account that earns interest grows slowly at first and then quickly. Each year’s gain becomes part of the base for the next year. These patterns work the same way for agentic development. A build plan that absorbs every successful experiment makes the next rebuild better. A log of every confusing instruction makes next week’s prompts clearer. Each cycle of the agent’s loop starts from a higher base than the cycle before.

This first post covers how to grow the prompt itself. I couldn’t write my agent’s prompt in one pass, and rewriting the prompt every time a gap showed up kept breaking rules I’d already gotten right. My build loop went through eight rounds. Each round surfaced a requirement I hadn’t planned for, like sudo commands on a shared box, iPads, and an LLM that talks to the kids during play. Each new requirement became a new section added to the prompt instead of a rewrite.

I found these practices produced large amounts of time savings while the prompt grew:

1. Wire every new section into the plan contents list, the acceptance criteria, and the directory layout. The agent decides what to build from the plan contents list, what to test from the acceptance criteria, and where to put files from the directory layout. A requirement missing from the plan contents list, the acceptance criteria, and the directory layout gets skipped, so wiring each new section into the plan contents list, the acceptance criteria, and the directory layout gets the new requirement built, tested, and stored.
2. Rank your goals in a numbered priority list at the top of the prompt. When two goals conflict, the agent follows the higher-ranked goal instead of guessing. Every rule section cites a priority number, so each goal keeps a single wording as the prompt grows.
3. Write one interpretation of each ambiguous requirement into the prompt, and tell the person who gave the requirement which interpretation you chose before the agent runs. The person can correct a wrong interpretation with one message, before the agent spends a week acting on the wrong interpretation.

My build objectives

I wrote the priorities first, in rank order, so the agent knows which goal to give up when two goals collide.

1. Protect existing services. Every service on this host keeps running exactly
   as it runs today. A Quake feature that risks an existing service gets
   dropped or redesigned.
2. Working LAN Quake. Quake clients on the LAN connect and play fun sessions.
3. Game modes. Deathmatch and Quake Team Fortress work.
4. Web app. A local web app serves players and the operator.
5. Creativity. The experience produces stories the family retells later.

Every rule section in my prompt opens by naming the priority the rule section protects. The standing rules section starts with “Each rule exists to keep priority 1 intact while you work.” When I added the privilege model section three rounds later, the privilege model section cited priority 1 instead of explaining again why the other services matter.

Problem: an agent hits conflicts between goals all the time, and a prompt that states its goals in several places gives the agent several different answers about which goal wins. Say the agent finds that QuakeWorld’s default port, 27500, is already taken by another service on the box. The networking section says players must be able to connect. The safety section says existing services keep running. If each section describes its own goal in its own words, with no ranking between the goals, the agent has no tiebreaker, and the agent can free the port by stopping the other service. The wording of the goals also drifts apart as the prompt grows, because each new section restates the goals a little differently, and after a few rounds two sections disagree about which goal wins.

Solution: I wrote the goals once, ranked, at the top of the prompt. Each rule section opens by naming the priority number the rule section serves. When two rules conflict, the agent compares the priority numbers of the two rules and follows the rule with the lower number. In the port example, priority 1 protects existing services and priority 2 is working Quake, so the agent picks a different free port and leaves the other service running. Later sections cite a priority number instead of restating the goal, so each goal has exactly one wording in the whole prompt and the sections stay in agreement as the prompt grows.

The pattern that carries over to any prompt: rank your goals once, in one place, and make every rule point to a rank. The ranking gives the agent a tiebreaker the agent can apply without asking you, and the single wording of each goal keeps new sections from redefining old goals.

Adding a section for each problem

When a new requirement showed up, I added a new headed section to the prompt for that requirement and left the existing sections as they were. My prompt is one markdown file with a heading per topic: priorities, standing rules, and one heading per build phase. Each requirement the file didn’t cover got its own heading. The new requirements showed up in this order:

Round	Problem that came up	Section I added
2	Some steps need sudo and could hurt other services	Privilege Model and Change Control
3	Claude Code on the host can generate content during play	Phase 4B: LLM-Powered Live Experiences
4	Players on iPads and iPhones need a way in	Research topic 10, iPad and iPhone play
5	Touch controls will need dozens of small tweaks	Phase 5B: Apple Device UI Fast Loop
6	I want a daily page that recaps the last session	Phase 4C: The Chronicler Agent
7	I want cheaper models doing most of the work	Orchestration and Model Tiers

Problem: rewriting the prompt to absorb the iPad requirement would have meant touching the server, client, and testing sections at once. This would result in the loss of prompt instructions that I’d worked hard to tune and that produced high quality results.

Solution: I wrote the iPad requirement as its own research topic and left the server, client, and testing sections untouched. A new section can only refer to things the prompt already names, so each new section forced me to name the things the new section needed to point at. The privilege model needed to tell “commands that touch only my project” apart from “commands that touch the whole server,” so I defined privilege tiers. The feature toggles needed a list of features, so I created a feature manifest file. Resuming after an interruption needed a place to read progress from, so I created the STATE/ directory. Every later section points at the privilege tiers, the feature manifest, and the STATE/ directory by name instead of describing them again.

The pattern that carries over to any prompt: when a new section needs to refer to something that only exists as scattered descriptions, give that thing a name and a file. Named things become stable reference points that later sections can cite without redefining them.

Wiring each new section into the build, test, and file lists

After writing a new section, I edit three other places in the prompt: the plan contents list, the acceptance criteria, and the directory layout. The agent reads the plan contents list to decide what to build, the acceptance criteria to decide what to test, and the directory layout to decide where files go.

flowchart LR
    P[Unanticipated problem] --> S[New prompt section]
    S --> A1[Build plan contents]
    S --> A2[Acceptance criteria]
    S --> A3[Directory layout]
    A1 --> B[Agent decides what to build]
    A2 --> T[Agent decides what to test]
    A3 --> F[Agent decides where files go]

Here’s the wiring for iPad support. The iPad research section was the new section. The edits below to the plan contents list, the acceptance criteria, and the directory layout made the agent build, test, and store iPad support.

Plan contents:

- Client bundle contents and install flow for Linux, plus the chosen iPad and
  iPhone path: browser client hosting and transport bridge, or native app
  build and install procedure, including any local TLS setup and the
  per-device onboarding steps.

Acceptance criteria:

- An iPad and an iPhone each complete the documented onboarding and join the
  same match as a Linux client, with playable frame rate and working touch or
  controller input.

Directory layout:

  ios-ui/   # Apple device UI configs, envelope, tests, telemetry, fast-loop log

The agent builds and tests iPad support only when the plan contents list and the acceptance criteria both list iPads. The agent builds the items in the plan contents list and tests the items in the acceptance criteria. A prompt with the iPad research section alone would get an agent that researches iPad options, writes a recommendation, and then builds and tests a Linux-only server.

Problem: a requirement described only in its own section stays out of the lists the agent builds and tests from, so the agent researches the requirement and never ships the requirement.

Solution: after adding a section, add a line for the new requirement to the plan contents list, the acceptance criteria, and the directory layout. I use the plan contents edit, the acceptance criteria edit, and the directory layout edit as a checklist every time the prompt grows.

Naming the files each phase produces

Every phase in my prompt ends with an Artifact line listing the files the phase must produce. The agent marks the discovery phase complete when these files exist:

Artifact: STATE/discovery.md, STATE/storage-decision.md, STATE/blog-howto.md,
STATE/healthcheck.sh, STATE/baseline-health.md

The listed files are the documentation for the phase, so the record of the phase is the work the agent already produced. The same files are also where a fresh agent session picks up the work after an interruption.

Stating which interpretation of an ambiguous requirement got encoded

When a requirement could mean two things, the prompt author writes one interpretation into the prompt and tells the person who gave the requirement which interpretation was chosen. I asked for a daily recap page that becomes “viewable the day after the last visit.” The phrase could mean the day after anyone’s visit or the day after a specific kid’s visit. Claude, drafting the prompt with me, chose the day after anyone’s visit, wrote that interpretation into the publication rules, and told me the choice in the same reply. Correcting the interpretation at that point would have taken one message from me. Correcting the interpretation after a week of the agent publishing on the wrong schedule would have meant reading logs to figure out why the page appeared on the wrong days.

What I’d do differently

I worked these practices out while the prompt was already growing. Starting the next project with these improvements in place from the first draft would make each round of growth cheaper.

I’d put empty headings for the plan contents list, the acceptance criteria, and the directory layout into the very first draft.
Why: without the headings in place, wiring each new requirement into the build, test, and file lists depends on my remembering to do it. A section that misses the wiring describes work the agent researches and never builds.
How: start the first draft with a “Plan contents” heading, an “Acceptance criteria” heading, and a “Directory layout” heading, each empty. Every time I add a section, I add one line under each heading in the same edit, so each new requirement reaches the build, the tests, and the file layout in the round I write the requirement.

I’d write the priority list before anything else and add only rules that name the priority they serve.
Why: a rule with no priority behind it gives the agent instructions without a reason, so the agent can’t tell how much the rule matters when the rule conflicts with another rule. Unranked rules also make the prompt longer without making it clearer.
How: write the ranked goals as the first section of the prompt. Before adding a rule, write the priority number the rule protects as the rule section’s first sentence. If no priority fits, either the rule is unnecessary or the priority list is missing a goal, and I fix the priority list first.

I’d keep a dated log of every interpretation chosen for an ambiguous requirement, in the prompt repo.
Why: interpretations get decided in conversation and then disappear from memory. When the agent does something odd months later, I need to know whether the agent is following an interpretation I approved and forgot, or whether the agent is making a mistake.
How: create an INTERPRETATIONS.md file next to the prompt. Each entry records the date, the original requirement wording, the interpretation chosen, the alternative that was rejected, and the prompt section that encodes the interpretation. Check that file first whenever the agent’s behavior surprises me.

Summary

A prompt for a long-running agent grows one requirement at a time, and these practices kept my prompt coherent through eight rounds of growth:

• Rank your goals in a numbered priority list at the top of the prompt, and open every rule section with the priority number the rule serves. The agent uses the ranking as a tiebreaker when goals conflict.
• Add a new headed section for each new requirement and leave the existing, tuned sections as they are. Give a name and a file to anything a new section needs to point at.
• Wire each new section into the plan contents list, the acceptance criteria, and the directory layout, so the agent builds, tests, and stores the new requirement.
• End every phase with an Artifact line naming the files the phase must produce. Those files serve as the phase’s documentation and as the restart point after an interruption.
• Write one interpretation of each ambiguous requirement into the prompt and confirm the interpretation with the person who gave the requirement before the agent runs.

The next post will cover guardrails for keeping an agent from damaging the machine it runs on.

---

---