# Building Data Watchdog: A Two-Gate Approval Agent on TrueForge > Source: > Published: 2026-08-30 11:51:38+00:00 I went into the WeMakeDevs Agent Harness Hackathon wanting to build something using TrueForge's approval-gate system properly — not just have a model promise to "ask before doing things," but actually have the harness enforce that pause. Here's how it went, dead ends included. Starting point: the Approval-Gated Assistant The hackathon's example ideas list a simple starting point: an agent that drafts something (an email, a ticket) and pauses before doing anything irreversible. I picked Gmail as the connected tool, since I already had an account. That turned out to be the first wall. Gmail's MCP server requires a Google Cloud OAuth Client set up on the developer side, and even after wiring up the OAuth consent screen, scopes, and redirect URI, TrueForge's connector kept failing with a DCR (Dynamic Client Registration) error — Gmail's MCP endpoint doesn't support DCR, and TrueForge's UI only offered sign-in via DCR, not manual Client ID/Secret entry. After a few rounds of trying to force it, I switched to GitHub instead — a built-in catalog connector, header-auth based, and much simpler to wire up with a personal access token. Getting the approval gate to actually work The UI doesn't expose a "require approval" toggle per tool — that setting only exists at the API level, in the agent manifest: json "mcp_servers": [ { "name": "github", "enable_tools": ["@all"], "require_approval_for_tools": ["issue_write"] } ] Once I set this via a direct PUT /api/v1/agents/ call, the harness genuinely paused before creating a GitHub issue — showing the raw tool-call request and an Allow/Deny button. That was the moment the project started feeling like a real approval-gated agent rather than a polite prompt. **Wanting more: trying an Analytics Agent** With the certificate basically secured, I decided to push for an actual competitive submission and picked the Analytics Agent idea — natural language question → SQL → execution → explanation. This meant enabling TrueForge's sandbox, which currently only supports Daytona as a provider. I hit another wall here: Daytona rejected my API key from inside TrueForge, even though the same credentials worked fine locally on my own machine — never fully resolved why. Rather than keep debugging an external dependency close to deadline, I built a small custom MCP server in Python (using the mcp SDK) that exposes a run_sql tool directly over a local SQLite database (the Chinook sample dataset — a music store with customers, invoices, and genres). This sidestepped Daytona entirely, reused the same header-auth-free custom-connector pattern TrueForge supports, and got me a working SQL tool in under 20 minutes once the direction was clear. **The idea that tied it together: Data Watchdog** Rather than treat the GitHub agent and the analytics agent as two separate, generic submissions, I combined them into one agent with two independent approval gates and real branching logic: Agent proposes a SQL query against the database → pauses for approval → runs it Agent evaluates the result against a stated rule (flag if a category's revenue is more than 30% below the average) If the threshold is met: agent drafts a GitHub issue with the finding as evidence → pauses for approval again → creates it If not: agent reports the finding in chat and stops — no second approval, no issue I tested both branches explicitly. Asking about the lowest-revenue genre in the Chinook database correctly triggered both approval gates and created a real GitHub issue with the underlying numbers as evidence. Asking about the highest-revenue genre correctly reasoned through the same threshold and concluded there was nothing worth flagging — no issue created, no second gate triggered. That branching is what convinced me this was a genuine decision point, not a fixed two-step pipeline dressed up as one. **Code quality with Qodo** I connected Qodo to the GitHub repo early and ran every meaningful change through a pull request rather than pushing straight to main. Qodo reviewed each PR automatically — checking for bugs, rule violations, and requirement gaps — and reported no issues on the changes that shipped. **What I'd do differently** If I'd picked GitHub as my connector from the very start instead of chasing Gmail's OAuth flow, I'd have had a lot more runway to build something more ambitious with the sandbox itself. The lesson that stuck with me: TrueForge's built-in catalog connectors (GitHub, Linear, etc.) are dramatically less friction than anything requiring custom OAuth setup, and that's worth weighing heavily when time is tight. **Links** Repo: github.com/satvik8954/Wemakedevs Qodo-reviewed PRs: #1, #2 (Data Watchdog)