You are no longer building your platform for humans

Coding agents are now your platform’s primary user. They didn’t onboard and have never once attended your all-hands. But they’re here and they’re consuming your platform right now.

Your platform acquired a customer

When a developer needs a secret injected into a workload, they increasingly don’t do it themselves. They ask Claude Code or Copilot to do it. The interaction with your platform is no longer a human editing YAML. It’s a human having a conversation, and an agent doing the editing.

So your platform has acquired a new customer. Nobody filed a ticket for this. The agent simply showed up and started consuming everything you’ve built: the APIs, the repos, the docs, the half-documented golden paths. It is now a major consumer of all of it, and its traffic share is only going up.

When a product picks up a customer it wasn’t designed for, the product has to change to serve that customer. And it’s important for us platform engineers to change our product quickly. Developers now generate code faster than ever, so the friction everywhere else in the delivery path becomes the bottleneck. Platforms that agents can’t use will generate more support load and more frustrated developers.

So: three strategies, in rough order of ambition.

Strategy 1: No UI-only capabilities

If the only way to accomplish something on your platform is to click through a UI, an agent cannot do it. The capability does not exist for your new customer.

Every capability needs a programmatic path: an API, a CLI, a file committed to a repo. The UI should be one of several interface sitting on top of a capability.

This isn’t novel advice. “Everything should have an API” has been platform engineering common sense for years. But UI-only workflows used to be a minor annoyance for power users and automation. Now they’re a hard wall for your primary user.

Strategy 2: Your platform’s real manual lives in Dave’s head

Suppose every capability has an API. You’re still not done, because an agent that knows Kubernetes in general does not know your platform in particular.

It doesn’t know your naming conventions, your preferred abstractions, or the five gotchas every senior engineer has quietly memorized and never written down. That knowledge — the difference between “knows Kubernetes” and “can ship safely here” — is scattered across wikis, repos, Slack threads, and Dave. Dave is on vacation. Dave is always on vacation.

If you want the agent to behave like one of your engineers, you have to hand it what your engineers know:

• Convention files like AGENTS.md that encode how things are done here. Which tools to use, which patterns to follow.
• Shared skills and reusable playbooks for common platform tasks.
• Worked examples from real, blessed services, so the agent pattern-matches against configurations that actually run in production instead of inventing plausible-but-wrong ones.

One caveat: naive retrieval over your existing docs is usually not enough. The real knowledge was never all written down, what is written is often stale, and the important parts live in conversations and in Dave’s brain. Context has to be gathered from many sources, preprocessed into something an agent can actually use, and ideally improved with every interaction instead of quietly rotting.

Strategy 3: Build things for agents

The first two strategies still treat the agent as a guest in a human’s house. You’ve widened the doorways and left a note on the fridge, but the house is built for the human. The ambitious move is to build infrastructure whose primary customer is the agent itself.

Concretely:

• A shared layer that exposes your platform’s capabilities and live state to agents. With authentication and permissions done properly, so an agent acts with the access of the developer behind it.
• Guardrails inside the layer: Safety checks and policies live in the system the agent calls.
• Purpose-built agents behind that layer: Agents that are wired into your systems: CI/CD, observability, K8s, etc. Rather than a generic agent in one platform component, you want a system that understands how your platform fits together. The friction often lives in the seams between components, not the components themselves.

Conclusion

You didn’t choose to take on coding agents as users of your platform, but they’re here to stay. Successful platform teams will treat that as a product problem: the product has acquired a new customer, so the product has to adapt.