This is Epicenter Episode 532 with guest David Minaj. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Federica Ants and I'm here with Maher Roy. Today we're speaking with David Minash who is the Co founder and CEO of Valerie and founding member of Autonalus. And Autonalus is a funny project, it kind of. It's an AI slash blockchain crossover and why that is interesting we'll dive into in
just a second. Let us tell you before about our sponsors this week though. This episode is brought to you by Gnosis. Nosis builds decentralized infrastructure for the Ethereum ecosystem with a rich history dating back to 2015 and products like Safe Cow Swap or Gnosis Chain, Nosis combines needs driven development with deep technical expertise. This year marks the launch of Gnosis Pay, the world's first decentralized payment network.
With a Gnosis card you can spend self custody crypto at any Visa accepting merchant around the world. If you're an individual looking to live more on chain or business looking to white label the stack, visit gnosispay.com. There are lots of ways you can join the Gnosis journey. Drop in the Gnosis Dow Governance form, become a Gnosis validator with a single GNO token and low cost hardware, or deploy your product on the EVM compatible and highly
decentralized Gnosis chain. Get started today at Gnosis dot IO. Chorus One is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, Celestia and Dydx. More than 100,000 delegators stake with Chorus One, including institutions like Bit, Go and Ledger. Sticking with Chorus 1 not only gets you the highest years, but also the most robust security practices and infrastructure that are usually exclusive for institutions.
You can stake directly to Chorus One's public note from your wallet, set up a white table note, or use the recently launched product Opus to stake up to 8000 ETH in a single transaction. You can even offer high yield staking to your own customers using their API. Your assets always remain in your custody so you can have complete Peace of Mind. Start staking today at Chorus .1. Hi David, it's a pleasure to have you on. Yeah, pleasure to be here. Thanks for having me. Absolutely.
Tell us a little bit about yourself and your background. Sure. So I came to crypto from a sort of background in maths and economics. I did maths undergrads and then really got into applied game theory. There were some fantastic courses at UCL where I did that and one thing led to another and I ended up doing a PhD there and then that.
You know, if you Fast forward quite some time that for me to discovering that I really like this intersection of game theory and machine learning which I've done a lot together with and interest which had sort of grown steadily in crypto and blockchain. And so I'm working in that space now for over 5 years, and particularly at this intersection of crypto and AI. Yeah, super interesting. Sounds like applied economics and maths. And yeah, sounds like the ideal background for getting into
crypto. You. As we said in the intro, you are Co founder Valerie which is a Co contributor to Autonallers. You kind of Co founded with someone else also called David and what kind of what motivated you to kind of Co found this project kind of What's the problem you were setting out to solve? Yeah, it's a good, it's a great question.
So Valerie's mission is to basically create open source software for people to Co own primarily agentic AI and we'll kind of uncover but what we mean by this. I actually have two Co founders 1 David Galindo has a background
in cryptography. What's a cryptographer and so is and the other Co founder has a pseudonym called Oak Sprout Bataan. He has a product background and the three of us really kind of in different ways we're excited about autonomous agents and this general pressure which you see in AI towards agentic kind of AI systems.
And we had different experiences with this topic, different insights and we came together to basically build a substrate on which you can as groups kind of Co own these agentic AI systems. So I think that's sort of the driving force is to provide this kind of software set which allows people to do that and also kind of create applications which people then can own in that way. You've used the term agentic AI system quite a few times there. What is an Agentic AI system?
The way I think about it is that if you look at the sort of dominant forms of AI then you can sort of see maybe three ways. So you have like in the other parts of the last century like this dominance of rules based systems. And then and then they basically said you know that you have hard coded rules, often extremely sophisticated, which allow you to build sort of certain types of AI systems. And by no means has this kind of part of AI research and applications gone away.
But at some point you then had more of these kind of learning systems emerge where you have like neural networks and deep learning and other forms of learning, reinforcement learning, where you effectively use data to construct part of the algorithm effectively, right. So the the system learns from data rather than all the rules
being prescribed. And if you look at what's now happening as we have these very powerful large language models and other types of powerful AI models, but they by themselves are certainly now not, not authentic in the sense that they, you know, there's some some data which sits somewhere and then you effectively query these models, you instantiate them, you query them and then you get a response.
And that can be a very sophisticated response, but that's it. What what's interesting is once you think about effectively systems that are having agency and can sort of autonomously act and there's an enormous pressure towards the system from a pure optimization point of view and evolution point of view. Like if you think about it, where can you make the most money?
Where are the most exciting applications as well It's autonomous systems which can take actions by themselves and then not, you know maybe instructed by some third party, some human or or some other system. And so yeah, these kind of agentic systems we we can uncover but what what they look like conceptually. But that's I think where the train is headed, where where a lot of focus is going towards across like the AI fields.
So David, maybe to kind of let me repackage this somewhat, would it be fair to say that in the genetic system is something where you kind of give an AI agent a goal but don't perfectly specify how it should, how it should go about achieving that or is that too simplistic? Yeah, I think that works. And in particular, I mean what we're interested in are sort of these autonomous agents. And so we can briefly define
that sort of conceptually. So usually it's a sort of software system which is placed in some environment and from which it perceives certain information. They could be blockchain events, literally, or they could be things from an API. They could be something from a sensor, which it has locally. It then uses that information plus whatever its internal architecture looks like, to then take action again in its environment.
And that environment again can be like a blockchain, another API, another agent, some actuator of any, any form. So this is what we would call like an autonomous agent. And effectively what I'm saying is that what we're seeing increasingly is that there's more focus to basically create models which can act as subsystems of such autonomous agents. Or even like, almost like Subsume and autonomous agents as a whole, right? And so there's this kind of pressure towards these kind of
systems. So as an example of an autonomous agent, maybe we could think of. So imagine there's a there's diagnosis network and then there's the code base of diagnosis network. And one could imagine like a coding agent of some kind where somebody opens an issue on against the code base of diagnosis agent or against the code base of the network. I want to add this feature to the core protocol of diagnosis
network. Then an agent could be something that kind of as a first step isolates the pieces of code that need to be changed, as a second step creates code making those changes. As a third step does some form of testing. So that could involve kind of like static analysis, but that could also involve like runtime analysis and gets feedback from the environment and then makes another set of changes and comes up with a draft like a draft change a draft pull request. Yeah, I like that.
I think that's that's a good example. Also Speaking of Kinosis, Jane, So one autonomous agent which is running there, one type of autonomous agent which is built on the autonomous stack and it's running there every day is a agent which trades in prediction markets. And so if you kind of map that into this model which I was just describing, it might be quite helpful. So again here. What it's observing are sort of basically new markets. Opening.
So it adds us to the list of markets which it kind of has a look at. It might then fetch information pertaining to the events which are referenced in these markets from really anywhere in the web, so a. Search API or just like crawling itself almost. It then uses that information, that context basically, on the event. As well as various AI models.
At the moment most of the agents use some form of large language models to basically prompt these models with that kind of information and then once it arrives at a prediction for that event together with an accuracy and other kind of information which it estimates, then sorry confidence wizard estimates, then it will. Construct A transaction and then sort of act in that market IE kind of take a position in that
market. So for instance if it's a binding market, yes or no by the relevant tokens which represent these events. And so here what you then have is this environment being sort of these smart contracts and the information endpoints where which are pertaining to these markets. And then the actions are these taking these positions in the markets and then sometime passes and then? The agent might actually make some money. Oh, OK. But that sounds primarily like kind of like automation
technology, right? So basically people wouldn't necessarily know that I run this sort of software to do things just like kind of I run for instance, say trading scripts, right. So how how do we know that this is, I mean, I assume to some extent this is already happening, but kind of like where it gets really
interesting. It's kind of when you kind of design systems where several of these agents kind of come together to kind of in a game theoretic way to kind of figure out you know something to do some conclusion or something, right. So yeah, a couple of things. So firstly I think. You're right that like there's sort of automation and then there's different levels of
autonomy. And like if you think about the self driving car, they have these sort of levels and it's a bit similar to think here like you have different kind of levels and you can be closer to what people might describe as automation. And then there's also this thing where as time moves on, we tend to prescribe things which maybe we saw as more autonomous towards automation because they kind of get wrapped behind like an agent, for instance.
And then I can just sort of see the act of interacting with this agent where the agent is actually autonomous. As for me, from from the perspective of the user, it's almost like just like automation. I'm just calling this API which then goes away and creates an outcome for me. And so I think there there's always. That but.
But you're right and then. In the system which I was describing, actually the way it's practically implemented already is that there's already three types of agents today. So the trading agent itself doesn't actually come up with the prediction. It's other agents who specialize
on that. And now we're even like picking apart that role because what we basically see and is that from a practical perspective if you can sort of specialized your agent that has its benefits like the same way we specialize as humans and but also from a sort of practical users perspective of running the the agent that can have its benefits.
So for instance if I had an agent which has to have all sorts of let's say open source model which needs to run alongside it which it uses, then this can become quite obese To actually run this thing like quite impractical. Whereas if an agent can use other agents to get something done, then it might be as simple as making a small crypto payment to for instance get a prediction.
And so that's the case here. And then you have to obviously trade that off with other design considerations of the system. So I'd like to state Frederica's question in like in different ways. So any standards taking company would would be running for example price oracles right? So in in in a price Oracle it's fetching the price from somewhere and submitting the price to the blockchain and it's getting paid in crypto to to do that and the one could imagine
that entire. So it's like the the code of like a price Oracle is is highly mechanical it can it is specified entirely in in in a in a programming language the input to it is very structured. It is probably coming as like Jason files that that are structured in a particular and it's output is also very structured. It is producing transactions that have these fields and etcetera. Perhaps that is like actually like an agent itself except it's like a very dum agent.
And the kinds of agents you are thinking of are like AI agents where we are trying to climb the hierarchy of well the inputs no longer need to be that structured. It may not come as Jason or or Protobuf or any of these protocols. It might come as a English language and it could be anything that comes in. So the inputs becomes unstructured.
Then the processing logic instead of being structured in the form of code, you could have processing logic where the agent like DNO comes up with how to execute on a certain input and its execution path is kind of like invented for that particular input and it might be different from what it was
previously. And then finally on the output side, it's outputs could also be unstructured, meaning it's it's producing output in the terms of English language which has like of course with English also has structure which has like but less structure than a programming language output or a Jason output would have. And so maybe the financing of the AI agent is we are trying to generalize the input, the processing and the output of what what is already kind of
like a traditional crypto agent. So validators, price oracles, we might think of them as traditional crypto agents, but we are trying to kind of push their boundaries in like what they can do. Yeah. And there's these different dimensions which you're kind of pointing at, right? So you have like the levels of autonomy and then the levels also of the kind of how dynamic is the decision making and how open-ended is it, how structured and unstructured can be the input and output.
And basically like if you look at it from our perspective, the way we look at it is our stack kind of allows you to build across a whole range of these things. So we have some products which are very, very structured. So they're basically rules based of the kind which you know in Oracle is actually one example we we you can build an Oracle on
our stack. It's not like anyone is like majorly focused on it, but we have some demos of the sort and then all, you know, you go a bit to the right on that dimension and then you add this prediction agent where it becomes a bit less structured because. Yes, some of the flow of it is entirely structured in the sense that it will always sort of do certain actions in a certain sequence.
I'll get to. That in a second as to how that's actually done on a code level and then inside of the states, actually let me explain it to them right now it's like we structured as a sort of finite state machine. So basically we say OK, the the overall agent is described as this graph like structure where transverses through these States and then in some of these states it might sort of dynamically choose which path to take going forward, but sort of the rails
are given, right. So it can't just sort of totally go off the rails and suddenly say I was a prediction agent now and now I'm kind of doing this other thing shopping clothes or whatever. And this we see this as A basically a pragmatic approach and B also a big advantage because you know obviously these kind of AI enabled agents, autonomous agents is something relatively new in that form.
They were stuck in the sort of beltrum for a long time where basically nothing much happened for for decades and multi agent systems research, I mean no, no sort of big move forward. And on the other hand, you now have these sort of AI agent models based mostly in large language models where it seems a lot is happening. But then when you dig a bit in, often if you leave them too unstructured, nothing, it's an interesting research exercise, but practically not too much
happened. So the sweet spot is still in between, that's what we say where you provide a certain degree of structure and then within certain states the agent can be dealing with unstructured input or output and and and and can do what you were just describing.
And that I think it's you know how long we will be in this phase where it's so an in between, I don't know, you know there's certainly attempts to build sort of like almost like a large language model but for actions where people sort of trained us sort of in in into the model itself. We'll have to see when when they're actually, I think usable, but if you want to use off the shelf technologies today and then you're sort of limited to still providing some degree
of structure. The other way to look at this is also from an efficiency point of view. So once you actually know that your agent is meant to be an autonomous agent in prediction markets, that it's meant to make its money there and that's that you want to use it for that, then it's kind of pointless is if every time it's running it has to figure this out from first principles. That's a very dumb approach, right? The same way in in in in in in programming.
If I write an efficient program, I might not generate everything dynamically. I might have like sort of hard coded, you know, look at tables or whatever where I just pull values out because they're way more efficient than if I were to generate them on the fly even if I can. And so the same thing is here, sometimes you might want to apply an agent actually at the building stage.
So going back to what you were saying earlier, Meher applying agents to build agents is also something we are focused on. So we have like some internal tooling now where we are able to basically prompt our tooling and then it generates sort of half of the agent, like not all the code is finished. There's still like some software developer engagement needed, but it generates a lot of it. So there's this angle as well.
From an efficiency point of view, where you don't necessarily always want to figure out everything at runtime, You might want to sort of ahead of time build a better agent which is then forced to act within these bounds given by that design. I'm still a little bit confused kind of As for the Asian terminology.
So I think kind of there's these cases where kind of I can imagine you kind of you have large games that you kind of you optimize for and kind of that means kind of you don't, you don't have to do so much on chain because kind of you can optimize it off chain and kind of agents can keep each other in
check, right. And that to me is kind of like the multi agent system, at least in kind of my lay understanding, but kind of in, in your description now it sounded like what I would have conceptualized as one agent, you guys often think of as different agents that are somehow amalgamated together into kind of like a super agent as you said, kind of like there's the prediction, there's kind of the research agent and the prediction making agent and so on.
Maybe you can kind of delineate the the terms here a little bit for us. Let me zoom out even like a bit further. So one of the you know core things which I guess like the idea of multi agent systems is, is that you have. Multiple potentially different types of agents which generate some sort of emergent outcome. And so if you look at any individual of those agents then they themselves wouldn't bring about this outcome and then
that's only the collection. So this is the example I was giving earlier where you have these three types of agents and then they kind of coming together and the outcome are sort of AI driven prediction markets where no human ever participates in. Now if we look at our stack specifically it gets a bit more interesting still which is that we basically say OK, going back to this idea of Co owned AI and Co autonomous agents like what motivates us there?
Well, what motivates us is that we are a bit concerned that as there's this tremendous pressure to build better AI models and as there's this tremendous pressure to build better agentic AI systems, that ultimately they will be owned in a very centralised way and also operated in a very centralised way. And so the question is, can you create basically a substrate where people can own them in a decentralised way? So now one obvious answer is if you somehow can make a smart contract smarter.
And there's a lot of exciting projects which are kind of trying to do that with CKML and other kind of technological approaches where and effectively you just use a blockchain, a public one, and you run some code on it which might have been sort of verified off chain as a verified on servershet might have been proved off chain. Now in our case what we offer is basically, OK, if you want to build an autonomous agent and you then want to run that code as a decentralized system, then
you can do that. So in the Ola stack you can develop this trader agent which I mentioned earlier and you then can run it as a multi node system. So what basically happens is that the trader agent is like the the whole of all these agent nodes and here it's a bit different because these agent nodes are effectively like blockchain nodes. They're sort of replicating the the work and also the code. They're you know often quite identical or can even be fully identical instances of each
other. And then they work together to effectively become the straighter agent and so on chain they're represented as a multi SEC and off chain there's this couple of nodes which have like a state synchronisation between them. So very practically what they use as tender meant and at the moment as a consensus gadget so that all the nodes in the system agree on the actions this agent
should take next. So in the field of LLMS itself, right like and now I'm referring to let's say like the non crypto part of building on top of LLS which is probably 1000 times bigger than the the crypto part. There's like lots of different frameworks that are kind of like building agents using LLM. So blank chain is probably the most commercially successful. But then you'll go and find like Microsoft Autogen which which is a multi agent system in in how it's constructed.
But there are, but there are like loads of others in fact. In fact the problem is it's a problem of plenty rather than a problem of problem of scarcity. So maybe to start with, in terms of like the agent framework you're building, what is like really different about your agent framework from the things that might be happening outside crypto as a whole? Yeah, I think one key thing is that we always want system which are sort of able to take action on chain like any other users.
So we see like alternative agents as these sort of the active users of various protocols and we can talk about this later in a bit what benefits that has for the protocol, but that means that in our case. Sort of the crypto wallet and also the on chain representation of the off chain agent are like first class citizens. So we think of this from the design beginning and then that
has implications. For instance when we come back to this trader if I want to Co own like let's say a long chain agent, well you'd have to basically build what we've built because you need some way of basically sharing ownership of let's say an on chain wallet like a a safe let's say a multi sic with these off chain instances of agent. So our our framework let's you do this that's that's one way to look at it. So it's just a sort of native
crypto support. I guess the second thing is this, if you go further to Co ownership, there's sort of two extremes there again. So if Co ownership can be achieved entirely on chain. So for instance you have like a safe which has some assets and now you have a lot of let's say land chain agent or auto GPT agent or whatever. One of those framework agents all kind of holding a wallet and
then being a signer on the safe. Then this could work right because they don't necessarily need off chain consensus depending on what the application is. But actually once you look into the interesting application, turns out that almost always once you go beyond like simple things which are done on chain, you need off chain consensus. Because often it's like things like oh like even on Oracle needs to agree off chain potentially on the data it wants
to put on chain. Certainly efficient oracles want to do that off chain and then if you imagine this off chain system wanting to act upon something else off chain then for sure you also need off chain consensus. So there it then also again helps to have a stack which gives you this out-of-the-box which always does.
Now a third way to look at it and this is sort of purely on the independent of crypto and more sort of on the structuring of the agent is that coming back to our discussion earlier, automation versus autonomy and like sort of fully AI based and dynamic agent systems rather than those which are maybe like sort of based on hard coded rules.
The reality is if you want to build like really use cases which can use, which people can use today and which are actually meaningfully and securely achieving something, then you can't go yet in these sort of fully unstructured models where you just basically repeatedly prompt an LLM like you can do it
but it's it doesn't work. I mean you need to provide structure and then if you look at the frameworks you know long chain is an interesting example and and you know I have no, no nothing bad to say about it but it's an interesting example. They're moving towards graph structures as well because it's pretty obvious that a chain won't cut it. Like your decision making is almost never a chain. That is the most basic kind of application where it's like ABCD
and then going back to a right. The reality is you're going to have even in the most basic application you're going to have the happy path which might look like this, but then off the happy path you have all these error paths which need to sort of loop back to different States. And so you're basically in a graph structure. And so that's where we started our journey.
We we basically like five years ago said, well, if you're building autonomous agent systems, then it's unlikely that we're going to have in the short term these sort of fully open-ended sort of just models which we need to trend or somehow the agentic system pops out. But instead we still need to provide some rails and then use models alongside those rails. And these rails in our case are these basic graphs along which the agent has to travel.
And now if you put it back all together, I think one of the benefits you have our stack is that you can go and say, OK, I have a A use case where there's some states in which the agent is very free. There's other states where I want the agent to just travel along this track, then I can do this and now I also want this agent to take action on chain ever so often then it already comes out of the bots.
So we obviously from the beginning when we built the framework, we're really heavy users of the safe.
So we had like if you're in support with Safe since basically day one, since the framework is usable and now as we're sort of expanding it to other sort of types of blockchain ecosystems, we're always kind of having the same design podium again where we pick like a multi SEC which is dominant in this ecosystem and then build the compatibility of the stack around it. OK, I think I'm I'm now less confused about the agentic part, but I'm still confused about
kind of like the protocol as a whole. So kind of like if you look at the stack now, now we kind of have some understanding of what these agents I can and can't do. I can't just give an agent, I don't know I can't just say here you have 100 die, you make me some money and basically the the agent will go and kind of like either kind of like but but you know build the arbitration bought or kind of make saucy pictures on mid on mid journey and kind of put them on only
fans. And I mean, so basically it's like, it's like you have to give it some structure, I understand that now, but but how do you put this all into a protocol and kind of where does the Co ownership come in? Because this is something that in principle with an LLM model and like some dev background I could just do on my own, right? I don't need autonomous for that. Yeah. And that's a great question.
So basically I think for like one of our core insights is that it's not about building individual agents, it's about building effectively many agentic systems which can interact. Because ultimately we're like big believers in the specialization and even like from a very practical point of view, we want to build better agents. People will build very different agents, so the framework will have to get get a very different. Sort of use cases so.
So the protocol was always designed to enable basically entire Asian economies and enable their bootstrapping. So there is a couple of mechanisms which facilitate that. The stack itself is open source. So when you have an open source stack, there's never a forcing function to tell them or you have to use this protocol. So you have to basically create like a a reason on top where why it would make sense for people to engage with this protocol.
So one thing which we noticed is if you want to have these busy autonomous agent use cases really grow, then we need obviously a lot of development, you know, developers who build on the stack. Why do developers have the benefit of building on the stack? Well, there's some of the technical reasons we mentioned before, but there's also one of composability.
So we basically have created a very composable framework where it's not so much about composing arbitrary Python libraries, which is a focus of a lot of the other frameworks, but where it is the focus of the stack to compose business logic itself. And that's particularly with autonomous agents of the current generation. If you think about it, it's very
important. So if I have like for instance this trader and at some point it's going to settle a transaction you might say well that is just a matter of sending the transaction. Well this is actually not true.
There's around like 20 or 30 states in the finite state machine which takes care of settling the transaction because there is like on the happy path whereas things are you need to come, you need to sign it from all the agents, you need to then submit it. You don't need to wait for it to be settled. And if anything goes wrong in any of those states, the resolution looks different. Now you don't want a developer to re implement that.
Similarly if you think about things like interacting with these prediction markets, that might actually be like something which you might want in another agent. So being able to kind of compose these things is is is very, very interesting. And so one big part of the protocol as a result is this focus on creating a developer developer incentive mechanism whereby developers get rewards for contributing these pieces of agents and entire agents into the stack. So that's this code side of
things. They can do that permissionlessly. So very practically, you know you develop the stuff you registered on chain as these NFTS and then there's a sort of reward system which works sort of on a on an epoch basis. And on the other side of this is, is the question of capital. So obviously the developer rewards come partially from you know emissions, but over the longer term they will have to come from productive agent systems which the Dow kind of operates.
I'll get to that in a moment, but even to get you there, basically you need a bootstrapping mechanism whereby the people can actually use this OLAS token. And so that's where bonding comes in. So whenever the protocol is deployed on a new chain, then effectively there's a bonding mechanism in place whereby people who use or believe in the protocol can provide liquidity in this token and the chains token and then.
Return that LP token to the protocol and receive effectively all us. And what this does is that basically you have a very decentralized way of bringing that utility token. 2 more chains. Why do you want it on more chains? Because that's the third bit which is staking. So once I obviously have like code which does something useful and now I want to be able to actually operate these agents. And as we noted before, you can operate them like a
decentralized system. So it ends up looking a bit like operating a blockchain. So you effectively then have the staking system where the operators of the nodes in any given agent can basically earn these staking rewards. And in order for that to obvious move, it helps when the token is basically accessible on that chain directly. So that's sort of the three mechanisms like staking being the last and then the code capital sort of pair and then we can dive in there if you want. Yeah.
So actually that's a lot of things, right? So let's try to recap. So right at the layer of building the agent, what you're saying is like, OK, your framework in a sense like there are many frameworks which we can can be used to build agents. But the differentiation of the orthogonal AS framework is that it contains the differentiation is in two dimensions. The first dimension is it contains components that would make blockchain integration and blockchain transaction creation easy.
So this could this could involve things like, OK, a blockchain, an agent. If it needs to interact with a blockchain, it needs to store a private key. So maybe it it needs some components for the securing of private keys, it needs components by which it can read blockchain data, it it needs components where transactions can be sent and it can it can figure out that they were
confirmed or not. So there are like some standard pieces of logic that are use in a lot of different places, maybe in exchanges, you use it in the hot wallet or things like that, and you're going to build the standard versions of those components and integrate them into a framework so a developer doesn't have to worry about those aspects. Then the second thing your framework's providing is it is providing some kind of cognitive architecture.
By that what we might mean is that you want the agent to basically apply its intelligence, but you want it to you want to constrain its intelligence in a certain manner which is like you know, for for a particular problem, always think, always create a tree and reason through the nodes of a tree or in this particular problem create a line and like there are nodes and reason through all of these nodes.
So particular problems might have particular ways of thinking that if we constrain the agent to think in that particular way, it will produce better outputs. And so you are you're providing a way to develop against some of these of these like constraints right Like so a developer can put these constraints into their system and then they could they could use it. Those are on the framework itself and then what you're saying is actually like the the network itself.
So, so now we jump from like the framework deals with the problem of how do you build a single agent or how do you build with two or three agents and they coordinate with each other. But then you jump to the network level, where it's the problem of ultimately you want thousands of agents to be to be built. And there the kinds of problems you're trying to solve are how to provide developer incentives for the improvement of your agent framework itself. Yeah, so this is.
So if we zoom out a bit what we ultimately want is a machine to well even if you zoom out a bit more so the Co ownership of autonomous agents and agentic AI ends up being I think what if you think about like Tao like decentralized autonomous organization is sort of almost like the end state of that.
So if you, if you think about this concept of like some organization which we own, which is in itself autonomous and which has the highest degree of decentralization we can achieve, then ultimately this will be using forms of AI and and be agentic right by by its definition. And so the different angle at which to come at this is to say, OK, how, how can you basically coordinate all the actors which
need to make that happen, right? Because if it's just on chain, then you're always constrained by what you can do on chain, right. So if you just have a smart contract then there's always someone who has to call that smart contract for something to happen. And by necessity you will always be limited to what's possible on chain which I think will always be less than what's possible off
chain. And so in a way that the other way to look at it is to say how can you create basically a protocol autonomous which allows the creation of these kind of Co ownable autonomous agents. And then this means you need to coordinate a bunch of actors, you need to coordinate those who are developing them. That's why you have the def
incentive mechanism. You need those who operate them, which is around staking and you need those who basically provide this liquidity for the whole system to exist at any given point, which is the bunders. And so that's kind of what the roles of the protocol is to coordinate all these actors. Now obviously it's highly complex. So we should make it a bit concrete. If you think about what we had earlier discussed quite a lot the the trading agent use case with the prediction markets.
And then there's the system called the Max inside of it, which is the third type of agent which basically just specialises on making the predictions. And these kind of agents are basically something which you can imagine running as this decentralized system which the autonomous style itself then can
own. So you effectively then have a situation where the autonomous style can provide on an ongoing basis this kind of off chain system with configurable degrees of decentralization which offers these services to other agents in the autonomous ecosystem and then that allows you to sort of bootstrap this over time, if that makes sense.
Can I think of it like this? That so today we have a few different chains that are trying to build what I call like puppet accounts or delegated account control. Those are those are two like 2 interchangeable words. But the essential idea behind it is so the Near network is trying to build this. So Near's idea is that, OK, there's a blockchain with a set of validators. And what if this blockchain itself could own a Bitcoin address? Not only a Bitcoin address, but
another Ethereum address. And so from the perspective of Bitcoin, it's like a normal address with a private key. But the private key is actually split into the validator set of near by some really smart cryptographic protocol. So Bitcoin thinks this is like a single, it's a normal address, a single individual, but in reality underneath it is actually validator set of near that controls that account.
And in a sense that you can say that OK, that in a near network by itself is kind of like owning this, owning this address on Bitcoin and this other address on Ethereum. If you start with that point and then kind of you layer on the idea that is it possible that OK, that there be a way by which a network could own not only an address but an address plus a piece of like running code. And that running code is 1 an
economic agent. That running code is an autonolous, this framework agent, so it has an address and it has some kind of like structured and unstructured logic so you can actually message it, give it tasks and expect responses. And so autonolous is trying to do that ultimately. Like how do you have a DAO that can own an address plus some kind of code and so and it it owns both of those components together.
And then it can also circle a set of like make money, make money through it, that that is what you're what you're seeking to achieve. Well, this this is, yeah. So we would call this like a protocol on tab. So it's basically if we go back to this concept which we said earlier, if you have an existing validator set, so basically you could say OK well let's just do this all on training, you know, like let's just somehow modify the chain so it can sort of run
long running tasks. And then you will find very quickly that there's all these arguments as to why that cannot work. Like you need an application specific chain in order to have long running tasks, Because if you have a public chain it becomes a immediate. Basically at hack vector for for. Denial of service. Distribute denial of service because you can just sort of pre empt future blocks indefinitely by scheduling tasks for future blocks now.
So effectively whatever nearest during there. I don't know in too much detail, but there's limits to kind of putting too much on a block public blockchain which is meant to run repeatedly or scheduled basically. So you need to do it on some sort of application specific layer. And now you could say, OK, well we can just run some sort of layer two or layer three or
layer N or whatever. And ultimately there it's mostly about having sort of again an architecture where you can basically then inherit some degree of security right and execute some of those instructions.
And in a way I think ultimately you know in in in the future one day an autonomous service will look quite similar, similar to an app specific roll up potentially because it will basically have a lot of degrees of verifiability and it will potentially even inherit some of the security as a result from
the chains on which it acts. But it will have these more autonomous a long running tasks here which is executing, which is different from like a public blockchain where I always need to basically at any given time offer these blocks which accept a certain amount of basically bidding into them and then once they're full, they're full right, I can't guarantee you that I'll execute you, whereas an autonomous service can do that. It can say, well, I'm
application specific. Ever so often I'm doing exactly this thing. OK, so I feel like this has become super abstract. Maybe that's kind of make some examples, right. So one of the main topics that kind of you posit this will be used for in the short term is optimization of Daos. Can you give us some examples how kind of things work in Daos today and how you see them improving by kind of putting these autonomous agent systems on top of them or kind of enmeshing them?
Yeah. So actually there's no answer to this question in, in the sense that originally before when we started out with the stack that like Dow's are this primary custom for that, right. They have various of chain processes which are often quite centralized. That's helped them make them more decentralized and and more autonomous and both things would join their name turns out from a
good to market point of view. And it's not particularly great because a lot of dials have actually a lot of things to do and they're maybe not the best organized entities always. And so it takes a lot of time and you you're not getting to the goal very fast. You also need to coordinate a lot of actors by the definition of it.
So actually what we noticed is that what's was we still believe in this and I'll talk about an example is that it's better to focus on problems we see in our own Dow and make them as autonomous and decentralized and or just build basically users for other decentralized protocols.
So what I mentioned earlier the use case, these autonomous agents are basically users of Omen, users of Knosis, users of Safe. You know they have done around 70% of all SAFE transaction on Knosis since summer like on a on a on a weekly basis basically we've done hundreds of thousands of transactions which basically benefit these protocols on which they're deployed and obviously themselves as well because
they're they're profitable. Now an example which I like because it's very easy to understand, which can apply to many dials and which they can adopt quite easily as governator. It was a bit of a joke project which is sort of slowly maturing. Basically it's built on the autonomous service stack which which OLAS offers. Autonomous.
What it does is it's it basically replaces a human delegatee in in a DA. So if I obviously have tokens and I don't always want to vote, I could delegate them to someone I think will vote more or vote in my favourite like with my intent and so on. And we implemented that in code.
So basically there's an autonomous service which continuously watches those styles for which it holds delegated tokens, and then when it sees those proposals either on snapshot or on chain, it can then vote in those proposals.
And obviously in order to do that, it needs to use a large language model to actually read the proposal and reason about it. It also needs that in order to make sense of the preferences it is given and sort of bring those two things together to arrive at a voting decision. But the actual voting, coming back to the structured versus unstructured is a very structured process. There's zero point and having the agent figure this out every time because it will probably fail most of the time.
Instead you just have that part hard coded right. So basically this is a nice example of what we were discussing about earlier in very abstract ways. You have these sort of structured bits which are defined very well and then you have these unstructured parts of of the logic where you're looking at this proposals making sense of it and so on. Are there new attack factors
that are introduced here? So basically, if if I kind of, if I kind of trust an autonomous agent to kind of make voting decisions for me, I kind of, I rely heavily on the fact that this autonomous agent actually will act in the way that I would act if I were to look into it, right? So how do you make sure that the agents actually do what they are meant to do, on the face of it? It's a great question. So the there's two parts to this. Well, many, but I would split it into one is like the
preferences. So that's where the Governator should fall short. It doesn't actually allow you to express very rich preferences at all and that's just a a matter of our time and effort which has gone into this part of the application. But one side where it exceeds on is the basically certainty that it implements the decisions, the decision logic which is meant to implement. So if you think about a human, if you delegate to them, you basically have no clue, right? It's all reputation based.
If you were to think to delegate to a single long chain agent or auto GPT agent, well, it really depends on the developer. Who's running that, Are they even running it? If they're running it, are they running the code they told you they're running? Right, all this kind of stuff.
Whereas with an autonomous service which has multiple nodes operated by different operators, you then start getting into a similar basically threat model which you have with like a, you know, like your Cosmos chain basically. Or any other sort of Byzantine fault tolerant system whereby you have to reason about OK, how many like operators are there, how decentralizes it and then is the majority of them honest.
If the majority of them is honest, then you have very high security guarantees because you effectively what happens is that each one of them has to agree or the majority of them has to agree and each one of them uses these models. So you're not even relying on a single model instance, which is another issue with large language models, they're not necessarily deterministic at all. They sometimes can be configured to be, but like some of them can't even be configured to be deterministic.
And so then having multiple agents each come to independent valuations and then sort of pool that decision making and then agree is actually like a massive improvement. So on that dimension I would say Governet is already better than a human, because a human could, you know, do whatever. And here you have like a node system implementing that decision logic. Yeah. So I think kind of what we often try to do in these episodes is kind of we try to understand how exactly things work.
And I think this was more an episode about kind of talking about why it would make sense to have something like this. So kind of I kind of I know I want to change gears a little bit here and kind of ask about concerns you may have about this. So kind of like if you look at AIS the way that they have improved in the last couple of years at least kind of like in, in the popular mind. I know that kind of it's been a long time time coming and so on, but it's really impressive, right.
It seems absolutely certain that they were kind of surpass human ingenuity and you know, capacity on all kinds of axes in. You know, the very short term, and if you talk to AI safety people, it kind of often they will tell you they're not so concerned because you can always switch it off and now kind of pairing it with a technology that by definition no one can turn off. Does that worry you? Yeah, I think it's a. A good topic to discuss and one we won't, will not be obviously sad about.
I think the, the first thing which I strongly believe in is that it's very, very, very unlikely that there will be just sort of one model which kind of runs away and like takes over. And that's just even in like very favourable cases to the sort of super intelligence arising and being able to consume a lot of resources. There's like geographical physical sort of constraints which make it unlikely.
I think what's much more likely is that it that we'll have a situation where certainly a lot of centralized players will own very, very powerful models. And so I think actually what we should be what I'm most concerned about is the economic impact of this kind of change in technology on people rather than these hypotheticals where some software's lasers all.
I think it you know it's not it's important to kind of keep it in the back of our minds but and and like with every technology be mindful as to when these dangers become more apparent that we kind of think about them. But like the the much, much bigger concern I think is you know economic under economics. If if if you hit hit listen to someone like Sam Altman. It's this naivety of the economics which really riles me up.
Like they all go around and say, you know, I mean that you know by all means like they're great like you know entrepreneurs and create great products and so on. But everyone has the weak ones. I think here it's like this kind of naivety around just because I create better technology, everyone will be better. Well, that never worked out that way. The reality is that it's always a distribution question.
And if the distribution sacks of access to these kind of models and people's ability to use them for their lives and improving their own situation, then it doesn't matter how good the best model is. Then there will still be even bigger disparities in sort of income, health, wealth around the globe. And I think that's what we should all be really worried about. And that's kind of the mission of our entire business.
And the mission of autonomous is about creating these kind of systems which can be Co owned so that there can be groups who can share these systems. That doesn't mean that all problems are solved because now you know, these groups could again be better off than others and you still have these kind of distributional issues. But at least it's it's a start.
So I'm worried about the economic impact of this much, much, much, much more than these kind of hypotheticals which I think are interesting for dinner conversations but really don't
kind of miss the point mostly. Having said that, I think, you know, let's say we Fast forward, there's like multiple generations of advances and like even like models which are basically agent in the model, sort of you know, like some call them large action models now I saw and others call them different D then you know Open AI has their reinforcement learning merged with large language models, there's different attempts, whatever it will be in the ultimate state.
And if you imagine that to run in a sort of blockchain like way where it sort of has a bad intent and we can't turn it off, yes, I think it's something we should keep in the back of our mind and and think about solutions. But I think the flip side of this is again that if this model is used for good, then having transparency and kind of censorship resistance can bring many goods as well.
So I think let's take it one step at a time basically and focus on the problems which we for sure know will happen, which I think are distributional. I feel like we've touched on many, many things. If people want to learn more or kind of build their own age genetic systems for autonlers, or kind of just use systems that are already there, where where should we send them? Yeah. So we have this thing called the Academy and that's a great
start. So that's for people who want to basically have more like support as they're building. We have the docs. All of that can be found on the website. So Olas dot network and then if you follow autonomous on Twitter as well, there's like weekly updates where I think those two places are are the best. Perfect. I am so curious to see how this
is going to evolve. I think we should pencil in kind of a follow up soonish to just to see kind of like what people build and kind of how it actually changes things because the opportunity space here is absolutely enormous. Yeah, let's do that. Yeah, it's been a pleasure to have you on. Thank you very much. Was a pleasure being on. Thank you for joining us on this week's episode. We release new episodes every
week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it. To listen to the latest episode of the Epicenter podcast, go to epicenter.tv/subscribe for a full list of places where you can watch and listen. While you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released.
If you want to interact with us guests or other podcast listeners, you can follow us on Twitter and please leave us a review on iTunes. It helps people find the show and we're always happy to read them. So thanks so much and we look forward to being back next week.