I have read the underlying paper, and found it may be useful, but not that useful.
For those who want to know what it achieves: it adds hot-reload and dynamic enable/dispose capabilities to a plugin system, like the one in Pi agents, though they push the boundaries further, to the UI components and so on.
For those who want to know what it does: if you have some PLT knowledge, ask your agent to explain the algebra to you better; for those who aren't familiar, the framework requires each plugin to provide how it initializes and how it destructs (like C++'s RAII, Rust's Drop trait and so on), and the runtime will then properly handle the lifecycle events and the common pitfalls. In addition, it provides a clean way to declare the dependencies between plugins, and the runtime will also properly process the lifecycle changes on a broader plane.
I think it's worth reading if you are not familiar with OSGi, iPOJO, React's useEffect and so on (which the paper itself mentions); for others, a skim is enough: it does point out the gotchas for some common problems, but the algebra may not help you further.
This is basically similar to what bb (https://getbb.app/) is also doing. It's interesting to see many different people exploring things in this space...
certainly a time of great convergence. I set out to build a very similar thing both to build my own agent applications but also to learn more about how to build extensible software.
just read the paper, and there aee definitely some interesting ideas in it.
a plugin's registrations returning individual cleanup handlers is nice. in pi, you clean up all registrations in one go in the session-shutdown handler.
i also like the use of generator to to clean up partial registrations nicely.
the cross-plugin dependency injection and resolution i'm not so sure about. it comes with a lot of footguns and limitations as pointed out in the paper.
works ok within a single compilation unit, i.e. a plugin with many modules. does not help with typing of cross-plugin dependencies.
most plugins do not have dependencies on each other, so this more complex system doesn't win you much, e.g. with load order and conflicting registrations (i.e. two plugins registering the same tool).
being able to reload a single plugin on change while letting the others not in its dependents list jug along is neat. but that also only works if plugins actually declare dependencies (see last paragraph), and also has a lot of limitations. and the simple case, a plugin with no dependencies or dependents, which i'd say is the 90% case, does 't need that complexity either.
definitely cool stuff tho! remains to be seen how well it works in a real plugin ecosystem.
> they push the boundaries further, to the UI components
can you elaborate on this? pi extensions support contributions to the UI. in pi v1, they are limited to in-process UI. v2 splits server and client, and with that UI.
If you run the `dsh`, you can go to the Settings -> Plugins, and you can find that they just write all UI components as plugins(maybe not all, I don't check). Also, you may ask the harness to write a UI plugin for you, I just read some neat examples somewhere.
> it adds hot-reload and dynamic enable/dispose capabilities to a plugin system, like the one in Pi agents, though they push the boundaries further, to the UI components and so on.
This has been a pretty big topic of discussion recently with Prime Intellect's new harness making leaps on ARC 3's public dataset. This is probably a bit overstated considering that a big focus of the benchmark is to test the model without custom harnesses, but you can imagine how for some tasks, especially long running ones, this kind of on-the-fly context management + tool generation could be quite useful. It gets better over time, it can build shorthand and tools for token efficiency, like a loose approximation of continual learning.
It's modular by default so you can experiment freely, in-session. If you don't like some plugin you built, just disable it and move on. No need for tracking changes, reverting and so on if you keep your plugins focused.
I have some self-improving harness tooling, I run it within Claude Code because of the cost advantage but that does mean restarting Claude Code periodically so it can pick up all changes. It sounds like the DeepSeek system won't need that, which is useful.
Seems to be an raft.build competitor but open source.
BTW, from my very own opinion, IM is a great place for agents to chat, but not a good place for get work done. Something more comprehensive like Linear should be work better. Communication is a key stone but not all for the agents.
Durable execution was one of my most worth investing techniques 2024, and glad to see it's blooming in 2026. The idea behind it is pretty simple: persistent state machines, auto or semi-auto context capture, and a run engine, but it actually solves many common headaches like exactly once execution with retry, signal based workflow and so on.
I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner.
Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.
That doesn’t really apply to Gleam, it’s not a type syntax for another language that can be stripped, it’s its own language that compiles to Erlang and JS
We self hosted Kratos only as our IdP: three million total users, about 200k login/logout/session/jwt queries a day, using only four 1C 2G k8s pods with one extra for courier, a standard proxied 4c8g Postgres, everything works fine. Really easy to maintain with simple configuration and fully featured API.
But their documentation is really bad, especially in OSS suites. I generally use Claude Code to read their code, find the matching implementation, and try to figure out how to properly configure.
Anyway, if you need self host your IdP, just go for it, you cannot go wrong.
I'm reading some literature(fictions and non-fictions) reviews these days, and realized that literature itself, is just recording our lives in thousands or even millions of different views. The events in the real life can be similar or even identical, but will finally result in many different books, some of them are bad while others are masterpieces. Then I suddenly realized that why I hate some AI work as a long time content consumer, because that the creator behind them are just utilizing AI as a "tool", to quickly generate something meanlingless only for sensory stimulation, which stays at the surface-level, becoming a sort of cheap sensationalism works.
In contrast, I must admit that there are some AI assisted creations really shine , for example, generate an AR annotated POI image with nano banana(https://x.com/bilawalsidhu/status/1960529167742853378). But sadly, there are only 1% of creations, regardless it's an image, an audio or a video, are good, inspiring and exciting as previous ones.
Before AI can get a consciousness, it's a tool, no matter how "smart" it looks like. Only the human who use the tool smartly will create outstanding works.
Really happy to see some company that plays a key role that publish such a statement. Creativity comes from humanity, from our experience, our work, our connection.
AI may be not a theft, but it just sophisticated combinations from our wisdom. Until it can really create, the human will always win.
I have a serious question about the term "AI TOPS". I find many conflicting definitions while others say nothing. A meaningful metric should at least be well defined on its own term, like in "TOPS" or expanded "Tera Operations Per Second", what operation it will measure?
Seemingly NVIDIA is just playing number games, like wow 3352 is a huge leap compared to 1321 right? But how does it really help us in LLMs, diffusion models and so on?
It would be cool if something like vast.ai's "DLPerf" would become popular enough for the hardware producers to start using it too.
> DLPerf (Deep Learning Performance) - is our own scoring function. It is an approximate estimate of performance for typical deep learning tasks. Currently, DLPerf predicts performance well in terms of iters/second for a few common tasks such as training ResNet50 CNNs. For example, on these tasks, a V100 instance with a DLPerf score of 21 is roughly ~2x faster than a 1080Ti with a DLPerf of 10. [...] Although far from perfect, DLPerf is more useful for predicting performance than TFLops for most tasks.
From my very own perspective, to compare OpenAI with any others is meaningless: AI is far different in terms of resources and business models, maybe similar to some others, but it may collapse or have the rug pulled out by another significant technology evolution, e.g., quantum computer which may ridiculously speed up the training, or a more self-update-friendly model architecture.
To the rest of us, training a usable model these days is relatively affordable, and it seems to make no difference to use a "most intelligent" model against a subtly small model. The current business blocker is to find the application fields that work for models, which is not an area where OpenAI has an advantage.
For those who want to know what it achieves: it adds hot-reload and dynamic enable/dispose capabilities to a plugin system, like the one in Pi agents, though they push the boundaries further, to the UI components and so on.
For those who want to know what it does: if you have some PLT knowledge, ask your agent to explain the algebra to you better; for those who aren't familiar, the framework requires each plugin to provide how it initializes and how it destructs (like C++'s RAII, Rust's Drop trait and so on), and the runtime will then properly handle the lifecycle events and the common pitfalls. In addition, it provides a clean way to declare the dependencies between plugins, and the runtime will also properly process the lifecycle changes on a broader plane.
I think it's worth reading if you are not familiar with OSGi, iPOJO, React's useEffect and so on (which the paper itself mentions); for others, a skim is enough: it does point out the gotchas for some common problems, but the algebra may not help you further.