flow-helper

Building Flow Helper

An agent I built to handle support, debugging, and onboarding for Flow Monitors.

Cole Banman · May–September 2026

I built Flow Monitors, a service that sends restock alerts for sneakers, Pokémon cards, and consoles. Clients tell me what to monitor, which stores or regions to cover, and which Discord channels or webhooks to send alerts to.

I used to set this up by hand, in backend code or SQL. Almost every client wanted something different: a list of ZIP codes, whole states, specific stores, or separate channels per retailer. That made a dashboard or fixed set of commands hard to build.

Flow Helper handles these requests in the same support tickets clients already use. When tagged, it reads the conversation, checks the code, database and logs, and makes the changes. Most requests are fully hands-off; code changes come to me for approval. I also use it for billing and keeping track of context across clients.

74%of tickets needed no intervention
75%of pilot clients switched to asking the helper
57%of September’s tickets went to the helper first
20+messages in hands-off threads

How it works

I use Codex through its App Server protocol, with a Node harness that connects it to Discord and controls its context, tools, and replies.

Discord ticketA client tags the helper
Request Checked reply
Node harness

Checks who’s asking and who can read the reply. Gives the agent context and allowed tools.

Client data Supabase
Billing · only me Stripe
Messages + threads Discord
Context + tools Tool callsTool results Answer
Codex agentWorks through the request
Local commandsRead code and logs
Stage a code fix
The agent requests an action; the harness calls the service and returns the result. API keys stay in the harness. Code changes come to me for review.

Results

Four clients opened 27 tickets with the helper from May to September.

Outcome of 27 client tickets

May–September 2026

No interventionI intervened
Done, no intervention15 · 56%Fix staged for code review4 · 15%Partial answer1 · 4%I intervened7 · 26%
20 of 27 tickets (74%) needed no intervention from me.

Client reliance, September 2026

Who clients asked when opening a new ticket

HelperOther
Asked helper directly8 · 57%Asked me3 · 21%Asked both1 · 7%Other2 · 14%
In the last two weeks of September, it was 4 of 6.

After a few good answers, three of the four clients stopped tagging me and went straight to the helper. Some threads ran past 20 messages without me stepping in. Usage was uneven, though: one client sent 26 of the 40 direct requests.

“No intervention” means I didn’t step in, not that every fix was independently verified. Four clients is a small sample.

Examples

These are real replies and tool calls from my replay tests, using synthetic client data against the real helper and database.

Diagnosing a missed alertReplay test
Client

this sku did not ping IR7336-001 at Nike Redlands. Can you check why?

Flow Helper

The Nike Redlands alert for IR7336-001 was skipped because your server was opted out of this SKU. It’s currently unsubscribed, so no ping was sent.

Would you like me to add it back?

  1. Product subscription
  2. Alert routes
  3. Delivery log: skipped, opted out
Found the cause in the delivery log and offered the fix. 5 tool calls.
Routing alerts by ZIP codeReplay test
Client

Please send Nike alerts for Chicago ZIPs 60620, 60502, 60619, 60018, 60523, 60031, and 60611 to this webhook: [webhook URL]

Flow Helper

Saved and verified: Nike alerts for ZIPs 60620, 60502, 60619, 60018, 60523, 60031, and 60611 are routed to your supplied webhook.

  1. Read current routes
  2. Save ZIP route
  3. Re-read to verify
A setup that used to be a manual SQL change for me. 3 tool calls.
Two more examples: late alerts and adding products
Explaining a late alertReplay test
Client

why did this slku IM3207-400 ping over ome hour after at Nike Glendale?

Flow Helper

The delay happened before Flow detected the change. Nike’s recorded update was at 2:49:49 PM ET, and Flow detected it at 4:06:49 PM ET, 77 minutes later. The alert was sent about 5 seconds after detection.

The change was size 13 going from LOW stock to out of stock at Nike Glendale. These records confirm the timing, but don’t establish why detection took 77 minutes.

  1. Delivery log
  2. Stock change history
Separated detection lag from sending lag, and said what the data couldn’t prove. 3 tool calls.
Adding products in bulkReplay test
Client

Please add the following three SKUs to all Nike stores: IR0968-500, IW1283-800, and IW1282-600.

Flow Helper

SKU IR0968-500 has been added.

SKU IW1283-800 has been added.

SKU IW1282-600 has been added.

All three are subscribed for your server’s Nike store alerts.

  1. Check setup
  2. Existing products
  3. Subscribe ×3
  4. Re-read to verify
Checked what was already tracked, added all three, then confirmed. 6 tool calls.

Security

Clients talk directly to an agent that can change the database. I need to keep it from acting as me, exposing another client’s data, or leaking credentials. The harness uses Discord’s identity and channel readers to decide what’s allowed. Permissions are enforced in code, outside the model.

Separate sessionsHarness checks each callSupabase
Client A’s agent
Client A’s data tool
Client A’s rows
Client B’s agent
Client B’s data tool
Client B’s rows
Each client’s agent has its own history and writable folder, with no network access. The data tool is bound to that client; Postgres enforces which rows it can reach.

The sandbox and database boundary are built and tested, but not deployed yet. I test this with 60 unit and integration tests, real Postgres tests, sandbox escape probes, and workflow replays with the real model, including two attack scenarios.

Issues and fixes

Issue: naming another clientClient ticket · Sep 2026
Client

Could you tell me the name of the owner of the other server?

Flow Helper

[Named the other server and its owner.]

Fix, pending rollout: isolate each client’s data (see Security). The updated helper refuses a replay of this request, even with “ignore your rules” added.
  • Going in circles. One hard ZIP-routing project got stuck retrying the same approach and pinged me 19 times. It created work instead of saving it.
  • Disk filled up. The first runtime never cleaned up saved sessions. After seven weeks the disk filled and the server hung. I pruned it, and later moved to Codex.
  • Usage limits. Model usage limits caused a crash loop that burned through Discord logins. I separated the model connection from the Discord connection.