CreatorLoop Taskmaster

Our demo creator is Maya, a bilingual Hong Kong lifestyle creator who publishes in English and Cantonese. The agent identifies a recurring audience signal such as: “Healthy snacks are fine, but please make them taste real.”

It proposes a bilingual taste-test experiment with a clear hypothesis, content format, opening hook, success metrics, and source evidence. Maya must approve the experiment before publication. After she marks the content as published, the system schedules a follow-up. When the follow-up becomes due, the agent wakes up, recalls the experiment context, requests performance metrics, reviews the result, and records what should change next time. The agent never publishes content automatically. Human approval remains required for every publication. How We Built It Evidence-Grounded Audience Signals Audience signals are represented as structured records containing:

signal ID;
source and data mode;
time range;
sample size;
evidence comment IDs. Every proposed experiment must reference at least one evidence ID. The agent is not allowed to invent audience trends, sales numbers, or creator growth results. The demo separates:
Public Historical Data, used for audience evidence;
Scripted Replay, used to demonstrate the workflow. The project does not claim to be real-time social-media monitoring or proof of actual creator growth. A Stateful Taskmaster Agent The workflow is implemented as an explicit state machine: proposed → approved → published → awaiting_metrics → reviewed Invalid transitions are rejected. For example, an experiment cannot enter published before human approval. The competition build uses Gemini 3.5 Flash through Vertex AI and Google ADK. The agent is given a small set of restricted tools:
get_creator_context
get_audience_signals
get_active_experiment
schedule_follow_up
request_metrics
record_learning The model interprets context and chooses among permitted actions. The application owns state transitions, metric calculations, evidence validation, and audit logging. Background Execution The most important behavior happens after the user leaves the application. When a creator marks an experiment as published, the system creates an idempotent follow-up action. Cloud Tasks invokes a protected Cloud Run endpoint when the action is due. The agent then:
retrieves the creator’s goals and style preferences;
recalls the active experiment;
decides whether a follow-up is appropriate;
requests metrics through an approved channel;
records the action and its result. The action is claimed atomically, so retries cannot create duplicate follow-ups. Persistent Memory and Structured Facts Business facts and agent memory are stored separately. Cloud SQL stores experiment states, evidence links, metric snapshots, scheduled actions, and audit events. Memory receipts store concise, verified learning conclusions linked to an experiment and its evidence. For example: “This experiment earned saves, but the current dataset is not large enough to claim improved follow conversion. Test a clearer follow CTA next time.”

In a new session, the agent must recall the creator’s goal, the previous experiment, and the learning receipt. This makes memory inspectable instead of treating a chat transcript as long-term memory. Outcome Metrics For each completed experiment, CreatorLoop calculates: [ engagement_rate = \frac{likes + comments + saves + shares}{views} ][ save_rate = \frac{saves}{views} ][ follow_conversion = \frac{follows_gained}{views} ]If fewer than three completed experiments are available, the system displays insufficient_baseline and does not claim a growth percentage or causal improvement. Challenges Making Autonomy Real The first challenge was separating “the agent generated a response” from “the agent completed a task.” We solved this by making every follow-up a durable action with a due time, an idempotency key, an explicit state transition, a protected execution endpoint, and an audit record. The agent is awakened by an external event instead of waiting for the user to send another message. Preserving Human Control An autonomous creator agent should not make irreversible decisions without consent. We added a hard approval boundary. The agent can propose experiments, schedule follow-ups, request metrics, and record learnings, but it cannot publish content. Combining Model Reasoning with Deterministic Guarantees LLMs are useful for understanding context, but they should not calculate business metrics or invent performance results. We separated model reasoning from deterministic application logic. The model explains evidence and chooses among allowed actions. The application validates evidence, owns the formulas, and controls state transitions. Building Reliable Memory A conversation transcript is not the same as useful long-term memory. We introduced memory receipts that summarize verified learnings and connect them to experiment IDs, metric snapshots, and evidence. This makes memory testable, traceable, and safe to reuse in later sessions. What We Learned The biggest lesson is that an agent is not defined by how naturally it talks. It is defined by whether it can safely continue a piece of work across time. Reliable agentic applications require more than an LLM call. They also need:

durable state;
event-driven wake-ups;
restricted tools;
human approval boundaries;
idempotent retries;
evidence-linked memory;
observable failure states. We also learned that good AI product design is partly about deciding what the model must not do. By limiting the model’s authority and moving critical guarantees into application code, we make the system more reliable and easier to audit. Data and Safety Boundaries The project does not automatically publish content, log in to social platforms, bypass platform protections, or send messages to arbitrary recipients. All demo outcomes are clearly marked as scripted replay data. We do not present them as real creator growth or real-time platform data. The previous xiaohongshu-insight project influenced the problem framing and evidence-grounded audience analysis approach. It is disclosed as prior product research. CreatorLoop Taskmaster is the new competition project containing the Taskmaster workflow, agent interface, Google Cloud deployment, product UI, tests, and submission materials.