Abby Bangser (00:00):
You're not only having agents touch your software. You might only have agents writing your software, right? Totally. I know of companies that are operating that way, so I know that's possible and actionable, but you're still having humans validate it, you're still having humans support it, you're still having humans interact with it. So it's not that the agent is the only user of that platform. It is just maybe the primary coder or engineer within that platform.

Ganesh Datta (00:29):
You're listening to Braintrust by Cortex, where we explore how engineering leaders blend AI, platforms, and culture to build high performing software teams. I'm your host, Ganesh Datta, CTO and co-founder of Cortex, an engineering operations platform designed to help organizations continuously improve their operational maturity and reduce developer friction. In each episode, we go deep with CTOs, VPs of engineering, and technical leaders who've been in the trenches, navigating the tension between speed and quality, building reliability at scale, and figuring out how to lead through major platform shifts. Whether you're running a team of 10 or a thousand, this is your space to learn from people who've made the hard calls and live to talk about it. Today, I have with me Abby from Syntasso. Abby, it's great to have you on.

Abby Bangser (01:23):
Yeah, thank you so much for having me. I had a great time working with Cortex at many different organizations. It's really nice to work together.

Ganesh Datta (01:31):
Awesome. Thanks for joining me. If you wouldn't mind doing a quick introduction for the listeners.

Abby Bangser (01:36):
Of course. So I'm Abby. I'm based in London. I work in the platform engineering space. More specifically, I work on a open source project called Kratix, and then the enterprise version of that called Syntasso Kratix Enterprise that helps organizations organize all of the great tools they have already internally into platform APIs that can be used. Outside of that work, I'm involved with the CNCF. I'm a former lead of the working group around platforms and currently working on a white paper within that group, as well as a co-chair of KubeCon for the last few KubeCons in Europe and North America. And I'm an advocate for Team Topologies and an ambassador for the CNCF. So I keep myself busy making sure to stay involved in the sort of sociotechnical side of platform engineering. I've been involved in that my whole career basically.

Ganesh Datta (02:27):
That's awesome. I was going to say, I was getting exhausted just hearing the number of things you have your fingers in, but that's really, really cool. We are very lucky to have you on. I think you have a unique perspective having been part of that so many communities over the last couple of years and seeing the evolution of platform and how things are shifting. And that's kind of where I want to start our conversation. One of the things that I've been hearing in the wild that gives me a little bit of unease as an engineering leader is, oh, we don't need golden paths and investments in platform anymore because coding agents can just write all that code for us. Why not just give AI access to our AWS credentials and good luck, go to whatever you need. What are you seeing in the industry right now?

(03:13):
And what do you say to folks who are having some of those intrusive thoughts today?

Abby Bangser (03:20):
Yeah, I think A, I get it. There's a lot of excitement around what can be done with being able to empower agents to be successful and be empowered. But I would say you wouldn't have said that about your engineers five years ago, a year ago right now where you wouldn't say, oh, just give everyone AWS ownership permissions and go to town. You'd be putting guardrails and something around them. And those guardrails are where they start to sneak up on you about how much you need to do there. It's more than just saying, oh, I'm going to provide them a key that only has certain permissions for certain parts of the AWS ecosystem or the cloud ecosystem. It's also about how you make sure that things are labeled correctly so that you can have costing associated with it or how things are scanned and reported on for compliance requirements and things like that.

(04:13):
And as you think about wanting to add those things in for consumers of the resources, whether it be human or agentic, you start building a platform. That is exactly what a platform is. And so I think that the aspirations are really great and that AI should be able to do what it does best, which is reason about an ecosystem and work within it. But also the requirements to make that possible are a set of APIs that it can reason about that have encoded in them the requirements of your business. The financial requirements, the security requirements, the performance requirements, the just consistency requirements. And so if you can create those APIs internally, then letting AI loose to say, go figure out what infrastructure you need and go get it becomes extremely safe and extremely high leverage because they're working within the guardrails and the constraints that you've put into place via very fast self-service on-demand APIs.

(05:19):
So that's platform engineering.

Ganesh Datta (05:21):
There's two things you mentioned I thought were interesting. First, the idea that we wouldn't have done this for humans. And what's funny is, in fact, we did do this with humans and we realized it was a big problem. We were like, oh, we should do micro accounts and just give your own access to AWS console with some budget cap and go forth, do whatever you want. And then we realized, oh my God, this is not great. It is the wild west out here and we should reign that back and give people clear ways of doing things that encode all these requirements in them. And so we learned that lesson the hard way, and it feels like maybe we're going to have to relearn that lesson. And you also mentioned this idea of business context and business requirements and coding that into the platform. I feel like for this conversation, it's worthwhile to rehash what that means.

(06:09):
What business requirements are involved in the world of provisioning infrastructure? Those two things sound to maybe the untrained ear, two very distinct things, but there's clearly a reason there.

Abby Bangser (06:22):
Yeah, I think you really actually brought those two points come together so well because what happens when someone is given a micro account and said, "Go have fun," is that they have to build themselves a platform. They have to build themselves all the layers from that blank account in the cloud up to what they actually want to do that's going to bring value in their business to create new applications that are for end users who are consumers of and provide revenue to the business they work for. And that platform is, there's a lot of decisions you're making at all times. You're making decisions about what size of things you're doing, how you're labeling things, how you're tracking things, how you're keeping things up to date. You're making decisions about what region you're running in. You're making decisions about your level of disaster recovery and resilience and reliability and all these things.

(07:14):
So all those decisions are first of all, fatiguing. And second of all, extremely important and demand a deep level of knowledge. So when we talk about what is it that a platform needs to encode around business requirements, it is everything from we have a brand that is a certain way through to we have a government auditing us that we will have percentages of our revenue stream in fines if we don't keep up with the requirements and everything in between. And so when you create APIs internal to your organization or services internal to your organization that encode that, you are building your own sort of cloud-like experience, but for your business. So what I speak a lot about is that platforms should be what is unique to your business, but common to your teams. So breaking that down, the public cloud gives you what is common to the industry.

(08:14):
And you should leverage anything available to you on the industry, whether it be software as a service, whether it be a cloud provider, whether it be anything else that you can, an open source project, et cetera. You shouldn't build non-differentiating software, but there are things about your use of it that are unique to you. So your compliance requirements, your labeling requirements, your performance requirements. But even within those requirements, some of those are unique to only a single team at your organization or maybe a small percentage of your organization. And other of those requirements are true across the board. Prioritize the things that are common to many of your teams because that's how you build your own sort of economy of scale on that platform where the investment in the platform is multiplied across many, many teams that they can then build the unique bits on top of if they need to, just like you did on top of the publicly available APIs and providers.

Ganesh Datta (09:07):
I love that framing. One of the things that people who are all in on AI might hear from that is, well, that sounds like context and I can maybe put that in a skill and like, oh, here's all of our business requirements and our needs, and then give AI access to AWS credentials and everything will be fine. Does that work? Why or why not?

Abby Bangser (09:26):
So it can. So a skill is essentially now you're starting to create your platform and you're choosing the architecture of that platform to be skills. So what you're saying is that I would like to build my logic and my constraints into the way in which my consumers are working. The choice I'm going to make is I'm going to write a lot of markdown that describes it in a pretty please, will you listen to me kind of way. And I'm saying that almost intentionally derogatorily, but accurately.That is what skills are doing. Skills are markdown files that describe workflows and ways of working in a suggestive way to the AI. Now there are tons of other architectures that are being built within AI harnesses that you could add more sort of oomph to. You could create MCP servers with endpoints inside of it and workflows inside of it, tools inside of it that have more determinism or at least more specificity and force around way in which the agent is interacting with it.

(10:30):
You can create CLI tools that then are loaded in. You can create all sorts of other ways in which you are enhancing the agent harness without the suggestive nature of skills. And so what I would just say is AI is one of many consumers and harnesses are one of many interfaces. You're not only having agents touch your software. You might only have agents writing your software. Totally. I know of companies that are operating that way, so I know that's possible and actionable, but you're still having humans validate it, you're still having humans support it, you're still having humans interact with it. So it's not that the agent is the only user of that platform. It is just maybe the primary coder or engineer within that platform. So if you only engineer your platform for use in agent harnesses, what are you going to do when your customer support team needs to go in and explore something or your go-to-market sales team needs to go create environments to make sales pitches with or something?

(11:38):
You're going to need that other thing. So that's why what I advocate for is think about your platform as a piece of software, middleware software that sits between the infrastructure that you demand and the consumers that demand it, and then make it so that that can be consumed where your users are, whether that be amazing kind of portals with scorecards and things like Cortex provides, whether that be MCP and other harnesses around AI agents, wherever that might be.

Ganesh Datta (12:09):
I think that's perfect. The description of skills is like pretty please, could you do a thing is very accurate. And in other words, it lacks determinism and you're kind of hoping that it does the things you want it to do versus just codifying the things that you know are important. Which in fact, I think what people are realizing is the right way of giving agents the ability to do things. We talk a lot about tools and whatnot, and that's what tools are. It's like, yes, as an LLM, you can make decisions on what you want to use, but when you want to do something that is very specific, we'll give you a very specific way to do that. And so that's true about these organizations that are building their own agents for their customers. It's like, hey, if you want to access data from our platform to do something for a customer, these are four very specific ways that you can do that.

(12:57):
Why is that not the same for your internal platform? It's exactly the same thing. Sure, maybe you want to give your agents the ability to provision infrastructure, deploy something, roll things back, like you're building an incident on-call agent. Sure. Why not just give it a very specific way that it's allowed to do those things? So then actually you can build a much better agent that can reason about those things in very specific ways. And so I think that's kind of missing from the conversation is actually it is better for agents. You're making a better experience for agents as well, not just humans.

Abby Bangser (13:27):
And I think at the micro scale and something that's maybe not controversial, if anything, what we're saying now is, is the conversation about you can use AI to reason about things, but that doesn't mean you want to use it when you want a very deterministic repetitive action. Then you use AI to write a script that then AI can use and reason about. This is something that I think has been very popularized over the last, I don't know, more than six months, which is when everything else blew up. But for the last couple of years where you say you can use AI to write yourself a make file or a script, a build script or a test script that says anytime you want to test my software, use this script to test it. That way you're removing the expensive tokens, the expensive logic, and also the risky non-determinism of quality in your software by leveraging AI to write yourself that repeatable script and then executing on it.

Ganesh Datta (14:28):
Exactly. Yeah, we're building out our internal software factory. And I mean, as we're doing that, we're looking at things like how do you verify changes autonomously that agents are producing? And for example, for UI changes, you could use just general browser use or what's blowing up in popularity now is Playwright. Have your agent write Playwright tests. And that is a much more deterministic way of testing UI stuff for an agent. Obviously you should do unit tests and whatnot too, but compared to browser use, you have much more deterministic ways of doing things. And it's interesting, these libraries that have been around for a while are suddenly blowing up in popularity, which is very interesting to see.

Abby Bangser (15:06):
I particularly love that because I started my career as a QA 15 years ago. And I feel like it was a dying breed. It was a dying role back when I was joining. And I was like, "I don't know what you're saying. This is awesome. And I get to make really high leverage impact at organizations by using automation and quality coaching and all these things." And I feel like now it's just coming straight back to if you have the mindset of what does quality look like and how do you do so in a sustainable and practical way? You're so far ahead of all this, "Oh wow, you can automate browsers and make them repeatable and all that." It's

Ganesh Datta (15:45):
Really funny. I had Rob Zuber who was a CTO at Circle CI on an episode a while back. And he also came from a QA background and he was talking about the very similar thing, which is that mindset. Maybe QA as a field may be changing, but the mindset was very unique. It was like, how do I break this? How do I reason about all the different branches that I can take on this thing? And it's an adversarial mindset, which by the way, as people are building agents now, we're like, oh, we should have adversarial agents and et cetera, et cetera. It's like what's old is new and what's new is old. We're kind of looping back to those same things, which has been really, really funny to watch. You mentioned another concept when you were just talking about consumers. And I know that you've talked about this idea of consumers versus producers in the past when it comes to platforms.

(16:36):
What does that mean? If you could just give a quick overview of consumers versus producers.

Abby Bangser (16:39):
Yeah. I think that to give the one second history of why we're here, because we've touched on this, but just to pull it together, is to say 10, 15 years ago, you'd go to centralized team to get what you want. And it was always really slow because they were backlogged and they didn't have what you needed and they needed to do it custom. It was always very slow. So we moved to these, what you deemed or described as micro kind of cloud accounts. And I think the industry called DevOps where they said, "You're unleashed. We're going to give you the autonomy, but also the responsibility to build what you need." And what we're finding is that with that autonomy, there's a lot of cognitive load, there's a lot of security risks, there's a lot of ongoing maintenance costs and duplication of effort. So hey, let's go back towards centralization.

(17:23):
That's called platform engineering. Now, why some people think of platform engineering as hype or as just renamed centralized ops is if people literally just swing right back. But what's great about most pendulums is they don't go back to exactly where they were. They go back towards where they were and end somewhere over there. And I think that the really big nuance that needs to be applied for platform engineering is the idea of self-service APIs and the not being blocked on a single central team that can't keep up. Now, self-service APIs, cool. The industry's pretty cool on that. Pretty aware, pretty keen to support. But that whole idea of not being blocked on a centralized team to build those APIs is where I think there's a lot less experience and a lot less. There's more of a leader group right now that's doing it. And the way that I try and describe this to people, I have a couple of analogies, but one of my favorites is to talk about the team at Etsy.

(18:24):
So the engineering, the organization Etsy does not staff people who knit sweaters or paint paintings or build dining room tables. And they don't staff people to go shopping on top of their platform for things. They staff people who are in charge of building an environment where those that are creative and want to sell something can do so in the most productive way possible. And those that want to buy presents and search for interesting gifts and things like that can do so in the best way possible. The team at Etsy's in charge of building that marketplace, setting some standards like you have to provide a price, you have to provide an address, your ratings are visible, some standards of how this is going to work, but then provide the tools out to the people that are best suited to take on that job. And that's how they've been able to expand so rapidly and so largely.

(19:21):
Bring that concept to internal platforms. If you take an internal software engineering team and you tell them to build a platform, and they're in charge of not only building the APIs and the mechanisms by which all of this is managed, but also all of the infrastructure as code and also all of the security scanning and also all of the financial tagging and management and all of that stuff, you're going back to centralized ops. You're going to get stuck because that is just too much for any one team to take on. But if you take a software engineering team and you say your job is to make sure that all the experts in the organization are high leverage, that the database experts are able to provide databases to the organization in a compliant way, even though they don't know how to write software or that the security team, the CISO office can lock down on compliance across the organization, even though not only do they not write software, they don't write code of any sort.

(20:18):
How are you going to build that? And when you're building tools for those experts to be high leverage across the organization, now you're building something that is scalable. And that's what I mean by producers and consumers is you make a marketplace platform that they can both come into.

Ganesh Datta (20:34):
In the ideal state of a platform team, is that mutually exclusive? Is a platform team only in the business of creating the marketplace or is the platform team also responsible for delivering certain capabilities to the end user? Or is that all done through the marketplace where the other experts are building capabilities?

Abby Bangser (20:51):
I think I wouldn't like to call it exclusive. So first of all, there's going to be a scale reality here. If you are an organization with a hundred engineers versus a thousand versus 10,000, you're going to have a different division of labor. I was a platform engineer in an organization with a hundred people in the product and engineering team. We had a team of about 10. We were everything. Because you don't have in that size organization someone who just worries about databases. You have someone who does infrastructure as code in the cloud and so on. So I'd like to call out scale as one contributor to this. So I think what's more important is that what you're thinking about is mindsets. And so actually, I'll go back to my history as a QA and lots of people would like to poke at me and go, "Well, I don't think you need QAs on a team.

(21:39):
The developers should be testing their own code." And I'd be like, "I agree." But you know what QAs do bring is they bring a depth of experience and expertise in the area. They bring in oversight over not just a single item, but the whole holistic idea. And they bring an actual interest in doing the job, which not all people do when they're not interested. So what you need is you need the outcome of quality mindset and testing validation. You might need a human who's in charge of that, but you might not. And I'll bring that back to platform engineering and say, you can very well have one group of humans that are in charge of both the marketplace experience and the contribution to that marketplace. There is still value there because what you are building is a composable and extensible architecture. The value is reduced if you don't have any external contributors, right?

(22:36):
Because now you're maybe a little bit doing it for fun because you're just contributing to yourself. But it's forcing an extensible and composable architecture, which in itself is really high value. And so I think once you get to tens of engineers, not single digits, but well before you hit hundreds, having that architecture matters and therefore having a mindset of building the marketplace versus contributing to the marketplace matters, even if it's just you putting on different hats on different days of the week.

Ganesh Datta (23:09):
I'll take a stab at maybe updating that analogy. It sounds maybe more akin to Amazon. Obviously not the AWS, but the store Amazon, the retail side, because they started with their own shop and they were selling their own things and things really exploded when they opened it up to third party sellers. It's like, "Hey, actually we've built the platform to sell stuff. We sell some stuff too, but you can also sell stuff if you would like." And that's where it really created that momentum. And it's kind of similar. In the past, I've talked about platform teams maybe working with teams like SRE and security and whatnot to bake their practices into the platform. But I actually like this idea more of not just work with them, but make it easy for them to do that on their own. And it's kind of like the same thing on either end.

(23:56):
So yeah, I really like that.

Abby Bangser (23:59):
I love that analogy. I'm definitely going to steal that from you. I think that's fantastic. I think one of the things I'll call out is that a lot of people apply the term inner sourcing when we talk about this type of thing. And I will call out that I think it can be applied. You can use the term inner sourcing. I'm not a big fan of being a word police and saying you can use certain words in certain contexts, but I will call out there. And another last analogy here is around Kubernetes ecosystem that I'm obviously deeply involved in as an ambassador and as a part of the tag orient and all that. Kubernetes is an amazing piece of software that's been growing for 12 years. And through an open source mentality, through an inner source open source mentality, people can make pull requests, they can make suggestions of new features.

(24:47):
It has grown tremendously. It has hardened, it has become much better. It is absolutely minuscule amounts of change and evolution in comparison to what has been built on top of the custom resource definition and controller ecosystem that they've enabled. So despite Kubernetes being such a powerful open source community, it can never keep pace with the ability to extend it when given an open interface. And when you look at the 200-something projects that are in the foundation, let alone the thousands and tens of thousands that come along that are not in the foundation, that's why that is a really good way of looking at the difference between how much your platform can grow if you build a single component. And in order for people to engage with it, they have to write it on your terms and your code base, inner sourcing in that way, versus you build an extensible marketplace with producer and consumer mentality where then people can build their own way as long as they adhere to your standards.

Ganesh Datta (25:48):
I love that example. Who do you see generally are the other producers that are the early adopters of the platform starting to first sell their stuff on the marketplace?

Abby Bangser (26:00):
Yeah, it's almost always forward-thinking infrastructure engineers. So it's almost always operations and infrastructure engineers who have already tried to evolve their infrastructure as code from more static solutions into more dynamic ones, leveraging infrastructure as code controllers like Crossplane or ACK on Amazon or Google ConfigConnector, those kinds of things. They're looking for ways to more and more unleash their users, but they're just not sure how to do it within the ecosystem of their organization. And one, they get given the ability to do on-demand APIs, but without having to deal with any of the plumbing, they're off to the races.

Ganesh Datta (26:44):
That actually reminds me of, and maybe the final topic here is the idea of templates and infrastructure as code. You've talked about template pattern, the template-driven infrastructure as being an anti-pattern when for a lot of people think of it as like, oh, we've really done it. We've accomplished what our platform needs to do. Why do you describe that as an anti-pattern?

Abby Bangser (27:04):
Yeah. So it is worth clarifying before I get too many tomatoes on my face. I will stand by that statement to be clear, but I will try and clarify, is

(27:13):
The ability to template something and the ability to write infrastructure as code is good. I'm not arguing against infrastructure as code. I'm not arguing against templates within that space. But what I think is happening is that it has been such a high mountain to climb to write great infrastructure as code and to write great connections into all the diverse infrastructure we're managing that we haven't had the time to think about what that looks like to consume it. And so we have really leaky abstractions. So templates are fine, but if you take a template and you hand it out to a user, you're putting a few different stressors. You're creating a few different stressors. The first stressor is that that person now needs to know how to use your infrastructure as code. So they need to know how to use a Terraform module. They need to know how to use a Helm values file and chart.

(28:03):
They need to know how to use a Chef recipe, Ansible playbook, whatever it is, because to consume that, they have to be able to use it. Secondly, you are making ownership very convoluted. If that template is creating infrastructure, who's in charge of keeping that template and that infrastructure up to date? If you need to update that template to take into account a new change in the underlying cloud provider or whatever, can you force the consumer to use version two or not? If you can't, how do you know that they're going to take it on? If you can, how are you going to know that you're not going to break them? Because it's actually running in their environment often, not yours. You don't really have control over that. And it might not even have been run for a very long time, so maybe it's broken for other reasons.

(28:54):
So very difficult to deal with ownership. And I call that at best, it's the puppy for Christmas mentality. It's the, I've handed it to you, now it's yours, you figure it out. You've got four walks a day, you've got vet bills, you've got chewed up shoes, it's yours. I wrote you this great template though. Yeah. So I think those are two of the major challenges. And so I'm advocating not against templates, but I'm advocating against those as the interface because the final outcome that happens is not only are you asking people to learn your language, which was my first point, you now are locked into that implementation pattern. So I use the term API as an important feature of any platform between the producers and consumers. And the number one thing I mean here is not that it's a contract because the infrastructure as code tools give that to you, but that it separates the way that people consume from the way that people produce, allowing both to work independently as long as they maintain a shared contract.

(29:56):
Because what we're seeing is that very few organizations have one backend infrastructure as code tool. And so they need to be able to do more than one. And now their users are learning two tools or three tools or more. And if you can create APIs that hide out the implementation, then all of a sudden you're becoming a truly high leverage centralized team because when your team of 10% of the org, of the engineering organization changes something, only that 10% has to change. The other 90% don't have to change. But if today, if you're handing that infrastructure as code directly to a user, you think you're high leverage because you're 10% of the organization changing something, but because you're now asking the other 90% to actually change with you, it's not quite as high leverage and high impact as you might want it to be or hope it will be.

Ganesh Datta (30:48):
Again, standard software engineering principles that we follow pretty much everywhere or we try to follow pretty much everywhere. It's just apply that to your platform. It's no different. I'll say, A, I realized that you really like your analogies and I love them too. Sorry. No, they're great. They're great. And B, I think you articulated well also was going to be my follow-up question, which is if with coding agents, we don't have to learn those languages anymore. We don't have to learn Terraform. We can write those things. Some of the downsides of things like fleet management, it's like, oh, I needed to go and change this thing across a thousand databases, across a thousand repos, is easier now.You could set off an agent to do that and it's not the end of the world the way it used to be in the past, but it still doesn't solve for the abstraction layer where you want to be able to quickly iterate on the backend, not break that contract with all of your consumers.

(31:41):
And it again, goes back to just basic software engineering principles. Yes, you could have a code base full of just leaky abstractions all over the place and it would work, yes, technically, but it's very hard to maintain. And over time, your platform's so important, you don't want to lose that maintainability and kind of control over that as well.

Abby Bangser (32:01):
Had a lovely half an hour chat with you, but yes, we could have boiled this down to one sentence, which is if you're building internal platforms, they encode your business onto the infrastructure and you should build it like any other piece of software. It really does boil down to that one sentence.

Ganesh Datta (32:15):
I love that. If you could leave a parting piece of advice for somebody who's just starting their platform journey now or have realized that maybe their current approach isn't working, where do you think people should start? Or how do you think people should start?

Abby Bangser (32:30):
Yeah, I think it is getting that API in place. So I think, look, if you're in a position where your users are talking directly to infrastructure as code, it's going to be a transition for you from that solution to any other solution. All I suggest is that when you make that transition, you invest in owning an API layer rather than moving it onto the next infrastructure as code solution to then have to pay that price again later. So creating an API, even if behind that API you have long lead times because of manual steps and things aren't perfect, the API again unlocks you as a producer to create things, iterate on things, make things better. So putting into place APIs between your consumers and the infrastructure they depend on will make a really big difference.

Ganesh Datta (33:19):
I love that. I mean, thanks so much for the insight and I think there's a lot that platform teams out there can learn from this episode. So thank you for sharing all those learnings. It was great to have you on.

Abby Bangser (33:29):
Thank you so much for having me. This has been fabulous.

Ganesh Datta (33:37):
Thanks so much for listening to this episode of Braintrust. If this resonated with you, do me a favor. Share it with another engineering leader who's wrestling with these same challenges. And if you want to continue the conversation or learn more about how we're thinking about engineering operations platforms at Cortex, reach out to us at cortex.io. Thanks for listening and we'll catch you on the next one.