Ask an ecommerce team what it should send next week and the answer usually comes from the calendar, a dashboard someone remembered to check, and the last team discussion. Its limit is attention. An opportunity that nobody notices never becomes a brief, so no optimization model ever sees it.
Adding a language model after the brief only makes that reactive workflow faster. The Daily Briefing moves the initiation boundary: it investigates first and returns up to five campaigns connected to a real audience and send window.
How do teams choose campaigns today, and why is it weak?
The conventional workflow couples discovery to execution. A marketer checks reports, chooses a theme, finds an audience, and starts production. The chain still depends on somebody remembering where to look.
A generic model can produce five plausible ideas, but plausibility is not evidence. If the same model invents the candidates and grades them from its own prose, polished guesses can rank above an awkward opportunity supported by current data. Research on agents that interleave reasoning with actions shows why external observations matter: tools let a model update its plan from the environment instead of reasoning only from its stored parameters (ReAct).
Why is proactive email marketing worth getting right?
We define a proactive agent more strictly than scheduled generation. A proactive system gathers evidence, discards recommendations that cannot be executed, and leaves a human with work that can move forward.
The missing value often sits in unfinished business from a recent send, a catalog pattern, a reachable cohort, or an open calendar date. The problem is converting scattered state into defensible actions.
How does LTV.ai turn signals into Daily Briefing ideas?
Each enabled brand gets one durable briefing run per day. The agent uses typed tools for the marketing calendar, send performance, past creative, competitor context, product catalog, and audience data. It drills into signals that survive contact with the data.
Each recommendation is emitted through a structured tool call with a title, technical brief, send date, and audience label. The server caps the run at five, removes duplicate titles, and permits fewer. Five is a ceiling, not a quota.
The audience label is a join key. Before emission, an audience service resolves and sizes the cohort. The agent sees the count, while re-executable criteria travel on a private application channel the model never sees. The idea must point to that exact label or the server drops it.
A recommendation with no buildable "who" is not a recommendation.
What does the tool-calling architecture actually do?
The model never receives database credentials or arbitrary query access. It receives named operations with input schemas. The application validates each call behind a domain port and returns a bounded result. In the standard client-tool contract, application code executes a model's tool request and returns the result to the loop (Anthropic tool-use documentation).
Runs, ideas, audiences, builds, scores, and deliveries are persisted separately. Workers claim rows atomically, so several containers can process the queue without duplication. PostgreSQL identifies SKIP LOCKED as suitable for consumers of a queue-like table (PostgreSQL SELECT documentation). If a worker stops after insertion, the next worker finalizes existing artifacts instead of repeating the model call.
How are ideas built and ranked?
The generator does not assign itself a confidence score. Once an idea and audience are durable, a separate stage builds the email and subject lines. A separate scorer reads the final subject and rendered body, scores the complete batch, and stores projections with the model version and audience used.
A forecast on a one-paragraph idea measures the pitch. A forecast on the finished email measures the artifact a customer could receive. The briefing orders recommendations by impact tier and then send window. A missing forecast remains missing.
Approval creates the editable design and queues the stored audience for materialization. It does not silently schedule an ESP send. The recommendation arrives proactively while the send decision remains human.
How does the feedback loop stay honest and compound?
The system reads recent ideas before every run. Approved and pending concepts are not duplicated. Rejected concepts do not return as cosmetic variants. A structured rejection routes feedback to the responsible layer: relevance, audience, design, timing, or brand voice.
"We are already sending this" is a calendar collision, not evidence that the idea was bad.
That separation stops one blunt rejection from poisoning every stage. Review feedback changes future ideation and design guidance. Send performance supplies an implicit signal. Business impact is evaluated separately against a holdout, because attributed and incremental revenue are different quantities (NBER field experiment on incrementality).
The system does not invent a product, offer, URL, or date. It drops ideas with no resolvable audience, preserves partial runs instead of padding them to five, and omits unavailable scores. Infrastructure failures receive bounded retries. A run with no defensible idea fails rather than filling the briefing with noise.
Frequently asked questions
Is this just an LLM generating five ideas? No. The model controls an evidence-gathering loop, but application code owns audience resolution, contracts, persistence, building, scoring, delivery, and review state. Unsupported prose cannot become a sendable recommendation.
Why not generate hundreds and rank five? Candidate volume is not scarce. Evidence and executable audiences are. The system investigates a bounded set, then evaluates artifacts it can build.
Can the Daily Briefing send without a person? No. It carries an approved idea into an editable design with a materializable audience. A human controls the send.
Part of The Machine Learning Behind LTV.ai.
See it on your store: book a demo.