The Context That Lets an Agent Work Alone

I've noticed something about the way I work with Claude Code. I tend to spend a considerable amount of time at the beginning of a session talking through what I'm trying to accomplish, sometimes before I have a clear idea of the implementation. Once the agent starts implementing, I rarely need to correct its direction.

That might sound like I'm writing unusually detailed instructions. I don't think that's quite what's happening. Often I don't know what the implementation should look like yet. If I did, there would be much less to explore. I'm trying to give the agent enough relevant context to find the shape of a good solution on its own.

Preparing the problem, not prescribing the answer

There's a difference between telling an agent what to build and helping it understand what you're trying to achieve.

An instruction might say: create this service, use this interface, write these tests. It gives the agent a path to follow. That can be appropriate when the design is settled.

But much of the work I use AI for isn't settled. I have an objective, a set of constraints, some knowledge of the surrounding system, and a sense of which decisions will matter later. I want the agent to reason within that situation rather than execute an implementation I've already designed for it.

So I spend time describing the existing architecture, the problem I'm solving, the reasons certain approaches have been considered, and the trade-offs I care about. Sometimes I explain what I don't want, not because I know the alternative, but because I know what would make a solution unsuitable.

That preparation isn't a substitute for the agent's reasoning. It's what allows the reasoning to start in a useful place.

Priming is not quite prompt engineering

I've started thinking about this as priming the agent. Prompt engineering usually brings to mind the construction of an effective request: how to phrase instructions, specify an output, or constrain a task. Those techniques are useful, but this feels different to me.

At the beginning of a new coding session, the agent doesn't share the mental model I've developed while working on the problem. It may have access to a capable model and a repository, but it hasn't yet been given the background that makes some choices sensible and others obviously wrong.

A persona is one way to see the effect. If you ask an agent to act as a security reviewer, it starts interpreting the work through questions about trust boundaries, threats, and permissions. You haven't given it the answer to a particular security question. You've changed the lens through which it examines the problem.

What I'm doing with engineering context feels similar, but more specific. Through conversation I establish what the system is for, what has already been tried, which constraints are real, which concerns are important, and what outcome would make the work worthwhile. That material becomes part of the working context the agent uses when it reasons. It isn't a permanent change to the model's training or its underlying weights; it's a change in the information available to guide this session.

The interesting thing is that I don't need to deliver this as one perfectly composed prompt. I can talk it through, clarify what I mean, respond to questions, and let the understanding accumulate. Sometimes I discover what I think while explaining it. By the time execution begins, the agent is starting from a much more useful frame of reference.

I think of the process less as specifying an answer and more as helping the agent adopt the right perspective on the problem.

Why plausible assumptions are expensive

A capable coding agent is very good at filling gaps. Give it an incomplete problem and it can usually construct a coherent interpretation, choose an architecture, and write a convincing implementation.

The difficulty is that a plausible assumption isn't necessarily a relevant one. Nor do all assumptions carry equal consequences.

Consider a hypothetical request to add a workflow that updates customer information. Without much context, an agent could reasonably put the update in the service that already exposes a customer API. It might write clean code and thorough tests. But suppose that service only maintains a projection, while another capability owns the authoritative record. The implementation could look sound locally while placing responsibility in the wrong part of the system.

The missing information isn't a coding detail. It's the meaning of that service in the wider architecture.

This is the kind of rabbit hole I try to avoid by preparing the context first. Once an agent commits to a reasonable but misplaced assumption, it can spend considerable effort producing good work in the wrong direction. The more convincing the implementation becomes, the less obvious the original assumption may be.

Relevance matters more than volume

I don't mean the answer is to paste every document and conversation into a context window.

Relevant context is different from abundant context. The former helps the agent distinguish what matters; the latter can leave it with more material to sort through.

In my experience, the most useful preparation explains the objective, the constraints that must hold, the existing boundaries, and the reasons certain decisions are important. It also makes room for uncertainty. If I haven't decided something, I'd rather say so than let an unresolved question harden into a requirement.

This doesn't guarantee that the agent will choose correctly. Context can be incomplete, wrong, or weighted toward whatever concerns I happen to notice. Detailed framing can even make a mistaken premise harder to challenge.

But I've found that time spent preparing the framing is usually less than the time I'd otherwise spend redirecting implementation after implementation.

Autonomy starts before execution

We often measure an agent's autonomy by how long it can work without asking for help. I think there's another part of the picture: how well prepared it was before the work began.

An agent that runs for an hour without intervention may be doing excellent work. It may also be pursuing a mistaken interpretation very efficiently. The absence of correction, by itself, doesn't establish quality.

Still, I've noticed a practical relationship in my own sessions. When I invest in the initial understanding, I tend to supervise less. I don't need to review every intermediate design choice or keep repeating the same priorities. The agent has a better basis for making those choices itself.

This is why I don't find the preparation exhausting. I'm not trying to solve the implementation in advance or produce a perfect specification. I'm trying to make the problem legible enough that I can delegate the search for a solution.

If I had to dictate every step, I'd only be moving the implementation work into prose. The value comes from preserving the agent's freedom to discover a solution while giving that freedom useful boundaries.

The work before the work

I don't know how much of this will remain necessary as models improve. They may get better at identifying missing context, asking for it, and distinguishing important constraints from incidental ones. I hope they do.

For now, the pattern in my work is fairly consistent: the sessions that need the least steering during execution are often the ones where I spent the most time establishing what the agent needed to understand beforehand.

I used to think of that preparation as overhead before the real work began.

I'm beginning to see it as part of the work itself. Not because I'm supplying the answer, but because I'm helping the agent understand the problem well enough to search for one.

The goal of priming isn't to make the agent think exactly as I do. It's to give it enough of the context behind my judgment that it can make useful decisions without constantly asking me to steer.