Once upon a time, a company hired a tireless developer who wrote code before breakfast and even used Jira without complaining. They gave their new colleague access to every repository and a license for every tool. Onboarding complete.

A junior developer would have had questions. Who owns payments? Why don't we use that library anymore? Eventually, they'd learn that Alice knows, the incident report explains, and the runbook they found survived two reorganizations because nobody ever followed it.

Our developer is an AI agent. It has to work all of that out too. Except tomorrow, a fresh context window makes it a new hire again. Same impressive résumé, no recollection of orientation. It reconstructs the company from whatever it happens to find, one guessed unbounded MCP call at a time, while burning tokens like it's 2025 and tokenmaxing is still a thing. Yesterday it found Alice, today it found a wiki page written by her predecessor instead, and both answers sounded convincing.

Even if the frontier labs give us an agent that writes great code, who teaches it how we do things around here?

Baruch follows our unfortunate new hire through an organization that assumes access means understanding, and considers what an agent needs to know to work there. How does company knowledge become something an agent can reliably use and reuse, who keeps that knowledge current, and what should still require a conversation with Alice?

Alice is very good at onboarding agents. She calls herself a "prompt engineer" now. But onboarding the same colleague every morning is getting old, even for her.

The talk challenges the assumption that a coding agent is ready to work once it has repository access and tools. A fictional onboarding story makes conflicting company knowledge concrete, with questions about reliable reuse, maintenance, and the decisions that still require a person.