Working with AI against a real workspace is different from a one-off chatbot exchange. A project folder, shared document set, repository, or client artifact already carries drafts, decisions, boundaries, and history before the assistant ever enters the conversation. The work does not start from a blank prompt; it starts inside material that already has meaning, risk, and prior judgment attached to it.
Take a project lead revising a client-facing document. The request may sound like a narrow editing pass, such as cleaning up a section, revising a paragraph, or preparing an update, but the document belongs to a workstream with earlier drafts, client sensitivities, prior decisions, and sections that should not be reopened. The assistant cannot understand the task only by reading the latest file; it also needs the judgment that shaped the file and the boundaries that protect the work around it.
When that judgment has no agreed home, the human has to rebuild the room before the work can begin. They explain the client, the purpose of the document, the current state, the audience, the unresolved pieces, and the boundaries around what should not change. If the assistant can inspect local files or a shared folder, it still needs to know which materials matter and what authority they carry. If the work happens in a plain chat window, even more of that frame has to be pasted or summarized by hand.
The first session may justify that effort because serious work always needs some orientation. The problem appears when the same project keeps paying the same cost through different people and different sessions. A week later, someone else asks for help on the same client document and repeats the audience, approval boundary, and off-limits sections because the last session’s useful judgment never landed anywhere the project could reuse. A third person may give the assistant a slightly different version of the same background, which means the project is no longer only wasting time; it is allowing the operating frame to drift from person to person.
The team loses time, repeats effort, burns context, and keeps redoing the same orientation work because there is no shared process for how AI should enter the project. The context window matters, but it is only one symptom of a deeper problem: each person is still carrying a private version of the project’s operating frame, made from what they remember, what they noticed, and what they assume the assistant needs to know. Those private frames may each be partly accurate, but they diverge because each person sees only their own part of the work instead of the full frame the project needs to preserve.
Chat can still be part of the workflow, but the context that matters cannot live only inside whichever conversation happened last. If the project has files, folders, drafts, decisions, standards, and handoffs, it needs a way to introduce itself before the live session starts. Otherwise every assistant enters through the memory of the person asking for help, and every person becomes responsible for reconstructing a frame the project should already carry.
The project needs a way to introduce itself
Most teams already have context scattered across surfaces: old messages, meeting notes, prior drafts, working documents, and AI transcripts the next person or assistant may not know how to read. That is why the frustration can masquerade as a prompting problem. A better prompt may rescue the current session, but it does not create a shared way for the next person or assistant to enter the same work. Without that shared entry point, each session renegotiates what the assistant is supposed to understand.
A context convention is the team’s agreement about where reusable context belongs. It gives people and tools a place to look before the live conversation starts, and it should be small enough that people trust it and use it instead of rebuilding the frame from memory. For file-backed work, the convention usually needs to answer three practical questions: where a human goes to understand the project, where an assistant goes to understand how to operate inside it, and where the next session learns what changed and what still matters.
The answer can look different across teams. A software team may use README.md, AGENTS.md, and CONTINUATION.md; a consulting or operations team may use a project brief, an assistant guidance note, and a handoff file inside a shared workspace. The names matter less than the agreement behind them. Human orientation, assistant guidance, and continuity each need a home because they serve different readers at different moments in the work.
Human orientation gives people the plain-language frame for entering the project: what the work is, why it exists, where the important materials are, and what a capable person should understand before contributing. It keeps a new contributor from treating a mature workstream like a blank assignment. Assistant guidance turns that frame into operating rules, including approval boundaries, accepted standards, client sensitivities, and sections the assistant should not touch, so the tool does not reopen settled work while trying to be helpful. Continuity keeps the active edge visible by recording recent changes, key decisions, open questions, and details the next human or agent should not have to rediscover. Each surface answers a different entry question, and together they keep reusable context close enough to the work that the next session can begin from the project instead of from one person’s memory.
This is not a documentation project
Documentation-phobia is reasonable. Most teams have watched working documents turn into graveyards with too much material, too little trust, and no connection to the work people are actually doing. A context convention earns its place only if it reduces the explanation required to start useful work. A file that keeps the next session from reopening a section the client already approved, applying an outdated standard, or sending a draft the team has marked off-limits is doing real work; without that practical value, it becomes another stale checklist.
The convention should also reduce the small decisions that otherwise become repeated debates. If a client accepts a section as final, the next person should know whether that belongs in the document status note, the assistant guidance file, or the handoff. If a style rule changes, the team should not need a meeting about where the rule lives before anyone can apply it. The project has enough shape when the next useful breadcrumb has an obvious home and the team trusts that home enough to use it.
A stronger model may recover from weak context, but the team still pays for that recovery every time the project starts cold. The model spends its attention establishing background instead of helping with the work, while the human has to supervise that recovery, correct assumptions, and re-anchor the task. The cost is not only slower output; it is the loss of shared judgment that could have compounded across sessions.
The work becomes more transferable
AI-assisted work compounds when the useful part of one session changes the next round of work. A good answer inside a private chat may help one person today, but the project only benefits tomorrow if the judgment behind that answer lands somewhere reusable. Without a context convention, project knowledge fragments across people: the style rule stays in one person’s head, the approval boundary in another’s, and the reason a folder was organized a certain way may sit in an old chat. The assistant can still be useful in any single session, but the system depends on whoever happens to be present.
A convention gives that knowledge somewhere to land without removing human judgment from the work. The human still sets intent, corrects the assistant, and decides what matters; the difference is that useful judgment can survive the conversation that produced it. AGENTS.md is a useful example because agents need operating guidance, but the broader practice applies anywhere people use AI repeatedly against shared materials. Context, decisions, and standards are usually present; the failure is that the next person or assistant does not know where to find them.
Start with one active project where AI work keeps beginning with the same explanation, then choose the three surfaces it needs now: human orientation, assistant guidance, and continuity. Move existing context into place, cut anything that does not help the next session, mark uncertainty clearly, and keep the convention close to the daily work it supports. The point is not to build a knowledge system before the practice has proven useful; the point is to stop making people recover the same operating frame by hand.
Reusable context needs a place to live before it can shape the next session, but that place has to stay current. Maintenance deserves its own treatment because stale guidance can become its own source of friction. For now, the useful test is simple: before the next meaningful AI session, ask whether the project already knows what you are about to explain, then put that knowledge where the next human or assistant can use it.