Lifecycle email, drafted by an agent that cannot send it.
SocialPilotix plans and writes onboarding, activation and win-back email from the data already in your Postgres database. Every message waits in a queue until you approve it.
Wired — the run reaches
- Pseudonymised segments
- The draft queue
No wire — the run stops short
-
Sendheld by
sender -
Approveheld by
approver -
Eraseheld by
data_protection
The one run that is yours
Enforced by database permissions held by separate processes — not by an instruction in a prompt.
One pipeline, seven steps. The sixth is a person.
The agent does not invent its own workflow. It runs the same steps every week, and step six is never automated.
- SelectsSegment
Who is due a message, from consented users only.
- DecidesPlan
Reads last week’s results and picks what to try.
- WritesDraft
Each message, from your brand voice and product facts.
- BlocksCheck
Personal data, unknown links and risky claims.
- HoldsQueue
Drafts wait here. Nothing has left the building.
- YouApprove
You read each draft and approve or reject it.
- ReleasesSend
A separate worker delivers it and records the result.
The strip runs past the edge — drag it, or focus it and use the arrow keys.
Built for the failure cases, not the demo.
An AI that can email your customers is a liability until the limits are real. These are the limits, and what enforces each one.
-
The model never sees a name or an address
Users reach the model as salted hashes with behavioural flags. Drafts are scanned for personal data by value before they can be queued.
-
Unsubscribing always works
Every message carries a signed one-click unsubscribe link. Bounces and spam complaints suppress the address automatically, without anyone intervening.
-
One switch stops everything
A kill switch halts drafting and delivery. Sending starts disabled, and the first runs go only to an allowlist of your own inboxes.
-
Every decision is on the record
What was segmented, planned, drafted, blocked, approved and sent is written to an append-only audit log you can query yourself.
-
Access and erasure are one command
Exporting or erasing everything held about one person is a single documented command, so a GDPR request takes minutes rather than an afternoon.
-
A failed send cannot loop forever
Delivery retries with a widening delay and then parks the message as a dead letter, where monitoring picks it up instead of it disappearing.
If you are about to check my work.
The claims above are mechanisms, so here are the mechanisms. Open only what you want.
How “the agent cannot send” is actually enforced
Each service connects to Postgres as its own login, and each login is granted only the capabilities it needs. The agent’s login is never granted the sending, approving or erasing capability, so the permission simply is not there to use.
-- the agent's login holds exactly these capabilities
GRANT agent_reader, agent_enqueue TO lifecycle_agent_login;
-- sending, approving and erasing live on other logins entirely
GRANT sender TO sender_login;
GRANT approver TO approval_login;
GRANT data_protection TO dpo_login;Every privileged operation is a SECURITY DEFINER function owned by a role the agent cannot assume, with a fixed search_path. A prompt injection, a bug or a stolen agent credential still cannot send an email, because the database refuses it rather than the software declining to.
What the model actually receives
Not a name, not an email address, not a customer record. Each person is referenced by a salted SHA-256 hash, accompanied by behavioural flags such as days left in trial, whether activation happened, and days since last seen.
Before a draft can enter the queue it is scanned for personal data by value, not by pattern: the actual addresses and names from your database are checked against the draft text. A draft that contains one is blocked rather than cleaned up.
What happens when something goes wrong
A draft that fails its checks never reaches the queue, and the reason is recorded. A message that fails delivery is retried on a widening delay and then parked as a dead letter for a human to look at.
Claiming a message for sending is an atomic database operation, so two workers cannot send the same message twice, and a worker that dies mid-send releases its claim rather than stranding the message.
Setting MARKETING_AI_KILL_SWITCH stops drafting and delivery at the next run without a deploy.
Where it runs and who can read the data
Against a Postgres database you control, in hosting you control, inside the EU. Your customer data is not copied into someone else’s product.
The drafting model is a setting: Anthropic, NVIDIA, DeepInfra or any OpenAI-compatible endpoint. Whichever you choose receives only the pseudonymised context described above, and the GDPR paperwork — records of processing, the sub-processor register, the data subject request runbook — is written alongside the code rather than after it.
Two kinds of customer, one queue.
The difference between selling to companies and selling to people is a matter of segment rules and frequency caps, not a different product.
Trials that go quiet Business customers
Find accounts that signed up and stalled, and draft the message that names the step they missed. You approve it before anyone at that company sees it.
Customers who drift away Consumers
Win-back and activation messages, only to people who opted in, with a cap on how often any one person hears from you and the unsubscribe link treated as a first-class part of the message.
What this is not, yet.
-
Not generally available
It is in private build. The waitlist gets exactly one email, on the day it opens.
-
Email only
Lifecycle email is the whole product today. Other channels come after this one is proven, not before.
-
It needs your database
It works against a Postgres database you already run. It is not a hosted tool you upload a contact list to.
-
No price yet
There is no pricing to quote, and inventing one before the product is open would be a guess dressed up as a number.