Yesterday a clever build shipped, and the twist is buried in step two.
Long agent sessions have a way of drifting. You ask for one thing, twenty steps later the agent is confidently solving a problem you never mentioned. Anyone who has run a coding agent for more than an hour has watched this happen: the task starts crisp, then somewhere around tool call fifteen the agent starts “helpfully” refactoring a file you never asked it to touch, or chasing an edge case that has nothing to do with the original ask.
That’s the exact pain a builder on r/PromptEngineering set out to fix. The original poster, u/NoKaleidoscope1748, kept watching agents lose the plot in long sessions, so they built a skill to keep the original goal parked in front of the agent until the job is actually done.
The project is called “reasoning-doctrine,” and it lives inside a broader repo named governed-agent-skills. The idea is simple on paper: instead of letting context get buried under layers of tool calls and side quests, the skill keeps re-surfacing the stated goal so the agent has to check its work against it. Think of it less like a prompt tweak and more like a recurring alarm that forces the agent to stop and ask “does this still match what I was told to do?”
One commenter, u/Maleficent_Roll2705, put the underlying problem well: agents spiral into tangents halfway through, and the original intent gets buried under ten layers of nested context. That’s the failure mode this skill targets directly, and it is worth sitting with for a second, because it names something most people only notice after the fact, once the output is already wrong.
Here’s the twist: this isn’t a bigger model, a longer context window, or a smarter prompt template. It’s a governance layer that sits on top of whatever agent you’re already running. The fix for “the agent forgot what we were doing” isn’t more intelligence, it’s a forced checkpoint.
That reframes the whole problem. Most people try to solve drift by writing longer system prompts or repeating instructions every few turns, hoping repetition alone keeps the model anchored. This approach treats it like a process control issue instead, closer to a checklist a pilot runs before takeoff than a prompt tweak. A pilot doesn’t re-read the flight manual mid-flight and hope for the best. They run a fixed checklist at fixed points, every time, no matter how routine the flight feels. That’s the mental model here.
Here’s a quick way to try the same pattern in your own setup:
- 🎯 Write the end goal as one sentence before the session starts, and keep it visible the whole time.
- 🔄 At every major step, force the agent to restate the goal in its own words before it continues.
- 🧭 If the restated goal drifts from the original, stop and correct before doing more work.
- ✅ Only mark the task done when the agent can point to how the output matches the original goal.
That’s the mini version of what reasoning-doctrine automates. The skill just handles the re-checking for you instead of relying on you to catch drift by hand, which matters because catching drift by hand means reading through twenty steps of tool calls after the fact, which is exactly the tedious review work most people skip when they’re in a hurry.
A few things worth knowing before you dig in. This is one skill inside a bigger “governed agent skills” repo, so expect it to assume a specific setup rather than dropping in as a single standalone file. Budget some time to understand how it expects goals to be structured before wiring it into your own agent stack. And since it’s a fresh community project with just a single upvote so far, treat it as an early build worth testing, not a battle-hardened standard yet. That means checking the code yourself before trusting it on anything you can’t afford to have go sideways.
How this compares to what you’re probably already doing: most people fight context drift with reminders buried in the system prompt, hoping the model keeps referencing them on its own. This skill instead builds the check into the workflow itself, so it’s not optional and it’s not something the model can quietly skip once the conversation gets long. The difference shows up exactly when it matters most, on the sessions that run long enough for drift to actually happen.
Pro tip: don’t wait for a session to go sideways to catch the drift. Build the goal-check into your workflow at fixed intervals, like every five tool calls or every major subtask, rather than only when something looks wrong. By the time an agent’s output looks obviously off track, it’s often already burned a lot of steps heading the wrong way, and unwinding that is more expensive than the checkpoint would have been.
Second pro tip: keep the stated goal short and concrete. “Fix the login bug so users on mobile can authenticate” holds up far better as a checkpoint than a paragraph of context, because the agent can actually compare its current action against it in one glance. A goal buried in three paragraphs of background is a goal that gets skimmed, not checked.
If you’re running agents on anything longer than a quick single-shot task, this is worth a look. Go check out the reasoning-doctrine skill in the governed-agent-skills repo and see how the goal-checkpoint pattern feels in your own workflow. 🚀
Frequently Asked Questions
Q: How does the reasoning doctrine keep agents from spiraling into tangents?
It surfaces your goal throughout the work session, acting like a constant checkpoint. Instead of your original intent getting buried under layers of nested context, the system reminds the agent what actually matters at key moments so decisions stay aligned with the big picture.
Q: Can you change the goal mid-session if priorities shift?
A commenter raised this exact concern: what if new information legitimately changes your target halfway through? The skill’s design suggests you can feed it a revised objective without the whole chain losing its mind, but it’s worth testing on complex workflows to see how it handles context shifts.
Q: How is this different from just writing the goal in a system prompt?
Static prompts fade into background noise during long sessions. The reasoning doctrine actively reinforces the goal throughout your work, making it impossible to lose sight of it when you’re juggling multiple threads and decisions.
We kept losing what the actual goal was in a long session
by u/NoKaleidoscope1748 in PromptEngineering