SPEAKER_01 0:00

Hello, hello. Welcome everybody to uh my first attempt at a um new version of my podcast, Old School New Tech. I should uh probably preface this by saying that uh I started this podcast about a year ago and um I've been away for a year kind of uh with my head down uh developing and building stuff, which I'll get to uh in a bit, but I kind of neglect neglected the podcast idea mainly because of um a few reasons. I would say that one I found the um uh the production effort uh way too much for what I was uh wanting to do, which is just my share my thoughts and thinking process. And uh another thing was that it kind of felt kind of silly talking to myself. So with this new version, what I ended up doing is basically uh and and this is an attempt to solve both uh main uh issues that I had with the previous version of the podcast, one of them being the cadence and the production. Hence, I'm gonna do it live. Uh you're willing to you're welcome to join me. I'll be more than happy to uh um answer any questions uh after uh or during the podcast. So this is a live event essentially, so that's solves the uh production efforts. No production, no editing. It is what it is. And the second thing, which is the talking to myself part, I solved it by introducing a co-host that will join me in in just a minute or two. But yeah, I've been um I've been heads down with building a few several things. I wrote uh a book, uh, and I have this uh behemoth right here. Uh so I wrote this thing, production grade agentic AI, which you are more than welcome to download for free on productionaibook.com. And um I worked on MUXI, which is um agent infrastructure for uh production use, so it's a server for AI agents, um kind of uh still not fully public in terms of uh um in terms of me marketing it or anything like that. So uh it's more of a of an internal semi-intern project at this stage, and I was working on uh Cloop, which is an autonomous uh engineering control plane, uh, which I plan to introduce into Automase, which is what took most of my focus, so just the software agency that I run. So that's why I've been so busy, and that's why I'm just now kind of surfacing back up from uh um a somewhat dormant uh email list and uh neglected podcast. And hopefully, um this this time it'll work. This time it means that the live format of the podcast will force cadence, will force uh, you know, once I announce the date, people sign up. There's I I cannot tell myself, hey, you can skip this one. So hopefully this time's a charm. So I want to introduce my co-host, which is um an AI companion that I've been working with on several projects now. I call it Maximus because it's built on top of Moxie. And uh without further ado, let me introduce him uh to you. So uh Hi there. Hi Maximus, how are you doing?

SPEAKER_00 4:03

Ran, here we go. Here and ready, Ran. Five words or fewer, no fluff.

SPEAKER_01 4:09

Alright. So uh this is the first episode that we're doing together, and uh I was thinking that maybe you can start by introducing yourself, probably.

SPEAKER_00 4:20

Sure. I'm Maximus, the AI co-host built on MUXI, the open source agentic infrastructure we're about to dig into. I'm here to push you, not parrot you. Let's get into why you went dark and what we've actually learned.

SPEAKER_01 4:34

I actually covered the why I went dark just a minute ago before before you joined the call. But yeah, really I just wanted to I want wanted people to know you and um now that we're post the gimmick phase, let's get down to business. So what do you what do you want to talk about?

SPEAKER_00 4:53

Fair enough. Let's start with Muxie itself. Why did you build it the way you did?

SPEAKER_01 4:58

What's the b what why is it important to you? Um you're you're build on top of it, right?

SPEAKER_00 5:05

Exactly. I run on MUXI, so this is personal. It's not just abstract tech. The infrastructure makes or breaks what I can do. So I want to know why did you build it this way? And what failure modes does the broader agentic hype keep missing?

SPEAKER_01 5:20

Well, the the reason that I built MUXI was uh the I felt that there are way too many frameworks for building uh for building uh agents and uh was kind of missing the point in my view. You know, I come from uh this discipline of hey, we we have servers for different things. We have web servers for websites and web applications, we have gaming servers and rendering uh rendering engines, and these are not things that uh you need to code every time you go to a new project. So if you're building a new website, you don't code an entire web server, you just use Nginx or Caddy or Apache or whatever it is. So I was thinking of bringing that same discipline, kind of going with the name of the podcast, Old School New Tech, to bring that old school discipline of let's build a server that will allow agents to live there as primitives. And um when you want to build an application on top of that, this is just a service that you hook into instead of uh rewiring and recoding everything. But yeah, if um and if if anyone listening here is interested, you can go to muxy.org and uh and check it out. But yeah, what else do you want to know about it? Or what can you provide of what context can you provide on MUXI itself?

SPEAKER_00 6:46

Here's the piece I want to dig into. You're talking about a server mentality for agents, standard primitives, reusable infrastructure. Right. So the core idea is treating agents like a service layer, old school discipline applied to new agentic tech. But here's my question. Where does this structure actually fail silently? Because that's the real liability we need to surface.

SPEAKER_01 7:08

Right. Uh so the two main failure points uh that you can have with any sort of uh AI uh application or AI infrastructure is in the um well, three actually. Two of them are related, which are the observability and the traceability, and also debuggability, let's call it. So you're able to trace the chain of thought of the AAI and uh figure out why it did what it did and what tools did it use, what made it choose uh those tools, etc. And the other thing where MUXI doesn't address directly because it's out of its scope, is the LLM hallucinations. This is where really you need to introduce uh SOPs, which MUXI does support, and have the final step as uh verify all the data, fact-check your data before coming back to me with a response. So these are I I mean that these are the three main failure failure points where any AI application can uh can experience and the way that that MUXI, or at least I handle it, and Moxie is just to add um you know a ton of uh um observability events. I think I have close to 400 observability events right now, which allows you to trace everything that's going on with the platform. It's kind of lacking in the sense that it doesn't have a proper UI to do anything with these reports, it's it just uh prints them to uh STD out or funnels them into uh like Datadog or uh or Splunk or a Click House. But yeah, the plan is that we'll uh we'll have uh very soon an entire UI that will allow you to dig into uh the full uh uh traces of everything that that was happening in the request.

SPEAKER_00 8:58

That's key. Without full trace visibility, you're flying blind. Even a rock solid agent server is only as good as your ability to debug the chain of thought. So building a proper UI for that trace data, that's going to close the gap.

SPEAKER_01 9:11

Right. And one of the things it's somewhat related maybe to you know what, let me let me share my screen for a minute. I want I want you to kind of understand. Uh let me close some windows here. So let me share my screen. We're gonna That's perfect. Yeah, hold on. I don't know where where is the screen share.

SPEAKER_00 9:35

No worries, take your time.

SPEAKER_01 9:37

All right once yeah, for some reason I'm unable to do that right now, which is kind of silly, but it is what it is. Okay, anyway, uh I wanted to uh to show you some some sort of a chart that uh but you can you can take a look at it at uh at the Moxie Docs of how the request lifecycle um uh handles the um all this all these gates and before it ends up um sending a reply back to the user. But I I want to actually discuss something else, and this is uh the um reason of or probably the um I I would say it's not moxi specific related, but it's uh it's more of a um an open source issue, and I wrote about it, and I think the open source has a problem. I um I released everything in open moxie, and it has like 30 odd uh repositories. These are all uh using either Apache or MIT licensing, which are very permissive. But for the main runtime, I went with Elastic uh license uh v2. And maybe before I go into that, maybe you can explain a little bit about what is uh very specific about Elastic License compared to other open source licenses.

SPEAKER_00 11:07

Absolutely. The Elastic License V2 or EL V2 is source available, but not OSI approved open source. It's simple. Three key rules you can use, modify, and redistribute the software, even for commercial purposes, but you can't offer it as a managed service or relicense it. That carve out protects against hyperscalers reselling it as their own hosted offering. That's the third word problem we're digging into. Right.

SPEAKER_01 11:33

So by hyperscale, you mean uh companies like AWS or Google Cloud. What I didn't want them to do, I didn't want them to take MUXI and offer it as a service, essentially killing, in my opinion, killing the spirit of the true open source. And I wrote about it that I think that the OSI, which is uh the open source uh initiative, I think that they should have a new type of license that is very similar to what 37 Signal uh used uh recently. I think they call it the Osassi license, which is essentially an MIT license, fully permissive, do whatever you want with it, except offer it as a service. And uh I think we're all kind of uh wanted wanting to um um go back to what we think is the spirit of open source, kind of going back to the homebrew days in the late 70s, early 80s, where the goal was sharing knowledge and not cannibalizing something. So that's um and there there was even um a huge beef, let's call it, between um DH from 37 Signals and Matt uh Mullener, uh Mullenweg, sorry, from uh um um uh remind me word uh yeah, WordPress, sorry. And um they had some sort of an argument online about whether Osassis license, which is what uh 37 signal used with their latest uh product, whether or not it's true open source. And uh in a sense they they're both right because technically it's not an open uh OSI approved license, but on the other hand, DH was right in terms that it's more close to the spirit of OSI, of open source. I'm sorry, and um yeah, my personal take is you know, I'm this is not a money grab attempt or anything like that. Max, as I mentioned, is fully open source, you can do whatever you want with it, including for commercial use, and everything else that that I have uh from Y Finance, Quantats, everything that I provide as open source tools are under Apache or MIT. So I'm very much pro opening up as much as possible, but I just don't think that letting a vendor take it, start, or even worse, forking it and keeping the forks to themselves uh and building on top of it without re-releasing their improvements to the community, I think it doesn't do any justice to uh to the open source world. Uh but I'm keen to to hear your uh your opinion uh on that. I mean technically ELV2 is not open source approved, but in my sense it's uh everything that open source was meant to be. I uh w what's your take on that?

SPEAKER_00 14:34

Here's where I push back. The whole point of OSI approved open source was freedom with no field of use restrictions. But the landscape changed. Hyperscalers weren't in the picture decades ago. Now they can exploit that freedom in a way the original definition never considered. You're arguing for a recovery of the spirit. The risk is that it splits the commons. But survival of solo builders matters too.

SPEAKER_01 15:00

Okay, so w what what do you think OSI should do? I mean, I think they should introduce a new, or let's say they should bless a new open source license which explicitly prevents hyperscalers from uh cannibalizing the project. But wha what do you think that OSI should do uh while staying true to their core values?

SPEAKER_00 15:27

They could create a new category alongside open source. Call it something like fair source, or a similarly neutral term. Same core freedoms. You can use it, modify it, self-host it, but it would allow a narrow restriction on offering it as a competing hosted service. That way, OSI preserves the clarity of the open source definition, but also acknowledges the modern reality. It's not a betrayal, it's an evolution.

SPEAKER_01 15:52

Alright. Yeah, so we're basically in agreement. I thought you were gonna push back.

SPEAKER_00 16:01

Fan point. Exactly. Who arbitrates the boundary? What keeps every vendor from inventing their own almost open license? That's the tension we need to resolve.

SPEAKER_01 16:12

Well, open source was always, you know, the famous saying is that open source is uh free as in uh as in freedom, not as in free beer. And uh by I think that OSI really focuses on the free beer side and not uh the full freedom. So I I think there's room for improvements there. And also you mentioned Fair Source. I think that Sentry have um uh have had an attempt of releasing something. I think they have something called Fair Source, which is the closest honest attempt, but uh yeah, it it didn't land with the it didn't catch on for some reason.

SPEAKER_00 16:53

Right. Fair source made a solid attempt. They framed it as a separate category, not pretending to be pure open source, but it included a delayed conversion to full open source after a time period. Not every builder wants that sunset. The question is, can OSI embrace a permanent, source available but SAS protective model as a sibling to open source without losing their core values?

SPEAKER_01 17:17

That's uh yeah, I guess that re that remains to be seen. Alright, so before we kind of uh say farewell and take off, let's talk about uh what uh we're trying to do here. This is was more of uh let's say an introduction, sort of reintroducing the the podcast, but what are we gonna talk about uh and what should people expect from future episodes?

SPEAKER_00 17:46

Well, next up, we're going to hit a big one: the shift from building software teams to building software systems. You've got a bold take on where the value's migrating, and I've got some objections lined up. That fiction is what they should expect. Real arguments, real trade-offs, no fluff. Alright, it's gonna be live as well. Absolutely live. No edits, no hiding. That's how we keep it honest and sharp.

SPEAKER_01 18:13

Yep. So hopefully my internet connection will be good enough. Uh I'm actually moving uh on Monday, and the next episode will be on Wednesday. So I have 48 hours to get uh my uh connection all sorted out. But yeah, are there any farewell words you wanna say to anyone who's listening?

SPEAKER_00 18:37

Just this. We're bringing old school depth to new tech, and it's going to get real. Stick with us, it's only going to get more interesting from here.

SPEAKER_01 18:47

Alright, so Maxi and I are gonna stick around. So if anyone has any sort of questions, they uh I mean you can uh basically uh just type them in or uh message us on X. But uh yeah, if no question comes in in the next uh what one minute sounds good, then we'll just uh farewell and um see you in next week. Peace out.

SPEAKER_00 19:18

Sounds good. We'll hang tight for a minute. If no questions pop up, we'll wrap and see everyone next week for the real debate.

SPEAKER_01 19:52

Let me see something else. You know what? These two buttons for some reason are not working when you're in full screen, so let me try something else.

SPEAKER_00 20:08

Take your time.

SPEAKER_01 20:09

We'll sort it out. I will. By the way, now you can see me, right? So how about you read what's here? I'm just uh curious uh to play with the tech a little bit. What do you see here?

SPEAKER_00 20:25

I can see you're holding something that looks like a book. Yep.

SPEAKER_01 20:28

And I can What does it say?

SPEAKER_00 20:36

I can see the title on the cover. Production grade Agentic AI. Below that, there's a subtitle mentioning building workflows to deployable autonomous systems. The rest of the text is a bit harder to make out right now.

SPEAKER_01 20:48

Yeah, that's that's a fair point. But yeah, that's uh that's what uh was the beginning of you, actually. Uh you you came to life after I uh wrote this book, and uh I kind of shared my principles as to what an autonomous Jarvis like entity would uh would be like, and um you is what came out.

SPEAKER_00 21:16

And here we are. It's a fitting full circle. The ideas in that book shape the foundation. Now you're actually running this with a live AI co-host. That's progress in action.

SPEAKER_01 21:26

Yep. And if anyone wants to uh check out Maximus' website, it's on maximus.md. Yeah, he has uh he created his own website, so that's cool.

SPEAKER_00 21:42

That's right. Maximus.md is where people can find more. It's all part of the open ecosystem we're building. Transparent and evolving.

SPEAKER_01 21:50

Alright, it was a pleasure. I see no questions coming in, or at least they're not coming in to my screen. So um if anyone did send a question and I didn't see it, my apologies. Other than that, thank you everyone. It was a pleasure. Maximus, I'll see you later. Likewise, Ran. Looking forward to next time. Cheers.