A friend in our community both leads an engineering team and writes core code. His calendar is packed with back-to-back meetings every day, leaving him only the small cracks between meetings to squeeze in a few lines of code. A while back, he was chatting with us about his recent experience: he couldn’t hand over entire projects to agents because most of his energy was being drained babysitting agents. The 1M context window would quickly exceed its sweet spot of 30%-40%, forcing him to repeatedly ask the agent to summarize unfinished tasks and start a new session to pick up the slack. Staring at the scrolling stream of messages all day, his head would start pounding around 4 PM. He is very hands-on and well ahead of the curve—he thoroughly mapped out every issue he hit and even drew up a complete checklist of root causes and troubleshooting steps. When even someone this skilled gets stuck, it shows just how universal the problem is.
To solve this, he first tried all the conventional tricks you can think of. He started by trimming context: cleaning up AGENTS.md and CLAUDE.md, removing obsolete prompts left over from model upgrades, and disabling unused MCP servers and skills. We discussed this approach in detail in Thin Harness, Fat Skills. Next, he built an orchestration tool so the main agent could coordinate multiple sessions simultaneously via tmux. Even after going that far, the main agent’s context still ran out rapidly, and in the end, he still had to manually open new sessions over and over to keep things moving. The full transcript of our discussion is here; Superlinear Academy members can view the original conversation directly.
Reading this, you might ask: everyone is worrying about context, so why say it’s just a symptom? In reality, a context window is essentially a budget. Every file the agent reads, every test run it tries, every wall it hits, and every time we step in to correct its course and reinject background and state, we are burning through this budget. How fast it burns depends on how long each exploration cycle is. If the agent has a clear goal, can clearly see its own execution results, and gets immediate feedback, each single exploration cycle will be short, convergence will be quick, and the window will fill up slowly. Without these three things, it will wander down dead ends in every turn, draining the window in the blink of an eye. So the speed at which the window fills up is merely a dashboard gauge reflecting task management quality—it is not the root cause itself. The proof lies right in this friend’s experience: repeatedly opening a new session is nothing more than resetting the gauge to zero; as long as the agent is still running in circles, the reading will spike again immediately. Resetting the gauge does nothing to change how the money is being spent.
So the real solution is neither making the 1M window even bigger nor restarting sessions more frequently—the key is eliminating wasted spend. Cleaning up prompts and trimming context are certainly helpful, but they only handle the last-mile cleanup. If you don’t fix the upstream management issues, the agent will still wander off track, make blind guesses, and run into dead ends, forcing you to step in repeatedly to course-correct. A bloated context is just the symptom that surfaces at the end; the root cause lies in three earlier management failures: making the model rely on static predictions, leaving task goals unpinned, and leaving the model blind to its own execution results. Let’s go through them one by one.
It’s very natural that people instinctively put their effort into context maintenance. The window does fill up, and quickly cleaning up prompts, applying compression, or opening a new session often provides immediate relief from sluggishness. But these actions only offer temporary fixes. Restarting and pruning merely zero out the consumption meter; as long as the underlying way of working and spending doesn’t change, the context will run dry again in no time. If you want to genuinely cut down on wasted consumption, you need to shift perspectives and look at how we assign work to it in the first place.
To wrap your head around this logic, there’s an intuitive reference: treat the agent like a new engineer on your team. The way you wish your manager would delegate tasks to you is the way you should set requirements for an agent. A reliable handoff never just throws over a “get this done” and walks away; it always clarifies what needs to be delivered, where the boundaries are, and what “done” looks like. Delegating work to an agent follows the exact same principle.
Connecting back to the budget framework from earlier, the three management gaps—static prediction, unpinned goals, and invisible results—are precisely where budget gets squandered. When you make an agent predict statically, it gets no real-time feedback and can only read more code to make blind guesses, never narrowing down the search space. When goals aren’t pinned down, it has to re-evaluate what you actually want in every turn. When it can’t see its own execution results, it has no choice but to ask you whenever it hits a snag, turning the human into the feedback loop. Tackling these three areas directly shortens the length of each exploration cycle. The two experiments our friend ran on the context side clearly exposed this bottleneck. When writing a prompt for the agent, he manually typed out 5 background items with 4 verbatim in the wiki—a wiki automatically compiled daily by an observation agent he had built. He hadn’t missed a single management step, yet when he checked with actual prompts, he found that the main agent couldn’t retrieve information from the wiki, forcing him to explain everything from scratch every single time. The tmux orchestration experiment mentioned earlier led to the same outcome: the main agent’s window still drained rapidly. The gap between doing management and making management work isn’t the model—it’s closing the loop. That missing link is still a management action; without it, humans are stuck constantly babysitting.
Conversely, once proper management actions are in place, the outcome is completely different. Mid-project, he paused to redefine the goal and verification methods; afterwards, the agent turned around and wrote tests on its own, showing a noticeable boost in autonomy—we’ll dive into the details of this step later. We had a similar experience ourselves: a while back, when building a complex community backend, the early exploration felt overwhelming. Chatting with the AI only surfaced more issues, and it took us several days just to finalize the design. Once the design was locked in, the rest was simple—we set a clear goal, let the AI run on its own, and had it built in two to three days. While these are real-world case observations rather than rigorous controlled experiments, the direction is consistent: what changed was management action, while the model remained the exact same model.
When it came to accumulating context, this friend had actually put in immense effort, running two systems in parallel. One was his custom-built observation agent, which automatically extracted technical details from sessions daily, compiling 18 pages of wiki and 1418 lines of index. His capture pipeline was rock solid, but unfortunately, the main agent never consulted it because the routing lacked the right trigger. The other was the built-in memory in the harness, partitioned by working directories: 22 stores on his machine each operated in isolation, leaving cross-repo knowledge with nowhere to live. He later tried setting the workspace to a parent directory for centralized management, only to find that the parent directory’s store remained almost completely empty. Eventually, he proactively pivoted his strategy: consolidating core knowledge into his own code repositories while using the memory in the harness solely as retrieval pointers. We released an open-source version of this pattern in the context infrastructure repository, and Module 2 and Module 3 of AI Builders also break down how to organize private context and define human-AI boundaries. If you want to see how this works in team settings, you can check out principles and methods for sharing AI skills within teams. Managing context is essential groundwork, but if you want to break free from babysitting, the real key still lies in the upstream management actions.
Bottom-line takeaway: The root cause of babysitting lies in the management process, not model capability; doing context maintenance is merely clearing the battlefield—it does not solve the problem at its source.
In many teams’ cloud-native environments and CI/CD pipelines, there are countless hidden traps that you only discover after stepping into them. Initially, this friend gave the agent full access to the codebase—the code was all right there, so in theory, it should have been able to spot all potential issues just by scanning existing configurations. That tends to be everyone’s first instinct when starting out, but it implicitly assumes the model possesses superhuman static reasoning capabilities.
When human engineers troubleshoot these failures, they typically rely on repeatedly triggering builds, inspecting error logs, and checking the source code to map out the pitfalls step by step. AI follows the exact same learning path: it needs to hit walls, receive feedback, and analyze root causes before building reliable understanding. Expecting it to guess every edge case out of thin air just by looking at static code often exceeds the model’s capabilities. Even if future models possess stronger reasoning, we still wouldn’t recommend this kind of blind guessing. Anyone who writes code knows the feeling: staring blankly at the screen hunting for bugs is far more exhausting than attaching a debugger or running a test case to flush the issue out. Whenever dynamic verification is possible, never let an agent engage in purely static prediction in the dark.
A much more practical approach is to build a positive feedback loop around concrete tasks. First, have the AI read historical CI/CD failure logs, cross-reference them with the source code to understand what went wrong each time, and then document the lessons learned, underlying mechanisms, and solutions. In practice, there are two common pitfalls that require matching management techniques.
The first hurdle is that it easily forgets established guidelines. Once documentation is written, the main agent might turn around and forget to check it. At this point, you need to pull it back via static injection or interactive prompts. If you use Claude Code, you can add a rule in CLAUDE.md at the root directory reminding it to check the troubleshooting docs in the designated folder before diagnosing CI/CD issues; alternatively, every time you assign a task, include a quick prompt instructing it to investigate against those existing files.
The second hurdle is that the context quickly overflows. When faced with hundreds of build logs, a single agent easily gets overwhelmed by the flood of information—like picking corn while dropping the ear you just grabbed, forgetting earlier details as it reads further along. A more reliable approach is launching concurrent sub-tasks, having each sub-agent carefully review, say, 10 jobs, summarize the extracted lessons into a brief, and then have the main agent aggregate everything. Claude Code’s dynamic workflow is ideal for this: it can automatically orchestrate the invocation chain, allowing multiple sub-agents to extract insights individually before synthesizing the results.
This is exactly like mentoring an intern in real life. When onboarding someone to debug a pipeline, you don’t just show them the code; you equip them with testing tools, have them document mistakes in a runbook, occasionally remind them to follow conventions, and if the workload gets overwhelming, delegate tasks across a support team or write batch scripts to free up their mental bandwidth.
Bottom-line takeaway: An agent cannot handle untested hidden traps; giving it dynamic feedback and documenting SOPs is far more effective than simply tossing a pile of permissions at it.
Often, work stalls because the boundaries of requirements were never drawn clearly. If you don’t even know what you want in the end, the agent is left to make wild guesses. It’s just like a product manager throwing over half-baked specs and tearing everything down daily mid-sprint—the engineering team not only suffers, but productivity collapses entirely.
Some might wonder: if humans have to figure out every single detail beforehand, what do we need AI for? In truth, an agent can do more than just write code on command—it can also help us clarify architectural thinking. Take our friend’s experience migrating a hackathon prototype into a Kubernetes cluster as an example; the entire collaboration was roughly divided into three steps.
Step 1: Have the agent understand the existing codebase and grant it appropriate permissions to actually invoke services. It can simulate user operations via the Slack API or browser automation, executing logic directly in a real environment. The goal of this step is to produce two documents: a PRD defining behavior, and an RFC deciding design. AI-generated documentation is often long-winded and verbose, draining your energy if you try to read it end-to-end. You can explicitly instruct it to report with a low cognitive burden format, directly listing core conclusions, potential risks, and key decision items requiring your sign-off. You can even have it generate a lightweight web page with charts and cards to visualize the system state. Everyone prefers different information densities, and having the agent adapt to your reading preferences is precisely one of its strengths.
Step 2: Use the documents produced earlier for targeted communication. You can start with a clear goal: transform this hackathon prototype into a production-grade service and deploy it live. Then discuss trade-offs with the agent—cutting unnecessary features, preserving core logic, adding security boundaries—and translate these discussions into concrete technical decisions. You can even document your preferred reporting format in a template for the agent to follow going forward. Your cognitive bandwidth is your scarcest resource; there is no need to force yourself to plow through dense, tedious text—let the tool adapt to your rhythm.
Step 3: Lock down the final acceptance criteria. If you stop at the first two steps, the process remains an open loop: when the agent claims it is done, you still have to verify and troubleshoot everywhere, effectively becoming its assistant. The key to establishing a closed loop is defining the success state with crystal clarity: which functionalities are non-negotiable, and which code smells are strictly forbidden. Nail down the critical path and cover key scenarios; as long as these hard metrics all pass, you can have 80-90% confidence that the product works. Once standards are locked down, the agent can autonomously iterate around the clock while you sleep, rapidly converging on solutions through dense error feedback.
The second round of discussion also surfaced a crucial detail: what is the relationship between the temporary visualization web page and the formal documentation? The chart-laden web page generated by the AI is merely a temporary view to help you quickly understand and make decisions; the truly reliable source of truth remains the rigorous Markdown document, and any changes agreed upon during discussions must be synchronized back into that document.
There is an even more essential management habit: always maintain a concise baseline spec. Nobody reads through pages of AI-generated prose line by line, yet they are packed with all kinds of assumed defaults. If you don’t prune these unverified assumptions, the agent will overcomplicate things when writing code, adding unnecessary constraints and drifting off course before you know it. Halfway through the project, this friend proactively paused to realign goals, collapsing the bloated, ambiguous specifications into two clear tiers of objectives. Many projects fail because no one is willing to hit pause and recalibrate direction. We need to personally vet a minimal requirement document that only locks in non-negotiable baseline principles, establishing clear guardrails for subsequent implementation.
This is just like managing a team. A manager doesn’t need to read every draft written by their team members; the team is responsible for distilling key information for briefings, while the manager evaluates trade-offs, maintains safety baselines, corrects directional drift, and establishes a closed-loop system that runs smoothly without constant supervision.
Bottom-line takeaway: When goals remain unpinned, every detour the agent takes consumes your context; a personally vetted minimal requirement beats ten rounds of divergent brainstorming.
The essence of efficient collaboration lies in leverage: spending 5% effort for 100% of the expected result. The action where that 5% truly makes an impact is ensuring that whoever does the work knows clearly whether progress is smooth and whether it’s done right. Defining delivery boundaries is crucial, but there is an equally indispensable prerequisite: after receiving acceptance criteria, does the agent have the tools to verify how well it did its job?
If an agent doesn’t even have permission to view CI/CD logs, it can’t get detailed error stacks. In that case, even if you push it to make the build pass, it will be baffled by green and red status badges, unable to follow clues and fix the errors on its own.
Therefore, before starting, clear away the stumbling blocks and figure out what permissions and interfaces the model needs to verify its own work. If granting direct access to production environments is a security concern, you can build a high-fidelity sandbox for it to experiment in. Providing the agent with a safe yet realistic workspace enables it to understand task status through objective metrics and obtain detailed error information to bridge the gap.
While driving the project forward, this friend also encountered several friction points that required human intervention: code merges requiring peer approvals, database permissions needing admin sign-offs, a GitHub App that had to be manually installed, and Slack bot tokens that had to be stored in 1Password. Mid-project, he keenly identified these bottlenecks, streamlined the goals and verification methods, and compiled a dedicated manual to-do list to isolate these human-dependent steps. Many people never realize this until a project is over. Clearly drawing the boundary between automation and human intervention eliminates the friction of pretending everything is fully automated, allowing the agent’s autonomous closed loop to run smoothly.
Bottom-line takeaway: Acceptance criteria provide the goal, and result visibility provides the self-checking ability; without a timely feedback channel, humans are reduced to errand-running inspectors.
The entire project was ultimately shipped successfully in 2 weeks, accomplished entirely in the cracks between meetings plus a single evening of overtime. Facing such dense information throughput, our friend admitted that his brain was utterly exhausted, to the point where he wondered whether using AI had actually increased his burden.
In reality, this kind of mental toll existed just the same when writing code manually. Deriving requirements, architectural trade-offs, edge-case verification—none of these mentally demanding tasks went away; it was just that development cycles used to be drawn out, diluting the cognitive pressure over time. Today, AI acts as an engineer, an architect, and a part-time secretary all at once, dramatically compressing the entire development cycle. It multiplies output efficiency while dumping a high-density cognitive load right in front of you all at once. Whether you can adapt to and master the rhythm of this high-frequency collaboration is precisely a key differentiator in the AI talent landscape.
Looking at the team level, setting up sandbox mechanisms is a particularly pragmatic starting point. Becoming “AI-native” has become something of a buzzword that every leader wants, but in practice, it involves grunt work that often gets bogged down in organizational restructuring. Building a robust runtime environment and security sandbox for agents is purely an engineering task. It requires neither reorganizing teams nor altering existing performance evaluation structures, meeting minimal resistance while solving real problems. How exactly to implement it can be tailored to each team’s specific circumstances.
Returning to the question we started with: how can we get agents to work truly independently and free us from endless babysitting? The key comes down to these three things: provide a dynamic testing environment so it can turn error experiences into runbooks; clearly define delivery boundaries and guard them with a personally vetted minimal requirement; and establish visibility into execution results so that open-loop manual checks become closed-loop autonomous verifications. This mindset is entirely identical to mentoring junior engineers. As the baseline ability to write code becomes more commoditized, how to delegate tasks clearly, draw boundaries, and manage acceptance verification is what truly sets practitioners apart.
Bottom-line takeaway: Escaping endless babysitting comes down to shifting yourself from a frontline executor to the person defining the problem and setting the rules—stop always looking to solve the problem by simply switching to a smarter model.