Talk by Juan Herreros Elorza (Team Lead, Banking Circle) on designing internal developer platforms for both human engineers and AI coding agents. It argues that practices long valued for human usability—self-service interfaces, well-defined APIs with schemas and documentation, local-first workflows, and rich observability—are prerequisites for agents that autonomously build, debug, and ship software. Topics include exposing the platform as a product via structured APIs (and possibly MCP), why local tooling helps agents iterate on errors, observability as a bridge between runtime behavior and AI understanding, and new responsibilities from AI-assisted contributions such as quality gates, context files like CLAUDE.md, and maintainability. # Video Identity Observations: "Platforms for Humans and Machines: Engineering for the Age of Agents — Juan Herreros Elorza" ## Speaker Self-Identification (Explicit Claims) - **Name and role stated directly**: "My name is Juan and I work as the team lead for the cloud native technology team in a company called Banking Circle." - **Employer described as**: "a global cross-border payments provider… on top of accounts and liquidity management," processing "over 1 trillion euro per year" and serving "over 700 regulated financial institutions." - **Speaker positions himself within a platform engineering context**: "some years ago we decided to establish a platform engineering team in Banking Circle, which is where I'm working." The platform is named **Atlas**. - **Closing self-promotion**: "Here you have links to my LinkedIn, my personal website, and my GitHub… please connect over there." ## Intended Audience (Observable) - **Software engineers, platform engineers, and engineering leaders**, evidenced by: - Framing around internal developer platforms: "If you're building internal developer platforms, those are going to serve the developers in your organization." - Relatable failure narrative: "I'm sure many of you will relate to this story as well." - Technical terminology used without explanation: Kubernetes, DORA metrics, SPACE framework, MCP servers, schema validation, shift-left. - **Audience likely at a conference**: closing remark — "have a great AI Engineer Europe event." ## Claimed Scope of the Talk - **Topic**: making internal platforms usable by both humans and AI coding agents. - **Delivered as practitioner advice**: "I'll just summarize my advice that once again comes from my experience." - **Core recommendations enumerated by speaker**: - "Make sure your platform is **self-service**, **API-based**, and **local-first**." - "Make sure you have good **documentation and observability**… so that it's easy to tell the agent what to do." - "**Encourage welcome contributions** to your platform." - "**Measure** that all of these indeed work." ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Narrative-driven structure**: opens with a fictionalized onboarding story — "a bit of a story using fictional names and characters but a story based on my experiences." - **List-based argumentation**: successive named points (self-service, API-based, shift-left, documentation, contributions, measurement). - **Concrete fintech domain grounding**: references to "integration with the clearing schemes where we settle the payments" and "reliability… certainly is in fintech institutions." - **Slightly informal, humorous delivery style**: asides such as "[snorts]" and "and another one that I can't really remember right now" (re: DORA metrics). - **Strategic/persuasive framing**: ends with organizational advice to "use AI as the excuse to implement some best practices." ## Channel Identity Signals (From This Single Video) - Content type appears to be **conference talk recordings** (AI Engineer Europe, per closing line). - Speaker-led, named-presenter format with contact links (LinkedIn, personal website, GitHub) presented at the end. - **Caveat**: this is a single video; whether the channel aggregates multiple conference talks or belongs to the speaker cannot be determined from this material. No curated metadata was supplied. # Delivery Observations — Juan Herreros Elorza, "Platforms for Humans and Machines" ## Tone and Overall Style - **Conversational and affable**: the talk opens warmly and uses informal phrasing throughout, e.g. *"Hello everyone. Thank you very much for watching"* and *"have a great AI Engineer Europe event."* - **Collegial, relatable framing**: he repeatedly signals shared experience with the audience — *"I'm sure many of you will relate to this story as well"* and *"I think all of us have been at some point."* ## Structural and Teaching Habits - **Narrative anecdote as teaching device**: the core problem is introduced via a fictional but experience-based story — *"using fictional names and characters but a story based on my experiences."* - **Explicit enumerated advice**: the talk is organized as numbered points ("the first thing... The second point... my next point"), each stating a principle then justifying it: - *"the first thing to me it has to be self-service"* - *"The second point that I think it's important is make it API based"* - *"First of all, shift left"* - **Signposting transitions**: he announces structure in advance — *"I will get to that in just a moment"* and *"Which brings me to my next point."* - **Closing summary of the list**: *"make sure your platform is self-service, API-based, and local-first"*, ending with *"Last but not least, measure that all of these indeed work."* ## Recurring Phrases and Verbal Tics - **"You know what"** as a recurring dialogue marker (appears multiple times in the story): *"'Well, you know what? Actually I did that...'"*, *"'You know what you should do?'"* - **"Of course"** used frequently to preface points treated as shared knowledge: *"Of course we need to document"*, *"Of course, you already have documentation"*, *"It could also be of course a CLI."* - **"Once again" / "again"** for callbacks: *"Once again, think API first"*, *"again, just a markdown document."* - **"Last but not least"** appears at least twice (documentation contributions section and the summary). - Mild filler words ("um," "uh") occur throughout, consistent with unscripted spoken delivery. ## Explanatory Techniques - **Dialogued roleplay**: he voices hypothetical characters to dramatize pain points: *"'Hey what should I do with this application? How do I deploy it?'"* - **Contrast framing (humans vs. agents)**: a repeated rhetorical pattern — *"if this situation was tricky for a developer this situation is essentially impossible for a machine."* - **Concrete tooling examples**: grounds abstract advice in specifics — *"agents.md files or cloud.md, compiler_instructions.md, depending on on your agent of choice,"* MCP servers, CLI wrappers. - **Honest self-deprecation / admission of uncertainty**: *"and another one that I can't really remember right now"* (referring to DORA metrics) — an isolated moment, not a pattern. ## Argumentative Moves - **"Best practices are still best practices"** as a thesis, repeated with variation: *"they were never good. They are just much more obvious and perhaps much more painful now."* - **Pragmatic closing pitch**: leveraging AI's popularity for organizational change — *"Take advantage... It is a very hot topic. So, you can use AI as the excuse to implement some best practices."* - **Balanced caveats**: he flags trade-offs explicitly, e.g. contributions as *"a double-edged sword because ultimately, as the person or the team owning the platform, you are responsible for its maintenance."* ## Uncertainty Notes - Audience reactions appear as transcript annotations ("[snorts]") but their nature/context cannot be verified from text alone. - Pauses and nonverbal delivery (gestures, slide changes) are not observable in the transcript; observations above are limited to linguistic evidence. # Observation Record: Platforms for Humans and Machines — Juan Herreros Elorza ## Speaker - **Juan Herreros Elorza** (transcript self-identification; title slide name), team lead of the cloud native technology team at **Banking Circle**. ## Context Claims (Speaker: Herreros Elorza) - Banking Circle is a **global cross-border payments provider** with accounts and liquidity management, processing over **1 trillion euro per year**, serving **700+ regulated financial institutions**. - **250+ people** build technical systems there; the internal platform is called **Atlas**, with sub-platforms for **compute (Kubernetes), infrastructure (blob storage, databases, secrets), messaging, and observability**. ## Central Thesis - **"Best practices are still best practices."** Pain points developers faced (copying pipelines, asking teammates, waiting on other teams) "were never good" but are now "much more obvious and perhaps much more painful" with coding agents, because a machine cannot walk to another team or ask a person. - Agent pain points become a **limiting factor in productivity** for both agent and developer. ## Illustrative Story - A fictionalized account "based on my experiences": a capable developer writes an application but hits deployment friction — copying another pipeline, unexplained failures, needing a person from infrastructure to fix things, then discovering they also need a database/storage, and being told to wait until next week. - Speaker explicitly notes the frustration and reliance on tribal knowledge and scattered documentation. ## Recommended Practices (Speaker's Positions) ### 1. Self-service - No process should require **talking to or waiting for a specific person** — for humans or agents. - Self-service must be **intuitive**: if it technically exists but requires assembling pieces from five places, "it's not really self-service." ### 2. API-based - Agents are "good at calling **well-defined APIs**" — discoverable, with schema validation, authentication/authorization. - CLI or MCP servers layered on an API are also fine; the agent can **iterate in a loop** until it succeeds. ### 3. Local-first / Shift left - Agents typically run on the local machine; things should **fail as soon as possible**, not minutes later in a remote workflow. - Give agents **precise instructions** including explicit **success criteria**. ### 4. Observability for agents - Agents won't read dashboards; expose **logs, metrics, traces via API/CLI/MCP** so the agent can **close the loop** and verify its own work. ### 5. Documentation - **Structured** documentation: co-located with code for small repos; **centralized** for platform-wide docs. - **API-first** delivery of documentation beats feeding the agent a whole HTML page. - **Agent-specific docs**: agents.md / CLAUDE.md / compiler_instructions.md; layered general + project-specific files; **skills** (markdown) to codify conventions. ### 6. Contributions - Encourage platform contributions; agents **lower the entry barrier** — he states this is what he has seen. - Acknowledged **double-edged sword**: platform owners remain responsible for maintenance; use **policies/guardrails** for what must not happen, plus markdown context for how to contribute. He recommends **a combination of the two**. ### 7. Measurement - Measure **before and after** platform changes. Candidate metrics: - **DORA metrics** (he names change frequency, MTTR, lead time, and admits he "can't really remember" the fourth — qualification preserved). - **Reliability** — "certainly" a concern in fintech. - **Platform-specific**: support request volume — he notes an unresolved tension: self-service could reduce requests, or *increase* them if the implementation is confusing. - **Developer experience** frameworks such as SPACE. ## Closing Advice - Summary recipe: platform should be **self-service, API-based, local-first, well-documented, observable, open to contributions — and measured**. - Strategic note: if your organization resisted these practices before, **"use AI as the excuse"** to implement best practices, since attention to AI now spans executives to individual contributors. # Speaker & Provenance Observation Record ## Video Metadata - **Title:** Platforms for Humans and Machines: Engineering for the Age of Agents — Juan Herreros Elorza - **Video ID:** `01a15ca9-ba9a-72b8-b7ca-4677da62aa9e` - **Format:** Single-speaker conference talk (event identified in closing as **AI Engineer Europe**) ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Juan Herreros Elorza (self-introduced as "Juan"; closing full name given, transcribed as "Juan Herrero Salorza") | **Creator / sole presenter** — Team lead, cloud native technology team, Banking Circle | "My name is Juan and I work as the team lead for the cloud native technology team in a company called Banking Circle" | - **No guests, narrators, or other identified speakers** appear in the transcript. - Fictional illustrative characters within the talk (developer, teammate, infrastructure person) are explicitly framed by the speaker as **fictional names and characters** based on his own experiences. ## Employer / Provenance Claims (speaker-attributed, unverified) - Banking Circle described as a **global cross-border payments provider** with accounts and liquidity management. - Speaker claims: processes over **1 trillion euro per year**; serves over **700 regulated financial institutions**; **250+ people** building technical systems; internal platform named **Atlas** with sub-platforms for compute (Kubernetes), infrastructure (blob storage, databases, secrets), messaging, and observability. ## Referenced Sources & Third-Party Concepts - **DORA metrics** — deployment/change frequency, mean time to recovery, lead time (speaker notes he cannot recall the fourth metric). - **SPACE framework** — cited for developer satisfaction/experience measurement. - Tools/formats mentioned: **Kubernetes, MCP servers, CLI, agents.md / agent.md / cloud.md / compiler_instructions.md, skills (markdown), Teams, OpenClaw ("open claw")** — mentioned as examples, no third-party claims made about them. ## Promotional Segments - **Opening segment:** brief description of Banking Circle's business and scale (~first two paragraphs) — company/employer promotion. - **Closing segment:** speaker shares links to his **LinkedIn, personal website, and GitHub** and invites connection — self-promotion. - No third-party product endorsements or sponsor promotions identified. ## Comment Availability - **Not indicated** — no curated metadata supplied; transcript contains no information about comment availability. ## Uncertainty Notes - Speaker's surname heard two ways: title metadata says **Herreros Elorza**; spoken closing transcribed as **"Herrero Salorza"** — discrepancy recorded, unresolved. - No timestamps available in the supplied transcript. Hello everyone. Thank you very much for watching and welcome to my talk platforms for humans and machines. My name is Juan and I work as the team lead for the cloud native technology team in a company called Banking Circle. You probably don't know about us, so let me tell you just a bit about what we do. Mainly we are a global cross-border payments provider uh on top of accounts and liquidity management. We provide we process over 1 trillion euro per year and we provide banking services to over 700 regulated financial institutions. We are very much a fintech and in fact a lot of us are working within some capacity of engineering. Because of that some years ago we decided to establish a platform engineering team in Banking Circle, which is where I'm working. More than 250 people in Banking Circle are building some type of technical systems and this includes the APIs that our clients are using. This includes the core banking systems, some internal tools. This includes data science and data engineering and of course the integration with the clearing schemes where we settle the payments. Because of that we have decided to establish a platform that all of these teams can use so that we abstract away the complexity in some of the underlying infrastructure and cloud concerns and so these people can focus on building the systems that they are supposed to build. We call that platform Atlas. And Atlas has a number of sub-platforms. We have a platform for compute where people run their applications based on Kubernetes. We have a platform for infrastructure which people can use to provision blob storage services. They can also use it to provision databases. They can use it to provision secret management systems. We have a platforms for messaging for the different applications and the different systems to communicate with each other and we have platforms for observability so that we can know what is happening with all of our applications and all of the payments that we are processing. Now we have come a long way in this platform engineering journey. But it wasn't always easy. And I would like to start my talk with a bit of a story using fictional names and characters but a story based on my experiences while working here in Banking Circle. I'm sure many of you will relate to this story as well. Let's say that we have a new developer, right? And they have joined the company, they have joined the team. They just start working and they build their first application. Um this developer is great. They are very good at coding the application perhaps for some payment system. Um but eventually they hit a wall. They have the code but they need to deploy that application somewhere. Then the developer will naturally ask someone in the team, "Hey what should I do with this application? How do I deploy it?" And then the person in the team might say to the developer, "Well, you know what? Actually I did that, but it's already set in this pipeline. Why don't you copy it from there?" The developer might go, copy the pipeline, then maybe they have to adjust something. It wasn't exactly the same in this case because the application had some specific requirements. Then they will try to yes run this pipeline. Maybe the pipeline will fail and ultimately the developer doesn't know why it's failing because the error has nothing to do with the application that they coded. Maybe they then go back to their teammate and they are like, "Hey, what can I do with this?" And the teammate might say, "You know what you should do? You should talk to this person that is working in the infrastructure team. They will help you." Now this developer will go. Maybe they will talk with this person. Eventually they will say, "Oh yeah, of course this is an error that happens very often. I can solve it just for you." The error will be solved. Then the developer will deploy the application and then maybe that deployment will succeed only to realize at the end of it that actually on top of that application the developer also needed a database or maybe some blob storage. \>\> \[snorts\] \>\> Back to square one, the developer will go to maybe this person in the infrastructure team to ask "Hey, should I use you to create this database or this blob storage for me?" And maybe the person, let's assume best intentions of course, maybe they want to help but they will say, "You know what? I actually have a lot of other things that I'm working on. I will help you, but that's going to be next week." Um so obviously the developer will get frustrated because they kind of had done their part but then they struggled a lot in this process to then deploy the application and to get it running with all of the dependencies that it needs. Um perhaps they were following some pieces of documentation, something that someone wrote along the way, but then they were also relying on asking this teammate and asking the person in the other team. Now this is a bad situation that again I think all of us have been at some point. It's a bad situation for a person. But today all of us are using LLMs, we're using AI agents to help us in our daily job. And if this situation was tricky for a developer this situation is essentially impossible for a machine. Cuz the machine is not going to you know, go and try the pipeline and then go up to the second floor and talk to the person in that other team. Now of course an agent could use Teams or maybe even use something from some voice model and call over the phone, but generally a coding agent is not going to be able to do all of these things. So these pain points that the developers were facing suddenly become much more obvious when an agent is facing them. And they are limiting factor in how productive this coding agent can be or how productive the developer can be when using the coding agent. And what I'm about to tell you um I'm going to address some of the points in this story but the gist of it is that best practices are still best practices. We have known for a while that some of these things like relying on a teammate to tell us how to deploy an application or having to reach out to a person in a different team or having to wait for a pipeline only to realize that it wasn't exactly what we needed they were never good. They are just much more obvious and perhaps much more painful now that we have these coding agents working next to us. So what can we do about it? Well, the first thing to me it has to be self-service. If I need any resources from this platform, if I need to be able to do anything through this platforms, I should be able to do it in my own. Similarly, if my agent needs to be able to do anything on the platform, it should be able to do it on its own. There should be no process that requires talking to a specific person or waiting for a specific person to do something. The agent should be able to trigger everything it needs and for that of course it's also important that this self-service flow or this self-service process is intuitive. Of course we need to document how these things work and I will get to that in just a moment. But the easier that we make it, the more self-service it actually is. Because if if it is technically self-service but it requires fetching some building blocks from five different places and putting them together and then triggering a flow somewhere else then it's not really self-service. So make it automatic, remove \[snorts\] people from the process and make it easy to the greatest extent possible. The second point that I think it's important is make it API based. Self-service could look in many different ways and it could also be something based on sending some text somewhere. It could be based on clicking a button. It could be based on many things, but agents are good at calling well-defined APIs. It could also be of course a CLI on top of the API. It could be something like an MCP server around the API that the agent uses. All of those are also good ideas, but generally under all of that you should have a well-defined API. This is discoverable. So as it interacts with it, the agent is going to discover what it can do and the options that are there. It has schema validation. So naturally the agent will only send things that are going to work. Um it also has authenticate or it can have, depending on what you're building, authentication and authorization in place. So because of that your agent will be allowed to use your credentials as a developer or maybe if the agent is in a particular flow it will have its own. But it will be able to do all of these things in a secure way and it will know what it's doing. And with this the agent can go back and forth. It can try to do something. The API will get it a response and the agent can start working in this way where it goes in a loop until it gets what it needs or what it was asked to do. Which brings me to my next point. An agent is typically running in your machine. You could also have it on uh some server somewhere and you might have open claw or something and you're communicating with an agent there. But typically an agent is local to the machine. Of course, the models are running somewhere else. But the work the agent is doing is local. So, make it easy for the agent to do that. First of all, shift left. If something is going to fail, it should fail as soon as possible. So, don't make the agent push something to your version control system only to then fail on some workflow after a few minutes. If you can validate things up front, if you can run them just locally, again, by calling those APIs or maybe using some some type of wrapper about around them, do that. Shift left as much as possible. Then, like I said, the agents are going to go on a loop. So, if the agent is in your machine and it can do everything it needs there, and you clearly define this is what I need, the agent is going to iterate until it gets there. Now, it is important that you give it precise instructions, that you describe the task, that you tell the agent, this is what I need you to do. And it is also important that you tell the agent, this is how you know you have succeeded at the task. This is a bit important when when working with agents because as humans, we could verify this in different ways. And we have a lot of observability systems where perhaps we would like to check if the application has been uh deployed and the metrics are looking fine. Maybe we will be looking at some dashboards. The agents are not going to be looking at those graphical interfaces. So, you also need to think how does observability look like if the prime user is going to be an AI agent. Make those logs, metrics, traces, everything that can help available via an API or via CLI or an MCP server or something like that. By doing that, you're letting the agent close the loop. You're telling it how to do things and how to verify that the things have been done correctly. And since I'm speaking about telling the agent how to do things, something that is crucially important is documentation. Of course, you already have documentation. I think many of us have written documentation, uh have put it somewhere and then were unable to find it. Um when we need to expose this documentation to agents, but then again, this was already true for humans, we need to be structured around it. So, there are different strategies that you might want to take. One of them could be, especially if you're working in a smaller repositories, keep your documentation next to the code it's documenting. That way, if an agent is working in that particular folder or repository, it has everything it needs. It has the code it needs to work on and the documentation that describes it. If you're working on something bigger or perhaps as a platform team, if you need to expose all of the documentation about the platform that an agent might need, the better idea is to put it in a centralized place so that the agent can go there and start discovering which documentation is available. Now, once again, think API first. Because the agent is going to be much better at consuming the website doing that and specifically if you can give it the specific bits of documentation that it needs over API, even better, rather than getting the entire HTML HTML page in memory and trying to figure out what is the relevant uh bits there. Of course, when we talk documentation, we can also think about um agent-specific documentation. I assume that many of you are already familiar with this, but you can use the agent.md files or cloud.md, compiler\_instructions.md, depending on on your agent of choice. And by doing that, you can also describe the agent how it should work in a particular repository. \>\> \[snorts\] \>\> You can tell it, well, you should always build in this way, test in this way, deploy in this way. You can verify in this way. You can include all of that in your agents.md. You can also have one of these more generally applying to different systems and then add a a one uh an agents.md more specific to um a particular project or repository on top of that. You can also use skills. If you have some conventions that you're following or some uh well-defined way of uh interacting with some of your platforms, you can codify those in a skill, which is again just a markdown document. And by doing that, you're telling the agent, when you do this type of task, you should do it like that. Last but not least, you should also encourage contributions in your platforms. If you're building internal developer platforms, those are going to serve the developers in your organization. And you want them contributing because that way they can also help you. They can help you help them. Um so, you should encourage them. You should welcome contributions and because they are using AI agents, the entry barrier is going to be lower. And so, I would expect, and that's what I have seen, that people are more welcome to contribute to the platforms. Now, of course, this is a level a double-edged sword because ultimately, as the person or the team owning the platform, you are responsible for its maintenance. So, you should think a lot about which things should be taken into consideration when contributing to the platform. You need to have some guardrails thinking about security or compliance or just following a well-defined set of standards that then helps you maintain the platform um by virtue of always following those conventions. You can do this um with some policies perhaps in your systems, but you can also, yes, rely on giving context to the agent. Once again, you could uh use agents.md. You could use some skills so that when people want to contribute on your platform, they can also point their agents to these markdown files and refer to those as as documentation on how to contribute. Generally, I would encourage a combination of the two. Have guardrails in place for everything that you absolutely don't want to happen. Use some sort of policies for that. But then on top of that, use uh these markdown files to help the agents work in the way that you want them to. And then, we get to a very important question, uh which is, okay, we have done all of these things, right? People are using AI um in the organization. They are following now these practices that we have been recommending. We have built a platform that can be used by AI. But did it work? And I think the way of knowing if it works is by measuring whether it worked or not. You can, of course, measure these things before and after um making some changes in your platform so that you can see whether they had an effect or not. And depending on what you want to do, you might want to focus on some type of metrics or on others. Now, we know that there is metrics about application delivery and we have the whole uh Dora um metrics on that. Uh change frequency, uh mean time till recovery, um lead time, and uh and another one that I can't really remember right now. But those metrics are measuring how often your developers are able to release and how good those releases typically go. You can also measure reliability. Perhaps that's um the main concern. It certainly is in in fintech institutions. So, you can check, okay, are my applications more reliable than they were before? Am I having less errors than I was having before? Is um traffic performing in any different way? Um or you might want to look at more platform-specific metrics, such as how many support requests have I got? If people and their agents can do everything on their own because it's self-service, am I then not needed to support them? Or am I now having more support requests because the way in which I implemented this is confusing? Um you can also use some other frameworks about developer satisfaction and developer experience, such as the space one. But my general point is, think about what you want to achieve with this making it easier for AI agents to contribute, and then measure whether you actually succeeded at that or not. And with that, I'll just summarize my advice that once again comes from my experience. There could be more points in this list, but I think this is a good point where to get it started. If you want to make your platform ready for AI agents so that you can get the most out of them, make sure your platform is self-service, API-based, and local-first. Make sure you have good documentation and observability in that platform so that it's easy to tell the agent what to do, how to do it, and how to verify its own. And encourage welcome contributions to your platform cuz that way you can also move faster and implement the features that your users need. Last but not least, measure that all of these indeed work. And maybe one extra piece of advice, maybe your organization has been resisting some of these best practices. Maybe you have been trying to push for these API first platforms or to make them more local friendly or to have the time to write proper documentation. But then you have gotten some resistance to that because people have were focused on other priorities. Take advantage. Everyone from the executive level to the individual contributors are looking at AI now. It is a very hot topic. So, you can use AI as the excuse to implement some best practices that again were always best practices if you didn't have the chance to do it until now. Thank you very much for listening. My name is Juan Herrero Salorza. Here you have links to my LinkedIn, my personal website, and my GitHub. And if you've liked it, please connect over there. Thank you and have a great AI Engineer Europe event.