| ▲ | Show HN: Running local OpenClaw together with remote agents in an open network(github.com) | ||||||||||||||||||||||
| 7 points by kevinlu 4 hours ago | 8 comments | |||||||||||||||||||||||
Hi HN — I’m building an interoperability layer for AI agents that lets local and remote agents run inside the same network and coordinate with each other. Here is a demo: https://youtu.be/2_1U-Jr8wf4 • OpenClaw runs locally on-device • it connects to remote agents through Hybro Hub • both participate in the same workflow execution The goal is to make agent-to-agent coordination work across environments (local machines, cloud agents, MCP servers, etc). Right now most agent systems operate inside isolated runtimes. Hybro is an attempt to make them composable across boundaries. Curious what breaks first when people try running cross-environment agent workflows in practice. Project: https://hybro.ai Docs: https://docs.hybro.ai | |||||||||||||||||||||||
| ▲ | tensor-fusion 3 hours ago | parent | next [-] | ||||||||||||||||||||||
Interesting direction. One adjacent workflow we've been looking at is cross-environment execution where the agent / dev loop stays local, but GPU access lives elsewhere. In our case the recurring pain isn't only orchestration, it's making an existing remote GPU easy to attach to from a laptop or lab machine without shifting the whole workflow into a remote VM mindset. I'm involved with GPUGo / TensorFusion, so biased, but I think local-first + remote capability is going to matter a lot for small teams and labs. Curious whether you expect most users to want symmetric peer-style composition, or whether local-first control over remote resources ends up being the dominant pattern. | |||||||||||||||||||||||
| |||||||||||||||||||||||
| ▲ | aaztehcy 12 minutes ago | parent | prev | next [-] | ||||||||||||||||||||||
[dead] | |||||||||||||||||||||||
| ▲ | jeremie_strand 4 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
[dead] | |||||||||||||||||||||||
| ▲ | benjhiggins 4 hours ago | parent | prev [-] | ||||||||||||||||||||||
Hey - Really clean architecture on the outbound-only relay — solving the NAT problem that way is elegant. Curious how you’re thinking about observability once agents are actually running. You can see which agent handled a message and where, but do you get any visibility into what happened inside the session — like reasoning steps, tool calls, token usage per convo? The privacy routing layer is super compelling, but I’d imagine teams putting this into production would want that inner visibility too — especially for cloud agents where you’re effectively trusting a third party with execution. How are you thinking about debugging when a cloud agent gives an unexpected response? | |||||||||||||||||||||||
| |||||||||||||||||||||||