Kwesi’s retry fix risks duplicate records. A customer’s finance team pays.

An AI coding agent can understand the codebase and still miss the facts that determine the right product decision. Give it the repository alone and it can produce convincing work against an incomplete picture.

Consider Kwesi, a composite founder in Accra, at 9:12 on a Monday morning. His laptop is open to a pull request that adds a fallback when a customer’s document extraction fails. The coding agent has traced the error path, found the relevant service, and suggested a clean retry flow.

Then a customer replies in a private support thread: their team had deliberately disabled retries because duplicate submissions were creating a costly reconciliation problem. A deployment log from Friday shows a configuration change that never reached the repository. The customer’s workspace has a flag set during onboarding by someone who has since left the company.

Kwesi can merge the suggested fix and make the dashboard look healthier by lunch. Or he can pause, call the customer, and learn whether a second attempt will turn one failed document into two records their finance team has to untangle. The bad ending is clear: a well-written patch creates a problem for the account that has been waiting longest for a reliable workflow.

The repository holds the implementation. The system includes the exceptions people made around it.

The missing context lives where work actually happens

Early teams often treat source control as the authoritative record because it is the most legible record. Code has history, review comments, tests, and ownership. An agent can search it quickly and explain what it found with impressive confidence.

But product decisions accumulate outside the codebase.

A support thread may explain why a validation rule exists. A sales call may reveal that a promised integration is still manual. A deployment log may show a version mismatch. A customer configuration may contain the one condition that turns a sensible general rule into a bad choice for a particular account.

These are not edge cases when you build AI products for real teams. They are part of the operating environment.

The gap becomes expensive when a team asks an agent to answer a question framed as code maintenance but the real question is product judgment: should this workflow retry, block, escalate, or ask for confirmation? The code can show what happens today. It cannot establish why the customer chose a different path unless that reasoning has been captured somewhere it can reach.

This is also why a polished demo can create the wrong confidence. In Nia’s real workload and customer trust, the important test is the work the customer actually brings, including its awkward conditions and incomplete inputs.

A private thread can change the correct patch

Kwesi does not need every conversation added to an AI agent’s context window. That would create noise, access problems, and a new place for sensitive customer information to spread.

He needs a path from a decision to its evidence.

For the retry issue, that path could be a short decision record linked from the relevant service: retries are disabled for certain document types because duplicate records create downstream reconciliation work. It could point to the configuration setting, the support ticket where the constraint surfaced, and the owner who can confirm whether it still applies.

The useful unit is not “all company knowledge.” It is the smallest set of context needed to make a change safely.

That distinction matters on limited runway. Teams can spend weeks trying to centralize every note, call, and message before they let agents touch meaningful work. Meanwhile, the product keeps changing and the useful context goes stale. Start with the decisions that routinely surprise engineers or support staff: customer-specific behavior, deployment exceptions, commercial commitments, and rules created after an incident.

A customer map is often more valuable than another internal wiki page because it connects people, promises, configurations, and product behavior. That is the operating record an AI product team cannot afford to lose, as explored in The Customer Map an AI Startup Cannot Afford to Lose.

Build context around decisions, owners, and access

The question is not whether an AI agent can read more files. The question is whether it can reach the right evidence without exposing information it should never see.

Start by making a small number of high-consequence decisions legible:

• Record why customer-specific settings exist, alongside the setting and the person responsible for revisiting it.
• Link deployments to the product decision or incident that caused an exception.
• Turn recurring support explanations into short, reviewed guidance near the code or workflow they affect.
• Require agents to surface uncertainty when a proposed change depends on configuration, customer commitments, or recent operational history.

The last point deserves attention. An agent that says, “I found the retry handler, but I cannot verify whether this customer allows retries,” has done something useful. It has identified the boundary between implementation and judgment.

Kwesi pauses the pull request. He reads the support thread, checks the configuration, and asks the customer one direct question before changing anything. The eventual patch may be smaller than the agent’s first proposal. It may add a visible review state instead of an automatic retry.

By the afternoon, the failed document remains visible in the customer’s queue, with one clear next action. No duplicate record is waiting for a finance team to discover it later.