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

Channel: aiDotEngineer

Published at: 2026-04-08

YouTube video id: cCRO3ChaYhM

Source: https://www.youtube.com/watch?v=cCRO3ChaYhM

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.