One Idea at a Time

Most organizations approaching AI agents ask which model to use. It is the wrong first question, and the answer keeps changing anyway. Here is the more useful framing, which I picked up from Eran Yahav of Tabnine and have not been able to unsee since. An enterprise agent stack has three parts, not one: The LLM — powerful, general, and completely ignorant of your organization. It has never seen your systems, your history, your incidents, or the reason that one service is named after someone's dog. The agent — orchestration, tool use, interaction with humans. The context engine — a persistent, continuously maintained map of the organization itself. Almost everyone invests in the first two and improvises the third. That is why agents fail most complex enterprise tasks — and the failures are usually not reasoning failures. They are onboarding failures. The agent lacks the knowledge a human engineer accumulates in their first few months and then never thinks about again. The bl...

In 1968 Melvin Conway published an observation that has since outlived most of the technology it was written about: organizations that design systems are constrained to produce designs that copy their own communication structures. It sounds like a curiosity. It is closer to a law of physics. Siloed departments produce siloed systems. Departmental budgets produce departmental technology choices. Teams measured locally produce locally optimized architectures. None of this requires anyone to make a bad decision — every actor can behave sensibly within their scope and the result is still fragmentation, because no one is accountable for the whole. This leads to the uncomfortable conclusion for anyone who owns an architecture function: governance cannot win this fight indefinitely. You can publish principles, run review boards, and maintain a target-state model, and the organization will still quietly re-fragment your systems — faster than governance can integrate them — as long as repor...