The Loop: Re-Explaining Your Project to the AI Every Single Time

Welcome to The Loop. Every Wednesday we take one real, repetitive workflow that someone does by hand and unwind it into something you can run. This week: the four paragraphs you type at the start of every AI session to explain the project you explained yesterday.

The boring task you repeat is a specification in disguise. That briefing you retype is not conversation, it is configuration, and you have been delivering it by hand because it arrived in a chat window instead of a settings page. The moment you can describe what the model always needs to know, you can stop saying it and start loading it. Describing replaces doing.

This one shows up in the troubleshooting lane rather than the automate lane, because almost nobody files it as a workflow problem. It gets filed as a complaint about the model: it forgot, it lost the thread, it ignored what I said. Some of that is real and some of it is a loop with a person inside it. Let us separate the two.

The Loop, in Full

See the loop clearly before automating it, because two different failures are wearing the same costume. Dan is a solo consultant with three active clients. At 8:40 he opens a fresh chat and types the briefing: who the client is, what the product does, the eleven acronyms their team uses, the tone their marketing lead will accept, the two things the last draft got wrong, and the format he wants back. That takes six or seven minutes and he does it from memory, so some mornings it comes out complete and some mornings he forgets the acronym list and finds out forty minutes later. By 11am the session is long, he has pasted in two documents and changed his mind once, and the thing he asked for in the third message is no longer happening. He reminds it. It apologizes. It does it correctly for two turns and then drifts again.

1. Open a new session and retype the project briefing from memory.
2. Paste in whatever source material this task needs, usually more of it than necessary.
3. Work for a while, then notice an early rule has been dropped.
4. Restate the rule, get two good turns, watch it drift again.
5. Give up on the session, open a fresh one, and go back to step one.

Every step is easy, which is exactly why it never gets fixed. Nothing in that list requires judgment beyond "what does this model need to know before it can be useful," and you answered that question months ago. You just answer it out loud, from memory, every single morning, which is the signature of work that belongs in a file rather than in a habit. The repeating part is the briefing, and repeating parts are the ones you can hand off to a workflow that runs without you once you have written them down even once.

The Manual Tax

The cost is seven minutes a session, plus every output that came back wrong because the briefing was incomplete, plus the hour you spent not noticing.

The second half of this loop is measurable and worse than most people assume. In a study of more than 200,000 simulated conversations, Microsoft Research and Salesforce found that every leading model they tested performed significantly worse across multiple turns than on the same task stated once, with an average drop of 39%. Their decomposition is the useful part: aptitude barely moves, and unreliability climbs sharply. The model does not get dumber as the session grows. It gets less predictable, because it has made early assumptions, proposed solutions too soon, and now treats its own earlier attempts as evidence. That is not a quirk you can scold out of it.

• Errors. The expensive mistake is not the forgotten acronym, it is the output that looks right. A dropped formatting rule is obvious. A dropped constraint, the one that said never quote a dollar figure without the source, produces a clean, confident, publishable paragraph that is wrong in a way nobody catches until a client does. You then pay twice: once to redo the work and once in the trust you spend explaining it.
• Latency. The drift is discovered late by construction. You find out at turn twenty that turn three stopped applying, so everything between them is suspect and has to be reread. A seven minute setup cost is annoying. A forty minute review of work you already thought was done is the actual bill, and it lands on the days you are busiest, because those are the days the sessions run long.

A model that reliably knows nothing is easier to work with than one that unreliably remembers. You can supply what is missing. You cannot supply what has silently gone stale.

So the goal is not to get better at briefing. The goal is to stop briefing, by making the standing context a thing the workflow carries rather than a thing you perform, which is what it looks like to put the context your work depends on somewhere a machine can read it instead of somewhere only you can remember it.

Unwinding the Loop

Automating starts with description, not code. Write this loop down as a spec and the plumbing turns out to be trivial, while the decisions turn out to be the whole article.

Four of those rows are plumbing and two are judgment, and the two judgment rows are decisions you already make badly every morning without saying them out loud. Writing the spec first is also exactly how BYOBot turns a described task into a running workflow, so the description is not a preamble to the build, it is most of the build. The same move fixes a surprising range of tool fights, because telling a system what is always true is the thing that stops it guessing. It is the reason our installment on tables that arrive scrambled ends up being about defining the shape you want in advance rather than about pasting more carefully.

The Build: One Loop, Three Ways to Run It

The same described loop becomes three builds, and which one you want depends only on how hands-off you need it to be. Start at the top and stop whenever it is good enough.

The Prompt

You can close most of this loop today with no setup at all. Take the last three or four sessions where you typed the briefing by hand, paste them into any AI chat tool, and ask for the brief you should have been loading instead. You are mining your own repetition for the configuration hiding inside it.

Below are transcripts of several sessions where I briefed you
about the same project from scratch, plus the corrections I had
to make partway through each one.

Write me a STANDING BRIEF for this project. Rules for it:

1. One screen maximum. Shorter is better.
2. Include only lines that would change an answer if removed.
3. Use these sections, in this order:
     PROJECT     what this is and who it is for
     VOCABULARY  terms and acronyms, with expansions
     FORMAT      the shape every output must take
     HARD RULES  never/always, each with its one-line reason
     KNOWN TRAPS mistakes already made, stated as rules
4. Every rule must be checkable by looking at an output.
   Replace "be concise" with a number. Replace "match our
   tone" with three things our tone does and two it avoids.
5. Separate anything that is only true for one task into a
   second list called PER-TASK, which I will supply per run.

Then list, separately:
  (a) the corrections I repeated across more than one session,
      which are the rules that keep getting dropped, and
  (b) anything I briefed every time that never once changed an
      answer, which I should delete.

Do not invent rules I did not state or imply.

Save the result and paste it as the first message of every session, or load it as the project instructions in whatever tool you use. That alone removes the seven minutes and the from-memory gaps, and the audit in part (b) is usually a pleasant surprise: a third of the briefing was never doing anything. The same mining trick works on any instruction you keep retyping into any system, which is most of what people mean when they want to automate the documents their work runs on.

The Script

Here is the honest version: the build has no AI in it. Assembling a context pack, counting tokens, deciding what fits, and checking that the rules came back are all deterministic code, and the model is the consumer of this build rather than a participant in it. Two mechanics are worth knowing before you write it. The first is that position matters: models attend most strongly to the beginning and end of what they are given, so the hard rules go at the top and get restated immediately before the task, not buried in the middle where retrieval sags. The second is that repeating a fixed prefix is cheap if you let the provider cache it, which is spelled out in Anthropic's developer documentation, and you can measure what you are actually sending with a tokenizer such as tiktoken rather than estimating from character counts. If the standing brief needs to pull from live systems rather than a static file, the plumbing for that is standardized now in the Model Context Protocol specification.

BUDGET      = 60_000        # tokens, measured not guessed
BRIEF       = read("context/standing-brief.md")
RULE_IDS    = parse_rule_ids(BRIEF)     # e.g. [R1, R2, R3]

def pack(task, material):
    head = BRIEF                        # rules first
    body = trim(material, BUDGET - tokens(BRIEF) * 2 - tokens(task))
    tail = restate(BRIEF.hard_rules) + task   # rules again, last
    return head + body + tail

def run(task, material):
    if tokens(material) > BUDGET - tokens(BRIEF) * 2:
        return [run(t, m) for t, m in split(task, material)]

    out = model(pack(task, material))
    missing = [r for r in RULE_IDS if not satisfied(r, out)]

    if missing:
        log("rules not met", task, missing)
        return retry_once(task, material, emphasize = missing)

    return out with header(rules_in_force = RULE_IDS)

Three details carry the value. The brief is counted twice in the budget because it appears twice, top and bottom, and that duplication is the cheapest reliability you will ever buy. The split is on the task, never on the rules, so a chunked job is many complete runs rather than one run with amnesia in the middle. And the satisfied() check is the part people skip, because a rule nobody verifies is a rule that will quietly stop applying and never announce it. BYOBot will generate the working version against your actual tool and model, including the token accounting and the retry policy, so that you can load your standing context on every run automatically rather than remembering to.

The Schedule

Now make it boring. There is no clock in this loop, so the schedule tier is not about when the work runs, it is about keeping the brief alive. Two jobs on a timer do it. First, a weekly pass that reads your logged satisfied() failures and reports which rule is being dropped most often, because that rule is either badly worded or doing too much. Second, a check that fails loudly when the standing brief grows past its one-screen budget, since briefs rot by accretion and a bloated one puts your real rules back in the middle where they get ignored. A cron entry on any always-on machine runs both, and so does the free schedule trigger in GitHub Actions. Review the brief on a calendar, not on a feeling, because the day you notice it is stale is a day it already cost you something.

Steal This Build

Here is the whole loop as a spec you can copy into your own stack this afternoon, or hand straight to a system that will turn the description into a running workflow for you.

• Trigger: the start of every run against this project, enforced by the code rather than by your memory.
• Load: a one-screen standing brief from a file you own and version, never from recollection.
• Pin: the hard rules at the top of the context and again immediately before the task.
• Split: the task when the material will not fit, so every chunk carries the full brief.
• Report: which rules were in force on the output, and log every rule the output failed to meet.

The shape is universal. Somewhere in your week there is knowledge that exists only in your head, gets delivered by hand to a system that cannot keep it, and goes missing the moment you are the one who forgets. Swap the AI session for a new contractor, a support macro, or a monthly report template, and the spec barely changes: write the standing part down, load it every time, verify it survived. Most of what gets called routine work you can hand to a bot is this exact pattern wearing a different hat, and the file you write today is the one every future build reads.

Frequently Asked Questions

• Why does the AI forget my instructions halfway through a long session?+
  Two different things are happening and they have different fixes. The first is that a new session starts with nothing, so anything you said yesterday is gone unless you supply it again. The second is that inside one long session your early instructions compete with everything that came after them, and models attend most strongly to the start and the end of what they are given. A rule buried in the middle of a long transcript is still technically present and still gets ignored. Pinning the rules at the top and restating them at the point of use fixes far more than asking the model to try harder, and writing them somewhere durable is the first step toward context that loads itself on every run.
• Is a longer context window the answer?+
  It raises the ceiling and it does not fix the shape of the problem. A bigger window lets you paste more in, but retrieval accuracy still sags in the middle of a long input, and a long session still accumulates superseded instructions, abandoned attempts, and wrong turns that the model keeps treating as evidence. The cheaper move is to put less in, on purpose: a short standing brief that never changes, plus only the slice of material this one task actually needs.
• What should go in a standing context file?+
  Only the things that are true on every run and that you would otherwise retype: the project and what it is for, the vocabulary your team uses, the output format you always want, the hard rules with their reasons, and the three or four things you have already told it not to do. Keep it to one screen. The test for every line is whether leaving it out would make the model get something wrong, and anything that fails that test is making the useful lines harder to see.
• Do I need AI to build this?+
  Not at runtime, and that is the honest part. Assembling a context pack, counting tokens, splitting work into chunks that fit, and checking that the rules came back in the output are all plain code with no model involved. The model is the consumer of this build, not a participant in it. AI helps earlier: drafting the standing brief from the briefings you have already typed by hand, and flagging the instructions you keep repeating because they keep getting dropped. That split is how most durable builds look once you put the repeating part on a workflow.