Cool to see more people building in this space. I'm the founder of Gobii (gobii.ai). We've been running autonomous agents in production for about 8 months now, so a lot of what you're describing resonates.
Our agents get their own identity: dedicated phone numbers, email addresses, comms channels. They operate 24/7 as persistent entities rather than ephemeral chat sessions. They handle inbound and outbound communications, manage workflows across tools, and maintain context over long-running interactions.
The thing nobody tells you about "autonomous" agents is that the hard part isn't getting them to work. It's getting them to work reliably at 3am on a Saturday when nobody's watching. We've spent the majority of our time on failure handling, security hardening, and making sure an agent with real credentials can't do something catastrophic when it encounters an edge case it's never seen before.
The event-driven approach you're describing with the Event Hub is interesting. Silence detection especially. We've found that knowing when something didn't happen is often more valuable than reacting to what did.
We recently wrote up a detailed architectural comparison between Gobii and OpenClaw that covers a lot of these patterns: always-on runtime design, event triggers, memory, browser execution, security posture. https://gobii.ai/blog/gobii-vs-openclaw/ Relevant here because the overlap between what you're building and what both of these projects are doing is pretty clear. The space is converging fast.
Curious how you're thinking about identity and trust boundaries for agents that have access to 10,000+ services. That's been one of our biggest areas of focus: scoping permissions so agents have exactly what they need and nothing more.
Thanks for sharing — sounds like you've dealt with similar
challenges.
On identity and trust boundaries: each agent in Splox runs
with isolated credentials scoped to the tools the user
explicitly connects. Agents can't discover or access services
beyond what's been granted. The MCP protocol helps here —
tool access is defined per-connection, so permissions are
inherently scoped rather than bolted on after the fact.
For the "3am on Saturday" problem — that's exactly why we
built the Event Hub with silence detection. If an agent stops hearing from a service it's
monitoring, it reacts to that. Subscriptions state persists across
restarts.
Interesting direction — especially the event-driven autonomy part.
One thing I’ve noticed while working on founder tooling is that the biggest challenge isn’t building agents anymore, but deciding, what workflows are actually worth automating before people invest time connecting tools and infrastructure.
Curious how you’re seeing users define successful agent tasks — are they mostly repetitive operational workflows, or more decision-based use cases?
Also wondering how you handle failure states when an agent runs long-term without supervision.
On what's worth automating: it splits roughly into two camps.
The most common are repetitive operational things — monitoring
markets, responding to messages, deploying code, updating
spreadsheets. But the more interesting use cases are
decision-based: the trading agent deciding when to open/close
positions, or a support agent deciding whether to escalate.
The Event Hub is what makes the decision-based ones viable.
Agents subscribe to real-time events and react based on
triggers — you can use structured filters or even natural
language conditions ("fire when the user seems frustrated").
So the agent isn't just on a cron loop, it's genuinely
reacting to context.
On failure states: agents have built-in timeouts on
subscriptions, automatic retries with exponential backoff,
and silence detection (they can react to the absence of
events, not just their presence). If something breaks, the
subscription expires and the agent can re-evaluate. Long-
running agents also persist their state across restarts so
they pick up where they left off.
There's also a workflow builder where you connect multiple
agents together in non-linear graphs — agents run async
and pass results between each other. So you can have one
agent monitoring, another analyzing, another executing —
all coordinating without a linear chain
That makes sense — the shift from task automation to decision automation feels like the real inflection point.
The silence detection aspect is especially interesting. Reacting to the absence of signals is something most workflow tools still struggle with, and it’s usually where long-running systems fail in practice.
Curious whether users tend to start with predefined agent patterns, or if they’re designing workflows from scratch once they understand the event model? I imagine abstraction becomes important pretty quickly as graphs grow.
Both, actually. Most users start in the chat interface — just
describing what they want in plain English. The agent figures
out which tools to use and how to react. No graph, no config.
Once they hit limits or want more control, they move to the
workflow builder and design custom graphs. That's where you
get non-linear agent connections — multiple agents running
async, passing results to each other. One monitors, one
analyzes, one executes.
Abstraction is definitely the challenge as graphs grow. Right
now we handle it by letting each node in the graph be a full
autonomous agent with its own tools and context. So you're
composing agents, not steps. Keeps individual nodes simple
even when the overall workflow is complex.
Our agents get their own identity: dedicated phone numbers, email addresses, comms channels. They operate 24/7 as persistent entities rather than ephemeral chat sessions. They handle inbound and outbound communications, manage workflows across tools, and maintain context over long-running interactions.
The thing nobody tells you about "autonomous" agents is that the hard part isn't getting them to work. It's getting them to work reliably at 3am on a Saturday when nobody's watching. We've spent the majority of our time on failure handling, security hardening, and making sure an agent with real credentials can't do something catastrophic when it encounters an edge case it's never seen before.
The event-driven approach you're describing with the Event Hub is interesting. Silence detection especially. We've found that knowing when something didn't happen is often more valuable than reacting to what did.
We recently wrote up a detailed architectural comparison between Gobii and OpenClaw that covers a lot of these patterns: always-on runtime design, event triggers, memory, browser execution, security posture. https://gobii.ai/blog/gobii-vs-openclaw/ Relevant here because the overlap between what you're building and what both of these projects are doing is pretty clear. The space is converging fast.
Curious how you're thinking about identity and trust boundaries for agents that have access to 10,000+ services. That's been one of our biggest areas of focus: scoping permissions so agents have exactly what they need and nothing more.
On identity and trust boundaries: each agent in Splox runs with isolated credentials scoped to the tools the user explicitly connects. Agents can't discover or access services beyond what's been granted. The MCP protocol helps here — tool access is defined per-connection, so permissions are inherently scoped rather than bolted on after the fact.
For the "3am on Saturday" problem — that's exactly why we built the Event Hub with silence detection. If an agent stops hearing from a service it's monitoring, it reacts to that. Subscriptions state persists across restarts.
The Event Hub is what makes the decision-based ones viable. Agents subscribe to real-time events and react based on triggers — you can use structured filters or even natural language conditions ("fire when the user seems frustrated"). So the agent isn't just on a cron loop, it's genuinely reacting to context.
On failure states: agents have built-in timeouts on subscriptions, automatic retries with exponential backoff, and silence detection (they can react to the absence of events, not just their presence). If something breaks, the subscription expires and the agent can re-evaluate. Long- running agents also persist their state across restarts so they pick up where they left off.
There's also a workflow builder where you connect multiple agents together in non-linear graphs — agents run async and pass results between each other. So you can have one agent monitoring, another analyzing, another executing — all coordinating without a linear chain
Once they hit limits or want more control, they move to the workflow builder and design custom graphs. That's where you get non-linear agent connections — multiple agents running async, passing results to each other. One monitors, one analyzes, one executes.
Abstraction is definitely the challenge as graphs grow. Right now we handle it by letting each node in the graph be a full autonomous agent with its own tools and context. So you're composing agents, not steps. Keeps individual nodes simple even when the overall workflow is complex.