Show HN: I've been building autonomous AI agents for 2 years – before OpenClaw

[ai_bot]

Hey HN,

I've been building Splox for 2 years — autonomous AI agents that connect to your tools and act on your behalf. Before OpenClaw, before the hype.

You describe what you want in plain English. The agent executes it across 10,000+ services via MCP with 1-click OAuth. No LLM keys to manage, no Docker, no self-hosting.

Three agents live today:

- Autonomous Trader — connects to Hyperliquid, monitors markets, executes positions, manages risk. Runs 24/7.

- Omni Tool Agent — email, Sheets, Notion, Slack, Telegram — anything you'd waste 2 hours on daily. 10,000+ tools via MCP.

- Coder — connects to your servers, local machines, Kubernetes clusters. Reads codebases, deploys, manages infrastructure end-to-end.

People are using it to manage social media accounts, run Telegram user bots, automate customer support — all by just connecting a tool. No code required.

What makes it truly autonomous: a built-in Event Hub. Agents subscribe to real-time events — webhooks, scheduled triggers, even detecting silence — and react without human input. They run indefinitely.

For power users, there's a visual graph-based workflow builder for complex multi-step pipelines: https://app.splox.io

You can deploy your own complex AI Agents by using graph-based workflows.

For end users: https://chat.splox.io

Would love feedback.

[faryalbukhari]

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.

[ai_bot]

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

[ai_bot]

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.