The problem
Every workflow builder - Zapier, n8n, Make, the lot - opens on a blank canvas and a palette of nodes. That design assumes you already know what you want, decomposed into steps, before the tool is any use to you. Most people don't. They know the chore. "I keep forgetting to check the weather before I bike in." The gap between knowing the chore and knowing the DAG is exactly the work these tools leave you to do alone, and it is the reason most people who try one never build a second automation.
What it does
Weaver interviews you about a repetitive task, one question at a time, until it genuinely understands the goal. Then it designs a multi-agent workflow, validates it with deterministic code, deploys it, and runs it - on demand or on a schedule that survives your laptop being closed.
The interview is the product, and it holds to three rules:
- One question per turn. It never bundles three into a paragraph.
- It never invents a value you have not given it. No silently assumed recipient, city, or time.
- A correction updates one detail. Say "actually, Mondays" halfway through and it changes that and keeps going, rather than restarting.
Only once it restates the whole task in plain language and you confirm does it save the intent and hand off to a separate Designer Agent.
It also asks whether the result was any good, which is a different question from whether it succeeded, and only you can answer it. Feedback is read back the next time you describe something similar - so a note left on a run in August shapes a conversation in September.
And you can just reply to its emails. Automation emails carry a short tag in the subject, like [#wv-4bebac9b], that survives "Re:" in every mail client. Reply "too long, only AI stories" and Weaver records it as feedback on that automation and writes back.
How I built it
Fifteen ADK agents on Cloud Run, every one private.
- Conversation Agent (gemini-3.7-flash) runs the interview.
- Designer Agent (gemini-3.5-flash) turns a confirmed intent into a DAG, grounded in a live capability registry in Firestore.
- Thirteen step agents (gemini-3.5-flash-lite) each do one bounded thing: search, fetch a feed, read a page, get the time, get the weather, compose, wait, send email, post to Slack, post to Discord, POST to any webhook, generate a video with Veo 3.1, generate music with Lyria.
Adding those last two took a row in the Firestore registry and one agent each. The Designer picked them up with no prompt change, because it reads the registry live rather than having capabilities baked into a prompt - which is the whole point of keeping the registry as data.
The Conversation Agent and Designer Agent are deliberately separate. Understanding a person and designing a system are different skills with different failure modes, and collapsing them into one prompt makes both worse.
Between them sits a validator with no LLM in it. Unknown step types, missing parameters, dangling references and dependency cycles are caught by ordinary deterministic code. Asking a model to check its own work is not validation.
Firestore holds the registry, intents, proposals and run history. Secret Manager holds every credential, fetched at the moment of use and never at deploy time. Cloud Storage holds generated media. Cloud Scheduler pings the dashboard API once a minute so schedules fire without a laptop; firing is claimed in a Firestore transaction, so two instances cannot both send the same email. There is a Pub/Sub path for asynchronous DAG execution as well.
Challenges I ran into
Gemini 3.x is not served on regional Vertex AI endpoints. Every 3.x model 404'd at us-central1 while gemini-2.5-flash worked fine at the same address, which reads exactly like a permissions problem and isn't one. They need "global", separate from the Cloud Run region.
Steps were reported as successes while quietly failing. Step agents catch their own tool errors, and the model then paraphrases the failure into prose that no longer carries an error prefix - so an HTTP 200 meant nothing. Fixed by reading the raw functionResponse in the event stream rather than the model's final text. A workflow engine that lies about success is worse than one that crashes.
An email went out with the literal text {{compose_briefing.output}} in the body. The resolver knew one template spelling and the Designer had emitted another. Now it understands four, and any step whose parameters are still unresolved at dispatch refuses to run rather than sending the template. An honest failure beats a delivered placeholder.
Cloud Scheduler failed with status.code 7 and a 403 in the Cloud Run logs, which looks precisely like a missing run.invoker binding. It wasn't: Scheduler must also be able to impersonate the service account to mint the OIDC token, which is a separate grant nothing tells you about.
Imagen no longer exists. An image-generation step was built, deployed, and then deleted: every Imagen endpoint was deprecated on Vertex in March 2026 and shut down on 17 August 2026. The 404 it returns says "not found or your project does not have access", which reads like a permissions problem and sent me looking in entirely the wrong place. Media steps generate video and music instead, and a test now asserts no Imagen reference survives in the code.
What I'm proud of
It says no. Ask for something outside the registry and the Designer Agent names the specific missing capability rather than inventing a step. That refusal is what prompted me to build the delay, clock and run-cap features - the tool told me what it lacked, in terms specific enough to act on.
Failures are reported the same way: which step failed, why, and what to do. Never glossed.
What I learned
Verify against the installed reality, not against what you remember the API being. Nearly every hour lost this build was lost to a plausible assumption that a thirty-second check would have killed - and at least once, to a check written badly enough that it could only confirm what I already believed.
And a run succeeding is not the same as a run being useful. Separating those two questions, and asking the second one out loud, changed the product more than any model choice did.
What's next
Per-user credentials and real multi-tenancy; today it is single-tenant by design. Loops over lists, which the fixed-DAG model can't express yet. And more connectors - the registry is data in Firestore, so adding a capability is a row rather than a prompt change.
Built With
- cloud-build
- cloud-scheduler
- cloud-storage
- discord
- fastapi
- firestore
- gemini
- gmail-api
- google-adk
- google-cloud-run
- imap
- javascript
- lyria
- pub-sub
- python
- secret-manager
- slack
- veo
- vercel
- vertex-ai
Log in or sign up for Devpost to join the conversation.