Platform Concerns Versus Agent Concerns

The fastest way to build a platform nobody uses is to take away decisions the agent teams should be making. The second fastest is to leave them decisions they cannot possibly make safely.

Both failures look reasonable from inside the platform team. The first comes from wanting consistency; the second from wanting adoption. Most platform teams oscillate between them for a year before landing somewhere defensible, and the oscillation is expensive because every correction is a migration.

This lesson gives you the test to apply once, up front.

The problem

The over-centralised platform tends to arrive first. It ships a blessed agent template, an approved prompt structure, a required task-decomposition pattern, and a review gate. It is coherent, well-documented, and used by nobody, because the first team with a use case the template did not anticipate discovers that the platform is a constraint rather than a service. They fork it, or they buy a SaaS agent product on a corporate card, or they build directly against a provider API and tell nobody. You now have all the fragmentation you started with, plus a platform to maintain.

The under-centralised platform arrives second, usually as a correction. It offers a gateway, publishes a tool registry, writes a good README, and lets teams opt in. Adoption is genuinely high, because the paved road is pleasant. Then an incident review asks which agents can write to the ledger, and the answer requires interviewing six teams — because the tool registry was opt-in and three teams integrated directly.

So the bias should be: centralise few things, and make those few genuinely unavoidable.

How it works

Three questions decide which side of the line a capability sits on. A capability belongs to the platform if the answer to any of them is yes.

1. Does getting it wrong hurt someone other than the team that got it wrong? A bad prompt produces bad answers for that team's users. A missing idempotency key double-charges a customer. A leaked provider credential exposes every tenant's traffic on that key. Blast radius that crosses a team boundary is the clearest signal for centralisation.

2. Does the team have the information required to decide well? An agent team knows their domain. They do not know the organisation's data-residency obligations, which models legal has cleared for which classifications, or what the aggregate token budget is. Asking them to decide is not delegation, it is abdication — they will make a reasonable-looking choice using information they do not have.

3. Must it be provably uniform across the fleet? Anything you will one day have to demonstrate to an auditor — identity, action logging, policy evaluation, model allowlisting — must be uniform, because "most teams do this correctly" is not a control. If the evidence has to cover the whole fleet, the mechanism has to be shared.

Apply those and the split falls out with very little argument left:

The pattern in the right-hand column: every item is something that changes weekly and whose failure mode is a worse product, not a worse organisation. The pattern on the left: every item changes rarely and fails across boundaries.

Platform design implications

Knowing where the line goes does not get it enforced. Two mechanisms do that, and they are not interchangeable.

Mandates work only where bypass is architecturally impossible. The action gateway is mandatory not because a policy document says so but because agents run in a network segment that cannot route to systems of record directly. The model gateway is mandatory because provider credentials exist only inside it and are never issued to teams. That is the correct shape for a mandate: it is not a rule someone can break, it is a path that does not exist.

Write down the small set of things you will enforce this way and stop there. Every additional mandate needs its own enforcement mechanism, and mandates you cannot enforce are strictly worse than none — they create the belief that a control exists.

Everything else is a paved road, and paved roads compete on economics. A team adopts the platform's evaluation harness because building one costs them three weeks and the platform's costs an afternoon. They adopt the tool registry because registered tools get discovery, versioning, and on-call for free. The measure of a paved road is the time-to-first-working-agent for a team that has never used it: if that is under a day, adoption follows without a memo.

The general shape there is worth stealing. Where you need something to be universal, make it a side effect of a thing teams already have to do, rather than a separate obligation.

Tradeoffs and decision framework

Uniformity versus velocity. Every centralised decision is a decision made once and applied everywhere, which is efficient until a team has a legitimate exception. Plan the exception path before you need it: a documented way to get a scoped, time-bounded, reviewed deviation. Platforms without an exception path do not get fewer exceptions, they get undocumented ones.

Mandate breadth versus enforcement cost. Each mandate needs a mechanism, an owner, and a failure mode when the mechanism is down. Five enforced mandates beat twenty aspirational ones.

Early consistency versus early adoption. A useful sequencing: enforce the action gateway and identity from day one, because they are the two that cannot be retrofitted. Let everything else be opt-in until you have enough real usage to know what the right shape is. You will design a better tool registry after ten teams have used a mediocre one than you will in a whiteboard session with none.

Platform as gatekeeper versus platform as service. You will end up as both — Module 11.4 covers the readiness review that gates production access. The way to hold both roles without becoming resented is to make the gate mostly automatic: the criteria are checks the platform can run, not opinions the platform team offers.

Common mistakes

• Mandating anything you cannot enforce architecturally. It creates a false belief in a control while selecting for compliant teams over careful ones.
• Owning prompts. They change daily, they are the product's voice, and a platform review gate on them guarantees teams route around the platform entirely.
• Picking the orchestration framework for everyone. The fastest-moving, least durable choice in the stack. Own the interfaces, not the library.
• No documented exception path. Guarantees undocumented exceptions, which are the same thing minus the audit trail.
• Measuring adoption by registered agents rather than by traffic. A registry entry is not usage. Count what flows through the gateways.
• Adding a mandate to fix an incident. The incident usually reveals a missing enforcement mechanism, not a missing rule. Ask what would have made the failure impossible rather than discouraged.
• Treating "the platform owns identity" as covering only agent identity. It has to cover the composite chain through delegations, or the control degrades to "some agent did something." Module 7.5.

What to remember: centralise on blast radius, information asymmetry, and evidence uniformity. Enforce the short list architecturally so it is a path that does not exist rather than a rule to break. Everything else competes on being easier than the alternative.