DEV Community: Romanch Roshan Singh

I built an autonomous treasury agent, then let a code review bot find every way it could lose money

Romanch Roshan Singh — Sat, 29 Aug 2026 17:18:30 +0000

I just submitted TreasuryForge to the WeMakeDevs × TrueFoundry Agent Harness Hackathon, an autonomous agent that manages a simulated treasury across cash, crypto, and NSE equities, built entirely on TrueForge, TrueFoundry's agent harness. This isn't a writeup about the idea. It's about what actually broke, what a code review bot caught before it shipped, and what I learned wiring a real approval gate into an agent loop.

The pitch, in one line

The strategy is deliberately dumb. The harness around it is what has to be strong. TreasuryForge doesn't try to out-trade the market: it demonstrates a safe decision loop, real tool calls, computed risk checks (not the model's own guess), a sandboxed stress test when something looks risky, a hard human approval gate before anything executes, and a second agent that audits the first one's history afterward.

Why TrueForge, not a custom app with an LLM bolted on

The hackathon's own bar for this was blunt: a judge has to see TrueForge reaching a tool, running code in a sandbox, and stopping for a person. If it'd work as well as a chat box, change the project.

So nothing here is custom orchestration:

What happens	TrueForge primitive
Agent calls a tool	A registered remote MCP server, not a function call from app code
A trade pauses for a human	TrueForge's native approval checkpoint, not a custom `/approvals` endpoint
Pre-trade analysis runs	TrueForge's own sandbox (bubblewrap-isolated), not a subprocess I spawned
Periodic self-review	`create_sub_agent`, a real child thread in the session, not the main agent reasoning longer

The wallet itself is a FastAPI + FastMCP server exposing get_portfolio, check_risk_limits, execute_trade, etc. TrueForge never touches the database directly: every mutation goes through MCP, gated behind the approval checkpoint and a shared secret.

The loop

Agent calls get_portfolio / get_transaction_log, read-only evidence.
Agent calls check_risk_limits for the exact trade it's considering. This is a computed answer (average-cost-basis P&L, a rolling daily-drawdown baseline, real concentration math), not the model eyeballing it. TrueForge's approval checkpoint pauses every execute_trade call unconditionally, so the four risk triggers can't live in TrueForge's own config; they have to be a real tool the human can trust.
If check_risk_limits reports a breach, the agent runs exactly one Python script in TrueForge's sandbox, with no network access, applying a correlated shock (crypto −20%, equities −10%) to the fetched position values and computing the resulting drawdown.
Agent proposes the trade with its reasoning. execute_trade independently recomputes its own risk snapshot server-side; it doesn't trust whatever the model claims in reason.
A human approves or denies via TrueForge's own user.tool_approval.
On request (or its own initiative after enough new trades), a sub-agent reviews the last 20 decisions, pulls real performance metrics, and backtests an alternative risk threshold in the sandbox. Real output from a proof run:

Current Threshold (5%): 3 decisions breached the limit. Alternative Threshold (7%): 0 decisions would have breached. Suggestion: relax the daily drawdown threshold. The current one flagged 3 of 20 recent trades as breaches despite portfolio equity remaining stable, while 7% still safely bounds risk below the historical 6.1% max drawdown observed.

What the code review bot actually found

Every PR went through Qodo before merging, and it wasn't style nitpicks. A few that stuck with me:

The approval gate had a bypass. Early on, the wallet server bound to 0.0.0.0 instead of localhost, and the reset endpoint had no auth. Nothing stopped a direct MCP call from skipping TrueForge's checkpoint entirely, the one thing the whole project exists to guarantee.

A trade could double-execute on retry. execute_trade reported failure to the caller after it had already committed the write. If the caller retried on that "failure," it would trade twice. Nastiest kind of bug: correct in the happy path, wrong exactly when something else already went wrong.

Fixing one race condition created another. Switching some FastAPI routes from async def to synchronous def (to stop blocking the event loop with SQLite calls) meant those routes now ran concurrently in a thread pool, which turned out to make the day-start risk-baseline rollover non-atomic. The fix for one review finding created a brand-new one, caught in the very next round. Then that fix had its own bug: the date was captured before acquiring the lock, so a stale thread could still overwrite a fresh baseline.

A test that didn't test what it claimed to. A migration race-condition test looked correct but wasn't actually exercising the race. Confirmed by deliberately sabotaging the code under test and checking the test still passed (it did, which meant the test was wrong, not the code, yet).

One finding I dismissed on purpose, not by accident. Qodo flagged that the dashboard's auth middleware fails open when no access secret is configured. True, but this project has exactly one operator and one deployment target (local, for a demo), not a production environment to fail closed in. I replied on the thread explaining why, and left it. Qodo accepted it and marked it resolved. Not every finding should turn into a fix; the point is deciding on the record instead of silently ignoring it.

The other war story: free-tier LLMs do not like a live demo

Gemini's free tier (gemini-flash-lite) ran out mid-testing on a single busy day. Groq's qwen3.8-27b has an 8,000 token-per-minute ceiling that's uncomfortably close to this agent's own ~4,600-token fixed per-turn overhead, fine for light use, not for rehearsing a demo repeatedly. I ended up wiring in OpenRouter as a third provider, verified two of its free models with an actual multi-turn tool-call round trip (two others that claimed tool support failed on the first real call), and made the one that held up the default. TrueForge's manifest takes a single model.name with no built-in runtime fallback between providers, so this is a fixed preference order picked at setup time, not live failover.

What's honestly still rough

Daytona (the cloud sandbox option) doesn't work on a personal, non-TrueFoundry-issued account: the image it needs lives in a private registry. The local bubblewrap sandbox is what this project actually runs on, and it's Linux/WSL2-only, no sandbox at all on native Windows.
No real historical price series, so the self-audit sub-agent's backtest replays already-computed risk snapshots, not a full market simulation.
The frontend has no automated test suite. A production build plus manual smoke-testing is what it's had so far, and I'd rather say that plainly than imply coverage that doesn't exist.

Try it / poke at it

Repo: github.com/codedpool/treasuryforge

If you're building anything with a real approval gate in the loop, I'd genuinely recommend running a code review bot against every PR before you trust your own read of it. Three of the bugs above are things I was completely confident were fine.

Why Your App Breaks for Indian Users (And How to Build Infrastructure That Doesn't)

Romanch Roshan Singh — Thu, 26 Feb 2026 17:55:03 +0000

The Incident

A startup founder came to me with a frustrating problem.

His e-commerce site worked perfectly on Wi-Fi. It worked on broadband. But the moment any of his customers opened it on Jio mobile data, they got a skeleton screen. No error message. No crash log. Just silence.

He had built the entire app using AI-generated code. Lovable, Bolt, ChatGPT, the whole vibe-coded stack. It looked great in demos. It worked fine on his laptop. But it was silently broken for a massive chunk of his actual user base.

Within an hour of looking at it, I had the root cause.

Supabase's API endpoints were being throttled or silently dropped by Jio's network at the ISP level. Not a bug in his code. Not a Vercel misconfiguration. A network-level routing problem completely invisible to anyone who doesn't understand what their stack is actually doing under the hood.

This Is Not Just a Supabase Problem
Before we get into the fix, let me give you the bigger picture because this will happen to you too if you are building apps for Indian users.

India has four major telecom providers that together serve over 1.1 billion mobile subscribers:

Jio (Reliance Jio): largest 4G/5G network in India, ~500 million subscribers
Airtel (Bharti Airtel): second largest, strong in urban and semi-urban areas
BSNL (Bharat Sanchar Nigam Limited): government-owned, widely used in rural and remote areas
Vi (Vodafone Idea): formed from the merger of Vodafone India and Idea Cellular

Each of these ISPs manages their own routing infrastructure, their own DNS resolvers, and their own peering agreements with international cloud providers. And they do not always behave the same way.

A site that loads instantly on Airtel may time out on Jio. A backend that works fine on BSNL may have degraded performance on Vi. This is not hypothetical. It happens regularly, it affects real businesses, and most developers building for Indian users have no idea it is a risk until it hits them in production.

Supabase themselves confirmed the Jio issue publicly:

Telling your users to install a VPN to use your app is not a solution. It is an acknowledgment that the infrastructure abstraction between your app and your vendor is broken. Here is how to fix it properly.

Step 1: Diagnose the Problem

Before touching any code, confirm the issue is ISP-level and not your own code.

Check global DNS resolution:
Go to whatsmydns.net and enter your backend URL. If it resolves fine everywhere but fails on specific mobile networks, it is ISP-level routing, not a code bug.

Test across networks:
Works on Wi-Fi, broken on Jio mobile data = ISP block
Broken everywhere = your code or your vendor

Check DevTools Network tab:
Open your app on an affected connection and look for:

net::ERR_CONNECTION_TIMED_OUT
net::ERR_NAME_NOT_RESOLVED

Either of these on your backend URLs means the ISP is the culprit.

Total time to fix: 5 hours. It would have been far less if the person who originally built the app had understood what they deployed.

Step 2: The Fix — Cloudflare Worker Reverse Proxy

The core idea: instead of your frontend calling your vendor URL directly (e.g. yourproject.supabase.co), it calls api.yourdomain.com which proxies the request through Cloudflare's global infrastructure. Indian ISPs do not block Cloudflare the same way they block direct connections to foreign cloud vendors.

2a. Create the Cloudflare Worker
Log into Cloudflare Dashboard, go to Workers and Pages, then Create Worker.

Replace the default code with:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const SUPABASE_URL = "https://yourproject.supabase.co";
    const targetURL = SUPABASE_URL + url.pathname + url.search;
    const modifiedRequest = new Request(targetURL, {
      method: request.method,
      headers: request.headers,
      body: request.method !== "GET" && request.method !== "HEAD"
        ? request.body
        : null,
      redirect: "follow",
    });
    return fetch(modifiedRequest);
  },
};

Replace yourproject.supabase.co with your actual project URL and deploy.

2b. Add DNS Records
In Cloudflare Dashboard, go to your domain, then DNS, then Records, and add both:

2c. Add Worker Route
Go to Workers and Pages, then your Worker, then Settings, then Triggers, then Add Route:

api.yourdomain.com/*

Select your domain zone and save.

2d. Split Your Environment Variables

.env.production:

VITE_SUPABASE_URL=https://api.yourdomain.com
VITE_SUPABASE_ANON_KEY=your_anon_key

.env.development:

VITE_SUPABASE_URL=https://yourproject.supabase.co
VITE_SUPABASE_ANON_KEY=your_anon_key

Local dev hits Supabase directly. Production routes through Cloudflare. Clean separation with no DNS dependency for local development.

2e. Verify
After DNS propagates (usually 15 to 60 minutes), open:

https://api.yourdomain.com/rest/v1/

You should see a Supabase-style JSON response. That means the proxy is working and your Indian ISP users are now routing through Cloudflare instead of hitting the blocked endpoint directly.

Step 3: Build Defensively Going Forward

The Supabase-Jio incident is one specific case. The underlying vulnerability is architectural. Here are the practices that would have prevented this entirely.

Never expose third-party vendor URLs directly to users
If your frontend calls yourproject.supabase.co directly, you have zero control when that URL gets blocked, rate-limited, or the vendor changes their infrastructure.

Fragile:

VITE_API_URL=https://yourproject.supabase.co

Resilient:

VITE_API_URL=https://api.yourdomain.com

Now if you ever migrate away from Supabase, you update one DNS record instead of every line of frontend code.

Test on multiple Indian ISPs before launch
Before any production launch targeting Indian users, test on at least Jio and Airtel. They behave differently at the network level. A site that works perfectly on your Airtel broadband may be completely broken for 500 million Jio users. This takes 10 minutes and can prevent a production fire.

Add error boundaries to your frontend
A single failed API call should never white-screen your entire app. One network hiccup at the ISP level should show a graceful error, not kill the entire user session.

class ErrorBoundary extends React.Component {
  state = { hasError: false };
  static getDerivedStateFromError() {
    return { hasError: true };
  }
  render() {
    if (this.state.hasError) {
      return <div>Something went wrong. Please try again.</div>;
    }
    return this.props.children;
  }
}

Wrap your app:

<ErrorBoundary>
  <App />
</ErrorBoundary>

Monitor your proxy domain, not your vendor
Set up uptime monitoring on api.yourdomain.com using UptimeRobot (free tier available). Monitor your own domain, not yourproject.supabase.co. You want to know the moment your proxy goes down before your users do.

Keep client infrastructure on the client's account
If you are a freelancer or agency, never run client production infrastructure on your personal Cloudflare, AWS, or Vercel accounts. If payment disputes or billing issues arise, you end up either subsidizing their infrastructure or pulling the plug and breaking their live site. Transfer ownership before going live, every time.

TL;DR

The Jio-Supabase block will eventually be resolved. But the next ISP routing issue, the next vendor outage, the next DNS misconfiguration, those are coming regardless. The apps that survive them are the ones built with an abstraction layer between their frontend and their vendors.

One DNS record should never be able to take your entire app offline.

Final Thought
The founder genuinely believed I had just changed a link. That is the real cost of shipping code you do not understand. Not the bug itself, bugs are inevitable. But the inability to even know where to start looking when something breaks at the network level.

Vibe coding is a valid way to move fast. But understanding what you ship is not optional.

Building apps for Indian users or dealing with ISP-level issues? Drop a comment or connect with me, happy to help.

Inspired by a real incident I wrote about on LinkedIn. Read the story behind this fix here.