AI agents expose the same platform problems that already slow human developers, especially undocumented processes, manual handoffs, and pipelines that fail too late.
2
Platforms should give both developers and agents self-service, well-defined APIs, local validation, structured documentation, and machine-readable observability.
3
Teams should welcome agent-assisted contributions while protecting platform quality with policies, guardrails, repository context, and measurements of delivery, reliability, and developer experience.
Summary
Juan Herreros Elorza describes Atlas, Banking Circle's internal platform, and uses a new developer's frustrating deployment experience to show why agents need better platform design. A human can ask a teammate how to fix a failed pipeline or wait for an infrastructure specialist to create a database. A coding agent generally cannot. His advice is to make platform capabilities self-service, expose them through well-defined APIs, and let agents validate work locally before pushing changes. Documentation should live beside code where practical, or in a structured central repository for larger platforms. Agent-specific files and skills can explain local conventions. Observability also needs machine-readable access through APIs, CLIs, or MCP servers so an agent can check whether its work succeeded. Agents make platform contributions easier, so owners need policies and context that protect security, compliance, standards, and maintainability. Juan recommends measuring whether these changes improve delivery, reliability, support demand, and developer experience.
Agents make hidden platform friction impossible to ignore
Juan describes a developer who copies an existing pipeline, changes it for a new application's requirements, and then faces an infrastructure error that has nothing to do with their code. They ask teammates for help, wait for another team, and discover later that the application also needs a database or blob storage. A human can work through these social and organizational steps. A coding agent generally cannot walk over to another team or wait for a person to fix the problem. Juan's point is that these practices were already poor for developers, but agents make the cost much more visible because the agent cannot complete its work without a self-contained path.
Self-service must remove people from the execution path
Juan says that anything a developer or agent needs from the platform should be available without talking to a specific person or waiting for someone else to act. The flow also has to be intuitive. A process is not meaningfully self-service if users must collect building blocks from five different places, assemble them, and trigger another flow elsewhere. His practical advice is to automate the process, remove people from it where possible, and make the path easy to follow. This applies equally to human users and agents, since an agent needs to trigger every required step by itself.
A well-defined API should sit underneath platform interfaces
Self-service can use a button, text, a CLI, or an MCP server, but Juan recommends having a well-defined API underneath these interfaces. The agent can discover what the platform does and which options are available. Schemas provide validation so it can send inputs that are likely to work. Authentication and authorization let the agent use a developer's credentials or its own credentials for a specific flow. The API returns a response, allowing the agent to try, inspect the result, and continue in a loop until it has completed the requested task. Juan presents this interaction as the foundation for secure, repeatable agent use.
Local-first workflows let agents correct errors early
Because the agent's work usually happens on the developer's machine, Juan advises shifting validation left. A platform should not make an agent push code to version control and wait several minutes for a workflow to fail if the same checks can run locally. Local API calls or wrappers can expose those checks earlier. The agent can then iterate in a loop, provided it has a precise task description and a clear definition of success. Humans may verify deployment through several systems and dashboards, but agents need an explicit way to determine that they have finished the task correctly.
Observability must be available in forms an agent can consume
Juan argues that logs, metrics, traces, and other signals should be available through an API, CLI, MCP server, or a similar machine-readable interface. Agents will not generally inspect the graphical dashboards that humans use to check whether an application deployed correctly or whether its metrics look healthy. Exposing observability through callable interfaces lets the agent verify runtime behavior as part of its work. This closes the loop between an instruction such as deploying an application and the evidence needed to decide whether the deployment actually succeeded.
Documentation needs structure and repository context
Juan says documentation has always been difficult to find for humans, and agents make that weakness more costly. In a small repository, documentation can live next to the code it describes, giving an agent the relevant instructions in the same working area. A platform team with broader material may need a central documentation location where an agent can discover what is available. He recommends an API-first approach, especially when the platform can return the specific documentation an agent needs instead of making it process a whole HTML page. Files such as AGENTS.md, CLAUDE.md, or other agent instruction files can describe how to build, test, deploy, and verify work in a repository.
Agent-assisted platform contributions need guardrails
AI agents lower the barrier for developers who want to contribute to internal platforms, and Juan encourages platform teams to welcome those contributions. The platform owners still remain responsible for maintenance. They need guardrails for security, compliance, standards, and other conditions that must not be violated. Policies can block unacceptable changes, while agent instruction files and skills can explain the preferred way to work. Juan recommends combining both approaches: use policies for rules that cannot be broken, then use Markdown context and skills to guide agents through the conventions of the platform.
Platform changes should be tested against measured outcomes
Juan asks how teams can know whether an AI-ready platform actually worked. They can compare measurements from before and after a platform change. Possible measures include application delivery metrics associated with DORA, reliability and error rates, traffic behavior, support requests, and developer experience frameworks such as SPACE. A self-service platform might reduce support requests, but confusing implementation could increase them. The metric should follow the intended outcome. If the goal is to make it easier for agents to contribute, the team should measure whether that became true rather than assuming that new interfaces produced an improvement.
