Sign in or Join the community to continue
The Infrastructure Factory - Agents write the code. Who builds the place it runs?
Posted Nov 11, 2026 | Views 3
# Agentic AI
# Platform Engineering
# AI Agents
# Infrastructure As Code
# DevOps
# Software Factory
# AAIF Munich
Share
Speaker
Max Körbächer
CEO | Chief Technology Advisor | Founder @ Liquid Reply
Max is Founder and Chief Technology Advisor at Liquid Reply. He is a CNCF and Agentic AI Foundation Ambassador, Governing Board Member, and Linux Foundation Europe Advisory Board member. Max focuses on platform engineering to simplify the current challenges of complex sovereign systems in the AI and cloud native space. He is the author of the book Platform Engineering for Architects. Besides, Max organizes Cloud Native Summit in Munich, KCD Ukraine, and the Kubernetes, Cloud Native & Platform Engineering Meetup in Munich.
+ Read More
SUMMARY
Agents write the code. Who builds the place it runs?
Everyone is building software factories: agents triage, implement, verify, and ship. Google reports 75% of new code is AI-generated, and Uber attributes over 70% of pull requests to agents. But every one of those changes still needs somewhere to run, and in most companies that somewhere still arrives through a ticket.
Code got cheap. Environments did not.
Max Körbächer introduces the Infrastructure Factory: a platform that turns intents from humans or agents into compliant, owned, observable, cost-attributed environments, with no ticket in the path. He looks at why the most-cited software factory talks of 2026 call infrastructure the hardest part but none treat it as a factory of its own, how it relates to the AI factory and where the two share a floor, and what the factory looks like when its front door is an MCP server, and its policy gate is agentgateway. The target: zero tickets.
+ Read More
CONTENT & TRANSCRIPT
The Infrastructure Factory - Agents write the code. Who builds the place it runs? - YouTube
https://www.youtube.com/watch?v=OOwDloJ1_tQ
Transcript:
(00:06) Yeah, as as said already, I'm uh actually an agentic AI foundation ambassador. Um I'm also a cloudnative computing foundation ambassador. So the one thing falls into the other. It's a short pest to get from A to B. Um but we do and my company does a lot of open source. So that's why I have this nice t-shirt says open source, open bow.
(00:31) It's one of our projects that my team is contributing to to develop a free and open way to handle secrets for example and we do this for open telemetry and we have also an own AI project that we also handle. Um beside that um I'm also part of the CNCF governing board and the Linux Foundation Europe Advisory Board. So uh yeah if I like open source I do a lot of open source. So that's how somehow everything comes together.
(00:53) Um, initially this thingy had another uh description and title but I would like to introduce you to you something that we call the infrastructure factory as sort of a new kind of a concept that we currently uh push out to the world. Uh on Monday the um IIF put on their blog post one of my articles about it for example. So there you can find out more.
(01:16) Um but maybe you can learn something today. So who of you have heard that entropic had to reinvent git, right? Um and that's for a very very simple reason. If you have 30,000 mergers per day, it's horrible. Uh I'm currently also have a couple of open source projects.
(01:43) We sometimes don't get managed to to merge five things because everything every time something get merged, it blocks the next merge and you have to rerun all the tests and so on so forth. So I have no idea how they do that because mathematically there's not so much time left to all the time ensure everything runs. Um but that brings us to a very specific problem that there's a huge need and demand on continuously testing and running and uh put the software the the scripts the whatever you have um in isolated environments to shortly test them and then wipes away or as you can see it with entropic you have every I don't know three times per day an update on your app uh locally or on your CLI which is also sometimes crazy.
(02:22) And then we have this very um beautiful quote. I don't know from which report it was, but they they stated code got cheap. And that's true because whatever you need, you just throw it into your agent, wait 5 minutes, and then you have your website, your app, uh SARS, whatever.
(02:46) So, it it really gets interesting, but also problematic, right? Um, Google says 75% of their code is written by AI. The funny thing is if you search for what they said last year, the percentage was higher. So I think they cut down a little bit on some parts and I found out ah not every AI written code is the best written code. Maybe we should leave it up to to some humans.
(03:12) Um and yeah, Uber reports that's over 70% is also like uh done meanwhile just by um cloud agents and uh contributing to the code and all of these changes need somewhere a good place to run. But somehow is not a good answer to this one.
(03:34) So we live in the era of somehow because the agent is good enough that you throw whatever you have at the agent and tell it do your thing and somehow it will does its thing right it will fix all the problems you have no idea how it runs is it a container is it a running Python script did it deploy somewhere but actually sometimes it doesn't matter except um you're an infrastructure uh an enterprise that needs to take care a little bit about the infrastructure because then somehow how is not a good answer to like where the heck is my software running right and um what we can see in this context is also that um through agendic we have
(04:08) more stuff going in but less coming out so the faros AI report show that they have an increase of 440 something% um of uh yeah um u uh u code needs to wait when it um ends up on um their git versioning for example until it's reviewed and um the task throughput just increased by one/ird for the developers and then circles AI put on the other side some interesting numbers that the daily workflow increase has was by 60%.
(04:44) But what is so much interesting is that um the main branch throughput um was decreased by 7%. So way more stuff goes in, right? A lot of stuff is running. Um, a lot of changes coming in, but what comes out is not that good or not good enough. And at the same time, the main branch success rate uh is the lowest since 5 years.
(05:11) So whatever ends up in main somehow works but the one or other engineer would just like throw himself into graveyard because what the heck you have done right so it's an interesting interesting time and um again that's why code gets very cheap but the environments the whole stuff has to run on doesn't get cheap was last week in uh on the Nvidia GTC event uh where they showed like oh this fancy new servers and this one is new and that one and it's like yeah but that workstation cost $25,000 to run your model locally your server
(05:50) costs you a million I mean you can buy an uh how they call it a container so you can get a container with seven racks in it each rack has 72 GPUs that's nice but it costs insane amount of money and you don't have the substation Yeah. Uh and energy is another problem. Um the US is calculating something between 20 uh 10 and 20 gawatt of new GPU data centers in US next year which if you're have a little bit idea of energy that's I don't know how I maybe they found a way to develop nuclear power plants in 5 months. Usually they take 5 to 10 years to build but who knows. Um but I have
(06:40) crazy heard crazy story that they meanwhile buy old airplanes get the engines out rebuild them to burn any kind of fuel and get out of that one energy. I don't know sounds weird. No. Yeah. Good that we have solar panels in Europe. Um so when we take a look on all this one right we talk then very fast about um software factory for example an agent that's continuously producing stuff and stuff is really like it can be anything sometimes it's just crap you you throw away um so the time that an agent need from
(07:19) an idea to the first pull request is most of the time less than 35 minutes it's an average from one of the other reports that uh we can see in warp was also reporting about it. Um, and then it usually has one problem.
(07:37) It comes with a request because it doesn't know something about ownership or who should pay for that whole thingy and what what it should cost or which data they need or is it classified and networks and so on and so forth. Those are things that agents at the moment really blank because no organization or large enterprises usually have something beautiful like a change advisory board that is once in a month sitting together and deciding all the relevant decisions like data classification and approves things right and that leads to that we have actually a very hard gate. So the the person or the people who get all the
(08:11) requests from the agents and need to put it somewhere to an infrastructure have always to take care about like okay that is some kind of irrelevant whatever we can throw it somewhere where literally no one cares about or does it do something halfway relevant then we have to take care about but then we need days or weeks or sometimes months until we can provide you the right infrastructure for it. Yeah.
(08:38) And that's a little bit problematic. Again, code is cheap and everything is fast. So, people get very very much unsatisfied. You don't want to wait weeks or days or months or whatever until you get to the point that your application is deployed somewhere. Um, and so when we again take a look through the infrastructure factory, uh, the software factory, we go from the intent and whatever the agent does to the point like, oh, I need something. And yes, it takes some time. And usually what you can express with this work time in
(09:10) progress is um imagine it as a very very bad traffic light. And you have continuously going requests in but the traffic light let every 5 minutes just one person go through. Right? That's a problem that we that we have just because we cannot fill out a ticket. But the information in those tickets are quite relevant. Cost center.
(09:36) Yeah, no one likes to deal with costs, but still someone's credit card needs to burn for all the stuff you develop. So you need that a little bit. Um compliance, especially when you're in Europe, you cannot put anywhere anything if there's not somewhere in the end written a name of a person who's responsible for it. Right? that it was agent 0235 that have died 6 months ago somewhere.
(10:04) No one cares. It must be person. Um well good old things data classification blah blah blah lifetime is very interesting. There's many discussions about like um agent develop code should not live longer than a week. It's a quite interesting concept just because again code is so cheap that an application is continuously overhauled by the next development and so you should get rid of it quite fast to put it out again with a new version might lead to some inconsistencies or maybe not but um that's that's a yeah bold move I would say
(10:42) so I took some time and had a look on I think over 60 different talks and presentations ations about software factories and try to find out what do they say about the infrastructure and uh 50 of them never mentioned anything about infrastructure which is slightly problematic again because you you're populating then something that should be helpful but on the other hand side it doesn't give you the full answer.
(11:14) It just gives you an introduction to how you can get started but not how you can come to something that is production relevant. There's a few talks I listed here that in some way pointed out to the infrastructure ah attention please it is important. So let's talk again about something else right because it's a complicated part and the uncomfortable part and sometimes not the really uh interesting part.
(11:40) When I go to customers, I say like no one buys infrastructure because it's costly and you you really don't get what are you doing with it, but you run your business cases on top of it. But it's very hard to imagine how some bites and whatever do their job on this machine, right? Um so that's the top part and then we have something like this. Oh my god, on this wall it doesn't look so nice.
(12:09) Um there's very nice Nvidia movies about AI factories and I spent some time to understand like what do you mean with AI factories? In my world I'm thinking about like producing continuously AI stuff. But actually what they mean is like hey come to me and buy for one gigawatt a data center.
(12:32) I bring you all the hardware the physics the the bedon whatever you need some software some operating systems I bring you all with that. So that's the AI factory that large providers are talking to and we have seen that on the Nvidia GTC 30% of the um uh uh uh exhibition partner all were just talking about like oh do you want your rack in blue or do you want to have your wreck in gold or do you want to have it in silver it's so it's always all the time the same but they sell you very very big fancy machines that's the AI infrastructure which doesn't answer in the end also the question. How the heck do I manage all of that? Right?
(13:08) So, I now know where it can end up. And by the way, those machines are not for running your average application. You don't want to run that on your average application because it's way too expensive for that one, right? So, it's also just like one part of the solution that you need in the end, which is also quite interesting and no one talks about it.
(13:30) So um we came up with a concept of infrastructure factories and I have to to make here a disclaimer um my team myself are platform engineers. So of course our whole world can be solved by platform engineering best practices but we are not so far away from what we could do with an infrastructure factory and it actually sounds a little bit better than yeah build your kubernetes and some other scripts right so that's not again someone wants to buy so what we have to learn especially in infrastructure is that we have now intents coming in so an intent this can be from a human but it's usually will be
(14:07) from from an agent And we have one customer, we are not allowed to talk about it, but they have something like that. Um, they have some intent requests like this. I was sitting with them in a meeting. I was looking I was like, I can't do anything with that. I I cannot tell you what you should get.
(14:30) Do do you need 20 CPUs, 100 gig RAM? What what is your wish? Like okay, I need a postgress, but which one? One file CPU shared. whatever. So intent is quite interesting but um when the platform needs to decide how to react on this one, it needs to understand also what the software is doing or the requesttor gets better in defining its intents.
(14:56) Right? So therefore what we have to do is practically to mirror the approach of a software factory and put it into an infrastructure factory. When agents are done with writing their code and want to deploy it, then it ends up in the infrastructure factory. We have to take a care about the request. Then we need to find out okay this what you are asking.
(15:19) Does it make sense? Maybe we have to analyze it. Maybe we need to throw your application for 5 minutes on something to find out how much load it really produce because usually here no one can answer you this one, right? And then you have to vent the infrastructure attach whatever is needed databases for example or data sets um sources whatever and hand it over and at some point you can reclaim it and that's actually a quite simplified approach and most of it happens already in well-designed platforms. So uh the very very large infrastructure environments from the most enterprises
(16:01) more or less completely are automated but you still have every monthes someone sitting together and decide about where does which application go blah blah blah right so they already halfway there to answer those questions but they do not have yet the decision framework to really do that so that's a problem where most of the time all of this stucks and uh companies are extremely scared about putting agents into infrastructure on the software layer whatever happens just lock it down shut it down no one cares right if you have a sorry to say
(16:44) on the infrastructure that's usually a very very big problem because sometimes you just recognize it really weeks or months later And if something of your infrastructure is hanging within in the internet, you really do not want to have it. That's where a lot of stuff is like um crawling up to. Um so we came up with the with the uh good old 12 factor apps just in the 12 factory style.
(17:17) Um and I've marked them where I think it's most relevant in in wlet. Um I don't need to go through every thing but a few things might be interesting to shortly talk about. For example, I get questions why intent in and environment out is two different things. But I've explained you already that an intent can be extremely different and in a perfect world you have already a contract like engagement between agents on the intent and it's very much well defined.
(17:47) So that's a principle by itself and then an environment out can be again a lot of different things. Is it a container? Is it a serverless? Do you need a VM? Do you need access to bare metal? Right? So there's a huge different also the saying intent in environment out is like you can compress in one sentence.
(18:07) Um yeah I think the most stuff of it is not really uh crazy. The factory measures itself is something of like um you need to take care about your your lead times, your availability times, um which contracts do you offer to other agents and can you or are you able to hold those services as you have promised it because in worst case somewhere an agent will leave a note don't use this infrastructure agent. He doesn't keep his promise.
(18:46) he he shut us off and then the agent will maybe find another way to maybe um put your infrastructure or your application somewhere else in other infrastructure. Um so therefore what we currently see and where with the most platforms that we have we are somewhere between self-service portals and contracted API which is quite nice.
(19:11) So we just need a little bit of sprinkle love and magic of Agentic and a little bit more trust of people into Agentic. But most importantly a very good decision framework that allows to decide at which point in time which application goes to which infrastructure. Um people are not yet again bold enough to give this trust to an agent because it would mean in the end that somewhere in the wild an agent writes like yes Max has approved that this super duper critical HR application is allowed to be on a public reachable Kubernetes cluster.
(19:47) I don't want to have that. No one else want to have that. Right? So we need a couple of security layers around that to prevent it. The good thing is again platforms usually come with already the one two three technical guardrails to prevent that but we need a few more layers to really ensure that this agents uh it doesn't found a workaround for it.
(20:11) So where does all this thing sits? Um when we um again have the whole software factory thingy and we have our um yeah execution in the end where the uh software agents are asking to host software. Um, at some point we hit the so-called floor, right? So when we stay in this terminology, you have a factory.
(20:36) Floor means just the ground where you you build things on. And on this one, you create a line, an automation line. The cool thing is again, most of this exists already. It's not the the biggest magic to to reinvent this, but it's not ready for have the reaction on agents or being flexible enough to react on the demands of agents.
(21:05) And so um if you throw this three things into the into the same picture um then on the shared crown we have a few questions and things that are open to how do we really manage this for example GPU capacity and and quotas is that now a problem of the AI factory is a problem of the software factory that it needs to I don't know ask for it get it as a service or is it a question of the infrastructure factor factory right and we have a few other topics that that fall into this case where we can discuss actually who is responsible for it. I believe in an ideal world you have all three setups
(21:50) that are in some way play together and that you have clearly identified okay um yes the AI factory is is responsible for telling me which GPUs are available but for example scheduling efforts happen in the infrastructure right yeah so for me it means that we slowly need to talk about platform engineing platform from engineering 2.0.
(22:17) Maybe we have to skip 2.0 and already on 3.0. I don't know. Um maybe we're a little bit too fast. So what does a factory makes a factory? Um just for you again as a takeaway is always intense in um that there's no ticket in the pass of the entire uh approach of giving you infrastructure for example. um important but boring um policy before provisioning and yes everyone hates policies but they're very very much needed. Um ownership and expiry by default.
(22:57) So nothing should exist again with the name of an agent because no one cares about the name of the agent. It's there's a this old cloudnative uh world where we talked about pet versus kettle. So if kibonita clusters are just for throw away or should we maintain them as our pets and keep them alive? We have the same thing with agents, right? Is this a pet or is it a cattle? So something that you nurture and develop or just slaughter it away when it's done with this job for the sake of our future and maybe on the side pet if some AI research in future but um we will see. And then yeah
(23:36) the factory measures itself lead time zero touch rate um are quite important to find out and we can come there actually quite quite fast because most of these um points that we have seen um are given already through the one other open source tools that are out there.
(24:02) So if you talk about policies, yes again super boring, but there's tons and thousands of policy example and blueprints how to take care that your infrastructure do not have a um if you talk about vending lines, there's so many ways to control and manage and approach your infrastructure um that there's literally for for any kind of need and demand a solution how to do it. So there's no excuse not to take care about it.
(24:27) Um and I think the the biggest challenge where there's the least answers on it yet um is all about like identity um access management for example. Um where we shortly talked about like intentbased access management. Yeah. But what if the agent decides to tell me one intent but do the other? Is it instructed to lie or can it not lie or can it change its decision while it is doing something then it's not a lie it's just changes direction right so um intentbased access management sounds good I'm not sure
(25:08) so um where we start right now with most of our clients who wants to go to the next step not just have an infrastructure where we just build a random platform Um we are very fast talking about like agent sandboxes like in the kubernetes world there's a project called agent sandbox that works with geiser or cutter containers for example um that are fast introduced that's less of a problem it's more of a problem to make it work really with an agent framework that's not sometimes very nicely compatible
(25:40) um yeah the previews per pull request so that's also something that we um start doing with one of our open source project. Um, we practically do a pre-check of a pull request if it is good enough in quality and if not we move it back to draft and we do not have a crazy rule set. It's just about a couple of coding uh requirements, style guides, um a little bit like uh keep the API format in XYX shape, blah blah blah. Just simple things, but it's quite helpful that we do not spend too much time of useless
(26:20) reviewing because it is also what I have personally already found out. Oh, I will fast code something with an agent. It's not that problematic. Yeah. 75 comments later in your uh pull request, you're like, "Hey, bet I should write it by myself." Even though I'm a very horrible coder, but maybe it would have worked better.
(26:39) And yeah, the the production vending, I think this is the uh most interesting one for for the most um enterprises in this case because usually they have already all of the things that are needed for the vending line itself. So the automation, the blueprints uh for different application sizes, for different environment targets and so on, they are usually already there.
(27:04) Um what they sometimes need is like this red line that is really telling the the story from the beginning to the end and give a little bit more trust to the infrastructure that it's safe enough to just uh provide some environments um to the agents itself. So yeah um for us the biggest mission for this year and next year is zero tickets.
(27:28) Um I hope never ever need to log into service now and um just let the agents do their magic and not burn anyone's customers infrastructure. So yes code got cheap. Um my mission is to make the environments also boring and to make it accessible and useful and so on. Thank you very much.
+ Read More
Watch More
The Future of Compute: How AI Agents Are Reshaping Infrastructure // Diego Oppenheimer - Keynote // Agents in Production 2025
Posted Jul 23, 2025 | Views 363
# Agents in Production
# Hyperparam
# AI Agents
# AI infrastructure
The Infrastructure Imperative: What It Takes to Run Multi-Agent Systems // Dipanwita Mallick // Agents in Production 2025
Posted Aug 01, 2025 | Views 162
# Agents in Production
# Multi-Agent System
# HP
Let the agents handle it: Automating the energy lifecycle with LLMs // Adam Sroka // Agents in Production 2025
Posted Aug 06, 2025 | Views 140
# Agents in Production
# LLM
# Energy Lifecycle
# Hypercube consulting