Give the agent a way to find product context

Posted on September 28, 2026  •  7 minutes  • 1377 words

An agent can only check its work against the part of the product it can see.

I think a lot of developers give an agent one repository and a problem, then let it start cooking. If the other repositories that talk to it are missing, then the agent doesn’t have the context of changes happening across them. Before asking for a bigger prompt, give it a way to find the work around the change.

There is some data behind this that show where this can hurt. Jellyfish looked at around 20 million pull requests and found that teams working in one or a few repositories saw pull-request throughput trend towards 4x as AI adoption went up, while teams spread across many repositories saw essentially no gain… but their explanation is that most of today’s tools work best with one repo at a time, and the relationships between repos are often only in senior engineers’ heads. It’s a correlation rather than proof, but it matches what I’d expect.

The prompt tells the agent what to do now, and the repos, ticket and relevant decisions let it check that instruction against the product as it actually exists. I want the agent to inspect those sources as it needs them instead of pasting everything into the window. Anthropic’s guidance on context engineering also argues for high-signal context and retrieval when needed rather than simply filling the window. The guidance says little about whether a particular team’s product decisions are correct.

Make the context available

For a change that crosses codebases, I have all the relevant repos cloned with full Git history. The agent can then see changes in progress and trace why an interface looks the way it does across those repos. That depends on people leaving useful commit messages, and a history full of “fix” is technically complete but not especially helpful.

I also keep the AGENTS.md instructions in each repo and make sure the agent reads the instructions for the code it touches. These give it local build and test conventions; they don’t tell it why a product change is wanted. Strong tests add another useful source of evidence about behaviour, although they cannot decide the requirement for you.

The next connection is the ticket tracker. With a read connection to Jira through Atlassians MCP server , or another ticket tracker, the agent can look for related tickets and changes while it works. I have also let an agent access a wiki, but I’ve found the wiki is usually out of date and misleading. I would search it for a specific question rather than let a retrieved page settle the requirement.

Decide which source to trust

The tools make these things accessible, but they don’t decide which account of the change to trust. This is the rule I give the agent:

• Existing behaviour comes from the current code and tests.
• Requested behaviour comes from the ticket (and questioning me for further detail)
• A person decides when the two conflict or the requirement is thin.

A stale ticket doesn’t become a decision just because an agent can retrieve it. The agent should surface the conflict rather than quietly pick a winner. Unblocked , who build a context engine for coding agents, said one of their early mistakes was resolving conflicts between sources automatically instead of surfacing the ones they couldn’t resolve.

Context outside the code

Even with the repos, history, tests and tickets in place, the agent may not know how people actually use the system today. Most systems are not actually used how you think, and I don’t want an agent treating the code or an old wiki page as the whole product. It needs current diagrams or living PRDs where they exist, and some way to check what is happening in operation.

Selected logs might help show actual use, but reading that back into a useful way is difficult. You would need to think about privacy, whether the signals are relevant to the change, and how quickly the account goes stale. I think nightly jobs that read this sort of information and keep context documents up to date could be useful. A job for each area of the product could read the selected logs, the changes merged that day and the tickets closed, then rewrite a short document on how that part of the system is used now. The coding agent reads the document when it needs it, rather than digging through raw logs mid-task.

Anthropic has talked about something similar for agent memory. Lance Martin calls it dreaming : an out-of-band pass that goes back over what was stored, alongside the sessions that produced it, and corrects mistakes before they become lasting instructions. The same risk applies to a nightly context document. Unblocked warn against caching generated answers, because code, docs and the reasons for things keep changing, and a wrong answer fed back in reinforces itself. A document summarised from last night’s summary would do exactly that.

Therefore I would have the job start from the raw sources each night, not its previous output, and keep a link and a date against each statement so the agent can check where it came from. I do think this would be worth trying, but the documents would still need someone to check them against how the system is used now.

Work out the slices before writing code

The bit I don’t hand straight to a coding agent is the full problem with “go and solve this” attached. I want to break it down in my own head first, or use an agent to grill me on the requirement and propose slices before any coding starts.

I generally will use one agent to work out the slices and leave an output document, then throw that planning session’s context away. Each slice gets a fresh session that can read the document and pull in the code or history it needs. Otherwise the conversation accumulates every investigation and false start, most of which the next slice does not need.

A slice needs to go through the behaviour that a person can actually test. AI loves to work horizontally, so it is very easy to ask for a slice and get only the database work. That may be a useful task, but you haven’t learnt whether the product change works. I’d rather take a smaller change through the interface, the behaviour and its tests, even if that means the first release does very little.

If you’re using feature toggles , then theoretically you should be able to release each vertical slice to live. That’s the perfect codebase to work in, provided you have a feedback mechanism as quickly as possible before you move to the next slice.

Keep the decision with the person

Connecting a ticket tool does not mean giving the agent permission to edit tickets or release code. In my earlier Jira and source-code agent experiment , the agent found a possible email-validation regex from a vague report of errors, then filled in details about the fault that nobody had supplied. It was useful as a lead, but it was still a leap. I said then that the original wording should stay intact and the agent’s guesses should be offered separately for consideration.

That is still the boundary I’d use here. Let the agent search, propose a slice and write code against an agreed requirement; have a person resolve the ambiguous requirement and review consequential writes or releases. MCP tool annotations can describe risk, but their maintainers say those hints are not an enforced security boundary. Permissions and approvals have to do that job.

I start with what the agent needs to find:

• Relevant repos. Clone the ones that talk to one another, with their history, instructions and tests available for inspection.
• Ticket context. Give it a read path to the work tracker and the changes under way there.
• Decisions outside code. Look for current diagrams, living PRDs and operational evidence of actual use, and treat wiki pages with care.

The cost is keeping those sources useful and resolving disagreements, which a longer prompt cannot do for you. Work out the vertical slices before the agent starts cooking, and get feedback on each one as quickly as you can.