Writing
Part 6: Work-as-Code: The Micro-MCP Revolution
A surprising amount of engineering work is trapped in human procedure: check this dashboard, update that config, file the ticket, run the script, paste the result into the right channel. Nobody designed these rituals. They accreted, and now they live in the heads of whoever has been on the team longest. Work-as-code is the practice of turning them into explicit, callable interfaces. ("Revolution" is a big word for what I'm about to describe, which is mostly writing small wrappers with schemas. But the cumulative effect earns it.)
The underlying observation is simple: agents are only as useful as the actions available to them. If the work stays hidden in tribal knowledge and browser clicking, agents stall at the edge of every workflow. If the work is exposed as code, agents can compose it. The bottleneck isn't model intelligence. It's the interface surface of your company.
Micro-MCPs should be boring
I call these interfaces micro-MCPs, and the prefix is doing real work. They don't need to be platforms. A good one wraps exactly one workflow boundary — open a rollout ticket, fetch a service dependency graph, run a migration precheck, stage a report — with a schema, validation, authorization, dry-run behavior, and an owner. The agent supplies intent and context; the tool supplies guardrails and a consistent contract. The division of labor matters: the probabilistic part proposes, the deterministic part constrains.
The tempting wrong answer is "just let the agent use the UI." It demos well and it inherits none of your controls — no schema, no authorization boundary, no dry-run, no owner, and it breaks the day someone moves a button. A narrow typed tool is less impressive and more durable, which is a trade I'll take every time.
Design constraints that have held up
- Many narrow tools beat one broad admin tool with ambiguous authority. Ambiguous authority is exactly what you don't want to hand a model.
- Side effects should be explicit in the contract: read, dry-run, stage, execute, notify, delete. (This is the same read/stage/mutate discipline from the gateway in Part 2, pushed down to each tool.)
- Results should be structured enough that another agent can compose them and a human can review them.
- Every tool needs an owner, a version, and a deprecation path — otherwise you're building a new kind of legacy system, just faster.
Where to start is less mysterious than it sounds: take the repetitive tasks that already have a clear human playbook. If you can write the runbook, you can write the tool. The playbook was always code; it was just compiled into a person.
I don't think enterprise automation converges on one giant agent that does everything. It converges on a growing library of small, trustworthy work interfaces — and on the unglamorous question of who maintains them, which is a real question, because this library becomes infrastructure the moment anything depends on it.
This is Part 6 of the AI-for-Work series. Next: Part 7: Building AI Observability and Adoption Programs.