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.