My setup is Hermes on a beefy machine with running a swarm of pi.devs - connects to GH issues via bot app so I can call it @xxxx in the issue. It can create PR, run actions and all. If I want to see the code I just run kilo code in VS locally.
This setup is so plain and simple that it just works, and it works wonders. I feel like I’ve been running a dev team who actually communicates through issuess and keeps it up to date!
honestly its really more simple than it sounds. Get yourself a VPS, install hermes there and use this UI https://github.com/nesquena/hermes-webui next command Hermes to setup pi.dev as a coding agent on that host and ask it to connect to github - it will literally guide you through the setup or if given permissions - will do it for you. I'm using deepseek-flash and its dirt cheap and effective. Explain to hermes to setup webhook listeners from github about activities and comments in issues and PRs, register a github app so it can post from its own profile rather than you yours.
Thats it, that's the minimal setup, from here you can develop it in many ways.
Do you think it would make sense to create a blog post out of it?
Wait, isn't that how everyone is building their harnesses? I actually struggle to imagine an alternative. Just keeping a a single row in the DB for chat history and always overwriting that?
Maybe I'm biased because we are primarily building a chat interface ala ChatGPT, which isn't anything different than a "remote harness". I'm not sure why one would design a local harness differently.
I think a lot of people are building their harnesses this way more recently, but last year, Claude, Codex (and other harnesses) were storing everything on a big json file on disk.
Codex has (to my knowledge) always stored sessions in append-only .jsonl files. Whether you store an append-only log in a file or a database makes no difference.
It really feels like I'm being gaslight here into believing "durable agents" are novel. All I'm seeing is the API that is behind any Chat Web UI. Persistence, resumability, recovery from errors and branching and forking have been table stakes there since the release of the first ChatGPT.
Yep, I think that all harnesses will require native durability, and pi-durable is a step in the right direction. I'm skeptical of bolted-on durability, like vercel's durable-harness, because they have to neuter the harness for things they can't reliably make durable (e.g. https://github.com/vercel-labs/durable-harness/blob/fb056a3c...)
The two concepts of Durable Agents and Distributed Tools pair really well together.
- At work, I don't want to run agents on our overworked and unstable on-prem infra, but there is data we need to access there, so I build agents in the cloud and have on-prem services that listen for work.
- At home, I want to access my agents from the internet, but I don't want to punch holes in my network, so I build agents in the cloud and have at-home services that listen for work.
Of course, it's a bit slower than a single process with local tools, but it can still be a very productive user experience.
And then I think... we're not really inventing something new with Durable Agents and Distributed Tools, we're just moving closer to the event driven architectures that we already know. I can build a durable agent with Lambda Durable Functions and waitForCallback or Lambda Step Functions and waitForTaskToken. Or any pool of compute with a queue or two and persistent state.
So I guess my thought is... you don't need to learn a harness to build an agent. Use what you know. If a harness helps you conceptualize, use it.
I've built sth similar that acts as a mobile interface to your desktop setup via the multiplexer of your choice (herdr/tmux/zellij).
https://github.com/AltanS/collie
There's also a typescript SDK to connect a durable agent/harness to the app, still experimental though.
Our primary focus is a stateful API for you to manage / interact with agents. We manage all of the complicated parts (conversation persistence, sandboxes, MCPs, etc), which allow users to focus on building their product-specific agents on top.
On our managed platform, you can buy credits which you can spend on tokens and on sandboxes (which are priced at cost + a 5% fee). If you want to self host, you can also do that.
> A detailed I noted on permissions - looks like they're all prefixed with "always" - I think allow/deny/ask make more sense ?
Yeah, the wording can probably be improved here, thanks for the feedback!
Yeah, even as someone building in the space, I sometimes get confused on what and who I'm actually building for.
What we've settled on is that Omnara is a tool for building agents. It's for people putting agents into their own products or workflows using the API. If you're not going to use the API, you probably don't need Omnara. Think of it like Supabase, Supabase gives you a Postgres database behind an API, and the dashboard is there for convenience, but your app talks to the API. Omnara does the same for agents. The UI is handy for watching and poking at agents, or visual analytics, but the API is the main product.
Or more directly, you can think of it like the codex app server or opencode server. Their clients (e.g. the TUI and desktop apps) talk to that server to start and interact with agents. Omnara is the same kind of server, except it runs in the cloud or on your own servers instead of your laptop. We don't provide a client though, you build that.
Can you shed some light on orchestration? I don't want to babysit them. Do you have a concept of roles and hierarchies, like team lead, tester, engineer, etc?
looks cool. how's that different from things like markbase dispatch where you can fire up the agent remotely with some given context. i mean what is the advantage of having the agent run always vs start and stop when you need it but give it a long-term memory context? maybe i'm missing something.
not sure I fully understand the question, but in Omnara, the agent isn't always "running". When it's idle (e.g. waiting for user input, or tool results), the agent is just rows in postgres with nothing happening to them. When a tool result returns or a new input comes in through the API, then a worker is allocated to the agent and starts "running" the agent again.
Nothing special with caching in Omnara, works pretty much the same way as any other harness (we do pretty much what pi/opencode/goose do) since the cache lives on the provider's side. We rebuild the model request by reading from postgres instead of jsonl or sqlite, and the rest is the same as any other harness.
i was looking for good self-hostable durable agents to automate a persistent keyword watcher across sm. gonna give this a go. any pointers you recommend?
nice, this is close to something we run ourselves. we put up examples of sm agents that scan socials daily for keywords and DMs us (docs here https://docs.omnara.com/examples/x-signal-agent). probably the fastest starting point is to point your agent to it and ask it to swap in your keywords
> The loop runs on stateless workers in the control plane. A worker runs one iteration
> of the loop, either a model call or the tool calls it produced, then releases the
> agent and puts the next iteration on a queue in Postgres.
...
> Also unlike other harnesses, the machines that the workers (our agent loop) run on aren't
> where the agent runs its commands.
It's late but don't think I am grokking this.
Isn't running the commands the heavier part of the work? The agent loop itself is mostly waiting for a remote model and then running the commands?
Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against (which can't be stateless like the workers are?)
> Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against
You don't! You can have a single worker running thousands of agents at once, since they're mostly waiting on the model. You can add more workers for scaling to even more agents, and for redundancy (if one worker goes down, another one can keep the agents going)
The machines are the expensive part (after tokens, of course), which is why we split the execution environment machine from the agent loop. Most harnesses run the loop on the same machine as the shell tools, so every agent needs its own VM for its entire life, even though it spends most of that time waiting on the model or tools or external inputs. Because they're decoupled in Omnara, an agent can use 0, 1, or n machines. Agents whose workloads don't need a machine can go without one entirely, and an agent's machine can sleep or go offline without stopping the agent.
My setup is Hermes on a beefy machine with running a swarm of pi.devs - connects to GH issues via bot app so I can call it @xxxx in the issue. It can create PR, run actions and all. If I want to see the code I just run kilo code in VS locally.
This setup is so plain and simple that it just works, and it works wonders. I feel like I’ve been running a dev team who actually communicates through issuess and keeps it up to date!
I’m curious why you have Hermes using Pi and not just Hermes writing the code itself or spinning up subagents to do that?
Can you provide a link to Hermes/a short insight on your setup? It is quite interesting (I like minimal setup)
honestly its really more simple than it sounds. Get yourself a VPS, install hermes there and use this UI https://github.com/nesquena/hermes-webui next command Hermes to setup pi.dev as a coding agent on that host and ask it to connect to github - it will literally guide you through the setup or if given permissions - will do it for you. I'm using deepseek-flash and its dirt cheap and effective. Explain to hermes to setup webhook listeners from github about activities and comments in issues and PRs, register a github app so it can post from its own profile rather than you yours. Thats it, that's the minimal setup, from here you can develop it in many ways.
Do you think it would make sense to create a blog post out of it?
Would love a blog post!
Sure.
with a great related talk! https://ai.engineer/talks/UPwGaM2MKHY-log-is-agent
Wait, isn't that how everyone is building their harnesses? I actually struggle to imagine an alternative. Just keeping a a single row in the DB for chat history and always overwriting that?
Maybe I'm biased because we are primarily building a chat interface ala ChatGPT, which isn't anything different than a "remote harness". I'm not sure why one would design a local harness differently.
I think a lot of people are building their harnesses this way more recently, but last year, Claude, Codex (and other harnesses) were storing everything on a big json file on disk.
Codex has (to my knowledge) always stored sessions in append-only .jsonl files. Whether you store an append-only log in a file or a database makes no difference.
It really feels like I'm being gaslight here into believing "durable agents" are novel. All I'm seeing is the API that is behind any Chat Web UI. Persistence, resumability, recovery from errors and branching and forking have been table stakes there since the release of the first ChatGPT.
[flagged]
thanks swyx! the log is the agent is a core insight behind this
you beat pi-durable to it!
haha yes! this was the reasoning for making durability native in our harness
feels like everyone is converging on durable agents lately: pi durable, cloudflare agents on durable objects, vercel's durable harness
Yep, I think that all harnesses will require native durability, and pi-durable is a step in the right direction. I'm skeptical of bolted-on durability, like vercel's durable-harness, because they have to neuter the harness for things they can't reliably make durable (e.g. https://github.com/vercel-labs/durable-harness/blob/fb056a3c...)
The two concepts of Durable Agents and Distributed Tools pair really well together.
- At work, I don't want to run agents on our overworked and unstable on-prem infra, but there is data we need to access there, so I build agents in the cloud and have on-prem services that listen for work.
- At home, I want to access my agents from the internet, but I don't want to punch holes in my network, so I build agents in the cloud and have at-home services that listen for work.
Of course, it's a bit slower than a single process with local tools, but it can still be a very productive user experience.
And then I think... we're not really inventing something new with Durable Agents and Distributed Tools, we're just moving closer to the event driven architectures that we already know. I can build a durable agent with Lambda Durable Functions and waitForCallback or Lambda Step Functions and waitForTaskToken. Or any pool of compute with a queue or two and persistent state.
So I guess my thought is... you don't need to learn a harness to build an agent. Use what you know. If a harness helps you conceptualize, use it.
I've built sth similar that acts as a mobile interface to your desktop setup via the multiplexer of your choice (herdr/tmux/zellij). https://github.com/AltanS/collie
There's also a typescript SDK to connect a durable agent/harness to the app, still experimental though.
been following you guys from distance over x. congrats on the launch! excited to see where this goes
appreciate it!
Congratulations on the launch - looks interesting, and matches some thoughts I've had regarding herding LLMs in a sensible and secure manner.
What's the product? Can I buy anything right now?
A detailed I noted on permissions - looks like they're all prefixed with "always" - I think allow/deny/ask make more sense ?
Our primary focus is a stateful API for you to manage / interact with agents. We manage all of the complicated parts (conversation persistence, sandboxes, MCPs, etc), which allow users to focus on building their product-specific agents on top.
On our managed platform, you can buy credits which you can spend on tokens and on sandboxes (which are priced at cost + a 5% fee). If you want to self host, you can also do that.
> A detailed I noted on permissions - looks like they're all prefixed with "always" - I think allow/deny/ask make more sense ?
Yeah, the wording can probably be improved here, thanks for the feedback!
There is so much stuff in AI space. AI orchestrators, automations, harnesses. I often can't tell what is the difference between projects.
I started thinking is it something like 'ruflo', or 'mirofish', or is it something else totally
Yeah, even as someone building in the space, I sometimes get confused on what and who I'm actually building for.
What we've settled on is that Omnara is a tool for building agents. It's for people putting agents into their own products or workflows using the API. If you're not going to use the API, you probably don't need Omnara. Think of it like Supabase, Supabase gives you a Postgres database behind an API, and the dashboard is there for convenience, but your app talks to the API. Omnara does the same for agents. The UI is handy for watching and poking at agents, or visual analytics, but the API is the main product.
Or more directly, you can think of it like the codex app server or opencode server. Their clients (e.g. the TUI and desktop apps) talk to that server to start and interact with agents. Omnara is the same kind of server, except it runs in the cloud or on your own servers instead of your laptop. We don't provide a client though, you build that.
Can you shed some light on orchestration? I don't want to babysit them. Do you have a concept of roles and hierarchies, like team lead, tester, engineer, etc?
looks cool. how's that different from things like markbase dispatch where you can fire up the agent remotely with some given context. i mean what is the advantage of having the agent run always vs start and stop when you need it but give it a long-term memory context? maybe i'm missing something.
not sure I fully understand the question, but in Omnara, the agent isn't always "running". When it's idle (e.g. waiting for user input, or tool results), the agent is just rows in postgres with nothing happening to them. When a tool result returns or a new input comes in through the API, then a worker is allocated to the agent and starts "running" the agent again.
How does this interact with / take advantage of context caching?
Nothing special with caching in Omnara, works pretty much the same way as any other harness (we do pretty much what pi/opencode/goose do) since the cache lives on the provider's side. We rebuild the model request by reading from postgres instead of jsonl or sqlite, and the rest is the same as any other harness.
i was looking for good self-hostable durable agents to automate a persistent keyword watcher across sm. gonna give this a go. any pointers you recommend?
nice, this is close to something we run ourselves. we put up examples of sm agents that scan socials daily for keywords and DMs us (docs here https://docs.omnara.com/examples/x-signal-agent). probably the fastest starting point is to point your agent to it and ask it to swap in your keywords
looks great
It's late, but I'm not grokking this:
> The loop runs on stateless workers in the control plane. A worker runs one iteration > of the loop, either a model call or the tool calls it produced, then releases the > agent and puts the next iteration on a queue in Postgres. ... > Also unlike other harnesses, the machines that the workers (our agent loop) run on aren't > where the agent runs its commands.
It's late but don't think I am grokking this.
Isn't running the commands the heavier part of the work? The agent loop itself is mostly waiting for a remote model and then running the commands?
Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against (which can't be stateless like the workers are?)
> Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against
You don't! You can have a single worker running thousands of agents at once, since they're mostly waiting on the model. You can add more workers for scaling to even more agents, and for redundancy (if one worker goes down, another one can keep the agents going)
The machines are the expensive part (after tokens, of course), which is why we split the execution environment machine from the agent loop. Most harnesses run the loop on the same machine as the shell tools, so every agent needs its own VM for its entire life, even though it spends most of that time waiting on the model or tools or external inputs. Because they're decoupled in Omnara, an agent can use 0, 1, or n machines. Agents whose workloads don't need a machine can go without one entirely, and an agent's machine can sleep or go offline without stopping the agent.
Anthropic has a good post on this architecture: https://www.anthropic.com/research/managed-agents
Wow Literally what I was looking for.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]