Inspiration
The typical process for creating a marketing campaign is largely manual:
- Strategic initiatives, while informed by experience and data, are still inexact and often rely heavily on intuition.
- Data exploration can involve hundreds of tables whose attributes may have limited documentation.
- Journey creation is slow to test and uncertain with regard to impact.
- Generated content can be slow to arrive because content creators are managing many projects that require lengthy review.
This repository is designed to remove these pain points by creating an automated pipeline that generates a complete marketing campaign from start to finish.
What it does
In the deployed architecture, a marketer uploads a marketing brief to Cloud Storage. TaskMaster then acts as the background orchestrator, launching the multi-step workflow without requiring further human intervention.
Marketing audiences are created by an LLM that explores the available customer data and filters for records pertinent to the brief. A strategic journey is then created and tested in an agentic refinement loop that searches for a design that maximizes customer engagement without compromising brand reputation.
Journey branches can consider both static customer attributes and dynamic behavioral attributes, such as opens and clicks. The initial journey is simulated and evaluated using a fitness function, after which the agent analyzes the results and makes informed refinements. This process repeats across multiple candidate journeys, and a final agent determines which constructed journey performed best.
Campaign content is then generated automatically in line with the goals described in the original brief.
When the deployed background workflow completes, structured audience outputs are persisted to Cloud SQL. The final audience, journey, campaign artifacts, and agent logs are stored in Cloud Storage. Cloud Logging provides visibility into successful and failed TaskMaster runs, and the configured administrator receives an email indicating either successful completion or error termination.
The result is an unattended workflow in which the marketer provides the brief and the system performs the campaign-building process.
How we built it
The Marketing Campaign Generator was built primarily using Google ADK.
A SequentialAgent contains specialized sub-agents that build the initial audience and journey. A LoopAgent then iteratively analyzes the journey, reviews simulation results, and makes informed refinements. A final output agent determines the best constructed journey from the candidates that were simulated.
Journey creation uses the NetworkX graph theory package in Python, with the system enforcing a directed tree structure for the journey. This structure is consistent with how many marketing journeys are represented in customer data platform software. NetworkX provided useful tools for managing nodes, edges, branching logic, and traversal through the journey.
Journey edges contain filtering criteria that determine which customers move from one node to another. This allows the journey to branch based on customer attributes as well as behavioral data generated during simulation.
Data simulation was informed by data described in this paper:
https://journals.ashs.org/view/journals/horttech/35/3/article-p286.xml?tab_body=pdf
The simulated data provides a controlled environment in which the agents can build audiences, test journey behavior, and evaluate campaign outcomes before selecting a final design.
One challenge with agent-generated tool calls is that the agent may occasionally attempt an invalid action. Important structural rules are therefore enforced directly in the tools rather than relying only on the agent prompt. Agent missteps are handled using on_tool_error_callback, which gives the agent an opportunity to understand what went wrong and attempt a corrected action instead of immediately terminating the workflow.
Background automation was achieved by deploying the application on Google Cloud. Uploading a marketing brief to a Cloud Storage bucket triggers the processing pipeline, allowing TaskMaster to run as an unattended background workload. This moved the project beyond an interactive adk run session and allowed the entire workflow to execute independently of the local development machine.
The cloud architecture also allowed us to take advantage of Cloud SQL for structured audience storage, Cloud Storage for inputs and generated artifacts, and Cloud Logging for centralized monitoring and failure visibility.
A lightweight FastAPI web interface is deployed on Google Cloud Run to make the autonomous workflow easier to test.
Users can either upload a text/Markdown marketing brief or enter one directly in the browser. The web application writes the brief to the existing Cloud Storage incoming/ location, where the normal background TaskMaster workflow takes over.
The interface does not execute the agents directly. It monitors the existing workflow and, when TaskMaster completes, displays links to the generated campaign artifacts. Structured campaign, journey, and simulation data are persisted to Cloud SQL, while generated artifacts are stored in Cloud Storage.
Challenges we ran into
Imposing strict rules in both tools and agent prompts proved challenging, but not insurmountable. Testing showed that prompt instructions alone were not always sufficient to guarantee that the agent would follow every structural requirement.
For example, the generated journey must remain a valid directed tree, node types must follow specific connection rules, filters must reference valid customer attributes, and customer records must move correctly through the journey as filters are applied.
The solution was to enforce important rules programmatically in the tools themselves. Invalid actions are rejected, but the error is returned to the agent so it can reconsider its approach and attempt a correction.
Another challenge was maintaining consistent state across multiple agents and refinement iterations. Audience data, journey structure, node-level customer populations, simulation outcomes, and candidate journey performance all needed to remain synchronized as the workflow progressed.
Finally, moving the project from a locally executed ADK application into an unattended cloud workflow introduced a different set of challenges. We had to handle automatic triggering, persistence, logging, completion states, and error notification so the workflow could execute reliably without someone actively supervising it.
Accomplishments that we're proud of
I particularly appreciate the incorporation of NetworkX for journey creation. I've long held a fascination with graph theory and was pleased to see how my skills there could translate to this problem.
I am also proud that the project evolved from something that initially required an interactive local agent session into a complete background workflow. A marketer can upload a brief and allow the system to proceed through audience creation, journey construction, simulation, refinement, content generation, persistence, and completion without manually advancing each stage.
Another accomplishment was combining agent reasoning with conventional software guardrails. Rather than assuming the LLM will always produce a valid action, the system validates important operations in code and gives the agent the opportunity to recover when one of those operations is rejected.
What we learned
Coming from a LlamaIndex background, it was nice to learn a new agent development kit, where it was similar and where it was advantageous.
I also learned a lot about what Google Cloud has to offer and how effective it can be for turning an agent prototype into a deployed application. Moving the workflow into the cloud made it clear that building the agents themselves is only one part of the problem. Persistence, state management, validation, logging, failure handling, and deployment are all important parts of creating a useful agentic system.
One of the larger lessons from the project was that agents seem most effective when they are given flexibility in areas where reasoning is valuable, while traditional software enforces the rules where correctness is essential.
What's next for Marketing Campaign Generator
As of now, journey refinement is completely handled by the agent. The agent evaluates simulated outcomes, determines what it believes could be improved, and proposes modifications to the journey.
I would like to see a more mathematical approach to iterative journey improvement using genetic programming, genetic algorithms, neural networks, evolutionary search, or other mathematical optimization tools that could better inform the agent when suggesting journey modifications.
Rather than replacing the agent, these methods could complement it. An optimization algorithm could search more systematically through possible journey structures, filters, or parameters, while the agent could interpret the results and apply higher-level strategic reasoning.
The longer-term goal would be a hybrid approach in which mathematical optimization helps identify promising campaign changes and the agent uses those results to make informed strategic decisions.
Built With
- cloudsql
- docker
- fast-api
- gemini
- google-adk
- google-storage
- postgresql
- python
Log in or sign up for Devpost to join the conversation.