I've been analyzing a setup called BountyDesk, which attempts to solve this by using an LLM agent to do the heavy lifting while keeping a human strictly in the loop for the final verdict. It’s built on the TrueForge agent harness, and the core philosophy is that the agent can draft the response, but it physically cannot publish it without a manual sign-off.
The Workflow Logic #
The system doesn't just "chat" with a bug report. It follows a very specific, hardened data path to ensure that an AI hallucination doesn't accidentally close a critical vulnerability report. Here is how the pipeline actually moves:
GitHub issue
-> signed intake
-> durable worker
-> TrueForge agent session
-> sandbox investigation
-> approval-gated verdict draft
-> reviewer approval
-> idempotent GitHub comment
The "approval-gated" part is the most important bit for anyone running a production security program. The agent performs the investigation inside an isolated sandbox (using Daytona) to see if the bug is actually reproducible. It then drafts a verdict. That verdict sits in a queue until a human reviews the exact wording. Only after that approval does the system post the comment back to GitHub.
Architecture and Deployment #
The design philosophy here is about separation of concerns. You have three distinct layers: the control plane (BountyDesk), the agent runtime (TrueForge), and the target runtime (Daytona). By splitting these, the system ensures that the web interface never has direct access to sensitive GitHub installation tokens or the sandbox environment.
If you are looking at the technical implementation, the stack is surprisingly lean, which is great for a reliable deployment:
Application Layer: Next.js App Router, React, and TypeScript.Database & State: Postgres on Supabase using Drizzle ORM.Job Queue: Instead of using a heavy external broker, it uses Postgres withSELECT ... FOR UPDATE SKIP LOCKED
for durable job management.Agent Intelligence: TrueForge handles the sessions, sub-agents, and tool calling.Sandbox Environment: Daytona provides the runtime where the actual "investigation" happens.Integration: GitHub App webhooks for intake and short-lived installation tokens for delivery.
One thing that stood out to me during my deep dive is the use of Postgres as the queue. In a high-volume triage environment, you need real row locks to prevent multiple workers from grabbing the same bug report. Using a durable Postgres job table with worker leases is a much more robust way to handle webhooks than a simple in-memory queue.
It's a practical tutorial in how to build an AI workflow that actually works in a professional setting. You aren't just letting an LLM loose on your GitHub issues; you are giving it a specialized sandbox, a set of MCP tools, and a very short leash.
Next QuEra is using Claude to fix their quantum lasers in seconds →
a guide to making money with AI, with plenty of directly applicable cases.