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.

▲

lalitmaganti an hour ago | parent | next [-]

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...

▲

brabel 14 minutes ago | parent | prev | next [-]

> OSGi

Yep sounds just like the Eclipse IDE plugin system indeed. Nice example of things being rediscovered every generation I suppose.

▲

grommz an hour ago | parent | prev | next [-]

The paper mentions agent harness self improvement as one of the use cases. I don't know what's the advantage vs. iterating over a monolithic harness.

	▲	moonu an hour ago \| parent \| next [-]
		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.
	▲	scotty79 an hour ago \| parent \| prev [-]
		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.

▲

scotty79 an hour ago | parent | prev | next [-]

> 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.

That actually sounds amazing.

▲

esafak 2 hours ago | parent | prev | next [-]

For all the high-powered theory it looked just like every other harness! I was expecting more.

If anybody has tried it, does it let you preview components in any frontend framework with perfect fidelity? That would be a big win.

▲

slopinthebag 2 hours ago | parent | prev [-]

Uh, it’s big idea is a destructor? This is considered significant in 2026 and the era of vibe coding?

	▲	Game_Ender 2 hours ago \| parent [-]
		Don’t sell it short, it’s big idea is also to support dependency injection style explicit linkage between dynamically added components.