How to Handle Continuous Streams?

[walnutwaldo]

More of a discussion question

Scenario:
You want your agent to do some work for you that involves running / testing things like yarn start-server or something.
... Or maybe you want an agent to run some long-process jobs that it needs to check in on (training a LLM)
... Or perhaps you need it to use a website whose content changes over time (ex. YouTube)

Agents, including some I've built, need to work with continuous input streams that don't fit cleanly into the message-based model described in AgentOS. They also need to make temporal decisions that don't fit clearly into the wit model (decisions that involve waiting some time and then processing an event with new incoming events)

AgentOS is a very disciplined and beautiful piece of work for what its purpose was set out to be and covers a lot of use cases I've seen agents perform today. I'm curious how you think about things like this though going forward. In general, I'm pretty curious to hear about your vision of agents so would love to chat more if you'd like!

[lukebuehler]

Hey! Sorry I somehow missed your question. It's an excellent one and cuts to the very core of the architecture.

Yes, agent OS eschews the process model on purpose and forces everything into the message passing paradigm. This is primarily to make it a scalable architecture for the cloud, because my experience has taught me that is not feasible to run long-running processes (e.g. a linux process) for each user when you host such systems. But it's also a key part of the grit persistence model.

Some of the points your brought up can be solved relatively easy:

• agent OS will have timers, and wit functions will be able to ask to be woken up at intervals and times/dates. I'm working on this feature right now. This will allow deferred execution and waiting on things such as polling, and so on. The timer module will be part of the OS
• external events can be relatively high frequency and the OS is in charge of ingesting them. For example with the current web server in agent OS, you can already POST events to certain actors, and you could implement something like webhooks. If you need a custom process that watches a custom data source (like your YouTube example) then I'm not sure what the best strategy would be: either a companion program that lives outside the OS or a OS module/plugin that does run as a continuous process.
• a wit/actor could technically run relatively long for something like a training job, but I think it is better not to (but my mind is not made up on this). A probably better solution would be something like starting a linux process from within a wit and then checking back every so often. Or, again, just build an external "models training service" that works via message passing (start, complete, error, etc).

Generally, in systems design, message passing can replace a more pure (single) process model. We see this for example with various implementations of async (node, python, rust, etc). And this is actually an old topic that goes back to the origins of OOP and discussions over monolithic kernels vs. microkernels, and so on. Often, message passing is a bit more complicated to implement, but if you do it right, you get a lot of benefits. In the case of agent OS, you get the grit persistence and agent continuation. Plus it's actually quite nice to debug.

Absolutely happy to chat more!

[walnutwaldo]

Let's chat more! I'm very interested. [email protected]