Birgitta Boeckeler

Workflow instructions, coding conventions, tickets, wiki pages, and observability data all end up in the same context window, and we call all of it "context." To the model, it's all tokens shaping the next prediction. For the people who write, maintain, and rely on context, these tokens differ a lot in where they come from, how much authority they carry, and how they can go wrong. Some are deliberately authored and quality assured. Others emerge as a byproduct of work and are dynamically retrieved and reconciled from organizational systems.

This talk discusses how these differences change the ways that each kind is created, checked, and delivered to the agent, and that treating them alike can lead to using unsuitable tools and processes. You will leave with a clearer idea of the types of context you have available for your coding agents, and how to best maintain them.

It's your first week on the team. You read everything attached to your first ticket: the README, the wiki, the Linear project. You ship the PR. The review comes back from a senior engineer: "we stopped doing it this way in March, the vendor doesn't accept that shape anymore." Nobody wrote that down. It lived in a Slack thread from an incident two months ago and in the heads of the people who were up that night fixing it. You learned it by getting it wrong.

That's how most engineering knowledge gets earned. Not from documentation someone sat down to write, but from the act of the work itself: the pull request comments, the chat thread where a feature got argued out, the incident channel while people are still responding, the support channel where a customer explained what they actually needed.

I call this emitted context. It was just typed, by people, doing their jobs.

Authored context is what the team decides matters: the rules and skills files for agents, the wikis and READMEs we curate. High leverage, worth doing well. Emitted context is what the team told each other while doing the work. Your agents today are you, the new hire, on every single task, and they never get to build tribal knowledge.

Letting them build it is a lot harder than connecting a Slack MCP. Emitted context contradicts itself, goes stale overnight, and includes things not everyone is allowed to see. This talk is about the context layer that handles that: surfacing context nobody authored, reconciling it with citations, keeping it fresh, with no human in the loop. Automate a factory on authored context alone and it can only act on what somebody remembered to write down, and no one person knows everything the team knows.

I'll run the same task with and without emitted context, show why agents don't stop to ask for what they're missing, and cover the three things we got wrong building this. You'll leave with open source tools we extracted from our context layer, and a clear read on whether your agents can unblock themselves or if you're trapped in the factory.