The checklist works for one agent. The platform is needed after the second.

Agent design checklists are circulating again. Model, tools, context, orchestration, guardrails, observability. Every item is correct.

They describe one agent, built by one team.

The list holds until a second team ships an agent. Then all six items exist twice, defined differently, and nobody owns the difference.

Team A retries a failed tool call three times. Team B retries until it succeeds. Both call the same internal billing API.

Permissions is where this gets expensive. Tool access gets granted by whoever wired the tool. Six months later there is no record of who approved write access to a production system, and answering "which agents can touch this API" means reading six repositories.

Tracing has the same shape. A decision that crosses agents owned by different teams leaves a trace in each of them, in different formats, with no shared correlation id. The incident review reconstructs it by hand.

These problems belong to the platform layer. IAM and audit solved this shape for services years ago. Agents brought it back because they arrived as application features, one team at a time.

The platform question is narrower than the design question. Who decides what an agent is allowed to do, and where is that decision recorded.

P.S. The six-item checklist gets written often because it has an end. You can finish designing an agent. Permissions and audit have no finish, they have an owner, and that owner has to exist before the second team ships. It is the part that gets skipped in architecture for the same reason it gets skipped in posts.