Deterministic AI Isn’t the Goal. Deterministic Systems Are.

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right. It's been a while since we've published a podcast. I get to the point where I only interview people when they're interesting. I, Adam, by the way, we have Adam Jacobs, CEO of Swamp Club on. You posted something on the what I still call the Twitters. The other day that really got my interest in it. It kind of sounds like an oxymoron, deterministic AI. But first off, hi. How's it going? Hi. Yeah, it's great.

It's great. It's great to see you again. Yeah, I'm for people who don't know who I am. I'm Adam. I in a previous life, I started a company called Chef that was useful in the in the DevOps movement. And I spent a lot of time sort of helping people understand how to think about cloud and how to think about DevOps and digital transformation and lots of enterprises. And so that's the that's sort of the that's who I actually am.

In the end, I'm a systems administrator who, you know, turned into an entrepreneur. So, you know, everybody is sort of impacted by the by the transitions that are happening sort of broadly in the industry. You know, wrought by AI. And so sort of a small team of people started a new company called Swamp, Swamp Club. The product is called Swamp. And, you know, we really decided to go exploring, you know, like we wanted to sort of see what it was like to live as as much as a maximalist as we possibly could.

You know, like what happens if we just go live in that frontier and take what we know and the things that we love and like see what happens if we if we just give ourselves the permission to to really go deep and get weird and sort of see what works and what doesn't work and what breaks. And, you know, what has come out of that is is is Swamp. What caught my interest about the blog post in the concept in general is that we want to address the business problem of deterministic AI.

Let's talk about the technical toy. If I have my agent stand up of VPC, let's do some sheer like, you know, history from your chef days to now. If I have a agent stand up a VPC from a user of AWS perspective, I couldn't tell you. At this point in my career, whether start other than logging into your AWS console and going to easy to or whatever, I couldn't tell you the steps to start a new VPC. Yeah. But from a manager's perspective, from a technology manager's perspective, conceptually, an architect's perspective, I absolutely know what I want to deploy.

Right. In the chef days, I'd have to create my recipes and deploy that. So I'd have to have that low level of knowledge today. All I have to do is go to check, not check GDP, go to call code, give it limited credentials to my environment and say, set it up. Yes. Go at it. The problem that I have is that the next day, if I go to do that, it is going to it's going to meet the spec or that it's going to answer the request.

But it's going to look completely different. And that is the problem with AI is that it's probabilistic is going to get me the outcome that I asked for, but not consistently. And, you know, from your chef and DevOps days that that's a bad combination. Yeah. I mean, in a lot of domains, it can be, you know, sometimes sometimes you want the cleverness and sometimes you don't. I think. But but yeah, I think that is that is sort of the crux of the problem.

There's it shows up in a couple of different ways. Right. You know, one is is sort of the inefficiency of it. You know, so you go and create you, you go ask Claude to create you a VPC, for example, and it does that. Does it do you know that you have a VPC? Do you know? Do you know when that thing got created? Do you know that it matters when you come around the next day and ask for a VPC?

Yes, you're going to get an outcome. The VPC. Did you mean a new VPC or did you mean the one you already had? Did you just forget you already had it? How would you know? How would the system decide? And like all of that, that that knowledge, every time you go ask Claude in a new context window to do some work for you, it has to rediscover the whole of the world from first principles. You know, it has to start from that first question.

That's like, well, what do you what does what does Keith really mean when he says create me a VPC? And, you know, then it's going to go make some decisions about like exploring your environment. And he probably means AWS. And OK, well, do I have AWS credentials? And oh, do I already have VPCs? And like, you know, and or maybe you ask it again and it doesn't do any of that exploration. It just assumes you do. And it goes straight to the create.

And, you know, that flow of like, well, what are the questions I wanted to actually ask? What is the actual thing that we're describing? That's the part that largely is missing. And what's interesting is that as the frontier models have gotten better, you know, we can write skills and we can do all these other things that sort of help to align a little that trajectory of where that probabilistic thinking is going to go. And sort of what what the rails of that execution are and the cost of that is ever more token consumption.

You know, so it becomes basically a loop where I like I feed you more context, which then causes you to be able to run ever more complex processes, which mostly work out, but not always. And so then I build in loops and then what those loops are doing is pushing more context into the thing. And it just becomes this self-reinforcing circle of like first principles deduction driven in a loop as hard as you possibly can, which eventually results in the outcome you're looking for, which feels like magic.

But then when you look at it, you're also like it was very expensive magic. It took a long time. It was, you know, like all of those things were there and I couldn't validate it and I couldn't do it again. And like, yeah, that's the blog post that you're mentioning. That's basically what it was, was David Kramer at Century had written a blog post about how he'd spent like $10,000 on tokens in a week. And he was describing like sort of why and how that happened.

And he had built a skill called Garfield and Garfield's job was to like, as he wrote code, it was to like micro align his code to his standards. And the skill knew how to like look at your repository to find other skills or read me's or documentation that describes your standards and then spawn sub agents that would do adjustment on the code base to make sure that that stuff was true. So it was basically a really complex code review skill. And it used, I think the number was four and a half million tokens in one like representative problem I tried with it.

And by making some of that process a little more deterministic, it wound up using half a million tokens, you know. And the, you know, those are meaningful reductions. It also ran twice as fast, you know. And it's because instead of just using the intelligence over and over and over again to solve every problem, you have to apply that intelligence to the machine that solves your problem, right? We're creating, we're always creating software that solves my problem. And that intelligence can be, we can apply it either as brute force, or we can apply it to create a structure that then we run repeatedly deterministically to sort of solve the problem over and over again as we better understand it.

And use the intelligence to adapt as our understanding of the problem grows, then our ability to solve the interior design of that machine also grows. And, you know, it's a bit of a head trip, but it works. You know, the we'll get into the technical part of what you just described. But I think some of us from an engineering perspective, we kind of get there naturally as we're using clock code. I have a a research process where when I rate a company against my my four plus one infrastructure assessment, it's pretty simple, well-documented process.

If I gave it to another analyst to do, they could look at the rules, they could look at the system, then they could recreate it and they could do it themselves. I. agent. They can also do it because it's a well-defined criteria. It's a real well-defined set of rules there. There's some conflict resolution in that and all. I. agent. Raw, just hey, go out and do this. It's going to reason through the entire set of steps.

One, you kind of caught me in one of my raising blood pressure moments when you mentioned a skilled MD foul. In my mind, skilled MD deterministic, because it's exactly that. Here's the formula. And it's it's telling the agent what to do. And then there's the reality. When you give it to the agent, it doesn't always honor everything. Everything is skilled that MD. So my pushback to you is that you're basically solving an unsolvable problem. The the the the LLM powers, the agent is nondeterministic.

So how can you make the agent itself deterministic? If the compute that is running, that is that is controlling is nondeterministic. That's such a good question. OK, it's it's a little meta. So you just got to ride with me into the like into the metaprogramming space of it. But the way to think about it is you have a set of instructions that you set in a skill. Right. So you said here's here's my process of doing an evaluation based on my criteria for my four plus one framework, you know.

So there's a series of steps that you describe that you want the agent to go through. Some of those steps, the flow of those steps, do this, then do that. If this happens, don't do that. None of that needs to be probabilistic. We know exactly how to encode those steps. We can just write software. That's like step one. Do this step to do that. That's what computers have been good at the whole time. Now, inside that process, there is a there is an there is a moment where it has to go nondeterministic.

For example, is this go fetch me the data about my architecture for this particular part of the framework I'm doing the analysis for. Now, analyze it and tell me if it's good or bad, you know, based on some criteria. I can't write a computer program to do that for you. I don't know what the data is. Right. I don't I don't know how to I don't know how to apply judgment the way that you're applying it. Like if I tried to do it, it would it would be it would be hard.

You know, we've seen this in in the history of computers that those were called expert systems that did that, where we tried to encode every possible branch of knowledge so that we could we could deterministically determine the truth. So what happens is you take the parts that can be deterministic when you need judgment. You ask the LLM to give you judgment, to give you creativity as a step in that deterministic process. And you make the output of that step a known piece of data.

You say, I know what that data is. I know what it's supposed to produce. And then I can validate whether or not that nondeterministic thing produced an outcome that I accept. And and then I can chain that together into ever more complex behaviors. And so the way the agent becomes deterministic is that that path that it runs on that says, hey, now I want you to run this framework again, only with these new inputs. I can tell you for certainty that the agent is going to run that process through a deterministic program, because that's what something like Swamp does.

And once the agent has encoded it in Swamp, then it doesn't have to think about how to encode it anymore. It's going to run that process the way you tell it to. Because when that's what happens when you run Swamp workflow run, analyze my architecture, like that's just what happens. There's nothing you can it can't go wrong because it's a computer again. It works like computers work like they've always worked. The part that gets a little meta about it is that, like, I don't think anyone ever has written a Swamp workflow by hand.

Like, like, I don't think anyone's ever sat down and just like written like a Swamp model from scratch. Like the agent writes the models for you. The agent uses the framework to create its own path for how it's going to get to your outcome and then walks that path over and over again. So I don't think this is too meta because I've created this process naturally with my process with. Yeah. With with Clark Colt. I know my process. I know how to describe it.

I know how to do it. So I can describe it to Clark Colt to say when I want to create a new assessment, run this code, which will then follow these rules. Yes, you got it. And that limits that. It has the practical example of what you said, which was to limit my token costs, make it reliably a process that takes a half an hour every time I run it. And then on top of that, I can extend that code to say, OK, now reconcile the roles because now it's just a data set and it's a database.

And I can I can say, OK, reconcile. I might be consistent as I'm grading vendors. Totally. Very programmatic. Yes. I'm having trouble. Rocky with Swamp King Club is. Making that. Making that a process that's consumable by nine engineers or by nine coding experts, because the logic, even if I don't need to, even if I don't need to write the code, I still need to be able to describe the logic to to in a way that's possible to call code.

How are you that problem? Yeah. So what you're talking about is the ability to describe the architecture of the software to solve your problem. So as a software developer. Right. Like when you think when you as an engineer have thought through how to put that together in your framework, you as an engineer understood, well, I'm going to store it in a database and I'm going to run this workflow this way. And maybe you made a choice about what language you write it in.

You're like, I'm going to use I could write a Python script that talks to a database that does this. You know, like you made all these engineering decisions that allowed you to sort of get to the end. And then the software that it produced, you know, either solves for your outcome or it doesn't. Maybe you read the code. Maybe you don't. Right. If it doesn't actually work, then you tweak it. You know, you refactor, you change. Right.

So what the way that you solve that problem generally for everyone is you say that within a given domain. So, for example, my domain is automation. Like I work in repeatable automation. So what I have done is I have built an architecture for how to build repeatable automation. It's got building blocks like like typed models with inputs. It has met those models, have methods that are written in TypeScript that you can execute. It knows how to produce data that gets typed and stored in the swamp.

It can access secure vaults for secrets. It can do you know, there's all these different pieces they can get. Those models then get composed together into workflows. Workflows get executed in this particular way. You can always query the data that gets produced by them using this using this method. That's a software architecture in the same way that like domain driven design produces a software architecture. Right. Or the gang of four produced a software architecture. And by handing that architecture to the agent and saying, I am giving you this technical outcome, I want build me a process for automating my my and my my four plus one analysis and saying now use swamps architecture to do that task.

I've solved the problem of you having to come up with the architecture. I don't need you to know. You don't need to care how those things got broken down into reusable components. They did get broken down to reasonable components because that's the that's the path that we set the thing on and we told it to go do it. And now, you know, I love what you're describing here, because, as you mentioned, it's meta. And I think this will trip people up.

And I saw I need to challenge you on this. Please do is you're using a I. To make a I more deterministic, if I can, if I can simplify it, the exact level. As a architect. I get it like I can take. Three, I can take several three nine solutions, put them together, design them in a way that makes it a five nine solution. The redundancy, the architecture is in the redundancy comes from the architecture taking these non non reliable components and just adding more of them to make the entire system more reliable.

Right. But that's a known that's a known emotion. What's more unknown is using a I to make a I more reliable. Yeah, but that's but of course it can because like it's just all it is is a machine that's designed to give you to create outcomes. And like and then what we do is we tell it what outcomes to create and then we and then we tell it how what is it what is an acceptable pattern by which that outcome can be achieved.

And so, like, in the case of building automation, we already know what those patterns are in the case of building, you know, if you wanted to build RAID storage, I don't need an LM to invent RAID. We have RAID. I know precisely what to do. So this is because the output is possible. Right. I can test. If is this a is this a RAID configuration? The software is written, the RAID is running. I pull a drive. Yes.

Do I still have data? Yeah, I still have the data versus the spec. So if I'm getting you correctly, if I do it right, if I build Swamp Club correctly, I can create deterministic testing and deterministic rules. Yes. Well, first, deterministic code that implements deterministic rules that then have deterministic test. You got it exactly right. And and one of the things that I think is really interesting. So like this is also we learned to do this because this is how we built Swamp.

Like we learned we learned this was true because that's how we wrote the software that does this. And one of the things we had to do to make that process work really well was I think we're old enough. And maybe maybe our hopefully the podcast listeners are to to remember like when software came in CDs or it came on floppy disks. And if you if you were in the industry, then I was like we used to have rooms filled with people doing QA.

And what they would get is like a notebook and a CD that had been burned of the software that we were proposing to ship. And their job was to put the CD in the computer at their desk and then open the notebook to page one and go through every single use case that we had written down about how the software could be used and confirm that it didn't work. And if they found a bug, they would file the bug and then the loop would start over.

Right. So we would go through this like software developers write software. Release gets burned to a CD. CD gets tested by a bunch of QA engineers. They find bugs. Bugs go back to the top. You know, we rotate all the way through. That process we largely have done away with because it was too slow in the Internet era. Right. And so we've we've done all this stuff to sort of change how that works. Turns out in the era of starting to align agents to outcomes, we can use agents to build really comprehensive user acceptance testing suites that you would never, never have put human beings against.

Never because they would've been too expensive. It would've been too hard. It would've taken forever to do. And so we can have really comprehensive testing of the outcomes. Black box testing, you know, like from the outside. And that is such a powerful technique for ensuring that the outcomes of this probabilistic engine meet your standards. You know, like in a software project, it's the thing that allows you to do dramatic refactors. You know, if you want to change the architecture of some software in a dramatic way, that used to be very high risk.

But now it doesn't have to be. You can be like, well, first, I'm going to build a comprehensive black box testing suite that covers off on every possible thing that the software would do. And I'm just going to use agents to do that. And then I'm going to refactor the software and I'm just going to stick it in a loop until that until it turns green again. And and suddenly it's safe to do. And that same process is that's part of the process that gets encoded when you use Swamp to build automation is like, well, what is the outcome?

And how do you know what that loop is and how do I validate it? And like, yeah, the whole piece sort of comes together and it's it's super works. But, yeah, you're using you're using that intelligence that is inside the agent inside the LLM to to then produce the behavior of the LLM needs in order to produce the outcome you want reliably. And that's the game. And I sometimes talk about it as the machine that builds the machine. Like once you realize that's what it is, you start to see it everywhere.

You're like, ah, this is this is literally everything that we're doing all of the time as engineers. Now we're saying, how do I construct the machine that outputs the thing that I want all of the time? And I think what I want to leave the audience on is this last piece that. I don't want to paint over. While the machine is writing code for the machine, the human in the loop isn't reviewing the code. That's no longer the job, like the job isn't to review the code, maybe on edge cases, you need to nudge the machine and help it with novel problems.

But the the the frontier models are really, really good at writing code. Yeah. What they're not good at is what we just described. Entire process. And this is why engineers, architects, et cetera, are still needed. And this is where the needle is moving to or the push is moving to is this ability to deconstruct these. Except for the complex business requirements into systems that are testable and deployable in real life, will I ever catch up to this ability? Maybe.

I don't know. I don't I can't see it. You know, I've got I've gone pretty deep in this work from my angle. And where I see kind of the human ingenuity still kicking in is kind of the orchestration of all this and the human managing the agents and not necessarily doing that low level work anymore. The idea that the that there's no more engineering involved because the software is being written, like if you listen to what we just said to each other and you think that I'm not engineering.

Oh, you know, like, like, like our understandings of what engineering is, we're just they were always fundamentally different. And like, I think I think one one way to look at it now is that, you know, historically, most people learned architecture from the bottom up. You know, you started your career doing something tactically and then eventually you gained perspective as you climbed over time to be able to see the whole system and sort of how the whole thing sort of fits together. And I think now it's shifting to say, well, actually, you need to be able to see the architecture from the beginning.

And and then the system has to stay supple as I learn more about where my architecture is wrong, because it's still software, you know, so like you're going to be wrong. And then I have to refactor. I have to change the architecture. I have to I find new seams. And it used to be that, you know, the trigger for that behavior used to be while I was in the source code, you know, when I saw a problem or this part was hard to change or edit or now it's like, well, I see a commonality of bugs in this area of the product.

I see it like every time I try to make a change to this piece of what it does, it's hard or the system seems to not be able to do it effectively or I have to do it over and over and over again. Those are all now clues that the internal software architecture that's been created, the literal source code that's been written is wrong. And then you have to go investigate why is the architecture wrong? Like how why is this class of problem happening?

And it's very strange because it's it's suddenly a thing that you detect not from the bottom up, but from the top down from I've been experiencing the outcome of working on this software. I've been experiencing the outcome of this software being generated. And there's this piece of the outcome I don't like. And now I have to understand why that outcome isn't the way I want it to be. And so now I dive into that thing, but not from the bottom from the top.

Yeah, so we're not your path to becoming a architect isn't to learn how to be a great plumber or carpenter or you're just trained in architecture. Yeah, that's gonna be true. And I don't you know, when people ask me, like, what's it mean for software developers today? I'm like, well, I think that there's going to be a new generation of people who were trained in architecture, who, who they learned to do this, not because they understood necessarily how all the pieces fit.

That's always going to be incredibly valuable. It will always be incredibly valuable to know in great detail how the internals of a machine work that is so valuable. But like, yeah, there's going to be a generation of people who learn architecture first, and they learn the details second. And I didn't need to know the details of how to write a TCP IP stack to be able to implement TCP IP to to have a piece of software work across a network. Like, so there's there's layers and you know, you're going to have your protocol engineers who are always and we deep into the protocols.

Does it benefit me as a network engineer to know the protocols at that level? Absolutely. But that better not be if I want a job configuring network switches, which, you know, is is morphing. If I want a job managing networks, it's beneficial, but it's not critical to the path. And so we this is why we have more network engineers and architects than we have protocol engineers. So there is a role for all of us. I think our collective bet is that this architecture role is going to explode as people realize that I can be more deterministic and then can you can capture some of this this productivity games?

Yeah, for sure. Adam, this has been that my audience will know that this has been one of the longer episodes because this is I think what we just went over is the problem in the challenges and successful projects. It is why I thought it was worthwhile pinging you on Twitter slash X to have this conversation. If people want to find the company more about Swamp Club, how do they do it? Yeah, they should go to Swamp Club dot com and that you can learn all about the product there.

I would say the single best thing you can do is join the discord. So it turns out that there's a now a very fast growing community of people who this is the thing they're all exploring all at once right this second. So if you just if what you want is to just be immersed in a set of people who are like they're trying to figure this out together and they're really earnest and they're all like they're just trying as much different things as they can to try to figure it out.

They're all hanging out in that discord having a pretty good time trying to figure it out together. So that's the single best thing you can do. So go to Swamp Club dot com and just go to that discord and hang out with us and like bring us bring us your perspective. You know, like I want to hear from Keith like how that framework and those agents evolve, you know, and like it's from these conversations that as an industry we figure this out.

You know, it won't be because I go sit like a monk or or somebody else goes and sits and figures it out and then brings it down like a bolt of lightning. It's going to happen because as a group we go out and we experiment and we and it's messy and we figure it out. And then we talk to each other like we're doing right now. And then through talking to each other, we're like, aha. Yes, I see you like your problem is my problem, you know, and our solutions are similar and that tells us we're on the right path.

So that's what's happening. So come join us and do that. All right. And I am going to absolutely join that community. If you folks want to hear about what we're doing in this area, labs that layer to see dot com. But this is where I'm putting my lab notes of around my four plus one infrastructure. Yeah, infrastructure. But more importantly, how am I testing? How am I testing my deterministic loop in the code? And how do we make, you know, migrating from one platform to another one possible with a I in a deterministic way?

Kind of my core research right now. Until then, you can talk to both me and Alomar are if you're still, you know, big Twitter fans. We're still on Twitter, but it's just all X dot com. Talk the next episode of the CTO at Pfizer.