-
-
Controlled test outreach email generated by Ten Stores a Day. Sensitive details redacted for privacy.
-
Outreach queue Wholesale prospect queue showing retailers awaiting research, personalized pitch creation, and review before release.
-
Detailed retailer review Founder review view showing retailer rationale, personalized outreach, attachment, and skip, edit, or send.
-
What it has learned Learning view showing lessons the system stores from outreach results and uses to improve future decisions and pitches.
Inspiration
I’m a founder running a pajama company. I launched my company shortly after graduating in 2025, and ten days after launch, we sold out.
As I started growing the business, I began reaching out to retailers myself and successfully got the brand into stores. Wholesale quickly became one of the highest-return activities I could spend my time on.
The problem was that I became the bottleneck.
Finding potential retailers is incredibly manual. I had to search for stores, figure out whether they were actually a fit for my brand, find their contact information, research them, write personalized outreach, keep track of who I had already contacted, and repeat the process over and over again.
I knew wholesale worked. I simply didn't have enough hours to scale it.
I wanted something built specifically around my business: something that understood my brand, knew what kinds of retailers I was looking for, communicated like me, remembered what it had already done, and could actually take the work off my plate.
So I built Ten Stores a Day.
What it does
Ten Stores a Day is an autonomous wholesale outreach system for my business.
I can give it an outreach target, such as ten stores per day, and it handles the workflow of identifying potential retail partners, researching them, determining whether they are relevant to my brand, creating personalized outreach in my voice, queuing that outreach for release, and tracking what it has already done.
The goal was not to build another tool that gives me a list of leads.
The goal was to build an agent that actually does the work.
Because it is built around my business, it can use context about my company, the retailers I am trying to reach, my communication style, exclusions, and previous outreach rather than treating every interaction like a completely new task.
How we built it
Ten Stores a Day is built using Google Agent Development Kit (ADK) and Gemini 3.7 Flash through Vertex AI.
The main reasoning agent runs as a Google Cloud Run Job. Cloud Scheduler triggers it hourly, while the daily outreach target is controlled separately. This lets me change how often the system runs without changing how much work it is expected to complete.
The agent uses the Places API from Google Maps Platform to verify retailers and uses Gemini with Google Search grounding to research what a store carries, understand relevant context, and identify useful information about the business.
That research passes through a qualification layer before the agent is allowed to write outreach. The system considers factors such as product mix, pricing, business type, existing CRM history, exclusions, and whether the opportunity makes sense for the current scale of my business.
State is stored in a shared Cloud SQL Postgres database that I call the Brain. This allows the system to preserve CRM state, research, exclusions, drafts, run history, and lessons across otherwise stateless Cloud Run executions.
Ten Stores a Day also builds on my pre-existing Brain infrastructure, which connects business systems and data sources through MCP-connected services. Rather than rebuilding every business integration inside the ADK agent, the wholesale system can use shared context already collected by the Brain.
I deliberately separated reasoning from delivery. The ADK agent does not have an email-send tool. It researches, decides, writes the pitch, and stores it in the CRM with a timestamp. A separate Cloud Run job handles release.
Drafts sit behind a 24-hour veto window. During that period I can stop an outreach message before it is released. The release process also applies database-level eligibility checks, a master sending switch, and a per-run limit before calling the existing email delivery path.
Important restrictions such as blocked retailers, prior contacts, duplicate prevention, and release eligibility are enforced through code and database state rather than relying only on the model prompt.
The system also stores strategy and learning information separately from individual runs, creating a foundation for comparing approaches over time and testing whether accumulated lessons actually affect future decisions.
The core workflow is:
Discover → verify → research → qualify → check history and exclusions → write → queue → 24-hour veto window → release → track → learn
Pre-existing infrastructure disclosure: Ten Stores a Day was created during the hackathon period and builds on business infrastructure I had already created, including the Brain, shared CRM/database state, business data feeds, MCP-connected services, and the existing email delivery path. The wholesale-specific ADK workflow, decision logic, outreach process, safety controls, and deployment were built during the hackathon period.
Challenges we ran into
One of the hardest parts was teaching the system that finding a good retailer does not necessarily mean it should contact them.
At first, a retailer could look like a strong fit without the system understanding that I already had a relationship with them. Existing communication history therefore had to become part of the shared business context used when evaluating prospects.
Even that wasn't enough. There are retailers I have contacted before that I explicitly do not want the system following up with. That meant building separate exclusion rules and making sure they applied not only to new outreach, but also to later stages of the workflow.
Entity matching created another problem. Different locations or variations of the same retailer could sometimes appear to be separate prospects, so the system needed stronger rules around identifying related businesses and applying exclusions consistently.
I also realized that a retailer can be a great brand fit and still be the wrong opportunity for my business right now. I do not want an autonomous system targeting an opportunity that my current inventory or fulfillment capacity cannot realistically support.
To address that, I made business context collected by my broader Brain infrastructure available to the wholesale workflow, including context derived from systems such as Shopify. The goal became more than finding retailers that might want the product. It had to find retailers that made sense for the business I can actually operate today.
These challenges changed the project from a simple outreach automation into a much more contextual decision-making system.
The hardest part wasn't teaching the agent how to write an email. It was teaching the system when not to act.
Accomplishments that we're proud of
The biggest accomplishment is getting the complete workflow working in controlled end-to-end testing.
Ten Stores a Day can identify potential retailers, research them, evaluate whether they are worth pursuing, generate personalized outreach, store the resulting pitch in the CRM, and move it through the same gated release architecture designed for live retailer outreach.
So far, I have tested outbound delivery using controlled test emails rather than allowing the system to broadly contact real retailers. Seeing the system independently move from a prospect to a contextual message and successful controlled delivery was the moment the project started to feel real.
I’m also proud that the system is designed to support experimentation rather than one fixed outreach strategy. Strategy information can be stored alongside outreach records so different approaches can be compared as results accumulate.
The system also preserves research and learning information separately from individual runs, creating a foundation for future decisions to build on what happened previously.
What started as a way to save time has become something closer to an ongoing experimentation system: it discovers opportunities, acts on them, records what happened, and is designed to improve how future opportunities are handled.
What we learned
I originally thought the problem I needed to automate was writing outreach emails.
It wasn't.
Writing the email is only one small part of the job. The real workload is everything surrounding it: discovering opportunities, researching them, deciding what is worth pursuing, gathering context, remembering previous actions, and actually following through.
Building Ten Stores a Day changed how I think about AI agents. The most useful agent is not necessarily the one that gives the best answer. Sometimes it is the one that can take ownership of a piece of work you otherwise have to keep doing yourself.
I also learned that autonomy is not just about giving an agent more permissions. In some cases, a better autonomous system comes from deliberately restricting what the reasoning agent can do and putting irreversible actions behind deterministic controls.
For a small business with limited time and resources, that difference can be enormous.
What's next for Ten Stores a Day
The next step is making the learning loop much more visible and measurable.
Ten Stores a Day already records outreach strategies, research, and learnings, but I want to connect that more directly to the dashboard I use to manage my other systems.
As it begins running live outreach, I want to easily see which strategies perform better, what kinds of retailers respond, what approaches fail, and how those results affect future decisions.
The bigger question I want to test is whether the system is actually using everything it learns.
One thing I have noticed while experimenting with autonomous agents is that storing a lesson and consistently applying that lesson are two very different problems. An agent can have access to useful information and still treat it as optional context.
So the next phase of Ten Stores a Day is about closing that loop: making sure results are captured reliably, making those learnings observable, and verifying that they actually influence future retailer selection, outreach strategies, and follow-ups.
Ultimately, I do not just want to see that the system produced ten pitches today. I want to understand what those ten attempts taught it and how tomorrow’s ten will be different because of them.
Built With
- docker
- gemini
- google-adk
- google-cloud-build
- google-cloud-run
- google-cloud-scheduler
- google-cloud-sql
- google-gen-ai-sdk
- google-maps-platform
- google-search-grounding
- google-secret-manager
- mcp
- postgresql
- python
- vertex-ai
Log in or sign up for Devpost to join the conversation.