I’ve Been Working on Something Big

EmailBuddy

I’ve been working on something really big, it’s been on my mind for maybe a year now and I’ve been working on it for 8 months already, so I want to talk about it. EmailBuddy is your help for your inbox.

What is EmailBuddy?

What is EmailBuddy? He’s supposed to be your one stop shop for cleaning up your email inbox. So for example, if you have like 100,000 emails and you don’t know where to even start, that’s the point of EmailBuddy. It’s supposed to help you in multiple different ways and try to help bring back some structure into your email.

Inbox Health & Score

One key feature we have is our inbox score. There is five main categories that comprise this score. Those are unread emails, spam emails, old newsletters, expired promotions, security emails. These are emails that may not be needed anymore like expired 2fa emails.

If we go a level deeper, we can interact with each score and see which emails are falling under these categories. You can get a summary from EmailBuddy saying what to do, then you can delete emails by cherry picking which ones you don’t need, or you can delete 100 at a time, or if you really don’t want them delete all of them at once.

Cleanup Feature

Another feature is the cleanup feature, this one is my personally favorite it pulls in your last 200 emails (it can get more emails if you click deeper scan) and it will sort it by senders who have sent you the most emails.

So for example, let’s say you have Amazon at the top of this list and it’s showing you have 150 emails. You can click the sender, then you can see all your emails from Amazon. You can get a summary from Emailbuddy and a recommendation on what to do with them.

Also, you will get four key actions: unsubscribe, mark as spam, mark as read, delete all. I like the control and transparency that comes from this feature. You see how much one sender is taking up your inbox and you get to take care of it in whatever way you feel like.

Automation

For the automation feature, there are toggles available that allow you to do delete certain emails such as delete old promos, old receipts, auto phishing emails. When you toggle these and then hit run it will remove all of these emails at once.

This one is a very strong feature, but it can be dangerous since it will or most of the work for the user but can be super effective.

Wrapping up

Those are some of the core features of the app to help people clean up and manage their emails. Currently, I have a roadmap setup for future updates.

If you are interested in the app I’ll leave a link right here if you want to give it a try. At the end of the day this project was for me to learn more about how app development is some and it’s been a blast learning.

Try it out: https://apps.apple.com/us/app/emailbuddy-clean-inbox/id6759539281

CFFBRW went from drag-and-drop to “hey AI, just deploy this for me”

Hey! So if you’ve been following CFFBRW since the Blockly days (DOUBT IT!), things have… changed a lot. Like, “I threw away the entire visual editor” level of change. 😅

Remember when I was all excited about snapping blocks together like LEGO? Turns out, when AI agents can write code better than I can drag blocks around, maybe the blocks aren’t the product anymore.

What happened

So I’ve been reading a lot about the whole “SaaS is dead” thing (I wrote some research notes about it). The basic idea: value is moving UP to the agent layer and DOWN to the data layer. The middle — dashboards, drag-and-drop UIs, per-seat pricing — is getting crushed.

And I looked at CFFBRW and thought… wait. My visual builder IS the middle layer. 🙈

So I rebuilt the whole thing around one idea: what if you just write what you want in plain English, and AI compiles it into a workflow?

Before:  Drag blocks → Configure each one → Deploy
Now:     Write markdown → AI compiles → Deploy

The markdown is the source of truth. Not a config file, not YAML, not blocks.

The AI compiler runs once per workflow version, caches the result, and then execution is fully deterministic. No AI involved at runtime = fast and cheap.

The part I’m most excited about: BYOM MCP Server

BYOM = Bring Your Own Model. I exposed the entire platform as an MCP server at /mcp. Any AI — Claude, Gemini, whatever — can compile, validate, deploy, and run workflows. Not through the dashboard. Through MCP tools.

This is… kind of the whole point? If agents are the future users, the MCP server IS the product. The dashboard is just nice-to-have.

Here’s what the MCP server gives you:

Resources (so the AI understands the system before acting):

  • cffbrw://schema/execution-plan — the JSON format it needs to generate
  • cffbrw://schema/step-types — all 9 step types (http_request, ai_call, transform, conditional, loop, etc.)
  • cffbrw://tools/available — what external MCP tools you’ve registered
  • cffbrw://examples/plans — examples from simple to complex

Tools (what the AI can actually do):

  • validate_plan — submit JSON, get errors or a validated plan
  • deploy_workflow / update_workflow — create or update workflows
  • run_workflow — execute, get back a run ID and WebSocket URL
  • get_run_status — poll until it’s done
  • Plus get_workflow, list_runs, list_workflows

There’s also a compile prompt that tells the AI “read the resources, take this markdown, give me valid JSON.” But honestly the resources contain everything — the prompt is optional.

The auth model (learned this the hard way)

Remember the voucher race condition? Yeah, I’ve gotten more careful about security since then.

Two access levels:

  • wfk_ API keys — scoped to ONE specific workflow. Can read, update, and run it (only if published). Cannot see other workflows or create new ones. If this key leaks, damage is contained.
  • Clerk JWT — full workspace access. Everything works. For the dashboard and admin stuff.

So a CI/CD key can trigger your workflow but can’t create arbitrary new ones. That felt important after the voucher incident taught me that “it’ll probably be fine” is not a security strategy 😄

Expression eval: because eval() doesn’t work on Cloudflare (not any more)

This was a fun rabbit hole. Workflows need to evaluate expressions — like referencing a previous step’s output or doing a conditional check. But Cloudflare Workers blocks eval() and new Function(). Just… doesn’t work. I learned this the hard way (as I learn most things).

So I built a three-tier system:

  • Tier A — Simple string templates like "Hello ${steps.step_0.name}". Parsed by an AST walker (jsep). Under 1ms. Handles most cases.
  • Tier B — More complex expressions. Tries the AST walker first, falls back to a Dynamic Worker sandbox if it’s too gnarly. ~10-30ms for the fallback. And I cannot stress this enough Dynamic Worker is a game-changer. So try it.
  • Tier C — Full JavaScript code blocks in a Dynamic Worker. Network blocked by default. The escape hatch.
    And I cannot stress this enough Dynamic Worker is a game-changer. So try it.

The AI compiler is told to prefer Tier A/B. Only use complex JS when you actually need multi-statement logic. Because honestly, most workflow expressions are just “get this value from the previous step.”

The stack (for the curious)

Everything runs on Cloudflare:

  • API: Hono
  • Validation: Zod everywhere — schemas are the single source of truth, TypeScript types derived from them.
  • AI: Claude (primary) + Gemini (fallback). Strategy pattern, so they’re swappable.
  • Storage: D1 for workflows/runs, KV for compilation cache, R2 for artifacts
  • Real-time: Cloudflare Agents SDK — NotebookAgent for WebSocket streaming, WorkflowRunner for durable execution. They talk via RPC.
  • Dashboard: TanStack Start + React Flow for DAG visualization
  • Auth: Clerk with organizations for multi-tenant

The Agents SDK was… an experience. The TypeScript types are incomplete, routeAgentRequest() doesn’t work with custom URL patterns, and you need a magic x-partykit-room header that isn’t documented anywhere. I ended up reading node_modules/agents/dist/index.js more than the actual docs. Classic Cloudflare beta experience 😅

So where’s the value now?

🤖 Agent Layer    → BYOM MCP server (any AI can use it)
🔌 Protocol Layer → 8 tools + 4 resources + compile prompt
🖥️ UI Layer       → Dashboard (nice but not the moat)
🗄️ Data Layer     → Run history, step logs, compilation cache (the actual moat)

The dashboard looks cool. But an AI agent talking to the MCP server can do literally everything the dashboard does. The data — workflow definitions, historical runs, step-level logs — is what compounds over time. That’s what no agent can replicate from the outside.

Still building. Still learning. If you want to try the MCP server or have thoughts on how agent-native products should work, I’d love to hear it.

And I believe any builder should use Gstack from Garry Tan. Old news I know, but for people who live under a rock like I do.

So cheers! ☕