Signal monitoring
A named account list watched for the changes that justify a conversation, so timing is not guesswork.
Service · AI sales agents
Outbound that waits for your approval before anything sends
Outbound either eats the week or gets handed to a bot that sends things you would never have signed off. The agent watches your target accounts for buying signals, drafts a personalised hook for each one, and queues it for approval.
The problem
Signal-watching does not scale by hand.
Good outbound depends on timing: reaching an account when something has actually changed. Watching a target list for funding, hiring, leadership or stack signals is slow work, so most teams fall back on generic sequences that land flat.
The teams that do personalise hit a different wall. Once an agent is drafting and sending on its own, you have lost control of what goes out under your name. The hard part is not generation. It is keeping a person in the loop without losing the speed.
Fit
Who this is for.
B2B teams selling into a named list rather than a broad market, where the deal is worth a personalised approach and someone senior cares what goes out under the company's name.
Not a fit if you want volume above all else. This is built to send fewer, better-timed messages that a person has approved, and it will not beat a blast on raw message count.
In practice
What gets built.
Drafted hooks
Each draft written against a real, recent signal rather than a template with the company name swapped in.
An approval queue
Edit, approve, or reject with a reason. The agent reads those decisions and adjusts.
Agent access over MCP
The same approval rules apply when the request comes from a chat client rather than the app.
Deliverables
What you get.
- Signal monitoring across a named account list, so timing is not guesswork
- Drafted outreach grounded in a real, recent signal rather than a template
- An approval queue where you edit, approve, or reject with a reason
- Agent access over MCP, so the same approval rules apply from a chat client
- Approval history and tone examples the agent learns from
- Documentation written for handover
Design decision
Approval is the architecture, not a setting
Quiet hours, daily limits and auto-approve behaviour are enforced in the runner rather than only in the prompt. That distinction matters: a prompt can be talked around, a runner cannot. It is what lets a team hand outbound drafting to an agent without handing over the account's reputation.
Integrations
What we have built against.
Enrichment and discovery sources for account research, Claude for drafting and scoring, an MCP server for agent access, CSV export, and an HMAC-signed webhook on approval for writing into your own systems. Provider adapters for sending tools exist in the codebase; we treat sending as your step rather than a stage we claim runs itself.
Delivery
How the build runs.
Discovery
We agree the territory, the signals worth acting on, and what a good approach sounds like in your voice.
Signal design
Sources and thresholds set, so a draft only appears when something has genuinely changed.
Build
Monitoring, drafting and the approval queue, with limits enforced in the runner.
Handover
Your team runs the queue, adjusts the territory and reads the history without us.
- Scope
- One territory, fixed
- Typical timeline
- 3 to 6 weeks
- Ongoing
- Retainer, optional
- Ownership
- Yours, documented
Timelines depend on the size of the territory and how many signal sources are in scope. Ongoing work runs as Integration Cover: a monthly block of 10, 20 or 40 engineering hours on a three-month minimum, with overflow agreed in advance at the tier rate.
Oversight
Data handling, and what happens when something is wrong.
- Drafts are queued for approval; approving is a human action
- Quiet hours and daily limits are enforced in the runner, not only the prompt
- Rejections carry a reason, and the agent adjusts to them
- Approval can fire a signed webhook, and data exports as CSV
- Account and contact data goes only where you already send it
Proof
Open it before you talk to us.
Questions
What buyers ask.
Can it send anything without us approving it?
No. Drafts land in an approval queue, and approving is a human action. Quiet hours, daily limits and auto-approve settings are enforced in the runner rather than only in the prompt, so the limits hold even if a prompt is changed.
What stops the drafts sounding generic?
Each one is written against a specific recent signal on that account rather than a template with the company name swapped in. If there is no real signal, there is no draft, which is the point.
What data does it need?
A target account list and enough of your voice to write in it. Enrichment fills in the rest. It does not need access to your inbox to draft.
Can we use our own sending tool?
Approved drafts export as CSV, and an approval can fire a signed webhook into your own systems. Provider adapters exist in the codebase, but we describe sending as your step, not a stage we claim runs itself.
What is the MCP access for?
It exposes the same approval loop to a chat client, so you can list pending drafts, approve and reject from Claude Desktop or Claude Code through scoped tools. The rules do not loosen because the request arrives from a chat window.
Who owns it afterwards?
You do, documented, including the account list, the approval history and the tone examples the agent has learned from.
Bring us the account list.
Send the accounts you care about and what a good reason to contact them looks like. If your list is not specific enough for signal-based outbound yet, we will say so.