Platforms for Humans and Machines: Engineering for the Age of Agents — Juan Herreros Elorza

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.