GTM engineering sounds like growth hacking plus Zapier. That's unfortunate, because the interesting part isn't automating things.
The interesting part is teaching the company what it already knows.
Companies know a lot that their software doesn't. The founders know why the company exists. The best reps know which objections are real and which are smoke. Marketing knows which words make buyers lean in. But most of this knowledge lives in people's heads, scattered docs, Slack threads, and the muscle memory of whoever's been around long enough.
This was tolerable when humans did the work. A salesperson could read between the lines. A founder could jump into big deals. A marketing lead could fix the campaign before it shipped.
Humans are good at using context that was never written down. Agents are not.
Old software was at least honest about this. It did exactly what you told it. If the rule was dumb, the output was dumb, but nobody was surprised.
Agents create the impression of judgment. They research accounts, write emails, qualify leads, summarize calls, decide what work happens next. That's powerful. It's also dangerous. An agent with shallow context doesn't know it's confused. A junior employee knows when they're lost. An agent confidently produces the average of whatever you gave it.
This is why so much AI-generated GTM work feels off. Not wrong exactly. Worse: plausible.
AI-generated content often sounds like something a company might say. It mentions the right persona, the right pain points. But it lacks the thing your best people would have known. It doesn't know that the official positioning is three months behind what the founder started saying on calls. It doesn't know the feature everyone talks about isn't actually why customers buy.
It doesn't know your company.
The first generation of GTM engineers mostly wired tools together. That made sense. There was a lot of wiring to do. But wiring isn't the hard part anymore.
The hard part is deciding what the machine should know.
Suppose the company decides to go after security teams at mid-market fintechs. What should change?
The obvious answer is campaigns. But that's only the surface. Account scoring shifts. So does research, qualification, competitive framing, the talk tracks reps run on calls. The whole GTM system is downstream of that one strategic decision.
In most companies, these changes happen piecemeal. Someone edits a sequence here, tweaks a prompt there, mentions the new focus in Slack. Three weeks later, the company is running the new strategy and the old one simultaneously, and nobody quite knows which system believes what.
This is normal. It is also insane.
The reason it happens is that strategy lives as language and execution lives as systems. The missing layer is translation.
That's the real job of a GTM engineer. Not automating campaigns, but making strategy executable.
The best GTM engineers look less like growth hackers and more like interpreters between the company and its machines. The company learns something about the market. The GTM engineer figures out where that learning needs to live so every system can use it.
When a new competitor appears, you shouldn't be rewriting twenty prompts. The company should be able to change its mind in one place and have execution inherit the change.
This is hard because GTM knowledge isn't a list of facts. At its core, it's all about relationships.
"CFOs care about ROI" isn't useful. Everyone knows that. What's useful is knowing that CFOs at usage-based infrastructure companies care about margin predictability when preparing for a fundraise, and that this is where your product beats the incumbent because their reporting breaks at the account hierarchy level.
That's what real GTM knowledge looks like. It lives at the intersection of product, persona, segment, timing, competitor, and pain. Humans can carry those intersections in their heads. Systems need them made explicit.
As more GTM work moves to agents, companies will discover that automation isn't the scarce resource. Automation will be everywhere. The scarce resource is taste encoded as infrastructure.
The companies that get this right will feel strangely coherent. Their campaigns, sales motions, qualification, and customer conversations will seem animated by the same understanding of the market.
The companies that get it wrong will feel haunted by their own old decisions. Every workflow will contain a fossil of a strategy they no longer believe. Every agent will have a slightly different idea of who the customer is.
Right now, GTM engineers are doing this job with tools built for other purposes, like CRMs, spreadsheets, prompt templates, and wikis. They work, sort of. But they weren't designed to hold the kind of knowledge that actually matters: the relationships between products and personas and competitors and timing that make the difference between generic and sharp.
That's the gap we're building Octave to fill. Octave isn’t another automation layer. Instead, it is a place to encode what the company knows, structured so that every downstream system can search and consume it.
The GTM engineer's job is translation. But when you translate knowledge, that knowledge needs somewhere to live.
