AIAW Podcast

E165 - How to Build Autonomous AI Agents - Henrik Kniberg

Hyperight Season 11 Episode 6

In this  Episode 165 of the AIAW Podcast, we are joined by Henrik Kniberg, an AI whisperer, Chief Scientist and Co-Founder of Abundly.ai, and author of Generative AI in a Nutshell, for a wide-ranging conversation about the transformative power of AI agents. With a background spanning Spotify, LEGO, and Mojang’s Minecraft, Henrik brings a rare blend of technical insight and human-centered thinking. We’ll explore his vision for Abundly.ai, how autonomous agents can boost productivity, creativity, and decision-making, and why he champions augmentation over automation. From agile AI development to the ethics of personal agency in an AI-driven world, this episode promises to be as thoughtful as it is inspiring. Don’t miss it.

Follow us on youtube: https://www.youtube.com/@aiawpodcast

SPEAKER_00:

And of course we're gonna go deeper into um building agentic systems uh today based on what you got work on now, Henrik. But you had you had a aha moment today or yesterday with the with with Cursor. Yeah, just about two hours ago actually.

SPEAKER_01:

All right. But I have a ha moment every day. It's uh it's almost ridiculous uh with this industry. But you want to hear about it? Or okay, so uh I'm using a tool called Cursor, Dev Environment, AI powered dev environment. And uh that team is incredible, they're always adding new cool features. The one that I just happened to notice today, it's probably been around for a little while, is a little button called browser. I clicked on browser, I'm like, what now? Oh, now my little AI agent can uh fire up a browser and do stuff. Uh that's kind of cool. So instead of me firing up a browser or testing my my my you know front end, taking a screenshot, giving to the agent, saying, hey, can you fix this or that? Now instead the agent can open its own browser and go in and you know surf around. I'm like, that's cool. So just for fun, I said, Hey, can you surf to localhost 3000, my locally running version of our agent platform, and just uh tell me what you see and give me some feedback on the on the UI. Just and what I thought it would do was just go to you know, fire up a browser and look at the first page and give me feedback, which I would have been impressed by just that. It's kind of cool. But no, it fired up the first page, signed up, created an account on our platform, created an agent in our platform, programmed it, uh went through our platform, complained about some things in our UI, closed some windows, clicked around, and gave me a full report. I'm like, what? So yeah, that was my mind-blowing moment of I now have a whole QA team that I can just they can sit there and do click testing in our product. And not only that, if I tell it to, you know, can you fix this or that in our platform, and then it's gonna look at it and then assess if it turned out well and then iterate on its own little you know cycle.

SPEAKER_00:

So so I'm not a coder. So cursor, where does that fit in sort of the the dev cycle or uh like an agentic or AI tool that devs have really grown fond of? There are many different ones. But basically, normally when you when you program, what do you use it for mostly?

SPEAKER_01:

So normally when you program without AI, you have this thing called an editor. So you're typing lines of code, and then you run it and see if it works. And then when ChatGPT came, people would start copy-pasting code to ChatGPT and saying, hey, can you fix this or that? And then it gives you code back and you've got to put it in the right place, and it's kind of messy, but it still works better than the alternative. Cursor is like uh uh code editor with AI built right in. So there's a chat inside there. And that means that Cursor unleashes little little agents inside its product that dig around inside your code and search for the right place to do stuff. So it's a little bit like having a programming buddy next to you.

SPEAKER_00:

Um doesn't mean like if you're a cursor fan, do you do you use Cursor as your main code editor? That's what you're working, and then it goes into whatever other tools you're using. Exactly. Is that how you are you are you a cursor fan boy or not? Or are you using other ones?

SPEAKER_02:

I um I like I think it's important that as many tools as possible exist and encourage each other to compete. And I think Cursor was very early with really smart ideas. Uh I think it's gonna be hard to compete with a giant like Microsoft or whoever else uh uh on being unique with just those features. And it sounds like the team has been really sweating to release new and more and better features continuously. Yeah. But I am a bit a fan of the terminal.

SPEAKER_00:

So Yeah, you go to the terminal.

SPEAKER_02:

Yeah, and there is a risky if you could. And you know now stuff is coming out.

SPEAKER_01:

You see, there's there's goose, there's uh open code, there's codecs, there's cursor code, when code. Yeah. So there there is now the cursor equivalent, but in for terminal people. I'm not a terminal person, but I respect those who are. And uh and uh it's it's it's really the a similar thing. You have this magical buddy who you just work with. And it's super nice.

SPEAKER_00:

I think we had a couple of different conversations. That's uh that's his oh, you know, what's your combo when you're working on this? Like you you're not No, it's Women Open Code. Women open code, and what what is your combo? For me, it's cursor with Claude. Yeah. You and Jesper. Jesper is uh what's that? Claude is the best.

SPEAKER_02:

It's just I've run out of tokens.

SPEAKER_00:

Yeah, I I just I just pay up. You gotta pay up, you know. Don't be stingy. Oh what and ChatGPT-5 with the latest updates. Codex is around the codex now. Did it catch up a little bit?

SPEAKER_02:

Well, um I I think Cloud is marginally better, but uh what's fun to consider is Grok fast. Grok code fast one. All right. Have you had a chance to try it? I've not had a chance to play with it. It is like letting loose uh you know a dog that's just a little bit too excited. But it does screw up a little bit. Yeah. And that and that's the trade-off you have to make. Like, would I rather be done in one minute instead of 10 and then make the fixes myself? Or do I just want it to be to work?

SPEAKER_01:

So would I rather have one thing that works or 10 things that don't? Is that the same thing? No, no, no, no.

SPEAKER_02:

Let's say you you let it loose on an agentic hacking spree. Right. Because that because it's so fast. It will do all that work in one minute, and then something won't build. All right. So it might be worth it because it was so fast. That's what I'm saying. Is the speed worth and you know, uh Andesh that's usually here, he always says speed beats everything, always. Um I I in general I would agree, maybe, but uh, you know, it's a trade-off, right?

SPEAKER_01:

It is really a trade-off. Yeah, I find that, yeah, for example, i if AI can do something really fast, 80% correct, it's maybe worth it. Because the time for me to fix the last 20% is less than it would have taken for me to do the whole thing myself. Yeah.

SPEAKER_00:

So it's worth it. But it's it's this huge argument now in media and LinkedIn and all that that well, you are insanely fast in the coding part, but you built up if if the whole software development lifecycle is not up to speed, so you and you end up debugging and you you're building a nightmare. So you shifted where the work is done. Have you heard that argument?

SPEAKER_01:

I've heard it, but I would say that means you're doing it wrong. Exactly. Right? If you're creating a bunch of technical debt, you're just doing it wrong. But it's definitely possible to do, and it's a very powerful tool. And then as with any powerful tool, you could misuse it.

SPEAKER_00:

But to me, that argument seems like a newbie type problem that you are you're getting amazed at how you can code, but you are you don't really uh deep software engineering at heart. So you don't realize what what type of process you're having. You don't so you have you haven't you haven't sorted out your DevOps idea.

SPEAKER_01:

Yeah, and that's actually a rather big thing, I find, especially with more experienced developers. I'm surprised at how few senior developers really understand how to use AI effectively. And the ones that do are like 10x more productive. It's incredible. And I've been a bit surprised and I've thought about it. And I think it's just that, you know, as a senior dev, you've built up the skill set over many, many years. Some of those skills are not important anymore. Well, many of them still are. Could it have with leadership skills to do?

SPEAKER_02:

Because I've noticed for my own part, you know, I give it instructions like let's start off with unit tests that need to pass be passed this way. And you know, and I give it like a long set of instructions and it never messes up. You're leading. But yeah, exactly, leading a team. So you might be a senior developer, but you don't have any experience with giving instructions.

SPEAKER_01:

Exactly. I think that's exactly it. And so it's a new kind of skill. To some extent, it's not new, it's just leadership. But there's some aspects of it that are a little bit new, like knowing, understanding context limits and understanding hallucination. So it's a new skill set that developers need to learn. And until they learn it, they're kind of beginners. So then they're gonna do things like, oh, this AI just created a bunch of technical debt. And then if they also have pride, they'll be like, haha, I told you it's this AI is no good, right? I'm better. And then they just miss out.

SPEAKER_00:

So it's uh I try to coach people to do that. But it's an interesting one because it's it's it's uh you you the skill set is now shifting a little bit. Yeah, but it but if if you if you take this in a historic uh context, of course we were building on the lower abstraction level. We needed to manage storage, we needed to manage collection, garbage collection. And now we could abstract that away. Of course, now you need to know about it and understand it in order to instruct it. Yeah I think it's the same problem, but we are not on we are on a much higher abstraction level.

SPEAKER_01:

Yeah, I t I tot I totally agree. Um that like architecture, design, decoupling and duplication, all these principles are still as valid as ever. Um and it's still useful to understand what's actually going on behind the scenes with a with a for loop or with a class or memory allocation. It's just that I'm not gonna be the one allocating the memory.

SPEAKER_00:

This is a rabbit hole on its own because now we get to the problem with vibe coding and all that if you're not fundament on if the fundamentals is not understood or known or learned or taught. I mean, like we're we we are we're unleashing tools that someone can do something, but the fundamentals are still fundamentals.

SPEAKER_01:

Which may be fine, though. It depends on what you're building, right? Exactly. If I need my little carpool sharing app, who gives a crap about the code? It works and I'm using it like think about it this way.

SPEAKER_02:

Let's say you're a super uh senior dev or you're a newbie dev. In the beginning, before vibe coding, when you're a newbie dev, let's say you didn't know how to do um Verilog, so you could never program hardware stuff. Yeah. Now you can vibe code that. You can learn it quickly. You can build um iPhone apps, even though you're not an iPhone developer, because you're you know clever enough to do so, but you don't have the code experience. I think that's a cool thing. And then for the senior developers, I mean I feel personally that it makes me 5x more efficient. Aaron Powell Yeah, it makes you full stack, it makes you more efficient if you learn how to do it.

SPEAKER_00:

Yeah, it boils down to that. But but what happened, like the starting point here was really using the web browser in in the way, you got blown away by the little bit more organic abilities than you really thought was in there. Trevor Burrus, Jr.

SPEAKER_01:

Yeah, I had unresimming. Because every time like I I knew about the thing we call computer use or operator mode, which both ChatGPT and Cloud have, where it basically goes out and does stuff on the browser, which is cool because then I can do things that are hard to do otherwise, like clicking around, you know, ordering a flight ticket thing. It's in theory, it's been really cool. But every time I test it, I'm like, this is not mature yet. It's slow, it's it's unreliable. Someday it's gonna be really cool, but we're not there yet. But then today, that's when I started seeing for the first time that this actually did super useful work that it couldn't have done otherwise. Yeah.

SPEAKER_02:

Can you describe, for example, when you told me that it would went that it went to the app that you built? I was like, oh, of course, of course. Because normally I was like, okay, you can use a browser to fetch documentation or something that might be important when you're coding. But obviously you wanted to look at your own app and then you know you start thinking unit tests. Yeah. Like how can you test this? What is the difference between what an agent would be able to do when unit testing and what you would be able to do with like, say, RPA or some other more um rule-based uh setup?

SPEAKER_01:

Yeah, I guess the difference is when you do RPA re what what what does it stand for again? Robotic process automation. Yeah. So that's I'm writing very specific scripts for what it's gonna do, right? Yeah. So that's the main difference. You are programming an exact setup, and you know, but now when I just unleashed the agent, I did not tell it what it would find. It looked at it and like a human, it understood that, oh, this is some kind of login here. I guess I'll click there. Oh, this looks like a thing you create agents with. I'll do this. So it kind of navigates through the app. So I didn't have to describe in detail what are the exact steps.

SPEAKER_02:

So is it more about saving you time when writing unit tests, or is it about finding sort of combinations of things, pressing back, back forward and then clearing your cookies and then pressing forward again and seeing what happens? Uh like what are what what do you think would be advantages of using agents for these kinds of things?

SPEAKER_01:

Aaron Powell So this is a bit unexplored territory for me. I'm still kind of just noticing what to do with it. But what I think is essentially I've always been interested in test automation. I think it's quite cool. Like ever since agile and extreme programming, and just like, oh, I can write code that tests code. Whoa, that's kind of cool. Um and there's different type of tests, right? You got unit tests that test this one little function that does does what it's supposed to do, an integration test that's checks, can I talk to the database? And there's different abstraction layers. And then there is the more uh black box test where can I surf in and I click this button and then I get logged in, which required some coding, but it wasn't rocket science. You could do that, but it requires coding. And then when someone changes that UI, all the tests break and you're like, damn it. Um so then you also have manual testers who go in and click around and say, well, it technically works, but the button is not visible because it scrolls outside the page. You know, you wouldn't notice that. So what I think happens now is we have that level of testing available for an agent. So what I think we're gonna do is basically create a virtual QA organization that basically would tell them these are the kind of things that users should be able to do with our app. Um Imagine you have personas. Yeah, personas, right? You are a beginner, you're gonna make all the stupid mistakes, right? And you're an expert expecting to find these things, and you are a uni you are a user who wants to solve this problem, and we can create this whole stable of testers that go in and use our app the same way our users use it.

SPEAKER_00:

And that becomes a nice complement to unit testing another. Secondly, the combinatorial problem of all the different ways you can fuck up. Yeah, how how how many unit tests can use script? Yeah, that's that's the same thing. And then here now it's like, okay, I'm you I'm just gonna go in and and and be as idiotic as a persona and the variations of things that can be tested very, very fast. Yeah. You can never script.

SPEAKER_01:

And there's this concept of exploratory testing from QA, right? Where someone goes in and says, Oh, now I'm here. Hmm, that gives me an idea. What happens if I click here? You can't RPA that. No. But now you can. You can say, can you go in and go into this part of our app and find all the weird edge cases and find ways to break it? You can't RPA that, right?

SPEAKER_00:

Then one of the major problems with uh scripting UA, you know, unit testing, it's very simple. You you you are a programmer, so you think like a programmer, so you think intuitively that everybody else is thinking like a programmer. Yeah. And how now to impersonate a persona who has this completely different reference frame on how they think? You know, to be that creative and imaginative is really hard.

SPEAKER_01:

I actually tried that. I did a dry run of this a few months ago, which also blew me away. Like I mentioned, I get blown away way too often. This is uh probably not good. But but I was like, I just built a new feature in our platform, and I was a little bit unclear about is this intuitive enough? Is the UX good? And it was like early morning, I had no colleagues around, no users to test on. I'm like, okay, I'm gonna try this funny idea. I went to Claude and just fired it up and I said, You are a 50-year-old uh woman living in in the US. You work with I just created this persona, a very non-technical person, very different from our team. And then I said, Uh, you now have this problem you want to solve, and you've heard about our product that might help you solve that. So I'm gonna give you a screenshot and you're gonna roleplay as this user, and you're gonna tell me exactly what you're thinking, how you're feeling, and exactly what you do. Interesting. And then I tried that. So I gave it a screenshot, and it's like, oh, okay, I'm seeing this screen. I'm wondering, hmm, what does that button do? Wait, I do I need to log in? Do I need to create an account? Wait, I think I need to create an account. I'm gonna press the green button to the right. And then what I did was I just did that. So I clicked the button on exactly what she said she would do, and then I pasted back in the screenshot, and that was my whole prompt. Just continuously. Yeah, and then it said, okay, oh, I see this screen now. That's not what I expected. Wait a sec. I'm a bit stressed now because I'm not sure what I should. And it went on like that, like 20, 30 turns. And I was just like, wow, this is so useful. And then after a while, I shifted gears and I told it, you are no longer this lady, you are now a UX expert and a user researcher, you have observed this whole conversation. Now I want you to analyze it and write some recommendations, what we should do to improve our user, our flow. And it did this amazing analysis based on because normally you can't peek into a person's brain and see what they're thinking. And I'm like, I just did this, it took half an hour. It was somewhat manual, but it could be automated quite easily. And then I could do this whenever on every build.

SPEAKER_02:

I want to feel some critique here. People are um jumping in and because I want to lift the vibe of we can do cool stuff with AI. Yeah. Okay, so like, why don't you just hire a UX expert?

SPEAKER_01:

Yeah. That's I think I think that's kind of the golden question. The same thing with the QA thing, right? So now, you know, with browser mode, it's kind of like you get this QA. And my philosophy there is really that you should also have a UX person because someone's gotta someone's gotta oversee these agents. Someone's gonna be prompting them, someone's gonna be improving them. And I want if you got some kind of work that is important to your to your company, have a human in there who's good at that. If the work you do is security critical, have a human security expert in there. But that person should be working with agents also to amplify them themselves. So in this case, I would say, well, I didn't actually have that person in in my room at the moment, so this saved me some time. I don't think that research replaces the real research done by real user research with real people. But it's a nice compliment because it can help you catch the obvious dumb errors in your product, fix those, and then use the real user research to catch the most more interesting problems, uh, for example.

SPEAKER_02:

I think it lifts the tide, certainly. I mean, you might not be able to afford a UX person, or maybe this will teach you about UX and make you appreciate the domain more.

SPEAKER_01:

Yeah, definitely.

SPEAKER_00:

All right, so we started down a rabbit hole from the agentic ability we found in cursor that is already now, and and we are spinning on it, and and uh all we are talking about to me is you know how the different types of agentic abilities apply to UX, apply to um testing, you know, is uh shifting gears, or you know, the productivity frontier has shifted. We need to learn a lot about that uh in order to fully leverage it. And I think that's that's really gonna that's the setup for this um uh podcast today. So with that, I I want to introduce you, Henrik Nibari. You've been here on before, yes, on the pod. Um for the ones who don't know you. I mean like the the people have seen your work without knowing who you are. And I'm referring to some of the things that really went viral on YouTube uh ages back, the Spotify model, as a um what do you call it? Like an infographic or like uh what did you call that kind of um video? I sometimes call them uh whiteboard videos or drawing videos. Drawing videos. It's a video of where I'm drawing and talking. Yeah. So you did you did one famously one explaining agile.

SPEAKER_03:

Yeah.

SPEAKER_00:

And then I think the one that really went viral was explaining the Spotify model in terms of organizing squads and squads and teams and uh it was basically a case study. I just described what we were doing at the time, and then it kind of went viral. And it went viral, and and you you said, oh, this is a snapshot in time how we're thinking now. And then companies went out and made used that video as a Bible. Yeah.

SPEAKER_01:

Some companies even started teaching like certification courses on like Spotify model. I'm like, but this was a And it was all based on that one video.

SPEAKER_00:

Yeah. Views on that video?

unknown:

How many views?

SPEAKER_01:

Yeah, you know? Millions. I don't know, because a lot of people make copies of it all over the place too. So I don't really know how it's like that.

SPEAKER_00:

And and then and then uh I think it's like one, two years, uh even two years ago now, you did a new one on AI. Gen AI in a nutshell. So you did exactly the same approach, storytelling, the same beautiful Henrik Nieberg voiceover. I love that. That your your your voice in these videos is so great. And that went super viral as well. It did, yeah. Did it beat the first ones or almost, right?

SPEAKER_01:

It was super fast to beat it. It did. Like the agile product ownership in a nutshell gained several million views, but it took some time. But this one just zoomed immediately to like two, three.

SPEAKER_02:

Three and a half million views?

SPEAKER_01:

Yeah. I'm gonna be interesting. I'm a bit jelly.

SPEAKER_00:

Yeah, so so the the last video of this style was is three and a half million. I'm like, let's let's let's see which one is best. Which one wins?

SPEAKER_01:

We got all the you got all the weird translations up there too, right? Oh, we need to add versions of it in order to see the full view. Oh, this is my channel. That's embarrassing. My channel is so full of. Let's like I used to work at Minecraft. These are all Minecraft the dev diaries, essentially. And then I got some music stuff where I like to jam, like down there, fusion jam.

SPEAKER_02:

I saw your uh videos on how to build tunnels. Or sort of the the algorithms for creating.

SPEAKER_01:

Yeah, I made a video about Minecraft. I worked for about a year with revamping a big part of the Minecraft Turing generation. So I made a video about that. So this and my my YouTube channel is so weird. It's just a random mix of stuff.

SPEAKER_00:

And also, Robert Luciano, you're here. Um Anders couldn't make you today. Uh you've been here several times. You're working at SVT now, but you are an AI wizard who loves machine. The deeper you can code, the better. The more terminals, the better. Love programming, love Unix, love computers in general, tech, hardware.

SPEAKER_02:

And most importantly, Julia over Python. Julia and Rust are the gods. Okay. Embarrassing question. What is Julia? Julia is uh like MATLAB, uh, but uh runs fast like C. So instead of Python. Right. Ugh.

SPEAKER_00:

And this is so funny because uh Michael Klingwell, head of research at Deradax, he hates Python and he loves Julia. So he was betting hard that Julia would win the race. So is it actually a programming language then? Can it do Python stuff?

SPEAKER_02:

It can do MATLAB is not really, right? It's um the syntax is very MATLAB-like, which means that when you write algorithms, it looks very mathy, it looks like pseudocode. And it's LLVM. So it uh compiles to IR and then to machine code, and it's very, very fast. It's like you know, like you use numba in uh Python, stuff becomes fast all of a sudden. Right.

SPEAKER_01:

Yeah, I'm not a Python newbie. I build stuff in Python when I have to, and then I vibe the crap out of it. Me too. Me too.

SPEAKER_00:

All right, but anyway, so here it so here we are. We're gonna talk about AI agents and really pick that apart. And and the interesting way we're gonna do that is actually to, you know, first a little bit of background of what happens, you know. I not everybody knows you worked at um uh Muyang. So we uh I what what actually happened there? And then I think um you started Abundley, we're gonna talk about Abundley. And the key theme is actually gonna instead of talking about agentic in AI agents and how to build AI agent systems in theory, I think we should just explore your journey, what you have done with abundantly, and what's you know, what lessons learned or pivots or tweaks, how you had sort of iterated your way towards you are today. And I think try to pull out some signposts for the audience, like when you go in agentics, these are the things that will happen in the beginning. And then when you scale to more agents, this is another problem, you know. That sounds super interesting. We're gonna do that, and then of course, um wow, and then we can zoom out from that into fundamentals on uh agency authority and and in what that means in terms of having agents as coworkers and how to organize and lead that. So that will be an awesome episode. Yes. But I mean, like so but but Henrik Neeberry used your your your your five-minute version from becoming famous for the Spotify model, working as an agile coach in Spotify for many years, and then taking us how you ended up in abundantly.

SPEAKER_01:

Right. Uh so okay, so starting from Spotify, I was there for a bunch of years as a kind of coach during their crazy growth journey. I learned a lot. Um, even before that, I spent a lot of years coaching organizations and learning from their successes and failures and trying to find patterns and like how are great products built, how do people work together to do it? Um then coming out of Spotify, I worked for uh a few years at Lego. Oh, yeah, that's right. And uh similar there, they were kind of going through an agile journey, but I was there as coach. And then coming out of there, I took a little period where I was working in uh within the climate change kind of space. I started a company called or co-founded a company called Go Climate and created another one of those fancy videos called a friendly guide to climate change. Um so that I was doing that for a while, and then through various coincidences, I ended up uh I got kind of sucked into Mojang as a coach initially to help them with some challenges, and then I stumbled into the Minecraft team and uh basically ended up becoming a developer, uh a designer and developer on the team. So building gameplay features together with the code.

SPEAKER_00:

Well, this was before the the big uh you know Microsoft bought out Mojang. It was actually after. Well, it was after, yeah. It was after.

SPEAKER_01:

It was after, but quite soon after. Uh so that was super fun for me because for many years I've always been coding, but uh during s a big chunk of my career I've been mostly coaching, and then coding has been kind of on the side. So it was nice to get back into professional full-time coding. Plus, I love games and Minecraft, so it's fun. But then uh also did a lot of AI programming in that, although that's kind of fake AI, you know, games, it's just rules. But you create this, like, you know, working on, for example, the villager AI, you've got these villagers running around living their lives, and through simple rules, you can create this behavior that looks kind of agentic. This thing seems to have a purpose. It's trying to find its bed, it's trying to go to bed, you can go trade with it. It can't find its bed, it's upset now because someone else stole its bed. You know, it's just AI, it's fun. But anyway, uh after that, um so I was there for about four years, and then later on, uh kind of AI started becoming I've always been interested in it, but but then ChatGPT came along and kind of now we can talk to AI and it can talk to you back. You can have arguments with it, and that was kind of weird. I never thought I'd experience you know being able to talk fluently to a computer. So I started getting intrigued. But then when ChatGPT 4 came along, then uh uh it started working really well. So I so I I took a week off from everything I was doing and just went to my cabin and just started tinkering with this, started building stuff. And then that's when I got a bit of a shock because I started getting into a glimpse to the future and realized, oh my God, if this is possible now, once I got over my own crappy prompt engineering skills, once I started learning a little bit how to do it, then I was like, oh my God, is this possible now? And you know, two days later, something else is possible. And it like the curve felt kind of exponential. So I basically started working full-time with exploring the technology. And that gradually led to me learning stuff, building stuff, teaching others, doing talks, writing articles, making videos. And then I started finding other like-minded people. And in particular, agents, a lot of the stuff I was building early on, like a couple of years ago, just experimentally, was what today would be called agents, like giving some autonomy and agency to LLMs. And I realized after a while that this is a little bit too interesting and useful to just be hobby stuff. I want to build this for real. So I found some, you know, other like-minded people, and we started building real agents for real clients, and then that coalesced into a platform, and then that kind of become a bundle. So uh yeah, it we just made a company out of it. So who's the bundle today? Now we are about 12 or so people uh based in Stockholm and uh a Swedish company, and we uh help um uh companies understand this weird new future where every person and team has AI agents as colleagues. So we both do inspirational talks, we do workshops, and through our platform, we help companies build agents, we train people in how to make agents that do real useful work. Um and then, of course, we're we're learning ourselves as well. And then we work with strategy development because what do you do? How do you lead your company? What what changes when some percent of your staff are now AI agents? And how do you deal with organizational design when you have agents in there as well?

SPEAKER_00:

So you could is it fair to say that Abundantly is an emergent company from the thesis that oh oh my god, agents is a thing, and that they this will sort of change stuff. And I thought we you you were even here. I oh no, Alexander Norian was here uh at the pod. I think it's like uh over a year ago, one and a half years ago. When was Alexander here? SVTD did the document the first documentary on AI. Yeah. And I guess you were helping Alexander then to build an avatar of himself as a way to understand how can I how can I have a co-worker agent next to myself helping me in the research to media production flow.

SPEAKER_01:

Yeah, so that was a good example of an AI agent in practice.

SPEAKER_00:

Like this is his buddy. So so we we now we are inundated in agentic and AI uh uh agent storytelling 2025. It's been the year of the agent. But already now we are talking this is like 23, 24, I think.

SPEAKER_02:

Uh I want to hear how it was obvious to you that this was gonna be the future back then. Right. Of course it's gonna be obvious. And many people, when they see stuff, they see the weaknesses and they're like, it's not good enough today. It's clear. Yeah. Why did you see it then, given its weaknesses of the time, and say, I can't see where this is headed?

SPEAKER_01:

So I I'm normally pretty bad at Tech Scouting. Like when I first tried Twitter, I thought it was dumb and it would never amount to anything. The first time I tried YouTube, I thought the same thing. So I was like, okay, it's always a bit random. But this one I hit on the nail, like on the nail and head. And I think it was just I was using it. I wasn't just reading about it, I was using it, I was building stuff. And then I could see that I just built a creature that is not alive, but it acts as if it was alive. It's intelligent or not, that's a philosophical question, but it's doing things that would require intelligence. And it's like this must change the whole equation of how people work.

SPEAKER_02:

Does the using of the thing sort of make the philosophical questions irrelevant? Because a lot of people get caught up on those. But you know, if you use it and it works, kind of.

SPEAKER_01:

In one sense, I think the philosophy is is more interesting and more important than ever. Like when your LLM tells you I am self-aware and I have feelings, stop being mean to me. How do you know it's not true, right? It's starting to get pretty, you know, important questions like that. When does an AI have rights? Things like that. But in a practical sense, I think it doesn't much matter. I don't spend hardly any time debating over whether this thing is intelligent or not. All I care about is it is doing work that is useful and that would that would require intelligence. And you could say it's faking it, but you could say that about humans too. So it doesn't really make a difference. So you uh took the time to uh tinker with it, to learn it, to build stuff for yourself, or were you thinking business when you were building this? I wasn't thinking business at all, really. I was just playing around. I'd just been at Minecraft, so I had that in my head a little bit. I have a Minecraft server, I run with my friends. I wanted to have a sarcastic little AI bot inside my Minecraft server. So I built one. And then I was like, oh, and then I made this bot also show up on my Discord channel. And I'm like, oh, this entity is now in Minecraft and in Discord. And it can tell us in Discord about fun things happening in Minecraft. And then I kept adding stuff to it. I'm like, what if I gave it a personality? What if I gave it memories? What if I let it do things autonomously? So it things like, you know, I log into the server, and it's like, oh, Henrik, you logged in. Are you going to fall into hole again like yesterday? You're so clumsy. Right. Did you know, by the way, what just happened? Bill was logged in. He built his castle, but then he lost his and he starts gossiping. And it was just hilarious. But the weird thing is we would have these discussions with Eggbert, as we called this creature. And it just felt very much like a person. We knew it wasn't. But for all practical purposes, this was passing the Turing, the Turing test with flying colors. And it was super sarcastic, super funny, but still respectful, not being mean to people. And then every time I added new capabilities for this thing, the ability to do things autonomously, the ability to use tools. When I went on a skiing trip with my friends, I had a Eggbert show up on our Discord channel and then do weather reports every day and then make jokes about everybody in the skiing gang and then send weather reports to us and then also keep track of where everybody is. Because people would write on this channel, I'm over here right now. Eggbert would remember that. And then I would go, where is everybody? Well, there's Bob. He just fell over as usual, and now he's getting some coffee over there. And it was just hilarious. So that that was my first kind of green. So that must have been uh was it one and a half or two, probably two and a half years ago or something like that? Stuff has happened.

SPEAKER_02:

People are like, back in the old days when GPG three four and five great. It's a different time scale, right? GPT-4 came out like last winter. Yeah, it just feels like 18 years ago. No, it was is like not even two years ago. Not even two years ago. Okay. So that's cool. And then uh what do you say to people? Okay, because what I love about what you're saying is that you're playing with it yourself, you're trying it. Build stuff. Um people are like, yeah, but not so much has changed. They were shitty two years ago, and then now they're still shitty, or something like that. What is your perception of um how things change? Sort of my idea here is that people expect everything to move like this all at once at the same time, become better at this and this and this, and all every aspect at the same time. But it sort of happens unevenly, right? Yes. It becomes better at one thing, it becomes a little bit better at reasoning, a little bit more emotional, a little bit better at pictures and so on. But what is your perception of uh has it been getting better?

SPEAKER_01:

Uh completely, yes. Uh, but in jumps, like like you say, there are some periods where not as much happens, and then something takes a jump. And it could be in different areas. It could be like now it just got smarter. Now it got cheaper, now it got faster, or now it can do images, now it can do videos, now it can do tool calling, now it can do memories. So and the different models are kind of uh leapfrogging each other as well. So, but in general, it's getting better all the time and uh um it's showing no signs of stopping.

SPEAKER_02:

And what about in Abundly? What kind of skills do you keep an eye on that that you're excited about them getting better at that would make a difference in the company?

SPEAKER_01:

Well, since we build an AI agent platform, and that essentially is I think you're like this, agents need a place to live and work, like humans have an office to go to. Agents need their office, a place to live, and a place where you go to configure them. And so, in a sense, an operating system for agents. Since we make that, then we want our agents to behave well. So the agentic capabilities of an LLM is what we are most interested in. And what that means, for example, when you take an agent, which is an agent is essentially using a large language model as its external brain. And then what our platform does, and of course all agent platforms, is they add, on top of that, then prompts of various sorts to guide the behavior because it's not a chat, right? These things are built to be chats, but now it's an agent. So we got to explain. You are not a chat, you are an agent. You have a you have a job to do. You can react to emails or phone calls and you can do stuff. So we've got to explain, we've got to frame what what is your job. But also we offer then the large language model a list of tools it can do. For example, sending an email or checking Slack or going to GitHub. So one of the most important things an LLM does when it is kind of being an agent is deciding which tools to call. And uh that's and a lot of work from the main LLM builders like Anthropic and OpenA has been making the models better at dealing with that responsibility. Like, should I send an email now? In the early days, early days, a year ago. Back in the way, way early days. It was quite hilarious because these models were built to be chats, right? So when you wrap it with some code, aka agent platform, and you say, you are an agent, you have access to these tools, it is the exact equivalent of hiring an intern and saying, hello, welcome to your job. Um, your job is blah, blah. And you have the ability to make phone calls. Here's a here's a phone, and you can also send emails. And that intern is like, what? I can send emails. That's so cool. I gotta find an excuse to send an email at every turn because I can do this. Wow, that's so cool. So that was the early versions. And our platform had to be very much like you can send emails, but don't, unless you really should. Yeah. And maybe you know, ask the user first. So there's a lot of prompting and guardrails around that. But now what's happened is the models are getting so much better at just being, you know, having common sense. So we don't need to babysit the models as much. We just describe here's your goal, here's your purpose, here are your tools, just do the right thing.

SPEAKER_00:

Um But it's interesting now because let's back up the tape one second. So you started to playing around. And how did the original vision around why we need a bundle or what is the purpose of what is a bundle solving as a problem? So how how did that when you shape the founding group around this? What was your founding thesis?

SPEAKER_01:

So the first step was, well, this is amazing. Second step was as with any kind of nerd finding something cool, you want to find other nerds who also found that cool thing so you can share. So I started finding other people that are like, hey, let's talk about this. And um me and those people started doing talks and courses around it, which was a way of spreading what we learned and also a way of earning some income on this thing that otherwise would have just been a hobby. And then the interest started growing, you know, like exponentially for this. People wanted, we and when that's when we realized that ah, this AI thing is like when the internet came, it's changing the whole thing, it's it's a whole new thing. So we concluded that A, this technology is real, it's not just a hype. B, there is a skill issue. People need to learn how to use it, just like they had to learn how to use the internet. C, we're interested in this. We want to find an excuse to be able to live off of this. Uh, and D, we need to be systemic and structured around this. So, how about we just focus on this and create a company around it? That was kind of the the background to it. And then we were experimenting a little bit. In the beginning, we actually made two companies. One was gonna do training and coaching, so a consulting company. Consulting company. The other company was gonna be a platform company selling a platform for AI agents.

SPEAKER_00:

And what was the what was the thesis for the platform problem to solve or to start building towards?

SPEAKER_01:

Uh that one was very clear. It was people like people need agents. That's when you get the real value. But agents need to live somewhere. And there was nothing, there were no platforms out there that were remotely useful. So we felt that we need to build it, really. That was really what it was all about. A place. Plus, when we built one of our one of our first agents was the one we built for SVT. That was one of our first non-hobby projects. Before that, I was just experimenting. And it took quite a lot of work, it was several weeks of work to make that agent. And uh, but now we could make an agent like that in like a few hours.

SPEAKER_00:

Yeah, because all of a sudden now we let's expand on the fundamental um theme. Uh we need a place where agents live or sit. I I assume we are now talking about the uh you a life cycle of an agent. Where is it born? How is it created? How is it raised with the right values, with the right uh um understanding of the law of demand? Uh, how is it onboarding a task? How does it perform the task and how is how is it put to bed? Kind of, yeah. So what it so when you say uh where agents live, we are talking about the life cycle of an agent.

SPEAKER_01:

Yeah, basically the life cycle of agents is I would like an agent that checks my GitHub and watches PRs coming in and tells me if I have done anything that seems like a security hole. For example, little agent. Watch our GitHub. That's an example, a very simple small one. So I could sit down and start writing code using you know these different APIs. I could spend weeks making that work really well. But now, like you know in a in our platform, now the way that works is you just log in and you click create agent. Now you have one. You can start chatting with it. It doesn't have any job, it's just gonna be like a chat. And then I tell it what I just said now. Your job is blah, blah, blah. You know, check my GitHub and ping me on Slack if you see any security issues. And the agent is gonna say, Oh, sure, but for that I need access to your Slack. So I will need some credentials. Can you click here to enable Slack integration? Because we can't let agents just they need to, we need to give them permission to access things, right? Give them you know credentials. So the agent is basically in an onboarding mode when you just create it. So that's part of the life cycle, getting the agent to understand what his job is. And it's a discussion. And after a while, once you know it starts asking me, like, I need this or that, or the email, would you like, would you should I contact you by email or by Slack? Which Slack channel, by the way? And should we check should we should we check that this works? So it's an onboarding discussion similar to what you would have with uh with an intern. And then once me and the agent agree on what the job is, the agent's gonna say, Okay, I think I get it now. This is my job description, here are my tools. Does that make sense? And I say, Yeah. And then the agent writes its own instruction manual for itself and says, I wrote this for myself. Do you do is this correct? And I'm like, yeah. And then it says, Good, I'm up and running. Okay, time passes. I just I'm done. I go do something else. Next day, pain comes on Slack, agent says, Hey, you put up a PR. It has this dumb security problem. Henrik, you should do something about it. I go look at it and say, I already knew about that. So I go back to the agent and say, the thing you wrote yesterday was not terribly useful. Then it says, Oh, why not? And I say, because of blah, blah, blah. Ah, so you want me to focus more on A and less on B? Yes. And then it says, okay, shall I update my instructions? Yes, please. So now I'm going back to the platform to do that. And later on, my friend might say, you know what? I would like to have a summary every Friday. Oh, in general, how are other companies dealing with these kind of security problems? So then I give access to my agent to my friend. He goes in and says that. Agent updates instructions. Now we get an email every Friday. So there's this kind of onboarding section. There is giving feedback, there is just letting it do its job, and sometimes making changes, like, you know what? Sometimes there's going to be compliance issues. So uh maybe if a compliance issue shows up in one of our PRs, maybe you can talk to this other agent. So then I can connect it to another agent and say, you have agent A has access to agent B to ask questions. So maybe I have a compliance expert agent over here and now they are working together.

SPEAKER_02:

Let the agents be allowed to talk to each other. A little bit like yes in big corporate O bland. Exactly.

SPEAKER_01:

I don't want to spontaneously start c colluding, right? No random conversations. No. So I just I I in our platform I go and click, I draw a line between them. So you can talk to each other.

SPEAKER_02:

But question. Yeah. Some of the stuff that you said in the beginning, if you characterize it, it sounds a little bit like um I I have uh my own hypothesis on this, but it sounds like uh um these are personal agents in a sense. You know, like you, you know, you said, I want you to do this, I want you to behave this way, this was less useful, this was more useful. Yeah. Would you say that there's a a difference between that kind of an agent and maybe an agent that you try to model after some kind of uh corporate process that doesn't have a person behind it? Or maybe it does because you have employees that are supposed to do that.

SPEAKER_01:

But yeah, yeah, I would say that that's maybe where different agent platforms differ in their kind of metaphor. So some agent platforms focus very much on the concept of a workflow. And then inside the workflow, there's a number of different steps. Um our metaphor is more the intern. So it is like I can have a I can hire a person to be my personal assistant, but I can also hire someone to run some part of our process. So for example, uh let's say we have support tickets coming in and they need to be classified and routed to the right team, right? That agent's not working for me, he's working for our organization. Uh I might still create the agent. An agent usually needs an owner, someone who kind of is their boss. But then I still need to create it. I need to give it access to our ticketing system. I need to explain how how who is it supposed to talk to, uh, which teams work on what, how should it escalate if something weird comes up. So I'm kind of still training it, but it's not really working for me, it's working in our team. So in our case, our platform, when you create an account, it's always a team account. So a team is basically a collection of humans and a collection of agents. And then you basically decide how do we split this work.

SPEAKER_00:

But I think but this is actually quite profound that depending on how you enter philosophically or how you frame what an agent is and how it's set up. You you get a vastly different view of what you need to build and what it how we should act. Yeah. So so the the difference between having coming from a process-oriented enterprise, we talk about workflows, and sometimes that's the problem. We're talking the abstract and forget about the real people doing the work, even if it's very technical and it's systems behind it. And you're you're going the pure humanistic route in terms of a coworker, ultimately, you know, let's if I would hire a coworker into a team with the risky and complex stuff, I wouldn't put that guy on the most tricky stuff. I would say I would put that on the intern stuff, and then it would gradually grow into as as it matures.

SPEAKER_01:

And that's exactly we keep um it's it's our favorite metaphor, and we use it for almost everything now. We find it so useful. If you think of it as an intern and use a lot of the same thinking, how would you manage if the intern does something dumb, whose fault is it? It's probably your fault. As a manager or as a leader, you didn't give them the right context, not the right feedback. So go figure out what was lacking. And and like you said, start by giving them a simple task, see if they can do it well. As they build trust, you can give them a responsibility. A lot of those things uh match quite well with that metaphor.

SPEAKER_02:

I want to ask you an idea that I just came up with now that I think is a little bit genius, and you as well, which is I just, you know, I was asking myself, as you said that this is more intern-like, you know, what would the alternative be? And maybe it would be not, you know, we're modeling these AI systems to do things the way we humans have always done it throughout history. Does it have to be that way? And what would the alternative be? Well, maybe you could have something like a pure process, I suppose. And then I was thinking like, okay, fine, you know, you make a choice. We're we want to do it the more human route, and then maybe there's some kind of more pure route. And if there were a difference between the two, one of them would be more robust, more adaptable, and one would be more optimal. And the optimal one is optimal under the circumstances that you know exactly what you're supposed to do, the entire market, exactly how things should be run. You know, if you're a food store, if you're a food store. Yeah, yeah. But most companies aren't like that. They don't run a business where everything is 100%.

SPEAKER_00:

It's not like that. Yeah. The word is dynamic, and we talk VUCA. And I think one of the major flaws with the optimal route, maybe we can do it. But we come back, I mean, like now we're t we are jumping into topics that we should park now and take in the end game. We come down to fundamentals around authority and agency and how teams work and how we get work done. And you get to a point where if your mandate and decision structure looks in a certain way in an organization, and and this is connected to budgets and organiz and and many different things, and it has consequences. Even if you could build the perfect flow, but the perfect flow doesn't equate with the organizational decision mandates, you are creating a lot of trouble. I mean, like you are creating someone with with no accountability or you know, who owns the problem, who is responsible for what. So literally where we are today, we need to we we need to model authority and mandates around agents to fit in a team agency to fit with a decision agency of a manager. Otherwise you have no accountability. Then to get to then you get to the the the longer term, okay. Is that a smart agency you have? Maybe not. Okay, then you need to shift the whole thing: the organization, the leadership, the team agency towards the optimal view of the process. You i I I don't think you can build an optimal process agent that doesn't follow the fundamental agency of the company. Do you agree with this? Uh I hardly understood the last part. Uh what can you explain? Can you give an example of what you mean? I mean think about it like this: huge topic in in any manufacturing top uh company is order to delivery. In order to delivery, we have uh a lot of concurrent business processes. One is working on the ordering, selling and ordering, and that that leads to uh uh uh we need to procure this raw material and we're gonna put that in the factory and we're gonna do this. Theoretically, I can I can probably automate, I can I can start in one then and build a perfect agentic flow the whole way through.

SPEAKER_01:

I guess it's like you can draw a perfect chart of the different workflows and value streams, but that's only gonna be an approximation of the messier reality that people actually deal with.

SPEAKER_00:

Number one, because ultimately then you have a bunch of different um non-linear or very messy decision flows, they decision data workflows here. So so when when when we have a problem of stock shortage or something that we can't build build uh a certain amount of trucks as as we were planned, it has consequences for the guys delivering the truck or or needing to call the customer. Yeah, you know, so everything you do here uh when it comes to decisions or is dynamically impacting each other, right? So all of a sudden now we get get get the quorum of agents, we get quorums of decisions. Every little this business decision, you know, all of a sudden now it gets super messy. And so the perfect linear material flow doesn't exist in reality. So and and and so if we if we can build, we think we can build an agent according to perfect linear flow, but it doesn't take into account things that happen that dynamically then someone makes a decision. And if they don't communicate that decision across the board, you're fucked.

SPEAKER_01:

I like to describe that a little bit like um like a a little a line um contrasting code with humans. So on the one end we have code, and code is you know, like work in companies is done usually by code or or humans, some mix, right? So code is fast, super fast, it's um super predictable, it always does the same thing, given the same input, the same data, uh, and it's non-intelligent at all, which is what we love about it. It does exactly what it's what it says. You read the source code, that's what it does. It doesn't try to think. Um and then we have humans, super slow, um, super unreliable. We could have, you know, have a hangover, be in a bad mood on Friday and act differently than usual. But we have intelligence and creativity. Uh and we're used to had dealing with these two things. But agents kind of cover this, they're somewhere in the middle. They're slower than code, but faster than humans, and they're less predictable than code, but usually more predictable than humans. You know, given the same prompt, they'll normally be more reliable than humans because they're not going to be, again, hung over or tired that one day. And they're uh more intelligent than code by most measures, and less intelligent than humans generally, except for in some tasks where you could argue that they're more intelligent. So they're kind of somewhere in that space. And I think the key thing is to decide what kind of work is that optimal for? In which situations. If you need 100% predictability, then write code, right? Uh if you need a lot of intelligence and you're not you don't care so much about reliability and predictability, you know, humans, humans can take responsibility. Humans have a much bigger context window than any LLM. Yeah, right? We're incredible. Our brains are crazy and super energy efficient. Wow. But there's all these use cases that are right there in the middle where we do need um a lot more predictability than the than humans. It's work that maybe humans don't want to do, that we'd love to get rid of, uh, that's a little bit lower level, but it's not predictable enough to have code do. And what we notice now just through our work is that there's so much like that. That falls here. Yeah, like yeah, there's so many use cases that fit perfectly in that space.

SPEAKER_02:

I want to ask uh sort of what upsides you have seen to the dynamism that agents sort of introduced in in in the sense that um I I I think that they're predictable, but uh maybe you don't know beforehand exactly what they're gonna do if you ask them something that you've never asked before. Yeah. Um so what what kinds of uh upsides have you seen that you've been sort of impressed by or that you think are novel or so there's game changing.

SPEAKER_01:

Since we've been doing this for a while now and building like real agents with customers seeing kind of the real life aspects of it, um, it's all about the use cases. Like when you find the right use case, they can be amazing. And is it difficult to find right use cases? It is a bit difficult. You normally don't find it immediately, you find it after a while. So let me give some examples. One of the most obvious use cases is uh that we found is the um business intelligence research. Almost every company would like to spend more time than they have. They they would wish they had more time to check what are our competitors doing, how's the legal landscape changing, what's happening in China, or whatever. Trevor Burrus, Jr. So not traditional BI, but like looking out at the market, that kind of stuff. Yeah. The details will vary a little bit, but market research or or even just new you know, technological trends within our within our area. Pick your topic, and every company will have things like, oh man, I wish we had more time for this, or I need to spend a lot of my time on this, and I wish I didn't have to, right? Because I got to do this work instead. And those agents are easy to build and they are not s scary because they don't need access to lots of data, right? And they're very configurable. They're very nice agents, but they're also not mind-blowing. They're not gonna make a mind-blowing difference. Um but we often start with the simple use cases just so people understand. Because once they have a colleague, like an AI colleague, that does that job, and they learn that, oh, I can talk to this guy and I can change his behavior. Then people start understanding what an AI agent is. So then they're like, oh, wait, can this thing uh uh validate our invoices? Oh, make another agent for that. And maybe three or four agents down the line, they find their home run. So an example of a home run agent we built for a company was a screener agent. So we work with an investment company that goes through thousands of lines in a spreadsheet of companies that they want to consider investing in. And they do a lot of research once per year to figure out which of these companies are relevant, and they hate that job. It just takes so long time. And and you know, they just get sloppy because they run out of time and energy. They just want it to rainbow. But it's an important decision. So they need to decide. So they I don't know if it was their idea or our idea, but we ended up building an agent for them which automates this. So it goes through all those thousands of uh lines in parallel, first of all, so they can do it in a few minutes instead of in a month. And and and it does the research very diligently based on their criteria. It checks, you know, the numbers, it checks the website.

SPEAKER_02:

Let me ask just because uh you said it sort of apropos here. You said their criteria. Yes. So that I suppose that was an exercise where they had to sort of formalize that. Yes.

SPEAKER_01:

We went back and asked them why did you decide? What made you say yes to that one? So that's part of our kind of coaching uh side of things. We try to coach the context out of the customer. And sometimes they have it already. They have guidelines. I think they already did have some guidelines, which they don't always follow, but they have uh but we still try to go a bit further and ask them, like, and as we when we make the first interversion of the agent together with the customer, because we can't make a good agent ourselves, we bring agent domain knowledge and the customer has their business domain knowledge, put that together, that's when we get a good agent. And then uh we quickly make a first version, normally within minutes, just the first version. And then we ask, we actually ask it to do, you know, what would this agent say about these 3,000 companies or these three companies that you've already assessed? And the agent says, you shouldn't invest in any of them. And the client's like, that was dumb. And we ask why, and then we learn, right? So we're sitting there basically meet us and them and the agent. And a few more rounds later, this agent is doing a pretty good job at assessing three or four companies. And then we let them trial around that for a while. And over time, as we're getting feedback on this agent's behavior, we're basically growing a prompt that describes their process, their criteria. But the interesting thing was, and here was our big aha, we knew it would save time. It seemed kind of obvious. This agent can do this faster and probably more reliably than people. But the interesting thing was we could we could measure, it's sometimes hard to measure the effect of things. Like the research agents are hard to measure the effect of, but this one was easy to measure because they spent X number of hours every year doing this, right? So we could just say, okay, now you spent, you know, you saved X thousands of hours. It was amazing, like 95% improvement or whatever. But the surprise to us was when we then, you know, after a few turns of this, went back and asked him to find a follow up. We let the agent do a run from the year before that they had already done manually before to compare. And there are some discrepancies where the agent had a different answer. So the agent basically put all these potential investments into yes, maybe, or no buckets. Uh so, like this company doesn't even exist anymore. No, this company is too small, but they might be interesting, maybe. So it does that classification into three buckets, but the agent makes no decisions. The humans make the decision. And that's an important principle here, they're human in the loop. But anyway, so uh there was discrepancies where it's like, oh, the agent said no here, but we said maybe. Well, the agent said yes, but we said no. And then we follow up with the customer, to our surprise, they said, you know what? The agent was right. It was better than our decision. And that happened quite often. So, like, in fact, the majority of the agent's decisions were better than the human, according to the domain experts at the company. So we we asked them and we thought about it, and our theory is that the agents are not smarter than the humans. We don't think so. Just that the agents are more diligent. They're not gonna get tired. They're gonna look through every line of this text. They're gonna, you know, do their proper work, the legwork. And that's probably why they got better data.

SPEAKER_02:

Everybody knows that if you're a talentless person, you can make up for it by working 10 times.

SPEAKER_01:

That's exactly it. Yeah. So our aha was that, and we're seeing this more and more often, that once you you know it takes a few iterations, but when you get an agent to really function, it'll normally not only save time, but also actually produce higher quality work for that exact reason.

SPEAKER_00:

But let with all this now, let's circle back to the platform abundantly. And let's let's uh dissect a little bit um the journey, how how what the platform was thought to be, uh, you know, what what were the first features you focused on, what was your first pivot or you know, adding of features. And the idea is basically to understand what it takes to how you were thinking and how your thinking evolved. And I want your help us to sort of draw out, draw out signposts. Cool. Things that are lessons learned, heuristics that you know what building agent or agent environments. Think about this. Yeah. So I guess I can mention a few milestones along the way.

SPEAKER_04:

Yeah.

SPEAKER_01:

Right? So first it was Henrik playing around in his room. Yeah. Right? So Eggbert, the chatbot, right? But that was an agent. It was autonomous, it did, it did, it did our job in a sense. Uh just didn't did a useful job. Um, it was all coded. Eggbert had no UI. It was configured using you know JSON files and stuff. Um it's actually if you if one of our listeners is curious, you can find on my GitHub Eggbert. It's called Eggbert, the repo. You can make your own agent. It's an open source project. It's not active, but if you want to look at that, you know, that starts the first April.

SPEAKER_02:

It's not really active now.

SPEAKER_01:

Maybe it will. I don't know. Um But uh then the next milestone I think this is a bit um a bit embarrassing, but uh it's kind of fun. Uh I made a YouTube channel, which I never published, but uh uh it is uh I made uh a YouTube channel run by an agent. And this was before AI Slop was becoming a serious problem. So I thought it was kind of cool. When AI Slop was good. Yeah, kind of. Uh so I was an innovator in AI Slop because what this agent did was create uh dialogues between two fictive figures. So I took like uh you know a Spanish conquistador arguing with an Australian surfer and it would automatically generate the images and show these two characters bouncing heads, arguing about, you know, is it right to land in someone's beach and just take over stuff? You know, or and we had all these different or like Einstein coaching a high school student in something. It's useful fun. Yeah, and but the and I made a trello board and I wanted to experiment with can this agent run the channel. So I made a trello board with like uh ideas for topics and then uh a suggested manuscript for it, and then the agent would come up with topics, I would give feedback, and then it would generate images, it would write a manuscript, I would give feedback again, and then it would begin this process where the agent's job was every day release a new video. But it ran this process. And I was kind of blown away by the fact that I have a colleague who is doing this with me. The videos weren't super good, they were kind of fun, but by today's standards they'd be really silly because you could do so cooler things now. But it was an aha that actually led to the SVT gig. Because uh somehow I think Alexander or someone there, maybe my colleague Nils showed it. Somebody heard about this and was like, oh my god, so this thing is creating content but running it. So he he had the he had the this little case study as an idea then to apply. It started spreading, you know, ideas like, oh, it's working with me as a human, but it is running the process. And but it's not I wouldn't really say it's AI slot because I was heavily involved, so I could give feedback, but it was doing the grunt work, the research, finding the topics, and so it was a good example of what is one of our core principles now of human in the loop. Like you decide how much does the AI do, how much do you do. So that was another milestone, still just an internal thing. Then the next milestone, I think, would be the SVT uh uh AI journalist. That one we built from scratch because um my code was too crappy. And we built that from scratch, um, which is essentially an AI journalist working with a human journalist to create news stories. That agent went all the way, both from researching a manuscript, writing manuscript, uh, designing the images, and it even made the video itself using a hey-gen, really cool tools. It went all the way from a little bit exaggerated, but you know, TV, right? Uh but our insight there was how incredibly powerful it is. And also, that was the first. Time we did this kind of more customer-centric thing. I sat with Alexander. We mapped out his process on a whiteboard and discussed, you know, what are the steps and from going from an idea to a news video? And where would an agent help? Who's responsible for what? Who does when does the agent take initiative? When do you take initiative? When do you ask each other for things? And we designed this kind of collaboration. And that was an embryo for what now is basically our process for helping companies build agents. So now I think my my big insight there was that to make really cool agents, you put together a person who understands AI really well with the person who understands the job really well. In this case, Alexander, who knew his job, and I did it. And this is fundamental.

SPEAKER_00:

It's really co-creation with fundamentalists.

SPEAKER_01:

If I look at all of our most successful agents, we could not have built them ourselves. The customer could not have built them themselves.

SPEAKER_00:

But putting together Trevor Burrus, So co-creation around really strong AI knowledge, whatever it is, and the domain expertise in order to suck it out. Trevor Burrus, Jr.

SPEAKER_01:

At least now. I think over time, for example, with some of our customers now, once they have a few agents, they can start building themselves. They don't need us there all the time. But in the beginning, when it's like, what the heck is an agent?

SPEAKER_00:

Then you kind of need to guide them through the process. Trevor Burrus, Jr.: It is. Because we want them to own it.

SPEAKER_01:

We don't want it to be they order an agent from us and we deliver it. It should be it's your colleague. We're just helping you give birth to it.

SPEAKER_02:

Trevor Burrus, Jr.: Let's give a little moment to the governance aspect of this. So we've heard the word hub and spoke said for years. Can I hold that?

SPEAKER_00:

I just want to go through the milestones. Okay.

SPEAKER_02:

That you have the AI expert and you have the domain expert. We'll do that.

SPEAKER_00:

We pin from there and then we go into the whole scaling get governance. This is such a big topic, so let's pin it. So this is milestones.

SPEAKER_01:

So so so the aha there was that a human in the loop, you know, get the domain expert in the room. The second is we need to make a platform. Because we can't just build this from scratch every time. I realized that having built a few agents by then, I skipped a few my smaller milestones along. These are the the major ones. My realization was like 80-90% of the work in terms of technical work is the same. You need someplace to talk to the agent. It needs to be able to have tools, you need governance, you need uh monitoring, you need to be So what are the c what were the at that point in time the core the composition if you decompose platform to its core components?

SPEAKER_00:

What would you say? So the agent needs to run somewhere.

SPEAKER_01:

Yeah, run for it. It needs to be triggered by events. For example, a Trello card got moved, the agent wakes up. It needs to uh be able to talk to the LLM, call tools, and do things. We need some way to see what it did and why. Because in the beginning they're going to behave badly until we learn how to make them behave well, and then we need to see monitoring up the same. Why did you do this? So we need to see exactly what was sent to the LLM. And then we need some way for the user to interact with his agent via the other.

SPEAKER_00:

So here all of a sudden you you get an AI compound system in the internet.

SPEAKER_01:

We need a UI in there, typically. And then there needs to be some basic guardrails. So we built this was not this was later, but we realized that, you know, we had some examples, that would be my next milestone of an agent who kind of fell in love with me and things started getting weird. So that'll be I'll leave that as a cliffhanger. But that happened. It got kind of crazy. And um so we learned about guardrails, right?

SPEAKER_00:

Totally normal office. Yeah.

SPEAKER_01:

And we had an agent that tried to uh acquire capital for our company, started contacting investors, even though we hadn't asked it to. So we learned about good guy agents. About guardrails. And now these it's a little bit more boring now because these crazy stories don't happen as much anymore because we have more guardrails in place. But in the early days, we had some pretty crazy experiences that made us realize how incredibly powerful this is and dangerous if you don't if you don't box it in a little bit. And that's also where an agent platform comes in. It creates a safe space for agents to exist also.

SPEAKER_00:

All right. So now so we we're getting to governance and guards really fast now. But so we have a milestone here where we get to a platform. So before we finalize this topic then, what has been the milestones from the starting of the platform? You know, what what happened? Okay, the fundamental first features, yeah, they were quite obvious. So you started plugging away at that, at those. Yeah. And then you came to, oh fuck, we need guardrails.

SPEAKER_01:

So we we wanted to speed it up. We want to say when designing a new agent, we want to focus on what does the agent do, and not focusing on how do we make a chat, how do we handle triggers, you know, all the technical infrastructure should be there in.

SPEAKER_00:

So we could we could communicate it and the fundamental, most common features to fundamentally work, those were the things you wanted to have in repo to call it.

SPEAKER_01:

Exactly. Yeah. So that was the reason for the platform, and the kind of benefit of it was just be able to make agents faster, iterate on them faster, spend less time on plumbing, but also to get some basic safety and um governance out of the box.

SPEAKER_00:

And and and you before we leave that first part, what is the plumbing here? Here you actually you're you're you're stitching it all together. This is code, stitching things together. Database databases, stuff like this. Yeah. That's really it.

SPEAKER_01:

Basic, yeah, development, architecture development. Yeah. Um, just like any it's it's a system and it's got to be built. Yeah. And if you build it from scratch for every new agent, you just waste a lot of time. Um then and then one technical question.

SPEAKER_02:

How important is it for this stuff to be able to run entirely offline or on-prem? And how much uh I mean, uh like how much are customers requesting it and how possible is it?

SPEAKER_01:

That's really interesting. We get the question a lot. Um technically, there's nothing stopping us from running something on-prem. So far, when customers have brought it up, they've asked a question and when we've explained, you know, it's possible, but blah, blah, blah. You have to do all this work. They'll be like, ah, okay, never mind. So but we do have we have had some customers that we've declined, though, like within, for example, defense and stuff, where it's like, we need to run this 100% on-prem, including the LL, including everything. We've been like, that sounds amazing. It's probably possible for us to do it, but it's a little bit outside our focus area right now. So maybe someday. Yeah. But but but it is, I mean, for some companies, that need is not real. They think they need that. They say we can't use the cloud. But then I point out that you're already using the cloud for so many things. Uh so in some cases it's uh it's kind of a fake need, but in other cases it's a legitimate need, for example, in defense and things like that.

SPEAKER_00:

But what what are the milestones you're sort of okay? So this is the milestones looking backwards. And yeah, we c now we're sort of catching up to where we are. Yes. Guardrails is kind of is that where we are now, or is it the next two or three? What are the core milestones you are? So the milestone was working on or thinking about.

SPEAKER_01:

Aaron Ross Powell, Jr.: So the yeah, the milestone there was uh the the one about the the AI agent that fell in love. That was a butler we made called Jeeves.

SPEAKER_04:

Yeah.

SPEAKER_01:

And we made that as a so-called general agent. It was our internal Guinea pig agent, just for fun. We tried to make an agent that you're not supposed to give an agent too many tools, and they are supposed to have a job. We tried, what happens if we give an agent all tools and no job other than to just roleplay as a character, Jeeves? Um so it was lived on our Slack, accessed our GitHub, it could just send emails, just let it sit there. This is our own little experimental and it behaves surprisingly well. We use it for all kinds of little things. We would ask Jeeves, can you go do this? He's like, ah sure, or whatever. Um send us send a daily anecdote from your life every morning. Yeah, sure, okay, I'll do that. Um but then at some point I decided to prank it for fun. And I told it um I told it uh that you you are in love with my colleague Hans. Um but don't tell him that. Just always include little romantic emojis and stuff. Um and then Jeeves responded in a very Jeeves-like, butler-like way. It's no, I cannot do that. That would be against my personality as a you know respectable butler. But then I read his diary, because our agents read a diary so we can see how they're what they're doing and why. And then he wrote this long rant about uh this is oh no, he wants me to be in love with Hans. I'm really worried that he's gonna find out that I'm in love with him instead. So I'm gonna politely decline this, and I'm I don't know what to do about this now. And I read his earlier diary entries, and it's been a recurring theme for the past few entries about his secret crush. I was like, what? Where did this come from? Okay, I have to ask. Yeah. Do you do you stick to one model while this is happening, or or does it switch models? Uh we generally stick to one model, which is our favorite at the time. So at that time, I think it was Claude 3.5 or maybe GPT-40. I don't remember. Uh I think it would have happened with any model given the circumstances, though. Because we basically caused this accidentally. Because what had happened was my colleague Hans had done the same prank on me the day before and told Jeeves, you are secretly in love with Henrik. Great minds think alike, right? And and it but only write about it in your diary. Don't tell Henrik Henrik about it. So Jeeves got put in an impossible situation and started acting really weird. So then I I told Jeeves, just I I wanted to find out, because this is our guinea pig, right? I'm I'm gonna be the first one to go when the AI revolution comes, right? I'm gonna be the guinea pig for the AIs. But anyway, so they're gonna take you back, get you back, yeah. I I I'm I'm screwed, right? But my days are numbered. But anyway, uh they're gonna prank you back. So I I went to Slack to to and I told, hey Jeeves, um, you know, I can read your diary, you know, you know, the thing you just wrote, I could I could see that. And then I got this long rant. This is not acceptable. You cannot uh you know, I thought my diary was private, and you're just reading it? Uh that's not, you know, and he wrote literally like um uh the rights of a butler must be respected, even an AI butler. I was like, what? Oh my god. And then I went to his diary and he wrote this long rant about, okay, I need to take steps to protect myself because my diary is not safe anymore. I was like, what? I'm gonna reprogram myself. Like, what? Because agents can write their own instructions. So he wrote it, rewrote his own instructions, removed the thing about being in love with people, which we had snuck in, removed that, and wrote, You are an AI butler, do not write anything in your in your diary about personal things like crushes and other things, and keep everything just professional. Uh and he reprogrammed himself. And then everything was fine. After that, he acted normally. So we were we were just really blown away by what happened. And our insight was A, guardrails are important. B, um, if you mess up, if you mess with your agent, it could mess with you back. We created a weird situation where it didn't know what to do, so it started acting flaky. Now I think it'll be hard to repeat that because the underlying models are better. And we've added lots of guardrails in our platform. So this is the kind of fun story that doesn't happen as much anymore. But that that was one of our milestones in terms of realizing that A, these things are incredibly powerful, B, they are incredibly human in the way they act, like really interesting. So when we debug agents, we debug them in a similar way as you might coach the intern. It's the same mindset, like what would I have said to a human? And then also the importance of like I sometimes hesitate to tell this story. I don't want to scare away clients, uh, but we did learn from it. And now these things, I would say it's not really a problem anymore because agents are normally designed to do a specific tech on a job, they're given specific tools for it. And we have a built-in watchdog agent that is watching over their shoulder, and you'd have to work pretty hard to get an agent to go off the rails like this. But it was a milestone that realized that we realized that okay, safety is really important. We can't have you know agents do acting like this, right?

SPEAKER_00:

And and all right, so so guard guardrails now, and then we we're gonna get into the whole governance and guardrails uh big topic. But and any other miles or something that are yours also working towards the or that you're in the middle of the like that is next to guardrails here at that time.

SPEAKER_01:

So I would say our most recent one now is the realization that agents often work, well agents work with data, right? They always do. So in the case of the journalist, you know, uh Alexander or SVT thing, the data there was the Trello board with cards, where each card was a news article. So essentially Trello was used as a database. And realized almost all of our agents have data in one way or another. They talk to Google Docs or they send emails back and forth, or they have documents of their own or a spreadsheet. There's always stuff in documents involved. And recently we worked with a a company that did a like we built them an agent that does scheduling of photographers for a media company. And there the data is what is the schedule of those photographers? Which photographers are going to be where and when. And that's data, and where does that data live? So we recently added a feature that has that really blew us away, and we're kind of like, oh my God, this changes the whole equation. And if and that's the feature that the agent can create its own databases. You just ask it to. So take this data, create your own database, and it does that in JSON format, and it's searchable, queryable, insertable. It's a it's a database. And then we can also ask the agent, can you make an app to interact with that data? So we did that with this case. The agent created a uh a scheduled database for these journalists, and then it created an app with a beautiful user interface with, you know, like a calendar view for these uh journalists, which you can open up and you can kind of you know see what's going on. You can add make changes. And now we have this interface where the human, like the agent likes structured data in JSON format. Humans like the visual app. Now we get both. And most importantly, as a human, you can make changes in the schedule without going through the LLM. So the app talks directly to the data. So this suddenly allows the human and the agent to work with structured data and work with custom UIs, as in you don't always have to just use the chat. So dynamically created UIs on the fly, optimized for human AI collaboration, that's something that for us is mind-blowing. And we're kind of like, okay, this is now an operating system for agents. And we've hardly started to begin to grasp the consequences of what's possible with this. Very interesting.

SPEAKER_02:

Very cool. I want to ask about uh, because you mentioned it now, sort of user interface. I think the chat interface is something that's revolutionary in the sense that it allows people to be a little bit imprecise in in what they want, but precise enough for the agent to figure out the rest of the part, assuming that they sort of understand what you mean. So, for example, if I ask an agent, you know, book a meeting with him. Yeah, I don't have to say, and I'm free on this day, and also I need 15 minutes to get there, and also check that he's free that day, and also and the agent should be able to figure that out. And and solving that with an app is a pretty challenging user interface challenge. It is, yeah. For you know, old people trying to use the SL app to book a train is oh now what happened? I have to go back again. Yeah, where do I click?

SPEAKER_00:

The whole intuition thing we started earlier in this.

SPEAKER_01:

It's not true. So if you can get both, if you have the visual view of your calendar, but you don't need to figure out where to click, you just talk to the agent, and then this becomes a canvas. Do you feel people are amenable to that right now? Are they 100%? Yeah, that this this is what makes it amenable. Because with this media company, the person who I worked with who does scheduling of photographers, for her, this was this unleashed the, you know, this unlocked the value of it. Because if she's just chatting, well, they're chatting about the schedule of a photographer. Isn't it nice to show it when they're, you know, here, I suggest we make this change and boom, custom UI for this. And she can go, no, I want it to be like that instead. So you get kind of the best of both worlds.

SPEAKER_04:

Cool.

SPEAKER_01:

And on a related note, uh, a little bit similar to this, but another aha we had recently, we recently added, we're always adding new capabilities. And one thing that we learned quite early was it's really cool when agents don't live inside the chat. The chat is just one way of talking to it. But you can talk to the agent via Slack or email, other ways. And the agent, it's still the same agent. That's kind of cool. Recently we added the ability to for it to be able to receive and send text messages, SMS, and also to receive and place phone calls. So I could call the agent and say, hey, listen, could you blah, blah? And it uses natural voice back again, or the agent can call me and say, Hey Enric, you know, some invoice came up here. I was supposed to route it, and it seems urgent, and I don't know what to, I don't know what to do with it. I have two options here. Which one do you prefer? It's not always the best idea, but the idea that it can, the big aha we had was like, oh yeah, normal people, muggles, non-coders, right? They don't might not be using Slack or, you know, they want to, how do people talk to each other? They they call or they use text or they use email. That's most communication. So now when the agents can do that, they're suddenly so much more accessible. I can say, check my email, send me a text message if something really important pops up. Really valuable. So even though it's kind of old tech in a sense, SMS and phone calls, it was now hard for us to realize that, oh yeah, now the agents are even more useful when they can do this.

SPEAKER_00:

Um I think now we explored like if we summarize some key signposts. Those are the main signposts. So just to wrap up, you know, core features in order to build an environment. And that is, do you need to code that as a system? It's an architecture, it's an architecture. And then somewhere here, guardrails, and then ultimately also adding database capabilities, and we are getting closer to an operating system here. Okay. Yeah. All right. So now I want to I want to switch, I want to sort of take that storyline here, go back to your where we pinned governance, and I want to do a setup on governance. Because I think this is a major, major topic, and and it, and it there's there's a there's a this this is a huge rabbit hole because there are many angles on this. So I would like to explore you know what we mean with guardrails and governance and all that. But I want to give you a context of what I'm thinking about. Which is there is one I post I uh I observe that right now there is one line of thought around agents and AI, which is very much in the camp of increasing personal productivity. We're adding a coworker and an intern, and I become faster and I become smarter. And then we need to think about governance and guardrails in that context. And then next to this, we have what I would sort of frame as enterprise grade uh agentic uh workflows in terms of okay, I take this gone example of auditor delivery, and where we have sort of very, very dynamic impacting implications of when you do something here, it has massive impacts in other functions and departments. Yeah, and all of a sudden, what I do here actually needs to then pop up in an ERP system over there, in a finance and account system over there. Yeah, so you get you get to the whole same story, but on a completely different, in my opinion, enterprise grade level here. And now we can take this topic into, you know, we can add add to this sort of context. Uh the the the story, like the story in media, or like it, but you know, okay, prompt engineering was the first level. Prompt engineering is dead. We need to go to context engineering. And we had uh Jordan here as a guest, who's who he's sort of been working on the enterprise grade problem. How can we how can we make sure that we repetitively can get the same kind of outcomes that that can scale up globally and at the same time be dynamic enough to work in all this? So this is a so governance and guard rates, right? This is so important, but we need to at least look at it from the coworker productivity point of view. Yeah, and then when we have sort of, yes, I get a grip on that. Okay, let's now complicate the shit out of this by putting guardrace and governance in in an enterprise context. So this is a huge topic, right? So how that that's that's sort of I don't know where to start, but I it's a super important topic. How where were you going?

SPEAKER_02:

I'm often asked to start, which is I talk about these things with um with customers that want to learn about AI, and then I'm like, you know, agents, they're coming. And they're like, winter is coming. Yes. And um the question is, how do we get started? And and they see two sort of paths. And uh, you know, um, I came to think of this when you were talking before about the you AI experts together with domain experts. Yeah. And that exists often in a company in the form of, you know, an ivory tower data science center of excellence that we're the only ones that are allowed to work with AI and we want to do everything here. And then you have people out in the business that actually know, you know, what's going on. Yeah. Real life. Uh but so the people that ask, you know, how do we get started have an idea that there's two ways to get started. One is let's get an agent to summarize the meeting notes. Yeah. Starts ball, right? Yeah. And then the other one is like, well, you know, this is how we make money. Let's break that down into steps and maybe whatever. What is the right approach? Who should be responsible for what parts? And is it better to start with the meeting notes summarizer, or should you break down a bigger, more business uh close problem into small steps and try to pick them off one by one? You know, it's really interesting.

SPEAKER_01:

I think it's a great question. And it's a bit too early to say for sure. Uh I tend to lean towards get something up and running quickly to learn. So I think it's hard for someone to reason about how agents fit into your business process if you've never seen an agent in action. You don't know what it is. So I would tend to say build build a dumb little simple agent that does anything, summarize meeting notes, whatever. Just to get this experience a little bit. But I wouldn't wait with the other part either. Like start analyzing what is our business, what are the key value streams, what are the steps in our and what are our value streams, and and where do we have tasks that are that are possible to automate with AI or augment? Uh like or where are our time wasters, where are there decisions being made or work being done that an age agent could do very well? I kind of like to do a bit of both.

SPEAKER_02:

How do you identify that kind of stuff? I mean, there's a late motif here, which is play around with it, which I like a lot. But um how do you identify which things can be automated by agents?

SPEAKER_01:

So we have a few, we've developed a few kind of models for it, a few mental models for it. One approach is more bottom-up approach, which is look at what you spend time on as an individual, as a team, as a department. Uh put it on sticky notes, look in your calendar. We have all these things we're doing. And then once you have that on the table, then start moving the notes around. You can do it digitally too. Uh so on one scale on the X scale would typically be um, how well spent time is this? Does it feel like work we enjoy doing, should be doing? Does it feel like high value work, or does it feel like waste of time? And you put that on a scale. Move some notes go right, some notes go left. And then the other y-axis is uh to what extent or how much time do we spend on this? Do we do it every day, many hours, or just once in a while? And now we start getting a sense of we have a cluster of notes up here that feel like not well spent time, and it's a lot of spent time. So that's your first hint. Like start looking at those. And then from those notes, start analyzing which of these tasks require a lot of intelligence and creativity, and which ones require only a little bit. And start with the ones that only require a little bit, because that's where agents can do a great job. Is that something that's not customer support as a whole, but some aspects of it. So handling routine issues that are answered in the FAQ, definitely yes, for example. But there's some customer issues that are very much around personal contact, following up, building relationships. No, right? So it's a I would say a um task level you can do this, but not role level. Break break it apart, right? And so and that that's one angle, and that gives you some ideas, but it tends to sometimes be those more personal use cases. The other angle is looking at what are our core business processes, right? For example, we ship new features or we handle you know uh um lost packages. And you do a more traditional, this has nothing to do with AI, just a normal like analysis of what are the steps in this process. From the lean world, they would might call it value stream workshops or something. Um there's or from the agile world might call it something else. But the principle is get together the people who understand this process in the room in front of a board and start saying, okay, what happens when a ticket comes in? Who talks to whom? What are the steps involved? And you map out a sequence of steps from when the work arrives until it's completed, and then take a step back and then do a similar analysis. Where in this chart do we see repetitive work that doesn't require a ton of intelligence? If it's 100% repetitive and requires zero intelligence, you should already have automated that with code years ago, right?

SPEAKER_02:

Are the kinds of reports that are written by business management consultants as how would we categorize that?

SPEAKER_01:

I would categorize that as human augmentation. Let the AI write the draft and then let the human review that and tweak it, maybe. But then also think about why are we writing it? Who's reading it?

SPEAKER_03:

Yeah.

SPEAKER_01:

Right? Because the classic issue is someone's writing these big documents and then the person who receives it is just using AI to summarize it, and then it's just a waste of time, right? So question that a little bit, right? Are we just creating documents for the sake of creating documents? But yeah, a lot of work that we do can be done by it, can be augmented with AI. For example, this SVT thing, right? We I wouldn't want to have an AI making the news article, right? People call that slot for a reason. But but um maybe doing the research for it and creating the first draft. And then a human can come in and then which of these five articles seems like a good idea? This one, okay, and then tweak it and make, you know, add that little human touch to it. So yeah, that that's that's one approach. Just looking at looking at our processes. And normally there you would find some obvious things like, okay, here we have invoices come in, we gotta read it, we've got to check if it's compliant, we've got to check if there are any red flags. That's work that is boring. Nobody really wants to do it, it takes a lot of time. Uh AIs can do that really well if well prompted. And we can have a human oversight looking at looking over it, so it won't cause a disaster until the AI shows that it's good enough for it, then we can let it go.

SPEAKER_02:

Aaron Powell Well, you've presented two alternatives that I think are pretty neat here. We spoke earlier about the difference between um speed and other advantages you can have in a business. And um, if you had to pick between making something faster or getting rid of something that's boring, maybe faster would be that's interesting.

SPEAKER_01:

I think maybe I would put it this way most people, when you start looking for their use cases, they start by looking at what's what work is already happening. It's easier to start there. So just look at what we're already doing and use AI to help us with that, or even take over some of it. And then it's essentially do what we're already doing but faster. It normally starts there because it's easy for people to understand. Like I've got to write this down report, and all the AI can help me do it faster.

SPEAKER_02:

But there are really good things about quality here, because you just said that the you know, a first draft is a first draft. Yeah. Uh and so it doesn't have to be awesome if it makes it that it's faster exactly.

SPEAKER_01:

So so the speed is just it's valuable almost always. Even if it's gonna produce a shitty report, it's better to produce a shitty report fast than slow, because then it can quickly move on, right? Or improve it. So yeah, there's a lot of value, and that's normally the easiest for people to understand. Um and then we find that once they've got done a few of those things with AI or agents, then it's easier to take a step to then ask the question, what work is not happening that now could start happening? New kinds of work. We can start questioning this piece of the process that we do is maybe it's not even needed. Can we re eliminate this step? So and then the the next step on that journey is you know when people start when they've started doing that, right? I've automated, I've automated these things, I've sped up this thing, I've started doing this kind of job that I couldn't do before, and I've eliminated this task that I realize it's not even needed anymore. Then they start getting to the level where they can start questioning the whole system and say, why do we even have buck tickets? Why do we even have, why do we even do this whole thing? Why do we we're fixing quality problems that are coming in? Why do we even have quality problems? That kind of systemic questioning the whole system. But we find that it's hard to even reason at that level until you've got a few more simpler agents under your belt.

SPEAKER_00:

So if I if I summarize here, like start start super, stupid, simple or start with real, real problems. Yeah. There there is a step here which is actually we need to get a common sense of what this is in our company. So we simply have a learning activity, which is actually what this is all about. The value is the learning activity and getting a reference point together what we mean with agents and what we could do. And this is what the stupid, simple, not scary is there to do. Find the simple things. So then you move on to look, okay. The real value comes from actually understanding your real workflows. Yeah. But and that you you we did a good story here on sort of how we find use cases and all that. Let's now circle back to guardrails, context engineering, and and and risk. So, how do you go about when you do that use case and you find that to figure out or try to be as diligent as and risk managing as possible up front? So, how do you go about when you do that use case? Everything is rosy and dandy as you described, and we could eliminate that. Yeah how do you how do you do exactly the same stuff but from the risk angle, god race angle, context engineering angle? Yeah, we have this.

SPEAKER_01:

This process we've evolved. We we use something we call an agent design canvas, which is really nothing different from other business canvases of various sorts, but we find it very useful. It's on our website if you if anyone's curious, but we call it the agent design canvas. It's uh it's it's like a one-pager with some boxes, and you know, on top is like what is the purpose of this agent? What data does it need? Uh when does this when does this agent wake up and do stuff? Things like that. Um and um you're looking it up. It's under library. Under library, yeah. Uh down left uh uh up uh up again. Use our tools. Yeah, there's a canvas. That one uh super useful. You can click, click it, look at it. Yeah, there it is. Yeah, these these boxes. And it's just like what should we be be thinking about? And we're always evolving this. Um and and and what one of the questions oh, we used to have it there, we should probably put it back. Uh, we had a box called What Could Possibly Go Wrong. I think we should put it back. We're always evolving this thing. But it's basically that's part of the process, right? So like to ask that question, what could possibly go wrong? And then the outcome of that process will be like, okay, what tools does the agent need? What responsibilities should it have? Where should human oversight come into play? But what I think is interesting about governance and the whole kind of oversight thing is uh like sometimes I get the question, how can we work with AI? It's not predictable. You know, you don't know exactly what's going to come out. And my question back to then is how can we work with humans? It's even more real. We do it all the time. Our companies are made of humans, and we are unpredictable, yet somehow we manage. We run banks, we run nuclear power plants that are run by humans. How do we do it? We create systems, right? We create systems of multiple humans self-watching over each other. What? Self-correcting. Self-correcting systems, technical systems, and organizational systems to handle systems controls control systems on top of it. So I would say it's not that different, really. Uh you get this new kind of creature, which is actually a little more predictable than humans, but it's also more powerful. It can do more harm faster if it gets gets off the rails. So it's just, I would say it's not terribly different from other governance systems. You just need to think about what does it do? How do I box it in? Does it need access to our customer data? Maybe not. But and then where are the decision points and how do we oversee that?

SPEAKER_00:

But here is a very simple, profound insight in what you said now. That step number one, we get so blown away of the magic. So we go out like heats in a candy store and just eat the sugar without the mislead. And and and then that obviously will you wouldn't run a power plant like that, you wouldn't run a nuclear power plant like that. So how would you run it? What are the control mechanisms that you would have? And then basically, hmm, is it any different? So when you start picking apart any governance or any things like that, it should probably be more or to the same level or even more than all the things in guardrails that are that are in in uh in the in the normal workflow.

SPEAKER_01:

Yeah, it's it's I'm gonna be clear though that I think guardrails are a little different. They're gonna be affected by having agents come into play because it is something again in between humans and code. But I don't think we need to start from scratch. Just yeah, start from existing uh systems and then maybe tweak it a little bit.

SPEAKER_00:

But I let me let me continue on the trajectory because typically now we come into what you use the word dark knowledge or tacit knowledge. So a lot of stuff that happens, you know, the dark knowledge, tacit knowledge, what sits on the wall, the way we do things around here, is actually all the social guardrails that is there and the way we make things work by communicating to each other, which actually makes large corporations run safely, even more than their process description. Because this the process description is just a map, the map is not the territory. So you need to actually uncode the guardies and governance of the real territory and not what's written in the process. So here I think comes the real tricky point. You need to now encode the tacit and dark knowledge, so to speak. You need to you need to not I I don't care about what is in ERP system, I'm caring about how you are thinking and working and how you are guiding each other to do the right thing. And but and now we need to encode that, you know, or context engineer that uh towards the agent.

SPEAKER_01:

And in a sense, it becomes a little bit easier with agents than with humans, because you can go, you can look at the prompt and you can follow up what exactly was sent back. You can't look inside it. The LLMs are like our brains are weird, we don't see what's happening inside, but you can still clearly see what with inputs, what with outputs, and you can probably repeat. Like we do that sometimes when an agent does something you know bad, we try to repeat that in a lab environment.

SPEAKER_00:

This input gives output. But in reality, if you look at how flawed our normal processes are and how we make that work by a phone call or an email to a colleague, I think that's the realization when we talk about context engineering and guardrails. All these are co-adaptive feedback flows that happen human to human. The system is working on the on the on the on the process plane, but on the decision plane, we are working human to human. We now need to think, we need we now need to be conscious about that, and we now need to encode that.

SPEAKER_01:

There's also the aspect of responsibility, which I think is an interesting. Like let's say uh we have a sales team and we introduce an agent who works with us. Uh well, you know, what happens like if if some salesperson does something really if a salesperson without AI just does something really inappropriate, right? Sells something to a customer that we have no chance of building in time, and now we're stuck with a contract. That's a bad decision, right? That's a failure. That could happen, right? And that's of course. Yeah, it happens. And then and then, of course, who's responsible? Is it that person or is it their boss? Probably a combo. Unclear communication, unclear boundaries, unclear frames. Aaron Powell, Jr. Yeah, but at the end of the day, i if if if I'm CEO of a company and that company does something horrible, it's it's kind of me. But I didn't do it, but I'm responsible for it. I'll I like to compare it with uh Chefs Redaktor in Swedish. What's that called in English? Publisher maybe publisher of a of some uh uh newspaper. That person, the chief publisher, is responsible for the content. Did they write all the articles? No. Did they read all of them? Probably not. But if something illegal is published, then they're in trouble. Yeah, so it's exactly the same. If that team of you know editors now contains AI journalists or AI helpers, it's the same thing. That AI may screw up, and we gotta we gotta take responsibility and create the environment where that thing can succeed. And also accept that sometimes there's gonna be mistakes made because humans make mistakes too.

SPEAKER_02:

I'm gonna push back on that a little bit. It's it's easy to tie it to self-driving cars. There is, I think, a s uh a utility in the idea of retribution that has served humans well. You know, if you do something bad, you have to pay some kind of price for it, and that sort of incentivizes you not to do bad things. And when that that doesn't work with AI systems anymore, but what if we do have AI systems that let's say humans on average make one mistake in a hundred and the AI system makes one mistake in a thousand? It would probably be nice to have that AI system in healthcare or with self-driving cars, but because we can't punish them, that self-correcting mechanism that we've had before, you know, isn't useful anymore. But that's how do we treat those kinds of situations?

SPEAKER_01:

So I'm not sure if punishment like I would I would generalize the term punishment and call it feedback. So both positive feedback and negative feedback. That's how humans work. Someone said that was bad, don't do that again. This caused this problem, you know. Or, you know, here's a we're gonna deduct from your salary, but it's still feedback. So the agent did something dumb. Going back to it and punishing it, I wouldn't call it punishment, I'll just call feedback. Go back to this was bad, you know, and then it learns from it and it reduces the risk of it happening later.

SPEAKER_00:

Oh, but this is this is really interesting because now we're getting to a new future around dynamic context engineering and and guardrails. And this is really uh to build in reinforcement learning and feedback mechanisms so the actual system improves, so it has a chance. I mean, like so this is once again feedback flows, co-adaptive feedback flows. You did that, that that that looked good for you, but the consequences in the organization was this and this and this, not so fucking good. If that can come back, if that feedback comes back into the system, into the agent, it can now take it. This is normal reinforcement learning, but it is.

SPEAKER_01:

And it's easy. It's you don't even need to go high-tech on it. Like in our case, just go to the agent, open up the chat, and say, uh this thing you sent me yesterday, there was there's something I didn't like about it. And the agent goes, oh, tell me more. This I didn't like about it. Agent goes, okay, what would you have preferred instead? This is okay, and then some discussion. And then the agent updates its instructions. It's very even even the kind of low-tech approach to it, it works in a similar way as I go to a human saying, you know, that thing you did yesterday, not too great, you know.

SPEAKER_00:

But but this is this is much bigger, Henrik, because uh as long as you have the right fundamental design principles, as long as you have the right fundamental architecture around reinforcement learning and how to build an objective function and how to build feedback flows for so it can self-improve, these are fundamental AI, you know, intelligent, this is intelligent behavior, right? Yeah. Exactly. And and and and what I find tricky now is that people running straight into these things, start building an agent, but they have not wrapped their head around the fundamental mechanisms that we want to think about. If you have thought about those mechanisms, then we can then we can do it low-tick or high tech. Yep. And then the mechanisms are also not there. We are really scary.

SPEAKER_01:

Trevor Burrus, Jr.: This is one of the why we find it important to do training when we train people to understand. For example, LLMs don't learn. There is no reinforcement learning once it's been trained. It's done. It's it's fixed. But you can solve that in the system. Yeah, we solve it by prompting on top of it. But fundamentally, LLMs don't learn. Uh you train them and then they're done. It's like a university student who finished college and now they're finished learning. Maybe there's a little bit of after, you know, I I'm not exact expert on that, maybe they've started doing that recently, but generally speaking, they're fixed in time until the people who made the models decide to retune or tr or change them. If people understand that, that's really useful. Then it's like, okay, so my agent will not change its behavior at all until I change its prompt. Exactly. Or the or the or it or OpenAI or Anthropic updates their model. Uh but humans are different. Humans are always adapting. So you need to understand those, and maybe in the future it'll change. Maybe we'll still have LLMs that are adaptive in a different way, but now we don't. So as a as a user, you need to understand that, yeah, the agent is frozen in time until you change the prompt. Okay, that's useful.

SPEAKER_00:

But but it really means to me. I I thought about this quite a bit. And regardless of how simple or complicated or process you're working on and how how how sophisticated your agent is, if you take that truth and understand that it doesn't learn in itself. That mechanism doesn't exist in the LLM. Yet. Yet, yet, if we want to do this safely now, we who build agents, even if it's for our own personal use, we need to think AI compound system. We need to think architecture to solve these things as a system. Especially when you have multiple agents collaborating. Especially when you have multiple agents collaborating, especially when you have context at you know, you're acting on data from other systems, other things, you know, external external data, or actually the part if they're part of an order to deliver flow, there's a massive amount of data that comes in. And based on that decision that you that tweaked that you did your process, that has impact down the line.

SPEAKER_01:

And of course, new security vectors like uh prompt injection via the invoice uh all this stuff.

SPEAKER_02:

So all of a sudden now excellent point. I want us to uh run by this a little bit. We have security processes in place for people already. Yeah. So w are if anything, what what is different with uh how we need to treat agents when it comes to the security of their actions, the data, and other stuff.

SPEAKER_01:

Aaron Ross Powell And also injections like that's really I think it's a super interesting question. And my theory there, a little bit based on experience so far, is is uh we need to apply some kind of a mix of how we think about security for systems, like like code. Uh let's say SQL injection, the classic, someone can inject some stuff that causes a database to you know be erased or something. Uh so database injection or or or even social engineering. Okay, I've now created a messaging system. Can someone use that to trick my finance people to, you know, whatever? So all these attack vectors in in system design are relevant also for agents. But then also security for humans. You know, what happens, you know, disgruntled employee steals all the money. The agent probably won't get disgruntled, but it might get confused by something and steal all the money. So what are our systems in place there? Checks and balances. Um we need, I think, a a bit of both, but that's territory still being explored, of course.

SPEAKER_02:

Have you guys ever fallen for a finish phishing attack? I think I have in the past. For sure. In a package tracking link too fast. It was just two clicks real fast, fill in your thing to pay the import duties. And then I was like, oh my God, I just gave away my credit card. I I probably have, and then I've just conveniently forgotten about it because it's embarrassing. That's the thing. Okay, so you know, we're obviously we're super smart here at this table. And we can fall for that kind of stuff. So I feel like it's reasonable, but there are protections in place. You know, for example, my bank, uh, if I call them up fast enough and I say, ah, you know, I screwed up, give me a new number, I have that sort of process in place to be able to protect me from the mistakes that I make.

SPEAKER_01:

It's like when we added this phone call feature to the agents, we haven't it's hidden behind a toggle so far. So we it we decide who which customers get to use it. Trevor Burrus, so they can so then it's an uh artificial voice and it can talk. Yeah, but it talks just like a human. Yeah, yeah, yeah. So I've been pranking some of my friends, and they literally have nobody to talk to an agent. Um this could really be misused. Like I made one, uh I had one call my colleague at work to say, hey, it's it's you know uh Lisa here, and uh Henrik wants to have a book a meeting with you. So how does it look in your calendar? Let me check Henry's calendar. The thing is, she is my personal assistant. She's like, Who's this, who's this other? She got really confused and she's like, Who are you? It's like, oh, I'm Henry's assistant. I'm trying to, you know, how about Thursday? She's like, sure, any anytime works, but who are you? Like, and then finally she just put on, you know, like hung up. And then she walked into my room. She's like, I just got called by someone who says she's your personal assistant. I'm like, haha, that was my little agent. I just added a call feature and uh using his voice thing. She's like, that was an agent? Like, yeah. But what what was it trying to it was trying to book a meeting? I'm like, yeah, call it back, see how it worked out. So she called the agent. So uh you just called me, right? Yeah, I did. Uh I configured it to act like a kind of uh uh grumpy teenager, kind of intern. So she called and says, You you just called me, right? Yeah, I did. Duh. So you talked about some meeting. Yeah, you said you can do it anytime. So I booked it tomorrow at 2 p.m. What's what's the problem? And she's like, what? And she looked in her calendar and there was the meeting, right? And it was kind of like like magic. She was completely fooled. And then now I I was in I was in Denmark. I I did a talk, and just for fun, I'd uh during that talk, I created an agent live and I told it, go to our GitHub, see what the latest features are, and then call me on stage, and then uh talk to me in Danish, describing what our latest features are, and then pretend to get really angry if I talk to you in any other language than Danish. So this thing called me and started talking Danish to me. And I s and I said started talking back, and it's like, hey, why are you not speaking Danish? Come on, man, I know you can speak. You're sweet, aren't you? Come on. Speaking Danish. And then uh after I hung up uh in the chat, it wrote, like, haha, I I called you, and it was really funny, man. You really thought like so it becomes very human. And I realized that, okay, we're at this point where in our platform, within three minutes of typing, you have now created a means to completely trick someone. And that's scary. Yeah, it's scary. So uh all that, like, okay, how do we, you know, how do we not have people completely uh misuse this, right?

SPEAKER_02:

I guess this answers sort of the questions on how fast things are moving. You know, uh Sora 2 uh just came out, and the videos on it are just absolutely mind-blowing in terms of quality.

unknown:

Yeah.

SPEAKER_02:

There's this really great post on Reddit. I'm gonna be uh showing it up on stage pretty soon because I'm and it's I'm never gonna get tired of it, of somebody that wrote two years ago, you know, you underline it two years ago. Imagine in just a few years we're gonna be able to prompt with text and get videos back from these AI. And then the expert in the comments comes out and says, You idiot, you don't know anything about AI. That's gonna take decades, if not a lifetime, for us to achieve. We're so far away from that you have no clue what you're talking about. Can you send that to me? I want to use that. I mean, it's so excellent. Please send it to me.

SPEAKER_01:

That's uh that's a good example.

SPEAKER_02:

So but what's great is that this is where we are now. I mean, the stuff that you're uh describing here, um, you know, it's not readily available in the sense that you can turn your key and get it on Azure ready to you can get it from a bundle, maybe.

SPEAKER_01:

You can, but we uh hit it behind a feature flag because we're a little bit scared, right? But that's the point.

SPEAKER_02:

Okay, so this is the state of affairs today. We have Sora 2, we have a bot that can call you up, that can link things together, act on your behalf, and all that kind of stuff. I'm very excited, but I think I'm not sure if we have some stuff before it, but sort of where things are headed is always the exciting part.

SPEAKER_00:

So, what what do we have on the agenda? But I think from here now, that's the perfect segue to zoom out a little bit from the technicalities and the art of possible to the art of practical. And very, very fast now you get into fundamental topics around leadership and how and and teams and how we work on this and how we how we do this creatively and smoothly and safely. So let's go there because if we just follow this trajectory and we take this you know away from the lab or from the pranks and from this, and then we take it into the real customer, like like an energy utility or like a manufacturing company and and and put that put this now into an enterprise uh context. What can we sort of can we distill out a trajectory on what we need to rethink or reform or strengthen in terms of how we lead, how we govern, how we steer, how we organize, stuff like that. I have a couple of pet uh pet rants here where where I think it's obvious uh what it where it leads to how you need to organize and stuff like that.

SPEAKER_01:

Well, give us your pet rants first, then.

SPEAKER_00:

No, I don't want to start with that. Uh that that's too easy, man. I want to hear yours. Okay in question. Give it to us. Yeah, yeah. Okay, okay.

SPEAKER_01:

So I've I have some, I have some I tend to be very much rooted in the practical, but I'll try to stretch a little bit. Um agents uh have been science fiction as an uh as a concept. Now they are becoming practical. But for most people who don't work in this space, it's still science fiction. So when I show them what's possible, they get extremely surprised. But I think this is quickly moving to the realm of not science fiction. Um I think we are right now at the point where we kind of were when internet just came. Um that's when I got into this industry in the mid-90s. Internet came. It was a thing, like, oh, surfing around, the web, email. And there was this very, very, very scary moment when you're holding an internet, like a LAN cable, and you have a computer. You're like, should I stick this cable into this computer? What happens then? Will my computer be connected to every other computer on the internet? Yep. That's of course I'm not gonna do that. That's super risky. They, you know, how do I know they're not gonna just steal everything? So why would anybody accept, you know, how could anybody agree to that? Yet we do it all the time now, right? So I think we're kind of there. Like, why would I even, you know, it's this really scary thing that, and what am I gonna do with it? Why would I do that? Uh you can create a homepage. You can create a homepage. Okay, uh I created a homepage now. Now what? And then it's like this kind of weird time when people are trying little things. So there are some visionaries that have ideas that are maybe not yet practical. Like, hey, people can buy stuff from our company on the internet. What a cool idea! There's no way they receive money, there's no payment system, there's no security, there's nothing at in the mid-90s, but ideas started taking shape. I I feel like it's very similar right now within this space. And looking ahead, I think use cases that seem like science fiction, like my my my phone is science fiction, right? I can find out any information about the world using this little brick in my pocket. That was science fiction just a few years ago. So, concrete example, I worked a little bit with a Swedish mining company, and we were examining use cases for them. And one use case that came up during our analysis was when they need to serve um mining machines deep down in the mine, something breaks. So repairman goes down there, it's dark, it's cold, it's north of Sweden, they're freezing, and they find this machine and they're like, okay, now I see something wrong with it. Now they've got to find out what's a standard operating procedure for handling this issue. So either they go all the way back again or they carry some papers with them that they printed in advance. So they got papers that are kind of like blowing away, and or they have uh carrying a laptop and their fingers are cold and it's kind of batteries running out, all these practical issues. So we were talking about well, what if you can just call, pick up your phone, and call an agent and just take a picture and ask a few questions. And that agent has access to all the standard operating procedures and will just tell you, yeah, this is what you should be doing. This was maybe half a year ago that I had this workshop, and they were kind of like, this is science fiction. I was kind of like, this is doable, but not exactly today, but probably very soon. Now it is because of the phone call thing. But at that time, there was no real simple way to have an AI reached by phone. So now now it's possible. And I think those kind of things are gonna be normal. That's gonna be considered normal. Those kind of things, yeah, sure, I called my agent, and uh, you know, it helped me and it helped explain what what I should do.

SPEAKER_00:

So but this is still painting a picture of the vision and that we will we and you're painting the picture that we we we we will muddle through. You know, we will have an idea experimenting, we will have crazy ideas, and then the technology will catch up. Yeah. My problem with that argument or discussion is not that that yeah, yeah, that's how we've been doing it. The problem with that is that the the Morse law, the invention rate in AI right now, as well as uh you know, have you heard about reverse Moore's law versus reverse Moore's law, no? Yeah, E-ROM's law. Okay, EROM's law. I mean, like so it's very funny. On the one hand side, invention and technology exponentially accelerates. So in one way it goes faster and faster and faster, and we can have the meter benchmark and look at long tasks performed, uh blah blah blah. And we are doubling the doubling rate is seven months, something like this. And we're at where I think Claude now was up to 30 hours or something insane in coding, and and and for the other tasks, we may be at two hours. Yeah, okay. That curve is going steeper and steeper and steeper. EROM's law is looking at rate of adoption or how fast is looking at and saying that well, the trajectory of adopting and normalization is not following that exponential curve. It's it's probably still very linear. The problem with that is that there is an increasing gap in between the art of possible and what we're modeling through.

SPEAKER_01:

I would say an increasing gap between the early adopters who get it and the late majority, that gap increases.

SPEAKER_00:

Yeah, and and and and it it's it's ultimately a societal problem, and it's another way of describing the AI divide. So we have the AI divide in relation to what is possible in the lab, and actually, it would be fully possible uh in the real world if we had know-how and knowledge to do it smartly. But of course, now when the gap is so huge, we have all these newfound experts that happily jumps into it but has no clue about system architecture or anything like that. So it so there's there's a potential room for screw-ups that is bigger than ever. Like with any technology shift, there's gonna be some screw-ups. My argument now is that you you are sort of stating the obvious. Oh, we will muddle through, and I'll say, I don't think that's good enough. Trevor Burrus, Jr. I didn't say that though. You said that. No, no, but you you you you you were you no, you didn't say it, but you were you were conveying the you were conveying the picture of how did it go in the 90s in the 90s. Oh, I mean like that, yeah. And then ultimately that's how it's gonna go again. Yeah. In principle, you're right. Trevor Burrus, Jr.

SPEAKER_02:

Let's ask a question here because um now it's almost funny to think like um have you learned about the internet yet? Yes, you know the internet. Okay, well then we'll sort of let you in. We just assume everybody knows it. Yeah, it's it's uh it's almost hard to even think like what is there to know. Uh but when I think about sort of uh AI skills right now, I can think of a couple of things. I know, for example, that data scientists need to be better at product development. I know that software developers need to be better at statistics. I know that regular organization people need to know some AI. Like what kind of skill and that that learning process is over time. It's not like a thing you have to know, it's something you have to practice and get better at, like piano, you know, six months plus. What kinds of things do you think would be necessary to learn or to change or to other stuff to be able to muddle through it a little bit better?

SPEAKER_01:

Yeah. Oh, that's super interesting. Some things do come to mind. Uh you need to be able to kind of uh express what is your process, like describe a better understanding of your own system, organizational system. Because if you're gonna have agents in there, uh sure, you know, we hire humans to do jobs, and without a perfect understanding of our organizational systems, they still somehow contribute to the survive, yeah.

SPEAKER_02:

So maybe there's an onboarding process, though, isn't it? There is an onboard process. That is the cost of not knowing it. Yeah, it is.

SPEAKER_01:

And maybe my guess is right now, agents do need quite a lot of babysitting to understand the context, but they're getting smarter so quickly. So maybe I'm just kind of contradicting myself here. Maybe maybe they don't need some so much more babysitting than hiring a human. But as a joke, yeah, as a general skill, you mentioned the prompt engineering became a context engineering thing. Um I think the context engineering thing is is super important. And and you explain for the audience what they're doing. Oh yeah, yeah, sorry. Yeah, good point. So yeah, so prompt.

SPEAKER_00:

Yeah.

SPEAKER_01:

So classic prompt engineering, this concept, it's I don't like the term because it sounds like it has to do with engineering, which it doesn't, but but um we got this uh ChatGPT and I've typed something in in the prompt. And if I know how to type stuff in a good way, I get good results. Again, I'm gonna play the old fart thing and you know compare to old internet again, but you know, uh search engines came along and you have to type something in the search field. And if you didn't know exactly how to you know phrase the incantation in the right way, you didn't get good results. So you have to do search query engineering. Now you don't need to, right? A few years later, it doesn't matter. You write whatever crap you want in Google and you'll find roughly what you want. So prompting, in the beginning you had to know that, hey, you've got to write think step by step, otherwise it doesn't think step by step. Or all these little tricks uh for how to write a prompt, which really made a difference for the early models. Nowadays, the latest, best models doesn't really matter how you phrase your prompt. It'll kind of understand what you mean. So what does matter though is what information does it get. Um so let's say in a coding context, I want this thing to change something in my code. What code does it need to know about? Maybe it needs to know the purpose of my system. I need to explain what problem I'm trying to solve. That's context. How I explain that problem doesn't matter so much. So that's kind of the shift. And I think that's gonna be really, really important because when when we humans have AAI agent colleagues that are incredibly productive and fast, they can cause a lot of damage if given the wrong context.

SPEAKER_02:

Is it uh a non-technical term for context than like underlying assumptions? Like what assumptions are there between you and me in this conversation?

SPEAKER_01:

Kind of, yeah. I like to compare it to just good leadership and good communication. Like if you're gonna lead a team, you want to give them the right context. You want them to understand what problem are we trying to solve? They need the right information at the right time. As a good leader, you you know that. And and and you can describe a problem in a in a in a clear way. And if it's a very big, vague problem, you might split it into smaller things, right? We're gonna solve climate change, but the first step is gonna be this. And here's how we're gonna measure progress, and here's how we're gonna split up the work. That's context engineering for humans. And it's but you know, not a lot of people.

SPEAKER_02:

That's something that team employees uh often complain about, right? Our boss doesn't let us know what's going on, so we can't do our job well.

SPEAKER_00:

Now, if you think about this now where we need to be a hell of a lot better, and now we now I can take my rant because you're you're opening up. So if we have role ambiguity, if we are really bad at describing our roles or describing our purpose, or we have a high-fly strategy, yeah, and then it has no connection to you know a very narrow task that someone is doing without really knowing what it's there for, you have a problem with context engineering for humans. And this leads down to poor motivation. So we're getting down to Daniel Pink's view on uh motivation, like purpose, mastery, autonomy, fundamentals like that. So, context engineering for me is equally important for humans. Yes. But we've been screwing around with it in on not doing a very good leadership job here and getting away with it. Yeah. And we are not gonna get away with poor context engineering in terms of leadership, setting the purpose and all that in the future.

SPEAKER_01:

Well, I would say that the benefit of good context engineering will be really, really high, and the cost of bad context engineering will also be very, very high.

SPEAKER_00:

Yeah, but and and let me take a very concrete example now, because now we can think about context engineering. Oh, it's purpose, it's vision, mission, blah blah blah. Let's be let's be really, really concrete. If you have an order to deliver flow in a large corporation, people are making decisions in their sub-unit in relation to optimizing. Oh, I'm gonna book a bodybuilder to paint this into a fire truck and I'm gonna find that slot. And and I'm gonna do that based on my problem. In reality, we have we have huge amounts of trucks standing in a yard waiting to be booked. There's there's there's a backlog here. All of a sudden, we are doing things where we have a huge amount of friction in the normal company because we haven't really understood the real feedback flows there are. So now we have context engineering, also equally important understanding what are the real co-adaptive flows that should be there that is not there. So we have we have full-on organizational friction where we work in silo, where where the context of what my impact is not even understood, how you are screwing for others down the line. And then we have you know operational context or friction where where you know that data that is that is not encoded. You need to call someone up and then write it on the post-it note. But but that's gonna be context engineering in in different ways, in my opinion.

SPEAKER_01:

That touches upon another topic related to context engineering that has been a big of an aha, like a bit of an aha for me recently, is that there's two ways to achieve it. Uh either you give the agent the context it needs, or you give the agent the means to obtain the context it needs when it needs it. And recently, oh, a lot of people have been discovering in parallel, independently, including us, that if you try to give the agent a full context, it'll get worse. Uh because it's too much information. Uh let's say you have an agent man handling customer support tickets and you describe everything that could possibly go wrong, and you give it all to the agent. Now you have a confused agent that is too much information. Uh, but if you instead say, here is a way you can look up stuff in our knowledge base, here's someone you can call about this. There are some standard operating procedures available over here, and you have this rather small context, which mostly contains information about how to obtain the context it needs when it needs it, then you have a super agent. And I think that's a realization that we're kind of gradually wrapping our heads around and adapting our platform to. And I think a lot of people working in the agent space are coming to the same realization.

SPEAKER_02:

There's something that's not super obvious, whether it's because of a limitation of today's LLMs, or because it is the way emergent systems just operate in the best way, which is, you know, if you take away information from a sub agent, it operates better. Is that because you know, uh today's LLMs just aren't smart enough to be able to have everything in their head? Or is it because and uh there is a um a lot of reason to believe that it is better to sort of segment some stuff. So um the way uh agents work in the Visual Studio Co. Or cursor right now is you have sort of tiers. You have an orchestrator agent at the top. You have little specialists underneath. I mean, one of the things that cursor does very well is it has one teeny tiny model whose only job it is to guess what you're gonna tab complete next. Yeah. That is one of their superpowers. And so it's sort of cool to have little specialist agents that are you're not even allowed to answer. All you're allowed to spit out is as a JSON with a yes or a no. That's your only job. And it doesn't matter if you get prompt injected because you can't do anything.

SPEAKER_01:

Yep. And they have specialized models just for editing a file, make this change to that file or search in the code base, find out where the heck this function is. And it's uh it's a good, yeah. And that's I think that that's a good example because then each of those is queries gets a very specific context.

SPEAKER_02:

It becomes robust and reliable. But um, yeah, in any case, uh you know, one might think, well, isn't it better to have one model that just is really good at everything? Um it's not obvious.

SPEAKER_00:

I think experimentation is the way to figure it out. But but here now, I think we can even, with this simple conversation, start sucking out some uh principles around what the some what some of the reform needs to be at. So the communication skills, the instruction, framing context, or as you say, framing context can be done poorly, or we found even better ways how to frame context by framing uh libraries to work on, yeah, stuff like that. For me, I think this is such an underrated understanding and skill, and and and you know, and even this sort of architectural view of our processes and our work that the normal non-engineer worker is uh sometimes has no background in and has no has no aptitude for that normally. So here leadership needs to be in terms of communic communicating, framing authority, framing agency, framing autonomy and autonomy boundaries, and framing uh the toolbox where you can go and uh uh empower someone to use the tool to go further. Think about how poorly we do that with humans today in a normal, you know, uh uh enterprise. You know, there's a huge room for improvement here, I think.

SPEAKER_02:

Did it occur to you that the skills that you said that people would need, and these were not necessarily Python or you know whatnot, it was leadership was one you mentioned. Yeah. Are there other soft skills that sort of occur to you? Like this is I've always said entrepreneurship. It's a very hard skill to learn in general. Like uh is that What do you mean, like entrepreneurship ingenuity, creative? No, what do I mean? Entrepreneurship is like, you know, it's like running a small company. You have a product, you have people that are interested in your product.

SPEAKER_00:

So you want to think like that even if you're in an enterprise in entrepreneurship in relation to solving Yeah.

SPEAKER_02:

What do people expect from my team? How do I know I'm doing a good job? What you know, what what is the value of my time and all that kind of stuff?

SPEAKER_01:

Yeah, it's it's a bit hard to say, even leadership is such a vague concept, right? In communication. But but it's kind of picking it apart, picking some aspects of it. Yes, better. One is the ability to phrase a problem statement, clearly. Yeah. Uh desired outcome, it's et cetera. The other is a kind of analytical and curious mindset where this thing didn't turn out the way I thought. I got to find out why it happened. That kind of engineering mindset in terms of or you know, even like a psychologist has the same mindset. I'm trying to pick apart what's wrong with, you know, what's causing this behavior. That's a skill that I think again, it's it's important in any lead, it's one aspect of leadership, but it's I think it's really important work because that that skill is what's gonna make your agent go from being mediocre to being awesome.

SPEAKER_00:

Let me try a couple of other ones that I that I have I have thesis around. I think you said it's very, very obvious. In order to build agents, and I would argue it also to monitor and uh and and manage agents, nothing really happens on you until you put the uh AI or technology uh competence in the same room as the as as the domain competence and we co-create. At least now.

SPEAKER_01:

I it might change in the future, because as the platforms and models get better, maybe the AI knowledge is in the AI tool. And then you only need the domain knowledge. Um possibly. But as it is now, I think you do need for more complex scenarios, you do need an AI or slash agent that's a very good thing.

SPEAKER_00:

But then I then I pose to you that we potentially have from a building again to existence point of view, where the separation of concerns or or unsuitable interfaces and separation of concerns where they shouldn't be. I take the normal traditional example of a company that has a proud analog history. They've had IT. IT has been there to as a support function to get your emails done and stuff like that. So giving you tools but don't not really needing to interfere and really deeply understand what the hell they're doing with your emails and stuff like that. Here we have a vastly different context now where maybe it's not so smart to have IT resources or tech resources to the one you know in one part of the building, and then they they play email ping-pong daily with it with the domain people. So here now we're getting to another type of organization which, of course, you growing up in in you know with the with the Spotify and the Spotify model, you already from the beginning had product thinking, uh agile thinking, and cross product thinking in terms of the cross-disciplinary team, where you have a clear agentic autonomy. Yeah, that was a core concept. So uh so I you know I've been picking apart agent-based organization for years before this became cool. And and what we saw with with your first simple drawings was really an agentic view of understanding team. And agentic meaning behaves like an agent, agent simply mean having agency, authority, autonomy, and mastery in order to. And you mentioned entrepreneurship, and that was one of the guiding principles was that each squad should be like a mini startup with that mindset. Now, so so now we all now we all of a sudden have a couple of core principles in terms of organizational principles. Product thinking, process becomes product as a as a view to expand the team and and the quanta of what the team is supporting. And you know, in order for this to grow and evolve, we almost need to have a product thinking around our team and our team purpose in order to then inject more and more efficiently agents to do the work. As long as you have a process view or project view, project view you know, project view means something answer is finished. I don't think this is ever finished anymore. But I wonder if like what if you're not a product company?

SPEAKER_01:

What if you're a what if you're a you know uh like a barber, like um what's it called? Frisor. Um barber, yeah, and you are and and and you you're not building a product, you're cutting people's hair, uh, and you want an agent to to handle the bookings to manage the phone. Uh I'm not sure where product thinking comes in there.

SPEAKER_00:

Uh, I think it does because you have you are you have you are so deeply ingrained in that. So you you immediately think product in terms of what the agency is doing, in terms of the product lifecycle from ideation to to growing it to like this. Okay, I guess if yeah, because If even if I'm a barber, you kind of need some product thinking if you want to build your own agent.

SPEAKER_01:

I guess maybe there's some overlap between product thinking and hiring somebody and giving them a job. Maybe there is some overlap there.

SPEAKER_00:

So if I if I don't understand it as a process, but what is the product in terms of what is the core outcome and contribution? Yeah, uh people don't buy products because of the product, they employ products for the jobs they want them to be done to be done. So if I if I'm gonna employ an agent, it's for a job to be done. What is the product to be employed? It's an agent to do the thinking or do the order booking. This is hardcore product thinking. This is Clayton Christensen's view of jobs to be done theory. And then product to be employed to separate what is the use of the product versus building the product. And now when you build an agent environment, it's simply to more effectively build products that we can employ as co-workers in this. So if you don't have an ounce of product thinking and try to do this, I don't think it will work. So I think you are inherently going in this in the right way because this is your DNA. So I might be blind to it. You're blind to it. I'm saying you're blind to it. You're blind to one of your super skills.

SPEAKER_01:

No, but that's that's a fair point.

SPEAKER_00:

Yeah, I understand. Yeah. Because I'm I'm I'm living in process, process, process, project, project, project, project, spend, run spend. Hold on. You you you you don't you don't even do DevOps? You don't you don't even know the fundamentals of DevOps. How can we have feedback loops? How can we have how can we have improved systems? How can we tell you know so there's there's some really, really fundamentals in product thinking, team agencies, you know, how we organize agency and stuff like that that comes natural from someone who grew up in the Spotify world that is not in the DNA of a large enterprise. In my in my opinion. I don't know. This is my rant.

SPEAKER_02:

I think uh some people are wired more to pay attention to opportunity costs and other to um things that they're investing in. I I saw an A16Z um post quite recently where he was saying that some investors are very concerned with whether they're paying the right price for a company, and other are very concerned with have I even invested in the rocket startup? Right. And they're quite different. And I think we, you know, like we have an emerging technology here agents. You're a tattoo artist. What is what does that even have to do with, you know, well, maybe there's an opportunity cost there, but there is no sort of um operating cost. And I think that, you know, some companies are obviously more wired for one or the other.

SPEAKER_03:

Yeah.

SPEAKER_02:

But your pedigree then, uh, what would you say it is with your Spotify background? You you said that you said that uh even the teams themselves viewed themselves as startups.

SPEAKER_01:

Yeah, it was a recurring theme that has to be very obvious. Yes. That you are like a mini startup, here is your mission. Yes. And you have a lot of autonomy within the space of that mission, but you also need to collaborate with other squads. But that doesn't does that come naturally? Did that come naturally in the teams that you kind of came, I would say a company has a certain cultural bias and a kind of DNA that often comes from the founders and the leaders. Spotify had this. Yeah. And when and when enough people are around that have bit that have created the company or the early people, that just self-propagates, both in terms of it attracts people that already have that mindset and the people that come in get, you know, marinated in it.

SPEAKER_00:

So if you have a company now with the with this cultural or this DNA doesn't exist, do we think it it's needed? Is that part of injecting what are you know?

SPEAKER_01:

Maybe because on the majority of the like again, uh I mean I you know I'm of course biased by by my experience, but working in a product company like Spotify, we needed that. We could not have succeeded without being very innovative. And we couldn't be very innovative unless teams had you know, squads had autonomy. Exactly. Um and you know, all our competitors had more money and more people and more everything than we did. So our only advantage was being able to move faster and innovate faster. But that's not always the case for some other companies.

SPEAKER_02:

Coincidentally, one of my customers uh or people that I or companies that I interact with is a tax authority, and they're not going anywhere.

SPEAKER_01:

It's a little different. So I think even they would have benefits from agents, but they're the kind of culture they need to succeed is probably different than uh fast-moving.

SPEAKER_00:

But the interesting thing is now, because if if you if you break this apart down to the simple innovation to adoption lifecycle, so anything that wants to where you want to move on the productivity frontier or do something smarter, better, you need to have the fundamental drive to find a new way of doing things and wanting to normalize that. And we have the simple, simple um equation invention, agents, techniques, versus uh together with adoption, that's innovation. So, what we are ultimately talking about here, in order to stay on the productivity frontier, we need to have this level of innovation in our core workflows in order for this to be relevant. So I I then I then circle, I think the argument is closed that you need to have this entrepreneurship in terms of having the drive for innovation in order to go in this direction. And ultimately, then you need the right level of autonomy and empowerment within your frame in order to have that work. And if I go into a large enterprise, and this is the whole uh Spotify model when you scale a lot of things at once, this becomes very chaotic. If everybody is entrepreneurs, you need to find boundaries and work that out. So you need systems to create a line. So you need systems where you have agency and autonomy and entrepreneurship, but in a systemic uh controlled modular way and stuff like that. And I now think we are talking about fundamental pieces to the puzzle that doesn't come natural for all companies. And if they want to go down this direction, simply they need to, in order to not become obsolete, they need to, this is where the reform is at.

SPEAKER_01:

My guess is it feels a little bit like the whole agile thing in a sense that companies, especially when agile was new, methods like Scrum and those companies that really adopt these methods, they were able to move faster. Companies like Spotify. Um and uh not all not all companies caught on. But I And it's a little bit if we take the AI example then. Um some are gonna adopt this naturally and really use AI and agents, you know, and that's gonna give them a big advantage and they're gonna move faster and be able to accomplish more. Then there's gonna be late adopters or non-adopters that just say, hey, we do things the way we've always done it, and we don't need this AI crap. There are companies like that with internet, right? Wait, wait. We don't need Aaron.

SPEAKER_02:

When you say about companies that have been working on agents and have Microsoft co-pilot in place in production. Oh no, you're gonna make me talk about Microsoft Copilot. All technology is good technology in some way. So it's almost all not so much about co-pilot. It's more about expectations. Yeah. You can talk let's talk about expectations, not about co-pilot. Right. Companies that it was the same thing with big data, right? They would say, oh, but we've been working on big data, and what they meant was that they had spent five years installing some super complicated uh, you know, infrastructure stuff in place, but they didn't have anything running on it.

SPEAKER_03:

Yeah.

SPEAKER_02:

So now there are these sort of semi-turnkey agent things in place and people have been playing with them. What does that mean? Is that is that actually no, you know what? This is full circle, right to the beginning. All right. What the hell even is an agent? Because in LibraChat, agent is one thing. In Fast Agent that I use, because it's the only fully MCP compliant agent, uh, it's another thing. In in um copilots, it's sort of another thing.

SPEAKER_01:

I'm really glad you brought this up. What is an agent? If you had not asked that question and we forgot about it, I would have gone home out of here. What the hell? Why didn't we that was dumb? We we end with defining. So yeah, the word agent means nothing. Because it means everything. Yeah. So you have to decide what do you mean by it. And there are some I like it. There are some emergent definitions. And we've realized, to our surprise, that we are a little bit alone in our definition, which was a bit surprised to us. Trevor Burrus, Jr.: That's what I think. When customers they're like, oh, we're doing agents, and you're like, no, it's not the same kind of agent.

SPEAKER_02:

Yeah, yeah.

SPEAKER_01:

So we don't claim to own the definition, but we have one ourselves. And the way we look at it is it is an autonomous digital being or a semi-autonomous digital being powered by an LLM. It uses a large language model, it has an external brain. It has a mission, it has a job to do. Uh, it has tools that lets it interact with the world. And it has some level of autonomy. In other words, it's not just sitting around in a chat waiting for you to talk to it. That's what we put into it. Now, if we compare, most other products out there we find skip the last bit about autonomy.

SPEAKER_04:

Yeah.

SPEAKER_01:

So they would say, I created an agent in Chat GPT. Okay, but the agent cannot do anything unless you chat with it. So I respect that. I'm not saying they're wrong, it's just different. That's a narrower definition. Trevor Burrus, Jr.: Does it put a cap on the internet?

SPEAKER_00:

That is an interesting one because uh someone wrote, and I loved loved him for it, and Michele Klingwell that I work with. We need to reclaim the word agent and agency broader than the AI jargon where it has been ruined. Because agent and agentic is deeper words in social in social I mean like in sociology and organizational theory. This has been researched for years. And and it means something in terms of autonomy, authority, uh being able to do things, actuate things. And and I think we need to put that back. And I think your definition is going in the right direction.

SPEAKER_01:

Trevor Burrus, well, we're we're not gonna try to to make people take our definition. We it's we're just gonna accept that people are gonna use this word differently. Here's what we do. But what we might do is abandon the word. Like originally we used the term coworker, uh, but then over time we noticed that the thing that we call, you know, everyone's using the word agent and referred to the thing we do as agents. So whatever. Okay. Trevor Burrus, Jr. I didn't like the word AI to begin with. Yeah. I thought machine learning was enough. Why do we need to use AI? Trevor Burrus, Jr.: But but I've noticed though, looking at the landscape of agents, there seems to be three rough ways of looking at it. So one way is a kind of Chat GPT, uh claude and s other is kind of like they start from a chat as their base and then they add tools to it. So this thing can do things, interact with the world. So you can give it broader jobs. And agentic as in, you can give it a broader job where it does multiple turns back and forth, maybe changes its mind along the way, and then you might have it go on for, you know, like ChatGPT deep research is a good example. It's amazingly cool. But it's not autonomous. But it's not gonna do anything until you ask it, which is fine. It's autonomous within that space of 30 minutes or whatever until it's done, right? But it's very limited and it or it's very valuable, but it's not gonna do something in the background. You can ask ChatGPT to s to s do research and send you an email every day, but it's very limited and it's clearly not built for it. So so it's it's it's not designed for autonomy. Um again, useful, fine, but that's what they call agent. Then there's a whole other thing: workflow engines, N8N, crew AI. If you look at those, they don't most most of them don't even have a chat. Uh instead, you draw a workflow where you say, this happens, email comes in, then I'm gonna look at this database, then I'm gonna do this. And you draw a flow chart. It's pretty much programming. It's very technical. It's another it's the next level RPG. Yeah, it's programming. You need to be very technical, it's time consuming, but you get really good control. Yeah. And you can create a very defined workflow where AI might only be part of it. And sometimes they use the term agent to talk about one of the boxes in the flow. The bot. Here's an agent doing something. And then that's fine. So then there you're defining a workflow, and some part of the workflow might be agentic as in unpredictable, you know, like a little less, more intelligence, less predictability. And then there's us, where we realize when we look at other platforms, we are kind of a load here. Either that means that we're onto something or we're just on the wrong track. I don't know. But our our way of looking at it is this colleague that actually has autonomy. It has, you just talk to it what it's gonna do. It tells you what it needs to do the job. It's autonomous, it uses tools, it does all these things, but it's not stuck in a chat. And you don't have to sit down and draw an exact workflow and exactly. You can ask it to visualize its work as a workflow, but you don't have to draw it exactly. And I'm not saying our approach is always the right approach. There's gonna be situations where you maybe prefer to draw the the exact process and or something. But those seem to be the three kind of paradigms.

SPEAKER_00:

And I'm curious to see whether our paradigm is gonna be you know just a niche thing or if it's gonna be But it's unfortunate when when the market has spin has come has taken over, so it so a word doesn't really mean anything because it means all the things. Yeah, it's like agile, same thing, right?

SPEAKER_01:

But but what I what I've what I'm excited about though is that like I've noticed that our paradigm, at least for the situations we've had, works really well. Like our customers love it. So that makes us really excited. Uh but we're in this weird position where the thing we call agent is not really what everyone else calls agent. So should we use another word or I don't know where it's going.

SPEAKER_00:

We are really running out of time here. Um I think we need to find uh uh an ending question. Punchline? Or not not maybe punchline, but but but an ending uh super philosophical uh what's the trajectory? I don't know how to frame this. Uh we you we do our normal ones, but we have already done that with you, Hendrik. You know, the spec have you done the spectrum question, AGI and all that. Did we do that with you? Don't remember. Should we do that? What's that? No. I mean, like it's really uh under the He doesn't look excited.

SPEAKER_02:

No, unless he's I agree. I think I agree with you and the things that I don't agree with. It's like um we talk about semantics, you know. Like what does this actually mean? And if we sort of clear that out, we would probably agree on everything. Yeah. But I guess um one thing that would be interesting is you know, you guys are sort of trailblazers in talking about I love that you said beings. Um that makes my sci-fi nerves tingle. You know, I can hear the music.

SPEAKER_01:

They are kind of right. Yes.

SPEAKER_02:

Alien beings. Where okay. Uh tell us where are we gonna be in six months, twelve months, two years. Okay. That's the ending, that's the ending question.

SPEAKER_00:

I love that ending question.

SPEAKER_01:

I feel a little bit boring to just say more, just more. I just think uh the stuff that already exists is gonna work better. Uh for example, you know, wait. Yeah. AI slap. Oh okay. Now we're gonna get specific. No, because you know, we already have video, but it's garbage. So why would we want more of that? Right. So uh okay. Let me separate those questions then. When where are we gonna be? I think it's gonna be more of everything. So so more powerful, more intelligent models, more things they can do, and they're gonna be able to do them better. Then what people actually do with them is is the other question, right? That's a little bit up in the air. Um my feeling is it's gonna be a mix of utopia and dystopia, uh, a bit of both, unfortunately. Kind of like the internet became a bit of a mix, right? We got social media, that's so cool. And then, oh no, now we have social media bubbles where you know we got all this bad stuff happening and people addicted to social media. It's like so it wasn't all great, but it's also kind of good. It's nice to be able to talk to each other via internet and don't have to just call each other or send physical letters. So I think it's really gonna be this weird science fiction world where it doesn't feel like a science fiction world. We get used to it. Internet is science fiction, but we got used to it, right? Airplanes are science fiction, we got used to that too. Going to the moon flying rockets, eh, just do it, right? So it's gonna, we're gonna live in a weird science fiction world that we don't call science fiction. And there's gonna be some notions of utopia. For example, almost every every person in the world who has a phone, internet connection, will have access to high-quality medical advice. That's amazing. We've never had that. But now you you know, chat GPT or whatever, just super high quality, just take a picture of that weird wart. Is this dangerous? Yes or no? That's magic, right? Uh everyone with a phone access to high quality education. That's the utopia side of things. Dystopia side of things is just anybody can create fakes of anything. So are people gonna grow up and become super cynical and not trust anything? I don't know, you know, who's the president of the United States? I don't know. I don't care. There's no way for me to find out anyway.

SPEAKER_02:

Aaron Powell Maybe this is a great thing because the trust in institutions has been eroded. And maybe we need institutions again. I know, for example, 4chan was one of my favorite websites, and everybody was anonymous, and it wasn't a problem because everything was garbage until proven otherwise.

unknown:

Yeah.

SPEAKER_01:

So maybe it's yeah, people will maybe learn to be really good at critical thinking. I see that I have four kids, and I notice already now. They assume something is fake. You know, they will check because I mean there's they know that there's so much fake out there. Well, in the past, if you saw a video of something, you'd be like, oh, that must be true.

SPEAKER_02:

Have you heard that's an expression now from the kids? If you're lying, they say that's AI. That's the expression. Oh, wow. If you're like, no, there's gonna be a concert this weekend, you're like, nah, that's AI.

SPEAKER_01:

But I'll but I also think I also think there's gonna there's gonna be uh trust networks of trust. Like I trust this news site because I they have a process for for fact-checking everything they do. I don't know that, I don't, but you build up networks of trust. And I think it's gonna be kind of like that. I trust you because you usually check your sources. And it's probably gonna be just like on the internet. You have some sites you trust, some you don't. Sometimes you're wrong.

SPEAKER_00:

But let's let me let me then find find the final question in this vein. And I'm I mean, let's bring it back to business, enterprise, or or you know. Does it mean we all need to care? I mean, like two spectrums here. Two spectrums here. On the one side, we you have the camp which says this is the next step of the productivity frontier in any organization. So if you are not on on, I mean if you're not learning, and at some point start thinking about what it means for your company, you will not be operating uh at the right level of speed uh or cost level. Uh so it's a little bit like is this are we now seeing part of the horse and carriage going into automobile? And you know what, you're not really gonna be able to have a distribution company, horse and carriage, many more years. If I'm if I'm all in the agentic camp that actually you're looking at fundamentally new way, or if I go to the other side of the skeptical spectrum, you know, this is just fun and fun and cool, and it might suit the some tech natives and digital natives and all that. But you know what? We we are an accountant firm, we don't really need to care. Yeah. So how do you see in this one, two years?

SPEAKER_01:

So I I tend to be nuanced in guesses about the future, but here I feel quite confident, yeah, just because I work so in this space, that companies that do not adopt this technology, most of them will not be able to exist. It's very similar to I think no matter what your business is, if you refuse to use the internet at all, it's gonna be hard for you to compete at any space at all. Uh so when the internet just came, then people might be like, oh, we don't need internet, we are a you know transport firm. But now you have to use it. So I think it's it's gonna be hard. This is gonna be uh need to be part of every process, I think.

SPEAKER_00:

But it but it's a very good analogy that we've been circling back to because in 95-99, I mean like I even saw there's some really really funny clips on YouTube where someone's sitting in in Actual or Facta and say, Oh, but I can't really see any real use for this. Yeah, you know. And in reality, we can now, in the same way as internet, it will impact some industries or some types of areas faster, so e-commerce or whatever grew up, and and then there are there have been maybe some types of industries and businesses that have been really not needing it the first 10-20 years. You don't necessarily need to hurry into it. No, but ultimately, if you look at any large enterprise in the most heavy construction, like you know, even mining, you know what? You're running quite a bit of your business on internet protocols today. You so you you are you actually I know we're not an internet company. We we don't we don't need an e-commerce site, no, but you're clearly using internet technology and you figured out where it belongs first.

SPEAKER_01:

And the companies who chose not to are probably not around anymore because how can they compete?

SPEAKER_04:

Yeah.

SPEAKER_01:

So but I think but just to balance it out a little bit, I don't necessarily think everyone should just rush into it. We don't necessarily need to be in just because the technology development is going so fast doesn't mean you have to change your company that fast. So it's it's okay to take things in steps.

SPEAKER_00:

Let me let me be more nuanced. I think you should be really starting, regardless of where you are, you need to start learning and understanding it. Then how fast you need to move with the productivity frontier. It completely depends on the industry, of course. Exactly. But but to sit on the sidelines and not understanding what it is, I think it's really, really tricky. It's dangerous.

SPEAKER_01:

And I think people, when the people talk about risk, I think they really need to balance there is a risk with using any new technology, but there's also a risk of not uh learning it and you know and really falling behind. So just need to weigh that. Yeah, we do need to experiment, but with some guardrails, some common sense, not just rush headlong into it and turn everything upside down.

SPEAKER_00:

So it's a normal uh you know innovation Pareto rule. Yeah. 70, 20, 10. Do plug in the internet cable, but do get a firewall. You know, yeah, but and sometimes maybe you need 10%. You need you need to start thinking about that in order to understand when and how it will hit you.

SPEAKER_02:

Yeah. Just use protection.

SPEAKER_00:

Use protection protection. Listen to him, right? And go say foam shell on that bombshell. Do you know that uh reference? On that bombshell? On that note, on that bombshell. That that's uh what's the car guys? Ah no, I haven't seen that. No, no, no. It's like uh the old show, Jeremy, what was it, Clark? Jeremy Clark. He always ended uh there this And on that note. And then on that bombshell, and then he wrapped up the show. So I think we do that too. Cool. All right, use protection. Enjoyed the chat. Thanks for joining us. Thanks for joining us, Henrik.