Most B2B SaaS companies still scale outbound by hiring. They put SDRs on the floor, write sequences, and hope volume compensates for poor fit. The math was always brittle. In 2026 it has stopped working.
One of our US clients is doing the opposite. The team is small, the engine is engineered, and the asset is the pipeline that produces qualified contacts, not the people who run it. 38shift operates the GTM engineering on their behalf: sourcing more than 100 accounts a week across 14 industry verticals, running 12 custom campaigns in parallel, each mapped to a distinct ICP, with personalized outreach attached to every send. This is what GTM Engineering looks like in practice. The article is a field report from inside that build.
At a glance
- —More than 100 accounts sourced per week across 14 industry verticals.
- —12 custom-tailored campaigns running in parallel, each one mapped to a distinct ICP, with personalized outreach end to end.
- —Two-track outbound: Apollo into Instantly for email, Dripify for LinkedIn. Buyers do not live in one channel.
- —Claude agents handle ICP scoring, why-now generation, copy personalization, and reply classification. Each agent is named, scoped, and accountable to a specific output: Apollo Sync, ICP Research, Lead Gen, Sequence Builder.
- —Attio as the system of record. Every agent reads from it and writes back to it in the same loop.
The market the client is built into
The client is a B2B SaaS platform sitting in a mid-market category where buyers still close deals over spreadsheets, PDF quotes, and email approval chains. The largest brands have moved on. The mid-market has not, because the available tools were built for Salesforce-shaped companies. The category gap is real. The growth engine is the thing that lets a small team get into those accounts before the legacy vendors notice.
Four layers, one engine
A signal-driven growth engine has four functional layers and one substrate. The signal layer decides who deserves to be in the funnel. The enrichment layer fills in what the system knows about them. The reasoning layer decides what to do with that information. The execution layer reaches out. Attio sits underneath all of it as the system of record. Most outbound stacks treat these as separate products bolted together. Treating them as one engineered system is the entire point.
Signal layer
The signal layer is where most outbound stacks underinvest. They run a list pull from Apollo, filter on title, and call it sourcing. That produces volume. It does not produce a why-now.
For this client, the signals that matter sit downstream of where their buyers actually operate: software adoption patterns that indicate a B2B workflow underneath, integration choices that suggest a move into wholesale or enterprise selling, recent funding events, role changes in the buyer-side organization. Apollo handles the breadth. Clay handles the waterfall enrichment. Custom scrapers handle the long tail nobody else is pulling, which is where the moat lives. A list anyone can buy is not a moat. A scraper that watches for a buying signal the moment it goes public is something only the team that built it has.
Reasoning layer
This is where Claude does the work that used to be called judgment. Each agent has a scope and an output it owns.
Apollo Sync keeps the account universe and the contact graph clean and current. ICP Research scores accounts against the 14 verticals, flagging signal strength and exclusion reasons. Lead Gen takes the qualified accounts and produces ranked contact lists with why-now context attached. Sequence Builder drafts the cold outreach, grounded in the scraped evidence, in the voice of the operator who will send it.
None of this is AI for copy. AI for copy produces sequences that read like they came from a content farm. This is AI as decision logic, where every output has a citation trail back to a signal and an ICP fit score. Reply classification is its own loop. Inbound replies are sorted by intent class (positive, request for context, soft pass, hard pass, out-of-office, wrong person) and routed accordingly. The boundary between classes tightens over time as the system sees more replies.
Execution layer
Instantly handles email. Dripify handles LinkedIn. Two channels because the operations-side buyer does not live in one inbox. Some are LinkedIn-active and email-cold. Some are the reverse. Forcing the buyer into the channel that suits the seller is the oldest mistake in outbound.
Deliverability is treated as an engineering concern, not a vibe. Warmup, domain rotation, sending volume curves, inbox placement monitoring, and content classifiers run continuously. A sequence that lands in spam is a sequence that did not happen, no matter how well it was written.
The substrate: Attio
Attio is the system of record. Every agent reads from it. Every agent writes back to it. The reason for that choice is operational, not aesthetic.
Legacy CRMs were designed for humans to enter data and pull reports. Modern outbound stacks are built around agents reading and writing constantly, which legacy systems either rate-limit, distort, or fight outright. Attio's programmable model makes it possible to treat the CRM as a queryable substrate rather than a destination. The agents do not push data into Attio at the end of a workflow. They live inside it.
What gets built, what gets bought
Apollo, Clay, Instantly, Dripify, Attio, and Claude are rented. They are good at what they do, and rebuilding any of them would be a bad use of time.
The custom layer is the orchestration logic and the scrapers. The orchestration is what makes those rented tools behave like one engine instead of five products. The scrapers are what give the signal layer coverage nobody else has. Those two pieces are the asset. Everything else is leverage.
What sales-ready actually means
Traditional SDR teams measure meetings booked. The unit assumes that meetings are the scarce thing. They are not. The scarce thing is the qualified context behind the meeting.
The engine measures sales-ready contacts: prospects where the signal evidence, enrichment depth, and ICP fit are enough that the operator can step in with a why-now in hand. The downstream conversion is not random, because the contact arrived with provenance.
The constraint that flips
When the system carries the qualification load, headcount stops being the growth lever. Adding another SDR to a broken engine does not produce more pipeline. It produces more noise.
What scales instead is signal coverage and pipeline reliability. More scrapers, watching more surface area. Better classification of reply intent. Tighter enrichment waterfalls. Cleaner agent handoffs. Each of those investments compounds. SDR headcount does not.
This is the part most teams resist, because it requires building an asset that does not have a face. A growth engine is not a person. It does not produce energy in a Monday standup. It produces sales-ready contacts on Tuesday, and the same on Wednesday, and the same on Thursday.
The takeaway
If you are scaling outbound by hiring SDRs in 2026, you are solving the wrong problem. The right problem is engineering the layer beneath them, which is the engine itself.
This client is one example of what the right problem looks like. The same architecture, with different signals and a different ICP, applies anywhere outbound is a serious channel.