Platforms for Humans and Machines: Engineering for the Age of Agents — Juan Herreros Elorza
TL;DR
Agent-friendly platforms are just good platform engineering made unavoidable — Juan Herreros Elorza argues that the same bad patterns humans tolerated—copying pipelines, chasing teammates, waiting on infra teams—completely break when an AI coding agent hits them.
Banking Circle built Atlas to serve 250+ technical builders across a €1 trillion/year fintech — the internal platform spans Kubernetes compute, infrastructure provisioning, messaging, and observability for more than 700 regulated financial institutions.
Self-service and API-first are the core design rules for the age of agents — if a task requires Slack, Teams, or a person on “the second floor,” an agent can’t reliably do it, so every key platform action should be exposed through intuitive APIs, CLIs, or MCP servers.
Local-first workflows and shift-left validation make agents dramatically more effective — instead of pushing code and waiting minutes for a CI failure, agents should be able to validate, provision, and iterate locally in tight loops with clear success criteria.
Documentation and observability need to be machine-consumable, not just human-readable — Juan recommends repo-local docs where possible, centralized docs for bigger platforms, API access to relevant fragments, plus agent.md-style instruction files and skills to codify workflows.
If you want proof this worked, measure it — he points to DORA metrics, reliability indicators, support-ticket volume, and developer-experience frameworks like SPACE to test whether agent-ready platform changes actually improve delivery.
The Breakdown
The fintech backdrop: why Banking Circle built a platform team
Juan opens with the scale: Banking Circle processes more than €1 trillion per year and serves 700+ regulated financial institutions, with 250+ people building APIs, core banking systems, internal tools, data systems, and payment integrations. To keep all that moving, his team built Atlas, an internal platform with compute, infrastructure, messaging, and observability layers that abstracts away cloud complexity.
The painfully familiar developer story that agents expose
He tells a fictionalized-but-real story: a new developer builds an app, asks how to deploy it, gets told to copy an old pipeline, tweaks it, hits an error they don’t understand, then gets sent to someone on the infrastructure team to unblock it. After that finally works, they discover they still need a database or blob storage—and get told, kindly, “next week.” It’s frustrating for a human; for an agent, Juan says, it’s basically impossible.
Best practices didn’t change—AI just makes the cracks obvious
That’s his central point: relying on tribal knowledge, ad hoc handoffs, and half-reusable workflows was never good engineering. AI agents simply make the pain sharper because they can’t wander off, ask a teammate, or improvise around missing process the way humans do.
Self-service means no hidden dependency on a person
Juan’s first prescription is self-service: both developers and their agents should be able to get what they need without waiting for a specific human. He’s blunt here—if the workflow technically exists but requires gathering building blocks from five places and triggering something elsewhere, that’s not really self-service.
Why API-first beats clicks, forms, and vague workflows
Next comes API-first design, because agents are good at calling well-defined interfaces. Juan highlights schema validation, discoverability, authentication, and authorization as the things that let an agent safely try, get a response, adjust, and loop until it completes the task; CLIs and MCP servers are fine, but they should sit on top of solid APIs.
Local-first loops, explicit success criteria, and observability for machines
Since agents usually operate from the developer’s machine, he recommends local-first workflows and aggressive shift-left validation so failures happen immediately, not after a push and a slow CI run. He also stresses that agents need precise instructions and a way to verify success without staring at dashboards, which means logs, metrics, traces, and other observability signals should be accessible through APIs, CLIs, or MCP.
Documentation has to be structured enough for an agent to use
Juan jokes about the universal experience of writing documentation and then being unable to find it later. His advice: keep docs next to code for smaller repos, centralize them for larger platforms, and expose relevant chunks through APIs rather than forcing agents to parse entire HTML pages. He also calls out agent-specific markdown like agent.md, claude.md, or compiler_instructions.md, plus reusable “skills,” as practical ways to encode how a repository or platform should be built, tested, deployed, and verified.
Open the platform to contributions—but pair openness with guardrails
He wants internal platform teams to welcome contributions, especially now that AI lowers the barrier for engineers to help improve the systems they use. But he’s careful not to romanticize it: platform owners still carry the maintenance burden, so contributions need guardrails for security, compliance, and standards, enforced through both hard policies and agent-facing guidance.
Measure whether agent-readiness actually changed anything
Juan closes with measurement: don’t assume the platform got better just because it sounds more modern. He points to DORA metrics like lead time and change frequency, reliability metrics that matter deeply in fintech, support-request volume, and developer-experience frameworks like SPACE. His final note is tactical and a little mischievous: if your org resisted API-first design, local workflows, or good docs before, use AI hype as the excuse to finally get those best practices through.