DEV Community: Zoe Lin

Email Drafter — Multi-Agent Email Writing with Google ADK and Cloud Run

Zoe Lin — Fri, 17 Apr 2026 06:51:30 +0000

What I Built

I built Email Drafter, a small web app that turns structured user input into a polished email draft using a multi-agent workflow.

The app takes:

recipient type
purpose
tone
language
key points

Instead of using one giant prompt, I split the workflow into multiple specialized roles.

The system works like this:

one agent plans the email
one agent reviews the plan
one agent writes the final draft
one orchestrator coordinates the workflow

I also deployed the system as separate services on Cloud Run, so the app feels much closer to a real distributed AI workflow instead of just a local prototype.

I picked email drafting because it is a practical use case where planning, reviewing, and writing feel like naturally separate tasks. That made it a good fit for experimenting with multi-agent orchestration.

Cloud Run Embed

Your Agents

This project uses three specialized agents plus one orchestrator.

Researcher Agent

Creates a structured email plan from the user input.
Judge Agent

Reviews the plan and checks whether it is complete enough before moving on.
Content Builder Agent

Writes the final email draft from the approved plan.
Orchestrator Agent

Coordinates the workflow between the other agents and returns the final result to the frontend.

The overall flow is:

Frontend -> Orchestrator -> Researcher -> Judge -> Content Builder -> Final Email Draft

Key Learnings

This project helped me understand why multi-agent systems can be useful even for a relatively small app.

A few things stood out while building it:

Splitting the workflow made debugging easier. It was much easier to tell whether the issue came from planning, review, or writing than trying to fix one large prompt.
Deployment was harder than the basic prompt logic. Getting multiple services running locally, wiring them together, and then deploying them to Cloud Run took more effort than writing the first version of the agents.
Prompt wording had a big impact on output quality. Small instruction changes made a noticeable difference between getting a planning-style response and getting something that looked like a real email.
Multi-agent design felt more modular and production-oriented. Even for a simple email drafting tool, separating responsibilities made the system easier to reason about and improve.

Demo

Hack Desk — Minimal Coding Setup for Global Hack Week

Zoe Lin — Tue, 14 Apr 2026 10:33:13 +0000

My Global Hack Week setup

My laptop, mouse, and a clean desk setup for building, debugging, and shipping projects.

@mlhacks

LogoForge — AI SVG Logo Generator for Brand Concepts

Zoe Lin — Mon, 13 Apr 2026 08:48:05 +0000

What I Built

I built LogoForge, a small web app that generates SVG logo concepts from a brand name, industry, style, and keywords using the Gemini API.

The app supports single and 3-variation generation, validates the model output as structured JSON, retries once if validation fails, and lets users preview the SVG, download it, and copy the JSON output.

I also refactored the project into a frontend and backend proxy setup so the API key is not exposed in the browser. That made the app feel much closer to something I would actually deploy instead of just keeping as a local prototype.

Demo

In the demo, I show the input flow, SVG generation results, color palette and brand story output, and the difference between single and 3-variation generation.

My Experience

This project taught me that prompting works much better when I treat it like writing a product spec instead of giving a loose instruction. The clearer I was about the UI, output format, and SVG constraints, the better the generated app became.

The biggest lesson was reliability. A raw model response can look correct but still fail in subtle ways, so adding validation and a retry step made the app much more stable.

I also learned a lot from the deployment side. I started with a simpler client-side setup, then moved the Gemini call behind a backend proxy and deployed the frontend and backend separately. That part felt much more like real engineering work than just prompt experimentation.

During testing, I also occasionally ran into temporary Gemini API availability issues under high demand. The overall app flow and deployment setup still worked as expected, but it reminded me that real-world AI apps need both prompt design and engineering safeguards.

What I Learned

Clear constraints produce better results
Structured output still needs validation
SVG is a great way to create visual output without image generation
Small engineering steps like retries and safer secret handling make a big difference
AI tools can speed up prototyping, but reliability still depends on developer judgment

Dark Dish Lab — Cursed Recipe Generator for Strange Culinary Ideas

Zoe Lin — Sun, 05 Apr 2026 18:21:11 +0000

What I Built

Dark Dish Lab is a tiny, delightfully useless web app that generates cursed food or drink recipes.

You pick:

Hated ingredients
Flavor chaos (salty / sweet / spicy / sour)

Then it generates a short “recipe” with a horror score, a few steps, and a warning.

It solves no real-world problem. It only creates regret.

Demo

YouTube demo

Code

GitHub repo

How I Built It

Frontend: React (Vite)
- Ingredient + flavor selection UI
- Calls backend API and renders the generated result
Backend: Spring Boot (Java 17)
- POST /api/generate endpoint
- Generates a short recipe text and returns JSON
Optional AI: Google Gemini API
- If AI is enabled and a key is provided, it asks Gemini for a very short recipe format
- If AI is disabled or fails, it falls back to a non-AI generator
Notes
- Only Unicode emojis are used (no emoji image assets)
- API keys are kept in local env files and not committed

How I Leveraged Google AI

Gemini (via the Gemini API) is the text generator behind Dark Dish Lab’s “cursed recipe” output.

Instead of using AI as a generic chatbot, I use it as a formatting engine:

Input: selected ingredients + flavor axes (salty/sweet/spicy/sour)
Output: a short, structured recipe (name, 3 steps, 1 warning)

To keep the experience stable and demo-friendly, I added a few guardrails:

Server-side API key only (kept in backend/.env.local, not committed)
Strict prompt constraints (no emojis, short length, fixed format)
Fallback generator when Gemini is disabled/unavailable
Output trimming to avoid unexpectedly long responses

Prize Category

Best Use of Google AI — I integrated the Gemini API to generate short, structured cursed recipes from the user’s selected ingredients and flavor axes.
Community Favorite angle — Try to generate the most cursed combo you can. Comment your ingredient + flavor picks and the horror score you got. Bonus points if your friends refuse to read it.

Ops Hub — Notion MCP Dashboard for Assets, Subscriptions & Daily Digest

Zoe Lin — Thu, 26 Mar 2026 18:34:30 +0000

What I Built

Ops Hub is a Notion-first dashboard for asset and subscription operations (built with Notion MCP + Python).

It helps centralize scattered operational info (devices, warranties, renewals) into one workspace and turns it into a daily workflow:

Assets Ops: track equipment (3C / appliances), maintenance schedule, warranty dates, and manuals.
Subscription Ops: track renewals, pricing, and generate cancellation drafts.
Daily Digest: one command generates a Daily Digest — YYYY-MM-DD page in Notion with:
- KPI summary (counts + upcoming renewal cost)
- actionable lists with deep links to the exact items

All outputs stay inside Notion, so it’s easy to review and act (human-in-the-loop friendly).

Video Demo

Show us the code

GitHub Repo

Run locally (Poetry):

cp .env.example .env
poetry install
poetry run python -c "from homeops_mcp.server import create_daily_digest; print(create_daily_digest(14))"

How I Used Notion MCP

Notion is the source of truth (databases, views, templates, and the dashboard). The MCP server turns Notion context into an automated ops workflow:

Reads Notion databases to find:
- assets due for maintenance soon
- warranties expiring soon
- subscriptions renewing soon (within N days)
Writes back into Notion:
- status fields like Next Action and Lifecycle Stage
- helpful notes like Manual Notes (maintenance guidance) and Cancel Instructions (cancellation draft)
Generates a Daily Digest page in Notion with KPIs + clickable action lists, so I can review everything in one place.

This makes the workflow feel like “superpowers”: I stay in Notion, run one command, and get an updated dashboard plus a daily report ready to act on.

Data Model (Notion Databases)

Assets

Maintenance: Last Maintenance + Maintenance Interval (days) → Next Maintenance (formula) → Next Maintenance Date (calendar)
Ops fields: Next Action, Lifecycle Stage
Docs: Manual Notes, Manual URL, Warranty End

Subscriptions

Renewal tracking: Renewal Date, Billing Cycle, Status
Ops fields: Next Action
Output: Cancel Instructions (draft)

Daily Digest (Auto Report)

A single run creates a Daily Digest — YYYY-MM-DD page in Notion with:

KPI Summary (maintenance / renewals / renewal cost / warranty)
Clickable action lists linking to the exact items

Generated by create_daily_digest(14) and saved as a child page under the dashboard.

Tech Stack

Python (MCP server)
Notion MCP + Notion API
Poetry (dependency & virtualenv)