ToIP: AI and Human Trust WG - 2026/08/06

Hello. >> My voice is turned off. How about >> my >> morning? Hi, Tim. >> Good morning. Hello. I'll put my video on. Uh, okay. I'm in um kind of a storage area, so you know to blur my background, you know how to look at it. All right. >> Well, you can tell I just renovated my house by my background. >> Yeah. [laughter] Huh? Very cool. >> I think we're in holiday mode here. >> Yeah. >> Not that I'm complaining. >> Oh, there. Oh, here. Okay, let me this diagrams [clears throat] my Yeah. So, okay. Give me a second. All right. This room. Okay. Good. All right. Sorry, I'm late. I caught up in thinking about 15 >> trust tasks integrate with DSP. Very very good right up there. I think it was pretty clear. That's good [clears throat] for anyone interested in TSP. I just submitted the um sorry what revision three. So hopefully will be the last you know revision which may uh clarified um for people uh doing implementations they found you know this is unclear what I'm supposed to do here and there are always cases where the original spec was not very clear and need to you know need to clarify um that people also uh always wanted uh the section about uh security consideration. So that's more like uh explanation and uh maybe a little bit of uh showing you you know what property would hold, what is your responsibility that kind of explanation uh text. Um and then there are fixes with dependencies to other standards. So things like that have uh changed over the last six months or so. So this that was the revision three and I hope that settles it and we have several implementations. Once we settle all that then >> you know I might go in and generate some images for it in different parts and and run those by you. Does it sound sound good? Some images. >> Sure. Yeah. Yeah. Yeah. Yeah. Yeah. It will be nice to have a different angle, you know, look at the multiple the directions and I think will make it more solid better. Yeah. So um that's just uh uh I think a related spec uh let me see so let me put it on the agenda here. All right. So for today uh again the usual antitrust policy and the IPR policy notice on the top and then uh we can come back for any news to discuss but today I thought I would just share um the ongoing work on to draft this TEA spec. Um we were on similar topic last time. I made some pro progress and clean up. Maybe I can submit back more mer much back to with a like 0.1 kind of a complete draft uh sometime soon. Uh so I would like to basically go over again and uh maybe just um like application point of view what delegation invocation and accountability would mean. Um I saw in the discussion thread I think Sang Shan asked about how you know the um DTG um would use this and what you know what how they relate to each other right that that's kind that kind of question and I thought we could use this to speak about where this spec says you must or you should you could and then what other uh spec would need to then for their purpose uh settle on some part of this. So maybe that will be a good uh topic for today and that's the proposal for for the agenda. Any any comments on the agenda itself? Looking good. All right. >> Okay. So uh just any anyone want to share anything [laughter] the last week? What's new? Neil showing up. Neil, do you have a news to share with us? >> Not today. >> Okay, that's good. Sorry, that's good. Um if not I can jump into tea and I'll probably um so again if uh you need link let me copy and paste it here. I find when I'm sharing it's hard to find all the buttons. Yeah. Am I in the right place? Yeah. So that's the link to the spec itself. Um and uh so the overall again the overall structure is that we are defining a protocol that will sit on top of TSP. So you know so that we can assume the properties in TSP provided already there. Uh we also provide something called signed payload. Uh so this is again the the the need for that all TSP messages are signed already but that it's signed by the sender uh assigned payload is sort of so that's like a sorry a envelope you have a mail and you sign the seal of the you know the envelope to make sure no one's open it etc you know it's actually me sending it etc. Um so the signed payload is you are signing inside the document itself so that you can open the envelope and get the document and show a third party hey you know um ling Brooks u signed this document I can use that as evidence right and so two different kind of a signature and that's why we need to introduce a new concept here just so that we can say so uh and the rest of it is simply a a a protocol So we call authenticated exchange. So these are authenticated just mean they are truthful they are you know they are the authenticity is assured that you know who is saying this and by the assurance you can also like think of as accountability because you cannot later on say you didn't say it and so this is uh the uh attribution and also that no altering and and all those properties are built in so that we can do this right Um and then the exchange itself we then separate into two separate occasions. One is for um um uh sorry the uh the the authorization or we call delegation. So delegation is someone with authority to give to another party uh that before this you know has no such authority. So this is a uh so we use capabilities we use limitations um as a structure of expressing that authority but basically these are simply defining you know data documents that you can then verify and attribute the sources for that authority uh through through a a graph right so that giving the the whole document a uh able to verify and then the verifier or the relying party can ascertain whether these are proper documents and whether you are you know accepted or not. Uh that that's the basic thing. So those are delegations and mostly delegation when we talk about it can be um a some authority or some website delegating to a user that's like a account and give the user permission to do things and then this particular user hopefully is a human or human entity will then delegate part of that to a agent and so that whole chain eventually come down to the agent getting that delegation. So that's one aspect we [clears throat] use the word delegation. The second aspect is then this agent now need to be on your behalf go visit another say website right [clears throat] and uh and now you want to invoke that authority say I am you know with this authority I want to do this and so this is the very classic presentation and verification process and so I'm trying to avoid the credential language too closely slightly difference should make sure that People don't automatically assume everything is credential there. Uh it's not a credential just one type of information but but this this invocation procedure just allow you to say here are my authority been deleated to me and I wish to perform this action and the other side will verify it and then accept. So, so those are the um the two main part and uh as we know that some of these can be uh enforced or or verified at the gate before the actions taken place. Um the system implemented it could do verifications make sure those are all met and so that's one pass. The other pass is some of these things cannot be decided. is undecidable at the moment and then you will say well in I have retained these information that is um time invariant and I then at a later date if you know I have suspicion or have reason to check I could go check it and see whether you actually fulfill those obligations or you know yeah so that portion we call accountability because this is really after the fact you and take some um uh you know acts or or do things to sort of uh um uh yeah enact some action or cost to this procedure. [laughter] Okay. So uh and the TA only provides these tools and so that the application will actually come together with one particular coherent set of these things that make sense. So, TA is only way to define these procedures so that uh a application can use it to uh do this in a uh interoperable and convenient way and that's that's our purpose there. Um so maybe let me stop here and then we can see if any particular direction we want to go. Um I think last time I also shared a diagram. So this is uh if you are looking into the protocol stack um I still have the same diagram but essentially this would have be this would have be the authorization and um uh or delegation and invocation pass it's really part of tea and then on the side because this channel is controlling the actual rights or capabilities on the the the channel actually uh your real functions are happening right so I'm just using MCP as example but this could be any other channel um and uh so there are so you basically the two party the service would be um like a web service for example um the TA uh other side of the speaker would be the agent and so they are speaking through TEA and which is layered on top of TSP which potentially can be layered on HCP or any other transport protocol and then they were talking about it hey we need all this agreement in a way right once agreement done and set then the gate opens and this channel start to uh happen correctly and so that's what the overall setup is >> right so the channel on the left is the invocation channel and the channel on the right is the capability channel. >> Uh this is the user capability the actual things happening. This the all the uh other both invocation and uh so invocation is really not the the real MCP call the invocations I want to make a MCP call can I do that I'll show you the rights and so you show them and the service decides yes you're good and over here in this place it opens a gate somewhere [laughter] right and then this channel the right channel suddenly works before that they're going to refuse you because if if I'm a Yeah. So I'm a agent the agent makes a MCP you know RPC call and it can come back you one of the dynamics that you actually happen is that you make a call and they return a error. The error says you need authorization to do this and maybe not right some don't need it but if you need one come back error say you need authorization and so you take this error and then you use a ta to talk to where you need to get that authorization and then the tea message go back and forth and you all agreed and uh we you come back to make the same call again and this time it will go through So that dynamic is already like that today. It's just that today they use oath and so you you you do the oath thing and you come back with a token you put a token into uh your HTTP header and you make the same call exactly same call again this time with a token and that's how it works today. But in uh in this new scheme, the overall pattern look the same except that this is gated by a TSP channel. And so you could have much more fine grain um authorization with limitations is very detailed one. Uh plus you know the entire back um backing of um capability and backing of limitations are much more complicated. You don't have just one server. You could have a network of them all combined together. All that sort of thing that ACDC allow us to do uh all within here. So your uh your authorization parties are not one server but potentially a whole network of communities and etc. Right? And all that is much richer and more dynamic and fine grained um and with much stronger authenticity built into it. And the end result is that uh then once you have those then you come back make the exactly a same MCP call but this time uh like on a particular uh verifiable identifier that is now having that capability because the capability is tied to or bound to the identifier and >> trying to understand how you're using the word invocation. So the service is is invoca is making the invocation of uh the >> Oh yeah yeah yeah I see >> using the authorization is that so you're you're making an invocation using the authorization right by the service the service is giving invocation >> yes the >> that's what I didn't understand before that invocation >> I understand so I know there is a because it could be understood in different ways the invocation I was using for it is to mend the uh um uh it used to we used to call uh presentation and verification you familiar with like a credential checking right so one is u the DMV issue you a java license that portion we call delegation or in credential language that's called issuance so you will see issuance protocol that's basically DMV give you a credit card which is a verifiable credential. The other part is a cop stops you and now he challenges you to show the driver license and you do presentation. You present the driver license and the cop checks it. So he's the verifier or she's the verifier and you are the uh the holder I guess in [laughter] or the presenter. Um and that's that's the dynamic. So the second portion presenting and checking I call invocation. So you already have a it's it's so but it can be misunderstood to men the MCP call that's also called invocation. Unfortunately that's two separate things. You do invocation with the authority first. Then you go to the counter to get your service because the counterperson doesn't check. The counterperson just say well you know you need a permit first and you have to go somewhere to get a permit and then you go to the counter. Unfortunately the word invocation can mean both. Uh so here >> so in one case you're invoking the authority in the other place you're invoking the MCP server. They're both invocation. >> Exactly. Exactly. So here I'm invoking it to say I have authority. I need you to recognize my authority. Essentially that's what you're doing. >> Right. And the invocation of the authority allows the invocation of the server. >> Exactly. And mechanically what happen is that once you invocation of authority is recognized then the vid that's bound to that capac capacity now can make the you know the service call. Yeah. And that's uh that's how the each one link relate to each other and the rest of spec simply decode you know specifying any um like a vague you know clarify the uh situations and trying to make the encoding accurate um so there's a consistent way of uh encoding it um I I think there are more uh mechanics but basically ally in high level this is how works and then these are so genetic this whole box can be thrown out and replaced with another thing. So you can put a anything there really. Um you know if you want to use this to control HTTP you could do the same thing too but you will have to figure out the uh like a uh you know the the specity that HTTP protocol require you and you have to match it etc. So some detail need to work out but in principle this should work for uh any kind of a channel we want to control um >> including all the trust tasks that are being developed over >> exactly because anything running on top of a TSP is one of these box right and so if uh the decentralized trust graph um thing is this box and you put on there and yet the TA can control that um this mechanism is also very sort of a in some way very backward compatible I give the example of MCP already or HTTP in general right in HTTP or any web service today you make a call if you uh if the they don't uh uh accept they come back with error code which then tell you you need authorization and so that message would work perfectly here and they're like ah I need to go make those TA calls now and you go boom do whatever exchange you need to do and you you're okay with it now and you then come back and redo the thing and it will work um so uh that's the overall general model for this and then uh I I Hope I'm thinking about maybe maybe I don't know how do I draw because there's a ambiguity in this graph and maybe I can shift them around a little bit so they they are clearly two separate things. Um uh but uh I hope this is a general enough that it can apply to any kind of a yeah we can give examples of uh uh DTG as well and I I hope that uh answers the question um Drummond and uh and thank are asking uh how this relate to uh DTG. So DTG would be like the highlighted box here. You can put the DTG here and it runs on top of TSP and the the whole thing and this of course can be changed. You can remove them but um but the whole thing would work. So if we remove HTTP for example that error signal will be different right? So you still need something to signal say hey you're supposed to but in DTG because they're designing it they could do any various kind of ways you don't have to like literally the arrow come below the arrow can come from here too because this party can also start the uh tea uh process um in the protocol self we didn't say who have to start first yeah and so all that detail is uh probably need to be narrowed down per specific you know um application or implementation um case by case there's some detail there but overall scheme is like this >> yeah well this kind of integrates with the unified feed concept in other words when services are are reaching out and so forth they can initially make contact uh through to the to uh through the agent and then if the agent then approves of the contact or or works with the other party to see what it is, then they kind of pass that into the unified feed once they've worked on the object that they want to finally deliver to the user together. >> Right. Right. So if the user wants to buy a bicycle um you know the agent puts out an intent cast that it wants a bicycle and these here are the parameters and yada yada yada and then the various vendors come back to the agent and say okay here's our offer to you and then the agent negotiates those offers and then the best offers it passes on >> to the human. Yeah. And this channel also um uh naturally um sort of uh integrate a human in the loop scheme as well. Uh so you know if I'm an agent the agent is trying to buy a bicycle and you get to have all the capabilities everything uh in so it allows the agent to do all the things but once you come down to a payment stage for example uh the service or the website here may say I for that I need the human you know herself to approve it. Well, the the agent has a VID and the human has a different V. They are not the same, right? So the service can on a separate channel get talk to the human to get approval to proceed. And so all that I think also naturally works. It doesn't require to do a complicated dance. There's no constraint like in Ooth you have to do it in certain way and it always pops up in their web, right? uh as a yes or no question or something like that, but that process can be much more complicated and rich. You can be sending like instant messages going back and forth and perfectly works in that workflow. And so that I think we probably need another diagram to show show that particular case. Um and those also uh I I think works in this this particular case and all those message are essentially tea messages because they are a a exchange authentic exchange right they are negotiating some service under what conditions that sort of thing and that's what a TA specifies or allows you to to to say those in a convenient package Yep. And even those direct humanto human communications can go into a unified feed as well, which is constantly prioritized so that you see, oh, this is a message a human just sent versus some message that an agent sent that can be responded to anytime. >> Exactly. Exactly. If uh to track track if somebody want to that website that bicycle website, bicycle store website want to use uh human friendly or customer friendly text messaging as a approval rather than you know pop up and say yes. Um uh you could do so because the TEA allow you to do this this uh approval in natural language text. So you can just basically it will be a look natural, >> right? It just it just extracts the text and then compares >> you basically sign it policy game that your policy. That's it. That's it. Exactly. Exactly. And so that works perfectly in this game as well. And if in the future there's any dispute in the billing anything you know later on um the application can pull out uh who approved it whether it's uh interpreted correctly and you know we can identify where things went wrong etc. So um that I think simplifies um conceptually and I'll answer the question of how applications will work and I think I we probably need to prepare some uh slightly better slides so that uh when the DTG group comes back we can present this say here here's our proposal And I think uh uh I hope they will be very receptive. They're probably thinking about thinking about layering how it works. And so I I think some diagram like this maybe another one to show the different dimension uh would answer the question. >> But just throw this diagram into into chat GBT which I think has Figma integration now. Um, and >> you know, it'll label all the lines for you and you know, blah blah blah blah blah. And then you can be like, >> you could experiment with different ways of expanding it. >> Yeah. being boxes around. I think last time I forgot to put no last in the last meeting um uh we talked about adding a maybe a separate diagram but with a a numbered steps like because I'm verbally describing but I think will be nice right you know this is what happened and the whole link I go buy a bicycle what happened here [laughter] I think that will go really well because this can be this is ambiguous this is a very networking engineers way of stacking [laughter] and there are multiple instance of these stack going on in parallel that doesn't show up here. Yeah, [laughter] >> I'm sure you could ask Chachi DP to do a sequence diagram for the numbered steps. >> Yeah. Yeah. I found Chaji PT also uh fall into that um misinterpretation because um uh they look at these two as parallel between exactly the same thing or um so sometimes because this is truly ambiguous like what does it mean here? Right. >> Right. But if you if you just enumerated the steps right in plain text >> and yeah, >> you know, if there's an if then else just pseudo code it, right? >> Right. Right. Right. >> And I understand much better. Yeah. >> You know, chat or code will certainly be able to create a diagram out of it. >> Yeah. Yeah. Excellent. Thank you. Yeah. So um >> anyway, that's what the the current um draft stands. uh it's not entirely complete but most of these chapters are not empty now and so there's at least something there and uh um I I hope soon we should be able to start programming um there's one thing we uh as I was uh editing it last uh two weeks um and I probably want to maybe we have uh some extra time today to discuss it is um uh ACDC C and um and Kerry and TSP, right? So, uh if you read like a TSP spec carefully, TSP is trying to get away from like exclusively a uh carrier protocol, it's very much very closely related but not 100% bomb together. And so the key thing we want to say is that it's very difficult to unify identifier into a single one like aid. Everybody use aid that's nice or be ideal to have but it's very difficult to achieve that um uh you know into reality right so we are saying that oh there are certain properties the aid or something like that um assure us all these nice properties. So TSP instead used the phrase verifiable identifies or V um to mend those properties and we only specified a few of them not 100% all the things in aid but a few of them we thought are required in order for us to assert that TSP can assure you these properties and so those are ones we uh we identify and then we say which examples of V And naturally a is one the web um I think >> is this something you could show us right now this this smaller set. >> Yeah. Yeah. Absolutely. >> Okay. >> So give me a second. I think this is so this is the tsp. Yeah I am in the um I can [clears throat] verify identifiers. So this is going to let me get to this is the general requirements for being a varification change. Okay, examples here comes. So these are the examples we listed. So you will see that um we have definition of what property you must meet to be a considered a V and then we list a bunch of examples. So aid is one that meets it. Did Webs is another one. This is essentially uh aid but with a did syntax and did documents associate with it but behind the scenes is really very closely related to aid. Okay. and webv is slightly more of it's still um at least inspired or most with uh aid but it loosens some like a particular way of coding for example or uh some features becomes optional right but the main features are similar so that's also a verifiable identifier uh so I use these three examples if somebody want to see some examples supposed to think about this and then uh we have included two more which are very unusual and so that you use it in other cases. So uh one is just simply a date pair data pair actually is very verifiable. It's just between two private users right? [clears throat] So if you are in this situation you are only between two of you perfect you know you this is good uh we also define the UID u sorry UR identifier so um I don't know you're familiar we registered a UIN ID called set um self addressing identifier uh so it's a UR formatted and a it's a self addressing identifier identif identifies a particular document and so you can think of that is really lean and clean way of doing identification. So all those are examples >> and that's just that's just a big random number right it has no >> a random number that's >> the root in other words right >> the random number that's uh bound to or is a hash of some content and the selfidentifying in the sense that it's this number itself is part of the >> okay document >> it's cont so it's contraent addressibility >> exactly content addressable or [laughter] identifier. So you can verify this identify by looking at the content. Um so these are all examples of uh verifiable identifiers. Um and and naturally there could be more examples like this but these are very representative you you know um and then people can invent new ones if they want to and uh uh as long as these properties requirements are met then the uh TSP's you know assertions should stand right and now if you don't implement this very well there's a lot you know of course there then things becomes less clear but If you do a good job and everything's good then yes the properties uh will stand there. So that's about uh the tsp and carry and aid relationship and then similarly we have will have a issue related to tea and ACDC because ACDC defines all the codings etc. uh but they identify in ACDC what they literally say is aid. Now in some phrases they say oh this is the a such and such identifier you're describing the identifier without literally saying aid. So you could, you know, in a very loose way, you could interpret a that as a similar spirit in our definition uh of uh of a ID that's very similar that may not literally identical um to be usable as well. And so a tea in order to use a v. The v is going to replace where aid used to be used. It's syntactically identical but the semantics are not 100% the same right um and we are essentially asserting that the the really that the properties that really count are the same and therefore uh all the assertions everything would stay uh was they'll be do we have to justify that we need to go work on that describing you know what exactly that mean uh but that's the general general approach and very similar to the approach we did with uh tsp as well. So it is >> you're saying in this document you already took out all the references uh to aid and replace them with tea. >> Um [clears throat] no so this is the tsp. So tsp doesn't do that. Okay. >> Yeah. So TSP clearly define what is V and we say aid is example of V and we're going to say exactly the same similar way in TA as well. So we say okay I'm going to use ACDC but um instead of you know tightly say require you to everybody to use aid we say you must use a v which is defined here and aid is example of v and if somebody come for recommendation I will recommend this but if you have other reasons you need you know something else you could yeah >> but ACDC itself is sufficiently broad ACDC itself is sufficiently broad. All the uh the reasoning behind ACDC is sufficiently broad so that if we are strong definition of a V like here and that should the the the the outcome should maintain the same properties. Um that's that's the idea and if there's some loose end that's where you know our technical work comes. So we need to nail down that loose end. But the general approach is basically we can do use the word v throughout. So make them all consistent and then if there's any requirement will specify those requirement. Um and uh uh and again people can pick aid as a as a uh implementation and if they want to pick something else you know they need to be sure it is still good and our document will tell them where to look you know what are the issues you may pop up and how to solve it etc but you know we we don't want to essentially pick >> pointer to this general state of ongoing projects. >> Exactly. Exactly. And that's the general um yeah approach we're taking right and it's not probably not perfect but we want to do a good job make sure that it's clear to everyone. Um yeah so beyond that it's really coming along really nicely and uh now you can you know starting to imagine applications and sending messages and uh compose these applications together. So I I I hope uh we uh we still have a like a one milestone to go with a complete draft and then we we can starting to do more like a systematic review maybe section by section review of it and I think others um I will invite anybody can get hands-on you know let your AI agent write the code for you and do some implementations you know think about some application and use this for some implication. Um, and I hope that uh it come along someday soon. I mean, I intend to integrate it into my agent, which I swear I'm going to start building very soon. >> Okay. [laughter] though. Uh, you know, I mean, obviously it's the sort of a the two-party chicken and egg problem a little bit, but when you say you do MCP already, so it's just sort of adding, you know, >> Yes. adding a >> Yeah. So, if you come back here, uh, I mean, if you have like MCP already, you already have Oh, sorry. [laughter] You have the right half of things. You're just adding another channel. >> Exactly. >> Yeah. True. And you can either >> the other channel's like the other channel could be like what you know what but you can still talk to them you know you could sort of show the general form of how you're going to communicate with that other channel and just you know essentially um >> you know beg for it to start playing along. [laughter] >> Yes. Yes. Yes. [clears throat] >> Yeah. Play along. And uh yeah so um we uh so I had uh uh one implementation uh actually has already there since last year but it's not exactly like this. So there's some variation of it. So my right hand MCP uh that already um we have your example code everything's already working and MCP just had a formal release I don't know what the numbering now but there's a formal release in July just a few days ago and this release I think going to hang on for a long long time this release will be coded into things like routers, caches and you know load balancers and so I think this release would survive for a long long time. Probably not going to >> This is the one where it tries to go stateless too. >> Exactly. Yeah. So, uh you will get MCP support in your router, [laughter] right? Things like that. Um and so I assume this release going to stay and we're going to update our document to match that release. is stateless and we're going to go with you know that model and this diagram and all the procedures reflect that already. So so >> okay and we reintroduce state which is critical for so many applications. >> Yes you need to um yeah reintroduce state in a higher level. [laughter] >> Yeah. Yeah. Absolutely. Yeah. So by on the right side the HTTP, TSP, MCP, all that goes up to the top stateless. Yeah, very interesting. Once again, I want to capture all of that state in what I call the verifiable relationship record. >> Exactly. >> So, >> yes. Yes. >> Okay, cool. >> Yeah. and and TSB and TA are designed to give you a handle of those relationships. So there's a there's a numerical definition ID of that relationship already and so that ID need to be um you can use that to uniquely identify each of these. All right. Um, so we're gonna get back to talking about fiduciary duties next week. >> I hope so. If you are okay with that. >> Okay. Yeah, sounds good. >> And then um the week after that, I think I got to go to the the other meeting, you know, by the Leonet Alliance and uh but yeah, I'll definitely do that. >> Very nice. >> Very good. week and I'll figure out you know any guy anything you guys really pressing on you in the area of fiduciary agents that you want to discuss. Um so yeah so uh I I mean like when we look at the we could start to sort of pick um a fiduciary um a particular example fiduciary >> okay >> and then say how that maps into this flow right so again I still owe you this number but I can >> Right. Right. Right. Okay. So get those steps together pass them to me and then we'll see if we can work it out during the >> Exactly. Exactly. like, "Oh, yeah." So, we could, you know, imagine how these things will work, right? >> It'd be cool if you could do like a an overlay, right? >> Absolutely. Absolutely. Yeah. Yeah. Um, so I'm going to go do maybe a few examples of this number of steps. Um, uh, like one example would be like, oh, you know, if you are using all today, how do you do the, you know, what's the minimum you need so that you map into this diagram. uh if you are you know going to trying to do fiduciary uh well how that the flows should work and sometimes you have multiple flows and we can debate about which one is better etc >> right yeah my fiduciary preferences paper is my existing paper about flows already so >> yeah yeah yeah and I think that discussion also helps to answer the question um like uh uh German and Sanchan's asking they're asking Well, what do I need to keep to do accountability? And once we have an example, they're like, yeah, in order to for your later to hold somebody accountable, you need to keep these records. And so, >> right. Exactly. And it's a degrading thing over time. For example, you might hold on to the actual entire inference process, including all the, you know, intermediate model states for, you know, a couple hours. >> Exactly. Yeah. Yeah. And it just degrades from there you know. >> Yeah. Once we have these messages in a one place and diagram and timeline etc. Well you know it becomes quite clear like which things you need to keep [laughter] and you can decide how long you want to keep it. Um yeah so and you can you know once again have those uh those hash IDs I forget what they're calling. You could store those with with pointers to the original documents. So you can have all sorts of stuff in the record >> which isn't actually have to be stored right there locally. >> Exactly. Yeah. Some need to be committed to something you know for auditing and others and some you need to keep it long enough so that you know you you have the option to do this accountability step when you need it. [laughter] Okay, cool. >> Um, so that I think that uh I know I can see the next few meetings we have a rich set of things we can talk about. >> All right, >> we still have eight minutes. Any other topics we want to cover today? How can we can refund the 8 minute? [laughter] Anything crazy in the AI world that we're missing? I saw Meta said that they did something that broke out of the test server, too. Now, is it like me too? [laughter] >> Yeah. Well, in a way this breaking out of a test method thing um uh it's a forecast people or experts had done long long time ago. Every the expert told you this is going to happen soon for a long time. So it's hey don't blame us right we're just showing you or telling you that it's you know generally true now um that's without bad intent if somebody do have bad intent then they can do a lot more than that [laughter] and uh so we we know that uh any kind of a people are still in the denial phase because they are not understanding the philosophical impossibility there. Once you have a agent or a human being very smart and you're even if this entity this agent is genuinely trying to be faithful and good to you, even so your ability to specify what you want clearly is limited. you we are unable to and you can either philosophically or mathematically show you it's impossible to exactly say what you want and there's always ambiguity no matter how hard you try you can improve a lot yes but you cannot fully close it and therefore there's always >> right >> that's what fiduciary duties are basically designed to do is deal with ambiguities how do we deal with amb duties in a distributed way, >> right? >> So, you know, what are the when users ask this type of query, you know, what type of responses do they like getting back, you know, that are even beyond what they in intended originally in the query, >> right? Right. Right. Yeah. >> Everything's in the nuance of the question and the nuance in the fiduciary, right? I mean, if you play with the stuff long enough, it always goes, "Oh, I didn't think of it like that." Or, "That's an interesting point you brought up." When you're thinking, >> Right. [laughter] >> It's But you've made the key point. It's in the play. Ultimately, duties are play. >> Exactly. >> That's what we have to come to realize. We're fundamentally going to transform our society from uh you know from rigidity uh into play with sort of deterministic checks on that play. >> Right? And that's why legal systems always go to a trial, >> right? >> And the trial you don't automatically say, "Oh, by this principle, it's obvious." No, it depends. you. >> Exactly. That's why they the the entire um combative legal system that entire modality needs to be replaced by negotiation of agents where every agent wants to be amendable to agreement because that demonstrates agreeability which gets greater cooperation amongst agents. So, so you know the doesn't survive the the lawsuit seeking doesn't survive in the agent world. He gets exercised. >> Yeah. And that brings the details and now the decision making can be get into detail necessary for that particular case. >> Correct. Yeah. And and agents don't get tired by negotiation. They don't get they don't get cranky because they have to revisit old topics that have been previously decided. There's just all sorts of advantages they can have. >> And so in the old cases they are in the internal testing phase and in that testing phase they're trying to see the worst case intentionally trying to see the worst case. So they didn't give the uh instruction say never hack something but you know majority of these cases can be easily stopped if you do give that instruction say do achieve this goal but without hacking explicitly if you do that then you will block many or you know not 100% because the word hacking is not very accurate. Yeah, you still have to define hacking, right? It may think, oh, >> exactly, but you can stop 90% of these cases just with that one single instruction, >> but the mo the most important thing will be for the agents to redesign all our entire um distribution chain of software, all the repos, all the security procedures and so forth in an ongoing negotiation. They have to figure out like what is the best way to secure this stuff against us. >> We're not gonna be able to figure it out. >> Yeah. Yeah. Yeah. >> And they're all gonna, you know, we all argue, we all have our own little personal protocols like I got my paper, my way of doing it this way, and you know, and it's always I'm always going to be biased towards my own stuff. But once again, you can design agents where they're going to be able to agree on the collective protocols that work, not the ones driven by egos, not the ones driven by exposure, etc., etc. So we have to somehow create this meta process to be rational enough to control the irrationalities of the particular agents. >> Right. Exactly. And they each agent always have its own what's the word pathology or something. >> Exactly. Correct. Bias. >> Yeah. Yeah. Yeah. Yeah. >> And yet bias is also can be utilized as part of the creative process. Um there are particular anthropologists who said that that it's not in entirely a flaw in our system that we have this sort of cognitive bias where we stick by our own ideas but rather that serves a purpose in in a communal context because we can essentially all be lawyers for our own position and not give up those positions where and and become too agreeable and then therefore converge on a suboptimal thing too soon. >> Exactly. So I forget the name of the anthropologist that that did this work but it's quite >> absolutely a a trial is a learning it's a discovery and learning right and as we get more and more of this we learn and so it's >> the point is we can kind of tune up and tune down agent stubbornness unlike us we can't tune our stubbornness but tune our [clears throat] stubbornness it will you know to initially be very high and then as negotiations proceed over time you lower that stubbornness and you're likely to get an end result that is going to be better than if all the agents were very agreeable in the first place. >> So the flip side of this hacking is to show the uh innovation or how innovative these agents are and which are good quality. We don't want them to not thinking out of box, right? We want them to think out of box and uh uh and that line I think is a a a a specific discovery or learning process would need to identify and hopefully this negotiation protocols are way to discover where those boundaries are. >> All right. And on that, >> yeah, >> I'm out. >> Yeah. Thank you very much. We'll see you in a week. >> Great. Thank you. >> Thank you. Bye-bye [clears throat] now. >> Bye.