The outreach pipeline
The outreach pipeline is our system for finding relevant companies and drafting messages from one studio profile, with human approval before sending.
Two engagements are confidential. Every draft must pass automated checks that protect their names and keep our claims consistent.
Back to our workThe running architecture
Our own system · Human approval before sending- 01
Company research
Relevant public context
- 02
Grounded draft
One studio description
- 03
Guardrail checks
A failure blocks action
- 04
Human review
Approve the exact note
- 05
Recorded outcome
An inspectable trail
The problem
Written rules did not hold
Rules about client names, claims, and positioning lived in a document. Generated drafts could break them while sounding plausible.
The studio had conflicting descriptions
Site copy, outreach notes, and drafting profiles were maintained separately. Correcting one left the others unchanged.
What we built
01One shared studio profile
Connected tools read from one record. A correction updates every surface that uses it.
02Confidentiality checks on every draft
Protected names are stored as hashes, so the repository contains no readable list. Each draft is checked before human review.
03A safe test for the name check
An invented term is hashed into the protected set. Tests verify that the check works without putting a real name in test files or logs.
04Checks for the studio’s voice
Generated copy is checked for lists of tools in narrative text. One designated tool-list line has a tested exemption.
05Approval before sending
A person approves dispatch. Failed checks block the send and are recorded.
Known limitations
Blocked names stay out of logs
The confidentiality check reports a match count, never the name. The person fixing the draft must find the problem themselves.
One duplicate profile remains
A separate package still has an outdated copy of the positioning text, including tool lists the current rules forbid. It needs to read from the shared record.
Some valid drafts get blocked
Text checks detect patterns, not intent. We accept occasional false positives to keep the protections strict.
What it changed
- 01
Rules now fail the build
Tests enforce rules that previously depended on someone remembering a document.
- 02
Corrections reach connected tools
Updating the shared profile changes every surface that reads it. The remaining duplicate is the exception.
- 03
A pattern ready for client work
We deploy this same pattern for outbound work: one profile, checks on generated drafts, and human approval. We run it ourselves first.
Questions
- Can it send without approval?
- No. A person approves dispatch, and failed guardrails block the send.
- How are confidential engagements protected?
- Names are stored as hashes. An invented test term verifies the check without exposing a real name.
- Why not just put the rule in the prompt?
- A prompt can be ignored. Checks run on the finished draft before human review.
- Can separate tools still drift out of sync?
- Yes. One package still has a duplicate profile. It has not yet been connected to the shared record.
Bring us the processyou would rather not run.
Describe the work you want to automate. Get a starting sketch, then talk it through with us.