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.
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.