Run support queries and bug checks from Slack threads
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. Task: 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.; tools: custom-built or unnamed agent. Human role: The original post does not say how a person stayed involved.; limitations: The system relies on specific infrastructure (E2B sandboxes, external credential gateways) and integrations (Slack, Postgres, Stripe, etc.). Security depends on the gateway architecture preventing key exfiltration, though prompt injection remains a risk for tool misuse. The source does not specify latency, concurrency limits, or the exact cost of the per-workspace pricing model. Human approval workflows for destructive actions are mentioned as a feature (owners turn them on) but not as a mandatory step for every action..
Tools
custom-built or unnamed agent
Published on Agent Work Atlas:
Overview
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.
Workflow
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.
Reported result
The source states that 13 people at Spur use the tool daily and it has become a critical part of the team, primarily used by support and success staff rather than engineers. However, no quantitative metrics regarding time saved, error reduction, or cost efficiency are provided. The author notes the first version was 'hacky' but functional, and the rebuilt version is multi-tenant. A measurable acceptance check would be to track the reduction in engineering tickets related to simple data queries after implementation.
Human role
The original post does not say how a person stayed involved.
Limitations
The system relies on specific infrastructure (E2B sandboxes, external credential gateways) and integrations (Slack, Postgres, Stripe, etc.). Security depends on the gateway architecture preventing key exfiltration, though prompt injection remains a risk for tool misuse. The source does not specify latency, concurrency limits, or the exact cost of the per-workspace pricing model. Human approval workflows for destructive actions are mentioned as a feature (owners turn them on) but not as a mandatory step for every action.
Try it
Act as a DevOps engineer implementing a Slack-based AI support agent for [Company Name]. 1. **Context**: Support team waits for engineering to run SQL queries on [Database Name] or check [Payment Provider] status. 2. **Setup**: Configure an agent that triggers on @mention in Slack threads. 3. **Security**: Ensure the agent runs in an isolated sandbox (e.g., E2B) with no stored credentials. Implement a gateway that injects credentials per request. 4. **Controls**: Default all destructive tools to 'denied'. Require manual enablement by workspace owners. 5. **Audit**: Log every external action with a receipt in the Slack thread and an append-only audit log. 6. **Dry Run**: Execute one sample query for [Specific Customer ID] and post the result. 7. **Confirmation**: Wait for human review of the sample output before enabling broader access. Deliverables: A configuration file for the agent, a list of enabled tools, and a sample audit log entry. If inputs are missing, ask for the database schema and Slack workspace ID.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.