aarttsii outreach

aarttsii is an outside business, a handmade crochet studio selling to brands. OCTYN built its outreach system and operates it daily.

1. The situation

Rebuilt 2026-07-29. The earlier pipeline used Tor search, a proxy pool and small local models to qualify and write. It failed in two ways a buyer notices: India and abroad leads landed in the wrong workspace, because geography was left to model judgement, and the emails invented mascots the brands do not have.

2. Why it was hard

The volume is small and the cost of one wrong email is large. A fabricated detail, or a mail dropped into a live deal, is the relationship rather than a metric dip. So every unattended step had to be safe to run unwatched, and every gate had to be code rather than a model's opinion.

3. What was built

Two planes that never talk directly. They share one Supabase database and nothing else.

The heavy plane runs at night on a laptop: find brands by similarity and provenance, scrape the site, score against the tenant's ICP, classify the market, match a crochet form to the brand's object, resolve a contact, draft, schedule, suspend. The reasoning is a Claude session rather than an API call. The light plane is always on, on the VPS, with no browser and no model, polling for jobs whose time has come.

The gates are plain TypeScript with tests beside them. geo.ts classifies India against abroad from currency, phone prefix, GST and TLD. voice.ts is a hard lint every draft passes before it can be queued. Geography became code rather than judgement, which removed the first failure outright.

4. What it does under load

284 contacted leads on 2026-08-11. Volume is 25 first-touches a day, split hard at 15 India and 10 abroad since 2026-08-25, against per-inbox caps of 15 new plus 15 follow-up on one address and 10 plus 10 on the other. Follow-ups run at plus three and plus five days under a daily cap of 60, and nothing sends at the weekend. 51 unit tests as of 2026-07-29 cover voice, cadence, geo, the forms catalogue, the email kit and the learning loop.

Reply rate is not published. Replies are tracked per lead, but no rollup exists, so there is no number to quote.

5. What happens when it breaks

Sending is the part that can do damage, so sending has no intelligence in it. A Claude send-worker was tried, and it errored, mis-sent, then reported a send that had not happened. The replacement is a stdlib-only Python service under systemd, polling every 60 seconds, marking each job as it goes and posting a confirmation per send. Mail credentials are not on its disk, they are fetched at run time.

Every guard exists because something went wrong on a dated day, written into the operating doc next to what it prevents.

On 2026-08-10, 115 follow-ups came due across a weekend nothing picked up, because the due-check only looked at today and Monday already held 93 against a cap of 60. The scheduler now slides overflow forward at creation time and pushes weekend due dates to Monday.

On 2026-08-12, a lead had replied naming the person to contact, a proposal was already with that person, and the reroute step saw the old role inbox idle and queued a cold first-touch to a third person at the company. It was cancelled sixteen minutes before it would have sent. The gate now says that the moment any human at a company answers, that lead belongs to the conversation.

Rollback is per job. A queued send can be edited, rescheduled or cancelled up to its send time, and the row that sends is the edited row.

6. Who maintains it, and what that costs in attention

One operator, one window a day.

The decision that sets the attention cost is the one o'clock send time for India. Nothing goes out in the morning. That is a deliberate look-window rather than a technical constraint, so the owner can read the day's queue and pull anything they dislike before a mail moves. The system deliberately does not ask for approval per mail, because a per-mail gate at 25 a day becomes rubber-stamping inside a week.

The recurring cost is judgement on replies, where a person takes over and should. The other is that the sender lives on the VPS, so a scheduling-rule change is not live until it is redeployed there.

7. What changes when requirements change in six months

Configuration, no code. The ICP is a JSON file per tenant: sources, weights, thresholds, categories, market. Daily volume, the geography split, inbox caps, send windows and follow-up offsets are values. A third tenant already runs on the same engine with a completely different ICP, which is the proof the separation holds.

A code change, contained. A new geography signal is a rule in geo.ts with a test. A new banned phrase is a line in the bans list. A new email layout is an entry in the kit, and the learning loop starts scoring it against the others on its own.

A code change, larger. Everything here assumes email: threading, bounce detection, inbox caps, the reply check. A new channel reuses the finding, qualifying and drafting halves and needs a new sending half.

A rebuild, one case only. At thousands a day instead of 25, the reasoning session stops being the right brain, because it is deliberately slow.

8. What we would do differently

Write the rollup first, because with no published reply rate the operator has no line to read, and that is the number the system exists to move. Put the contact-quality gate at the front, because 201 of 284 leads sat on role inboxes before anyone counted and a role inbox cannot carry a cadence. And stop trusting a model with an irreversible action sooner.