How do you tell a model problem from a context problem?

They can look identical in the output. Before deciding, ask what information the agent actually had: most of the time the fault is missing context about the system, its rules or its priorities.

What context does an AI coding agent need?

Where the change belongs and what it must not disturb, how the team names, structures and reviews the work, which business rules must stay true, why the current approach was chosen, and which documents are current and who maintains them.

Your AI Agent Is Only as Good as the Context You Give It

Q: Are instruction files enough to give an agent context?

They're a good start for durable team rules, but each task still needs its own goals, constraints and definition of done. If a rule matters enough to correct in every review, write it down where the agent can use it.

Your AI agent can write the code—and still miss the point.

It’s happened to all of us: the agent produces something technically correct but utterly misaligned with your team’s needs. Maybe it breaks a business rule nobody documented, or it introduces a pattern your team explicitly avoided. You’re left wondering: is this a model problem, or did we just not give it the right context?

Most of the time, it’s not the model. It’s the missing information.

Your agent doesn’t know why you made that architecture decision. It doesn’t know which naming conventions your team uses, or why that edge case in the workflow matters. It’s a fast, confident guesser—but without the right context, those guesses are just that: guesses.

I’ve seen this in almost every organization I’ve worked with. Teams blame the model, tweak prompts endlessly, or throw more data at the problem. But the real fix? It’s often as simple as giving the agent the context it needs to understand your system, your rules, and your priorities.

Here’s what your agent needs to know:

Architecture: Where does this change belong, and what must it not disturb?
Conventions: How does your team name, structure, and review this kind of work?
Business rules: Which behavior must remain true, even if the code changes?
Decision history: Why was the current approach chosen?
Source of truth: Which documents are current, and who maintains them?

Documentation isn’t just for onboarding people anymore. When kept current and accessible, it helps onboard agents too. But “give the agent more context” doesn’t mean pasting your entire wiki into a prompt. Relevant, trustworthy context beats a pile of stale pages every time.

Instruction files are a great start for durable team rules, but they’re not enough. Each task still needs its own goals, constraints, and definition of done. If a rule matters enough to correct in every review, it’s worth writing down where the agent can use it.

Think of it this way: your agent is only as good as the context you give it. A model problem and a context problem can look identical in the output. Before you decide which one you’re facing, ask yourself: what information did the agent actually have?

Your AI Agent Is Only as Good as the Context You Give It

Questions

Find a reference entry