If a tool should be deterministic code, it is. Agents are used only where reasoning is required. An agent's judgement can differ from one run to the next, so a GTM engineer puts whatever should be the same every time in code and uses an agent where judgement adds something, on top of that: skills your team runs from Claude, personalization connected to your context and messaging, listening triage, and custom tools and sub-agents for your team. Every draft comes back with what the model was shown beside it.
HubSpot-first, no RevOps
Someone tried an AI tool that wrote outreach nobody read before it went out, and it invented a fact in the first week. Now AI is a word the team avoids, and the playbooks still live in one person's head.
Ecosystem sellers and agencies
Your buyers describe the problem you solve in public every day, and nobody on the team has a safe way to join in. The tools that offer to help want to act as your reps on LinkedIn, and that puts their accounts at risk.
Product-led SaaS
Trial follow-up is written by hand from whatever a rep can find across your product, the CRM and the inbox, or it is not written at all. A draft with the evidence under it would be worth having, if someone could see what it was shown.
Your ICP, personas and playbooks are written once, in documents your team keeps, and as skills that read them, installed from a private marketplace you own and run from Claude, so a non-engineer on your team runs a playbook without an engineer in the loop.
Each kind of email your team sends has its own rules, its template and a list of what the model may be shown, every draft is stored with that context pack and checked in code for any claim the pack does not support, and a judge step flags what a person should read before it goes out.
Your reps' drafts come from a daily agent that is a thin loop over tools that are code: the list decides who is eligible, the agent drafts, a task is created on the owning rep by code, and everything it proposes is recorded with the evidence.
A daily sweep of public conversations about the problem you solve is code, sorting each thread by problem and intent is reasoning recorded on the item, and a reply is drafted in the voice of a named person on your team, who posts it from their own account.
Your skills live in a marketplace repo you own, written against your own conventions and shipped through your own review gates. The rules and template behind each kind of email are text your team edits in a shared sheet or doc, compiled by code into files in your repo with a version on each, and the listening taxonomy and the style cards are files there too.
Every rep draft arrives as a task on the owning rep, with the evidence beneath it and the version of the rules that produced it. A listening item at a target account becomes a dated signal on the account, with its source. The email the rep actually sent is on the record beside the draft, so you can see how much was changed.
Involved whenever a draft or a personalized line is written. Each request carries what it needs, and what comes back is a draft with its flags, for your team to review.
What you receive at exit
Inline writer on your keyAn inline implementation on your own key, handed over. Nothing upstream changes.
A written scope, a typical timeline, and a deliverable you can inspect on day one. Timelines are typical, not guaranteed. The proposal sets the one for your stack. Every engagement starts with the Stack Audit: 1 week, and its readout proposes the next piece for your stack, priced in the proposal.
Typical timeline: 1–2 weeks
For the team that wants to run its playbooks from Claude without an engineer in the loop.
Typical timeline: 2 weeks
For the team that knows buyers talk about the problem in public but has no safe way to join.
Used in GTM systems we've built for B2B SaaS clients running in production every day.
Only where your rules say it can, and never on judgement alone. A cold line goes out under the suppression and eligibility rules, with a sample in a person's hands; a rep draft goes into a task the rep edits and sends from their own inbox. What the model was shown is stored with every draft, so when a line is wrong you can see why, and a play earns more latitude as the rules and the judge prove themselves.
Less often, and never unchecked. The model is shown only what is already on the record: CRM fields, the thread, meeting notes, research with its sources and phrases your buyers have used. It is never on the open web while drafting, so when the evidence is not on the record the line is left out rather than invented. Code checks that every name and number in a draft appears in what the model was shown; a second model call reads each draft for what code cannot check, and flags what it finds; a person reads the flags and a sample. A rep draft is read before it is sent. A cold line goes out under the rules, with a sample in a person's hands, and the sample is what tells you how often the judge misses; every decision on a flagged or sampled line becomes a label the next version is checked against.
It can surface mentions. It cannot check a thread against your CRM, so you would reply to a customer or an open deal as if they were a stranger, and it cannot draft in your people's voice. Here the sweep and the daily cap are code, sorting each thread by problem and intent is reasoning recorded on the item, and the reply is a draft for a named person who posts it. Over a quarter the phrases your buyers use become a corpus in your own repo, which no listening tool hands back when you cancel.
No, and that is the point. The accounts at risk would be your reps' own, and a reply nobody on your team actually saw reads that way. Nothing we build posts, comments, connects or messages, on LinkedIn or anywhere else. What we build instead is a capture tool: one click from a post a rep is already reading puts it in the queue with the company and the persona, never the poster's name, and the rep gets a draft in their own voice to post from their own account.
Every engagement starts with the Stack Audit: 1 week. Its readout says which piece to build first for your stack and prices it as a fixed fee.
Vendor spend stays yours: reported, never marked up.