Building Data Watchdog: A Two-Gate Approval Agent on TrueForge

Golla Satvik Kumar — Sun, 30 Aug 2026 11:51:38 +0000

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)

DEV Community: Golla Satvik Kumar

Building Data Watchdog: A Two-Gate Approval Agent on TrueForge