-
Notifications
You must be signed in to change notification settings - Fork 21
Long‐running agents
Until this point all agentic processes in OpenAgents products have been loops running in browser using the multiple tool use looping from the Vercel AI SDK. This has been fine for close oversight of agents making large changes to a codebase, but limiting because it requires the user to have a browser tab open.
Next we need to move this to a background asynchronous process. We also now have a good idea of what prompts and guardrails are needed to give more latitude to long-running agents so they can be productive over longer timeframes and allowing multiple at a time.
Building this in our new Rust app at https://github.com/OpenAgentsInc/openagents
One loop I want is agents to write code in a Rust app, compile & run tests right away, and make changes based on any errors. This must occur locally and not use slow/expensive CI.
Agent should start from a plan. The plan may be a standalone piece of content like a Markdown doc or a GitHub issue. For the MVP we can use GitHub as source of truth for plans and docs though we'll want to plan to have only optional dependencies on GitHub not full dependencies where our service stops working in case of GitHub outage.
Users must be able to see a stream of updates on openagents.com as the agent works and interact with it.
That agent chat should also be compatible with docs/htmx-nostr-chat.md so multiple users can interact with the agent, like the agent could have an associated NIP28 channel it posts updates in.
Frontend for this is in static/. Note how we adapted the demo htmx-nostr code from fiatjaf to implement basic NIP28 functionality. We want to repeat that process, writing extensions for htmx, that add whatever functionality needed to interact with nostr and/or our Rust backend as needed.
We need to identify what should be handled by our backend and what should be handled by Nostr. Let's consider ONLY having our Rust app be itself a Nostr client, like use Nostr for storage etc. May have it be also a Nostr relay itself, at least partially. May be good to start by implementing NIP-01 as a relay and then experiment with it- let's make a GitHub issue for that.