Product Context Layer
Even a small product holds far more unwritten knowledge than anyone realizes. An agent can draw it out quickly, but someone still has to own keeping it true.
What I built
I built a Product Context Layer for Work2gether AI: a structured set of files that holds what an AI agent needs to know to work on the product correctly. That covers what the product does and for whom, the domain rules, the decisions made along the way, and the conventions the product follows. The files are modular, so an agent working on a given task can load just the part that's relevant, instead of the whole thing or nothing.
I didn't write it myself. I gave an AI agent everything I had: product material, internal notes and the public website. I asked it to propose a structure and then interview me until everything was explicitly documented. My job was mostly answering questions and steering. It still took real time, most of it mine.
What it revealed
There was much more unwritten knowledge than I expected. I built Work2gether AI alone, so I assumed I knew everything about it. I did, but most of it existed only in my head. Why a feature works the way it does, which edge cases matter, which conventions I'd been following without deciding on them: very little of that was written down anywhere.
The material that did exist was the wrong kind of context. The website and product material described the product for buyers, not how it actually works or why. Some of it was out of date. An agent working from that alone would have been confidently wrong.
The agent was good at exactly the parts people find tedious. It kept track of what had been covered, knew where each answer belonged, and kept asking the next question. The constraint was never the documentation work. It was my time and knowledge.
Keeping it true is the unsolved part. Creating the layer is a one-off effort. Keeping it current as the product changes is ongoing work. My design is that each finished piece of work feeds its learnings back into the layer, but I haven't tested that over time yet.
What it means for a product organization
When AI agents do more of the work, the quality of their context sets the ceiling on the quality of their output. Context stops being documentation and becomes infrastructure.
In most organizations, this knowledge is spread across the heads of a few experienced people, and it leaves when they do. Drawing it out used to be expensive enough that it rarely happened. With an agent running the interviews, it's now cheap enough to be a realistic choice. The constraint is prioritizing the time of the people who hold the knowledge.
The same context helps people, not only agents. If individuals are expected to work across more of the product lifecycle, access to well-structured domain knowledge is what makes that possible.
That leaves an open question most organizations haven't answered yet: who owns it? Product, engineering, or a platform function? Whoever it is, keeping context true needs to be someone's explicit responsibility, not a side effect of good intentions.
What I'd test next
Building a context layer for a larger product with several contributors, and testing whether the feed-back loop actually keeps it current when many people and agents are changing the product at once. I'd also like to compare agent output on the same task with and without the layer, to see how much difference it really makes.
Read more
- The Bottleneck Didn't Disappear. It Moved. (on LinkedIn)
- AI Removes the Excuse for Poor Documentation (on LinkedIn)
- Documentation Is an Accelerator, Not Overhead (on LinkedIn)
- Related Fieldwork: Full Agentic Software Development Lifecycle, where each stage draws on a context layer like this one.
See the other things I've built to test how AI changes product organizations.
Back to Fieldwork