Writing
AI-for-Work: A Systems Guide to Governed AI Deployment
I've spent the last several years inside large companies trying to make AI useful under real constraints: security review, privacy law, production systems that cannot be casually broken, and thousands of engineers with different appetites for change. This series is what I think I've learned.
The short version: enterprise AI adoption is not mainly a model-selection problem. The models are good and getting better, and everyone has access to roughly the same ones. The hard part is the operating system around them — the tools, gateways, observability, orchestration, and adoption loops that let a large organization work differently without losing control of what its AI is allowed to do.
That last clause is the through-line. The durable advantage isn't the model. It's the system that decides which agents can see which context, call which tools, produce which artifacts, and touch which production surfaces. I think of it as deployment control, and every post in the series is a layer of it.
Posts in this series
Part 1: Get Everyone an AI IDE
The unglamorous first move: put AI at the point of work before building anything fancier.
Part 2: Build a Centralized MCP Gateway
Give agents access to internal context through one audited, permissioned layer instead of a hundred local hacks.
Part 3: From Proxy Logs to Intelligence
The request stream already tells you who's using AI well, where it fails, and what it costs. Read it.
Part 4: Agent Orchestration at Scale
Agents that touch real systems need a runtime: state, permissions, recovery, and a kill switch.
Part 5: Preserve Institutional Knowledge
Keep the reasoning behind decisions, because agents without context start from folklore.
Part 6: Work-as-Code
Turn repeated engineering chores into small, typed, owned interfaces that agents can call.
Part 7: Observability and Adoption Programs
Adoption is a product, not an announcement. Find your best users and learn from them.
How to read it
The posts are written in order and the order matters: each layer assumes the one before it. IDE surface, then the gateway that connects it to context, then observability over what's flowing, then the runtime for agents, then memory, then workflow interfaces, then the program that ties adoption together. You can dip into any single part, but the argument is the stack.
There's also a companion essay, When "Move Fast" Meets "Move Safely", on the mindset shift underneath all of this — how to keep startup speed inside an institution that has real downside to protect.