shivsarthak
4 hours ago
I built Doozy because support at my company (Spur) is understaffed and kept waiting on engineering to run a query for a customer, or to check whether something was a bug. The first version was a Slack bot with read access to our Postgres and Stripe, and it was very hacky. It could barely read files sent in a thread, but the agent was smart enough to find them through Slack search and finish the task anyway. It got used far more by support and success than by engineers, which surprised me. 13 people at Spur use it every day; it's basically a critical part of the team now.
Doozy is the rebuilt, multi-tenant version. You mention it in a thread with a task, it runs the task against your systems (database, Stripe, GitHub, Linear, PostHog, any MCP server, the web) in its own isolated environment, and posts the result and files in the thread.
How it touches production:
- Every job runs in a fresh sandbox (E2B today) with no credentials in it. Model calls, tool calls and git go through gateways outside the sandbox that add credentials per request. A prompt injection can make the agent misuse the tools it has, but it can't exfiltrate a key, because there isn't one to read. - Secrets the agent genuinely needs inside the sandbox (an SSH key, a CLI token) are handed over only when it asks for a named secret with a reason, and that request is logged. - Tools marked destructive start denied. Owners turn them on per tool. - Every external action writes a receipt in the thread and an append-only audit log.
Per-workspace pricing, no seats. 14-day trial, no card, install takes a couple of minutes.
Happy to go deep on the sandbox and gateway design.
user
3 hours ago