AI Agents Need Deterministic Building Blocks

Hey guys, thanks for the thrill. We're here with Adam Jacob, who's the CEO of Swamp Club, a new company that has been granted $7 million in seed funding to build a new platform for developers that are building AI agents, because, well, the existing ones are not as easy as they should be and don't have all the primitives required. Adam, welcome to the show.

Hey, thanks for having me. Glad to be here. I think it's fun.

I was granted $7 million. It makes it feel like the money fairy came, and just dropped off a bag. There you go.

Isn't that how it works these days? You just- Absolutely ... you put- You sprinkle a little AI on it, and then the money shows up.

Yeah. Put a little note under the pillow, and all is good. Mm-hmm.

All right. So explain to me what it is you guys are up to and what you guys are solving as a problem, because, well, people are building and deploying AI agents like crazy, but maybe there's something flawed about the whole approach. Yeah, for sure.

Well, you can really understand it in a pretty straightforward way. You know how you've tried to use AI to solve a problem, and it probably did, and you were like, "This is the coolest thing that I've ever done. " Right?

And then you tried to do it again, and it didn't do it. And you were like, "Man, you did it literally 30 seconds ago the way I wanted you to. " And then as you scale that up to larger business problems, that problem just compounds and compounds.

And it just fails to get from that prototype-y phase to the actual production working enterprise systems or systems in general that sort of solve real problems over a long period of time. That's what we fix. So Swamp solves that problem by providing a bunch of missing primitives that allow your agents to, or allow your harness to work to build up those behaviors from modular components that understand how to automate things.

They have typed inputs and outputs, and they store data, and they do all of this stuff that eventually allows them to run in this deterministic way. So all of these agents shift from basically asking an LLM to try to figure out how to do some stuff for you, and then hoping that it works every time, and hoping the models get smarter, and sort of paying frontier intelligence rates to solve your problems, to using Swamp to build up the set of primitives that the agent can call to then get that same repeatable behavior over and over again. And that's how you unlock that ability to work in the large.

That's what we do. In some regard, is that the equivalent of maybe a context engine for developers or in the AI agents and the tools they're using so that they can build something that is repeatable? Because to your point, the issue with Gen AI as it stands today is it's probabilistic, which means it never does the same thing the same way twice.

Yeah. You could think of it that way. I think what's interesting about that framing is that even that framing is sort of living inside the idea that we're asking the generative AI to do ever more of the task.

And I think what we have discovered is that when what we do is use the strengths of Gen AI, which are, it's great at writing code, it's great at understanding how to confine those systems, and then we feed it this set of architectural primitives that allow it to then create reusable automation that's easy to refactor, that's well scoped, that stores its data over a long period of time, that knows how to query and retrieve stuff, what happens is it starts to then build behaviors that get reusable, and those behaviors compound. And so, when you think of it as a context engine or those sorts of things, what we're kind of pointing at is the idea that, well, if I feed the AI a little more intelligence, what happens is the AI figures it out. And instead, what we're saying is, look, you're going to use AI to generate the behavior you're looking for and to maintain it over time.

But the vast majority of that is actually just deterministic behavior. It's just programming as it's always been. It's software as it's always been.

And what's changed is how we compose those things together, and then where we insert frontier intelligence, right? So if you think about any given part of the task, we have a customer, for example, who had a complex onboarding process. They hire a ton of seasonal workers and contractors, and so they had five different teams that had to coordinate across eight different systems, and it took six or eight weeks to get one of those people onboarded to be able to start work.

And so they used Swamp to create an AI agent that was fronted by Antigravity to actually figure out how to make that onboarding process seamless so that it could start by a line manager saying, "Hey, here's the employee that I need. Here's all the information. " 99% of that agent is Swamp.

It's just deterministic code that's been factored well, that talks to the system. And then in the moments where it needs judgment, it applies judgment by calling out to Frontier Intelligence. So is the art of software development in the age of AI going forward is striking a balance between these probabilistic AI LLMs and the more deterministic platforms that kind of capture, for lack of a better phrase, the institutional and tribal knowledge required to build software that runs at scale in an enterprise?

Yeah, you got it exactly right. And that learning of what are we doing as an industry to understand what is this capability, this new thing that we can do, and how do we slot that capability into what we do as engineers who design systems that solve real-world problems? And the first pass at this was, we're just going to use it for everything.

We're going to take all of it, and we're just going to throw every problem at the LLM, and they're going to get smarter, and we're just going to sort of pray for rain. And I think what we've learned is that the models today are incredibly good at constructing these sorts of systems. We see incredible results all of the time.

And the more what we do is design systems, design agents, design these behaviors, so that they're working together between those two layers, between that deterministic substrate that handles 90% of what you do, and then the parts that need intelligence or the parts that need judgment, we're calling into those models. Those are systems that both deliver the results you're looking for, but also do it in a much more cost-efficient way. We helped someone rebuild a code review workflow they had, for example, that dropped the token cost of that code review by eight.

It was a factor of eight less tokens. That was just by taking that process they had described in a skill file and turning it into deterministic code that knew how to evaluate those results and knew how to run them more efficiently. And that's just part and parcel of that learning process of how do we, as engineers, learn to unlock this value for our organizations.

Do you think we're all starting to get a better understanding of how these LLMs function? Because I think initially we treated them as kind of miracles, and now I think we have a better understanding of maybe what they do and how they break down a task. And maybe to your point, we're doing that out of necessity because we need to drive down the cost of these things, and well, tokens are not free.

Yeah. Look, I think the answer is yes. Essentially, we're starting to understand how those things fit into the engineering process.

And it turns out that they are miracles, and they do change essentially everything about the way we think about that engineering process, because you've never been able to ask a computer those sorts of questions and get those sorts of answers before. And so obviously, they redirect what it means for us to build working systems. And that's why we think stuff like Swamp is so important because, of course, what comes out of that is a set of primitives that you feed up into those systems to be like, okay, here's how you think about structuring working systems that actually deliver these outcomes.

And we build frameworks and platforms that help guide not only the people, but the agents that are implementing this code to build the working system on the other side. So it gets a little meta kind of quickly, but that's what's happening. And I think broadly speaking, that's what we're seeing across the industry.

The first frontier of this was the labs themselves going out and putting out the frontier models, and the intelligence gets better, and they're also building the models. They're not necessarily sitting in the trenches trying to use them practically day to day. The emerging second frontier is that we are starting to talk to each other about how to build working systems.

We are talking to each other now about how do I use these things practically to solve real problems. How does that then produce both a cultural understanding of what to do, but also new technology that enables us to do it? Do you think the overall quality of the software we're building might also improve?

And I ask the question because I'm not entirely sure how much of the code being generated by these AI tools actually winds up in a production environment because somebody at the end of the day spends an inordinate amount of time reviewing and validating it. Yeah, look, I think ultimately, what's going to happen over time is that we shift to building cohesive systems. Software factories are one way people have talked about that.

But what we really mean when we say that is more and more of the software development lifecycle, that is how we produced working outcomes before, right? So that connection between engineering and product to the outcome, that's a big piece of the puzzle, and that's what we've always done. More and more of that is becoming driven by agents, or driven by an agent in some cases.

And in order for those agents to build reliable outcomes, to actually change your product in a way that is good and the software survives, you wind up encoding much more of the knowledge of what working software looks like for your problem into that factory, right? So, in the first pass of this, we thought about it as augmenting an engineer, right? An engineer uses AI, they augment their existing part of the SDLC, but we're not going to change the product process.

We're not going to change the deployment process. We're not going to think about any of how we do testing differently. We're not going to think about how we express any of those pieces.

We're just going to make the developer go 10,000 times faster. And it turns out that that just is like getting stuck in this tidal zone of massive waves crashing over your head all day. It's too much information, and we can't effectively handle it.

And one response to that is to slow down and do it less. The other response to it is, as an engineer, how do I engineer a system that can produce good outputs at that rate of speed? How do I produce a system that does align those things better to the principles of what the software is I'm trying to build?

And so one of the ways people use Swamp today is to build those software factories that do encode things like, "Hey, make sure that every line of code that gets generated is aligned to my software architecture. Make sure it's accessible to me. Make sure it's accessible to my end users with disabilities.

Make sure that it passes all the black box testing suites that we can build now, that we didn't use to build because they took too long, and they were too slow, but we can build now, that prove the product hasn't regressed. " Mm-hmm. So are we in the process of kind of re-engineering the entire DevOps workflow?

Because to your point, writing of code was only maybe 20% of the entire mission, and the rest of it was trying to figure out how to deploy the code into something that looked like a build, into something that created an application that actually ran. And this is a step in that process? Yeah, I think that's right.

Look, the analogy I use to help people understand where we are is imagine that the water pressure in your house increased by a factor of 10. And what would happen to your house if the water pressure increased by a factor of 10 is your house would explode. It would literally explode.

The water heater would shoot through the roof like a missile, and all of the walls would explode. And that's what happens to your existing process and engineering design if what you do is enable agents to write code that move 10 times faster. That increase in velocity at that size, which is now being used to maybe create another order of magnitude velocity increase, possibly.

We don't know. Who knows? We have no idea where that ends, but we'll figure it out by building.

Requires that the entire rest of the process gets adapted to it, the same way that your house would require being rebuilt in order to deal with the fact that the water pressure is 10 times higher than it was before. And so like, in previous generations, the DevOps process, digital transformation, all of that piece of what we've gone through the cloud, sort of in the last 15, 20 years, this is like that. The difference is that the capability is even more disruptive than I think the drivers of those changes actually were.

A lot of our existing process did survive, and a lot of our existing org structures survived, and a lot of the existing SDLC survived. I think over time, what you're going to see as we learn more as engineers how to harness this new capability and build practical systems that deliver results is that's going to compound. We're going to gain more trust in building those systems.

We're going to gain more understanding as engineers of how to build them. And as we do that, things that right now sound crazy will start to be very reasonable because our risk tolerance will be adjusted because we'll have had better experiences actually building working systems. And we're just at the cusp of being able to really do that en masse right now.

What do you see folks doing today that kind of makes you shake your head a little bit and go, "Folks, maybe we might want to be a little bit smarter than that"? And granted, we are in the early innings of AI still, but I feel like people are developing some bad habits early. Yeah, they are.

Look, I think the number one bad habit is the idea that what you're going to do is solve this problem of how do we build these production-grade automations and how do we build production-grade agents with some combination of skills and MCP. What we're doing essentially when we do that is we're just writing the most expensive for loops that have ever existed. If you go read the skill files that we write that describe the interactions, or you look at the way that we're asking the system to do it, we're essentially asking it to rediscover from first principles the entirety of what needs to happen every single time, over and over and over and over again.

And that is incredibly wasteful, both in terms of wall clock time and in terms of tokens. And it turns out to not be very good at aligning it in the end. And so instead, the folks who have figured this out already have already started pulling less and less information out of skills.

They started building custom harnesses. They've started figuring out how are they going to encode more of that information. And what they're doing when they do that is catching up to what we have already done in Swamp.

Right? They're catching up to the idea that, hey, there's this set of primitives that you need to be able to pass into the agent and say, "Hey, here's how you're going to break software down. Here's how you're going to compose it together.

Here's how it's going to write data that gets stored in a large data lake, and you can query it over time. " And so I think the number one bad behavior that's happening right now is just that reliance on the idea that it's a god machine, and that we're going to just toss all the workload at it, and we're going to write it in a markdown file, and that what's going to pop out the other side of that is everything that we need, because it doesn't actually work. And as an industry, I think it's incumbent on us to separate the fact that those initial experiments of how should we do this work and how will it be structured, I'm glad that those experiments happened.

They're key elements. It's not like you're never going to write a skill again, but we're just learning how to put those systems together, and we have to be really willing to put them together in new and interesting ways if they solve our problems better. So does this kind of explain this conundrum that people are running into where they are clearly developing more code than ever, but they're not actually shipping applications any faster because it's all lost in this loop that seems to be going nowhere at the moment?

Yeah, you got it exactly right. Right? Not everyone is stuck in that loop.

And if you look at the people who have gotten out of that loop, it's because more and more, what they have done is they have figured out how to build these machines that build the machine. Instead of working on the direct software and trying to figure out, how do I use AI to accelerate my existing process and the existing thing, instead they're thinking about, how do I shift to a world where we're using AI to solve these practical problems, and how do I show that system working, and then how do I refactor that? How do I work on that loop?

And once you start working on that piece of the puzzle, that's the thing that unlocks shipping more of the application instead of just thinking about, how do I ship more code, right? Because all the rest of that cycle has to be a part of what it is that you do. And we see that happen all the time with people who use Swamp in their engineering processes directly, but sort of more interestingly to me, in really painful business processes that you wouldn't have thought to automate before because the cost was too high or because the difficulty was too big.

Or because the organization was resistant, that suddenly become really possible, where you can make really dramatic changes in the day-to-day lives of the people who we work with and who our end customers are. Because you can just build systems for them now that dramatically improve their day-to-day. And so for as much as there's an impact on software developers, and there absolutely is, that impact on the rest of the business, I think, is even more dramatic because our ability to solve those problems now by using these tools and using these techniques in this way just unlocks this massive amount of value that otherwise you could never get to.

Mm. You and I have been around the block a few times, and I think we're old enough to remember when $7 million was considered a lot of money. But what is the plan for the future for you guys?

Where do you go from here? Yeah. I think look, $7 million still feels like a lot of money to me.

I can tell you for sure if you don't have $7 million to build something, and then you do have $7 million to build something, that's a lot of money. It does feel pretty different. I think our plan is really straightforward.

We are some of the best people in the world at thinking about solving these kinds of problems. We've been solving them for years. This is the world we come from, and we're incredibly excited by the capabilities that this generation of AI has unlocked.

" It also unlocks the conversation with us as engineers, as practitioners, that says, "How do we learn together how to build these systems in ways that are reliable, auditable, deployable in production? " And I think that money goes directly to that problem. And some of it's technical of like, we're going to hire engineers and do that part of the work.

But a lot of it is just really hyper-accelerating that feedback loop between our already incredible community of people who use Swamp every day, to solve really practical problems, and then just adding more and more people into that conversation so that as a group, we learn together, how do we structure these systems? What are the primitives that are missing? Let's add those primitives.

Let's put those things together. Let's figure out how to build these working systems, and then let's teach each other what that process really looks like and how to thrive. Because in the end, those individual engineers who are working in those enterprises, who are working in small businesses, who are working in startups, they're the ones who have to figure out how to use this technology to solve practical problems.

And once we do that, that's how it becomes a movement that changes how industries work. It doesn't ever happen the other way. People love to think that it does because it would be so enticing to just be like someone comes down and they have the answer, and then everybody connects.

But the truth is that we're going to use that money to help those communities come together. They're going to use Swamp, and then that's going to produce the outcomes they're looking for in their org. In the absence of a platform like Swamp, are we in danger of maybe having some sort of backlash against AI because somebody's going to start asking questions about ROI soon, and the math's not going to come up right.

Yeah. That's the thing I'm most nervous about, to be honest. Right?

I think it's entirely in our power at this point to have the ROI come up aces. I think it's entirely possible to build systems where the ROI absolutely delivers. I think doing that without Swamp is very, very difficult.

And I think the pace with which the industry figures this out and settles in to building these practical systems that look like and are built with Swamp is actually the thing that's going to keep us from some disaster. And if we don't figure that out as engineers, and we don't figure out how to build these systems and work together to solve these problems, I think we're at real danger of having this incredible miracle of a technology also sort of fail to land its practical application fast enough to sort of keep all the plates spinning in the air. Mm.

I also kind of feel like with AI, we're having a bit of a Groundhog's kind of day because every time we invent some new innovation, we use it to do what we've always done before slightly faster, and it takes us a little while to wrap our heads around how to do something entirely different with it. Mm-hmm. Are we having the same experience here?

Is this déjà vu all over again? I mean, it's always déjà vu all over again at first, right? So like, a good example here was that somebody basically cloned the Adobe Creative Suite, and released it here recently, right?

Which is amazing. If you've used those tools, they're incredible tools, right? I'm sure Adobe's not thrilled about somebody just sort of feature-line cloning it.

And I would say that right now, that feels amazing to everybody. " That's cool. It's also not very interesting because we already know those tools are great.

What it did was clone the tool we already had, and gave it to us in a different shape or a different vector. More interesting, I think, is how do we rethink what's possible now that we have this new capability? " And now we're moving into this practical zone where it's like, okay, it doesn't fix everything.

Sometimes it's not the right tool, but when it's the right tool, it's transformative. And so if we're using it that way, what are the things we can build? How does the user experience change?

How does the operating system change? How does the networking stack change? How does the graphics composition stack change?

How does visual editing change? How does podcasting change? I think there's lots and lots of options for how all of those things could be structurally very different.

We see that in the rise of personalized applications, where my business partner, we've been charting around the same spreadsheet to do financial projections for decades. And we've replaced it with an application we built to do custom financial projections that he's now extended because it has its own embedded factory with Swamp to do actuals. And he's reaching out to NetSuite, and he's reaching out to our CRM, and he's pulling all that data in and visualizing it the way he wants to, and he's got his own application that he ships and runs.

And that's incredible. That's not a piece of software that you would package up and share, right? That's a piece of software he uses to run our business.

" We know how to put the primitives together as engineers to enable someone like that to serve themselves in adding complex features into a product that solves their problem as a domain expert. I think that's an absolutely wild new frontier that I'm not seeing it just at Swamp, I'm seeing it in other places too. And I think it's the future of how all of this comes together.

All right, folks. You heard it here. Hey, if you're using AI to write code pretty much the same way you always did, slightly faster, you may be missing the point.

Hey, Adam, thanks for being on the show. Thanks for having me, Mike. All right, and back to you guys in the studio.