Everyone is just taking a round about way to get there. The workflow/program as "tools" approach is the right one. Agents skills are more or less in that same direction.
It's an SDK for Certisfy (https://certisfy.com)...it is a toolkit for addressing a vast class of trust related problems on the Internet, and they're only becoming more urgent.
You can use the idea to spin-off background agent tasks that can then be seamlessly merged back into context when they complete.
The example above is a product specific approach but the idea should be applicable in other environments.... it's really an attempt to integrate long running background tasks while continuing with existing context in an interactive manner.
When you start working on the problem of working with automation programs (AKA agents) in an interactive human-in-the-loop fashion, you will naturally run into these kinds of problems.
We've all seen sci-fi movies with AI assistants that seamlessly work with humans in a back and forth manner, async spin-offs are essential for making that work in practice for long running background tasks.
Age verification could indeed be implemented in other ways. The approach outlined above is for information verification and trust projection in general, meaning you can put just about any verified information on a certificate and it can be used online.
Here is a concrete example of how trustworthy certificates can be used online, this is my personal profile on bluesky with verification that is independent of the Blue sky service:
https://bsky.app/profile/bitlooter.bsky.social
If you click on the profile image you can enter that code into https://certisfy.com/app to verify the identity of the profile. That sticker could be on any online profile to prove high quality authenticity, it could for instance be on an e-commerce site to prove that the site isn't a scam.
If the hammer ever comes down on this issue, ie hardcore requirement for age verification, there are ways to do this while protecting privacy.
We are experimenting with bootstraping a PKI certificate trust chain for facilitating trust projection and information verification online. Think of it as the ability to do things like age verification at scale via a peer-2-peer ish mechanism instead of sending your government id to a service provider.
One experiment is with PGP key holders (for now Keybase key holders) as CAs:
It's all self-service and requires no sign-up or download of anything, the app (https://certisfy.com/app) is an in-browser app and all the cryptography happens in the browser.
Trying to bootstrap a PKI certificate trust chain for facilitating trust projection and information verification online. Think of it as the ability to do something such as age verification at scale via a peer-2-peer ish mechanism instead of sending your government id to a porno service.
We are experimenting with Keybase key holders as CAs:
It's all self-service and requires no sign-up or download of anything, the app (https://certisfy.com/app) is an in-browser app and all the cryptography happens in the browser.
In general Just-In-Time app generation is a bad idea. The right approach is to create human-in-loop tools that a bot would recognize and invoke as needed, of course the human-in-loop tool would itself be AI generated.
Not to make excuses for plagiarism, I am looking at the code itself and somewhat scratching my head since it seems quite...trivial?
I don't mean to belittle the effort but at least in terms of volume of code and level of effort, I wouldn't recognize it as mine if someone had copied it from my work and passed it off as theirs.
Regarding the charge of plagiarism, is it possible that the PR attribution reflects someone eager to contribute something to a larger effort as opposed to simply trying to "steal" someone else's work?
One could reasonably interpret the PR and attribution as "I integrated this code into this project thus I am taking credit for it". In other words there is probably a stronger charge for misguided clout-chasing than plagiarisms.
>As someone who appreciates machine learning, the main dissonance I have with interacting with Microsoft's implementation of AI feels like "don't worry, we will do the thinking for you".
This the nightmare scenario with AI, ie people settling for Microsoft/OpenAI et al to do the "thinking" for you.
It is alluring but of course it is not going to work. It is similar to what happened to the internet via social media, ie "kickback and relax, we'll give you what you really want, you don't have to take any initiative".
My pitch against this is to vehemently resist the chatbot-style solutions/interfaces and demand intelligent workspaces:
1.Backup and recovery with this solution is no different from backup and recovery of your phone. It is a potential issue but not unique. Cryptographic certificates and associated keys reside on your device.
2.The data format issue is (or was) indeed a concern though it was never insurmountable. A data dictionary would have been the most straight forward approach to address it: https://cipheredtrust.com/doc/#data-processing
I say data format discernment was a concern because as faith would have it, we now have the perfect tech to address that, LLMs. You can shove any data format into an LLM and it will spit out a transformation into what you are looking for without the need to know the source format.
Browsers are integrating LLM features as APIs so this type of use would be feasible both for front and back end tasks.
My motivation is less about self-promotion at this point and perhaps just frustration with the face-palm quality of the failure to properly implement information verification on the internet.
Every time I hear about some dumb approach to age verification (conversation analysis...really?) or a romance scam story because of a fraudster somewhere in Malaysia..I have the need to scream...THERE IS A CORRECT SOLUTION.
It is also highly compatible with the internet both in terms of technical/performance scalability and utility scalability (you can use it for just about any information verification need in any kind of application).
Yes it has proven quite a useful feature. Primarily for the reason stated above, allowing users to get a full log of what's going on in the same session that the core task is taking place.
We also use it extensively to facilitate back-and-forth conversation with the agents, for instance a lot of our human-in-loop capabilities rely on the forking functionality...the scope of its utility has been frankly surprising :)
In Solvent, the main utility is allowing forked-off use of the same session without context pollution.
For instance a coding assistant session can be used to generate a checklist as a fork and then followed by the core task of writing code. This allows the human user to see the related flows (checklist gen,requirements gen,coding...etc) in chronological order without context pollution.
The verifier is the entity you hand your information to for verification, ie the CA. The extent of your interaction and linkage with them is mainly at point of verification and issuance.
It is however possible to trace a certificate to it's issuer, which on the surface sounds like a bad thing, but is in fact good if the goal is to provide privacy while ensuring accountability.
You use the ID to create an IRL identify anchor certificate, then use other certificates with varying privacy profiles that are then cryptographically linked to your identity but in a privacy preserving manner.
https://blog.codesolvent.com/2025/07/ai-assistant-with-biome...
Happy to chat if intrigued.