I’ve been thinking about how to improve my agent workflows- and I’ve discovered that there is a productivity speed bump that you hit as you get more fearless with agentic development: You know the agents cannot be trusted to make the right call, so you review every decision. This slows everything down.
I think I’ve managed to step past this problem. I wanted to share some observations about how one expereinces the cognitive speedbump that comes with multiple custom agents- and I some methods for overcoming these problems. If you have been brave enough to explore — dangerously-skip-permissions these problems may sound familiar.
AI skepticism typically starts with doubt about the capability of models. Over the last 3 months, there has been a wave of people recovering from end-of-year holiday tinkering with Claude. People have discovered that frontier models are smart enough to deliver. They can handle complexity. The models are continue to get better. Despite this- the challenge of context management is structural and it gets worse as projects grow.
You have probably noticed that as you do more work with AI agents, your time spent re-explaining a project to the agent increases. It might be that you’re re-delivering the project description you gave last session or relitigating an architectural decision from three sessions ago. Here’s a fun experience: A feature that was already built just got rebuilt, slightly wrong, because an agent with fresh context didn’t know it existed.
You’ve done your initial project work with an agent and now you’re running out of context in the session. You decide to start a new session and spend the first fifteen minutes re-establishing context. You describe your project. You explain what’s been built. You restate the requirements. If you were clever at the end of your last session, you’re copying and pasting a “hand-off” prompt that the last session created. The agent begins. But its interpretation drifts slightly from where you left off, and you don’t notice until the output from your deployment/development run doesn’t quite fit the project.
You hand off work to multiple agents and discover (often too late) that one of your agents overwrote what another built. Nothing is tracking which agent created which files. You didn’t write in your dev log about why a particular approach was chosen over the alternatives. A decision made in session four gets silently reversed in session twelve, and the reversal breaks something that was working.
You fear going to sleep and forgetting what you did today. You find yourself holding the entire project in your head. Your diary has a lot of copy/paste from sessions so you can review the decisions you made. You are the only thread of continuity between sessions. The agents are productive when you’re directing them, but the moment you step away, the project stalls. Or worse, it moves confidently in the wrong direction.
Agentic development looks like it could reduce the human burden, but it relocates it. You stopped writing code and started repeating context. You stopped building features and started answering the same questions at the top of every session. What are we building? Where are we? What has been decided? What remains?
If these questions have become your daily ritual, the problem is not your agents. The problem is the absence of scaffolding around them. Let’s discuss what outcomes we should produce that will get us out of this developer doom loop.
Agent features that defeat context fatigue
To move from superficial autonomy to something sustainable, repeatable, and auditable, your agents need to produce specific outcomes. I’ve had some success with patterns that fix these problems. These patterns can be evaluated as features that should be embedded in your agent flows. If you invest in these patterns, it will produce conditions where your agents manage context in a way that takes away your burdens. My recommendation is that you review the agents you’ve created and ask yourself how they can produce the following outcomes:
Persistent context across sessions. Project knowledge, state, and history must survive the session boundary without requiring a human to re-explain them. Context has been the first casualty of session-based development. It should be the first thing we protect. Your agents should write state to disk. Stop holding project context in your mind. How does your agent acquire project context? How does your agent update the project’s context to project planning files as it works?
Explicit phase and progress awareness. An agent must know what phase the project currently occupies and what has already been accomplished before it takes action. Agents lack an innate sense of where they are. The absence of this awareness is the root of duplicated effort, skipped steps, and misplaced confidence. Agents should log data about their current phase & development progress. Your agents should review progress logs & development artifacts that help them understand where they are in the project’s development & deployment before doing any work. How do your agents identify project status? How do your agents make incremental edits to project status documents to reflect completed work?
Clear provenance and accountability. Every artifact needs a traceable author. In multi-agent systems, files appear and change and sometimes break. Without an ownership record, debugging becomes archaeology. You spend time reverse engineering authorship of a change instead of solving problems. Make your agents implement git commits that document which agent was responsible for a change. How do your agents make authorship of code auditable?
Preserved decision rationale. The reasoning behind decisions, including the alternatives considered and the tradeoffs accepted, must be captured and accessible to future agents. Decisions without rationale become immovable. Nobody changes what nobody understands, and nobody preserves what nobody remembers choosing. When you build big enough projects with agents, you can become overcome with fear about changing an existing feature. You can overcome this anxiety by building agents that document their decision logic. Ensure that agents log the solutions they considered and the reasoning behind the solution they picked. Evaluate how your agents can be updated to document what decisions they made and what solutions were considered.
Stable alignment to product intent. A canonical reference must anchor all agents to a shared definition of what is being built. Without scaffolding, scope drift is quiet. Every session reinterprets the project goal by a few degrees. Over time the project curves away from its intent, and the deviation only surfaces when components fail to fit together. Your counterspell: Give all agents access to the same product spec every time they run. Explore how your agents ensure that they always align with your project’s north star goals & requirements.
Human-as-supervisor, not human-as-context-provider. The human role must shift from re-establishing context each session to reviewing, approving, and steering. Audit your development time. If you are finding yourself revisiting a pattern of re-establishing context, forgive yourself and take a break. You need to spend some time thinking about how your development flow manages context.
Your agents should be launching by accessing a file with a stable initial context statement. Your agents should write to it as they make decisions and changes. This file should document decisions and update the session initiation context to describe the state that evolves as your agents build upon your foundation. Your agents should spend their first moments figuring out what has been done so far, what lessons have been learned and where do we need to work next. Agents should be able to discover if they’re about to break away from any thoughtfully established conventions. Log all the time you’re spending making decisions and pasting context. Evaluate how you could change your agents to do that work for you.
Low-cost resumption. Any agent must be able to pick up interrupted work quickly and accurately without re-analyzing the full project or guessing at prior state. Resumption remains one of the most expensive moments in agentic workflows. It should be one of the cheapest. Cold starts of sessions should cost a file read, not a conversation. For every agent you build, evaluate their mechanisms for resuming an interrupted session. Don’t settle for /resume
Visible and manageable technical debt. Past decisions must be inspectable so that agents can distinguish between choices worth preserving and choices worth revisiting. Invisible debt accumulates in both directions. Agents blindly keep decisions they should change. Agents recklessly change decisions they should keep. Both paths lead to breakage. Make your agent’s historical decisions queriable. Evaluate your agents: how do they log the decisions they make? How do your agents avoid re-litigating a well established pattern? What criteria do your agents follow before making a change to an established pattern?
Coordination without collision. Agents must operate with enough shared awareness to avoid duplicating, contradicting, or overwriting each other’s contributions. Collision between agents can feel random, but it is structural. It follows directly from the absence of shared state. Shared state is cheaper than conflict resolution. Your agents should create & update project artifacts that capture project development state. How do your agents use files for coordination with other agents?
Five artifacts I use for scaffolding
I tried to describe the end state we want to cultivate. Here are some of my coordination artifacts that I use to reduce my time in an interactive agent.
These artifacts are documents that my agents create, maintain, and consult as part of their execution loop. For every project, my agents work around:
A Product Requirements Document that holds the high-level product statement that all agents build against. It is the fixed point we are working towards. When an agent needs to know whether a feature aligns with the product’s intent, this is where it looks.
A Features List Document that summarizes the capabilities that must be implemented. It tells an arriving agent what has been built and what remains. Resumption becomes a matter of reading a list, not reconstructing a plan.
A PRD-Agent-Reasoning File that captures the decisions agents have made, along with the options they considered before deciding. This is the institutional memory of the project. It turns opaque choices into auditable decisions.
A Project Manifest that carries a brief project description, timestamps for creation milestones, and a record of which development phases have been completed. It answers the question every new session asks first: where are we?
An Agent-Ownership File that maps every file to the agent that created it. If you’re ever wondering if you know for sure which agent produced a file, you’re in a pattern that will cause you problems. Build agents that make accountability traceable. When something breaks, you have a map to consult to discover which built it.
What problems are solved with this scaffolding?
My artifacts serve multiple outcomes, but one outcome draws from all five: the shift from human-as-context-provider to human-as-supervisor.
- The PRD eliminates “what are we building?”
- The Project Manifest eliminates “where are we?”
- The Ownership file eliminates “who did this?”
- The Reasoning file eliminates “why was this done?”
- The Features List eliminates “what is left?”
If you the human keep finding yourself in the decision loop, knock it off. Use scaffolding artifacts. Resist the temptation to fiddle. Make it easy for your agents to make decisions you can audit later. If you can’t confidently start the project over from scratch, that’s a signal you’re trying to maintain too much control. Build guardails and loosen your reins.
Development loops become repeatable when context persists. They become auditable when agents record their decisions. Agentic development loops become enhanceable when agents preserve their rationale alongside outcomes. The models will grow more capable, but the scaffolding problem will remain because it is not a problem of intelligence. It is a problem of continuity. Continuity has always depended upon something being written down.
I’d love to hear what you think about this. If you’re struggling with these problems, let’s connect!