How I think about AI GTM architecture

Almost everyone asking how to use AI in go-to-market is asking about prompts, or which model to buy. Both matter way less than the thing nobody wants to build, which is the context layer.

Default model output is the median. Ask for a campaign brief with no context and you get the average campaign brief, which is precisely what you didn't need. The same model does 90th-percentile work for an operator who's invested in context and mid work for everybody else. That gap is the whole game, and it's a systems problem long before it's a prompting problem.

I've written separately about why AI scales expertise instead of replacing it. This page is the architecture underneath that argument, meaning what I actually built and what it cost me to learn.

What I'd hand over, and what I wouldn't

Start with what you already know cold. That's the whole heuristic. Your ability to verify scales with your domain expertise, and when you know more than the model you can direct it. When you don't, its confidence wins, and confidence isn't correctness.

Where I've landed after a couple of years of this: AI is genuinely good at content and design production, it's emerging and worth piloting on reporting and attribution, and it's still not compelling on strategy or PMM. The delegation ceiling sits somewhere around manager-level tasks. AI gets me about 80% of the way and then I take it across the line, and I haven't seen a version yet where the person comes out of the loop.

I'm also suspicious of my own motives here, and you should be of yours. The automation pitch appeals to the lazy thing. Can I make some other system do this and have it come out as good as if I'd done it? Sometimes yes. Usually that question is how you end up shipping output you can't grade.

Two layers: what you believe, and how you operate

The piece that took me longest to see is that there are two separate knowledge artifacts. Teams that build only one of them stall out.

The first is a curated wiki. Mine's in Obsidian, and it's my second brain more than a doc set. It holds what I actually believe: frameworks, ingested sources with the tensions between them logged instead of smoothed over, a running register of contradictions I haven't resolved, and the first-party numbers I'm allowed to cite. It's a graph, so a claim in one file links to the source behind it and the concept it belongs under. It's written for a reader I'm trying to convince.

Then there's the operating system, which is separate on purpose. Mine lives in Claude and I call it KelOS. Rules, agents, skills, scheduled jobs, memory. Its reader is a machine that has to execute, so the writing stays operational, and anything aspirational or discursive would just confuse it.

Keeping them apart matters because they run on different clocks and break in different ways. Beliefs get revised when new evidence lands, and operating rules only get revised when something actually falls over, which is a completely different cadence. Merge them and you get a document that's simultaneously too abstract to execute and too procedural to argue with.

Progressive disclosure is what makes it survive scale

The naive version of a context system loads everything at the start of every session. That fails three ways. You pay token cost on every turn whether the work touches the context or not, attention gets diluted across material irrelevant to the task, and your cache invalidates every time anything in the pile changes.

So the boot file doesn't contain the context. It contains a routing table, task type mapped to file path, plus a couple of core docs. Everything else gets pulled in when the work demands it. Name what exists, don't include what exists, let the model go get it.

That's the difference between a context system that works at a handful of files and one that still works at hundreds. A session running a paid pacing check shouldn't pay to read ABM playbooks and SEO audit rules just because they live on the same disk.

Corrections go to a log before they become rules

Here's the failure mode nobody warns you about. You overfit your own system.

You correct the model once, you write a permanent rule out of that single correction, and now a context-specific edit applies to every future case forever. Do that fifty times and you've got an unsearchable pile of contradictory rules, some of them pointing at projects that ended months ago. People are calling this context debt, which is the right name for it, because it accrues without announcing itself and you find out when the system starts contradicting you.

So I split the two kinds of correction. Facts go straight into memory, so IDs, schema names, URLs, and anything I explicitly said to remember don't have to earn their place. Behavior and style corrections go into a dated log instead. Then a periodic audit clusters that log, and only patterns that have actually recurred get proposed for promotion, as a diff I approve one at a time. Promoted entries stay in the log rather than getting deleted, so the whole thing stays auditable.

The rule doing the work: one correction never becomes a rule. Reactive editing is how you build a Frankenstein skill that nobody, including you, can reason about.

Where the automation actually has to run

Least glamorous section on this page, and the one that's saved me the most time, so I'm going to be specific.

Cloud-hosted scheduled agents couldn't do the job. The workflows I care about need cloud connectors for Slack, Notion, the CRM, and the ad platforms, plus local scripts and outbound calls to vendor APIs. Remote sessions couldn't reach any of it. Connectors didn't provision, tool lookups came back empty, direct API calls returned 403. That held across every trigger I tried, which took me longer to accept than it should have.

So the whole fleet runs locally, on my machine, on a schedule, and those sessions deliver into the same places a person would.

I moved the scheduling off cron too. Cron skips anything scheduled while the machine's asleep, which on a laptop means your 8am job simply doesn't exist on the mornings you weren't at your desk, and nothing tells you. The macOS job scheduler runs the missed job on next wake. It also runs on local time, so 8am stays 8am through daylight saving instead of drifting an hour every winter.

One more that'll bite anyone doing this. A headless session doesn't reliably load the same connectors an interactive one does. Two of my data pulls still fail intermittently for exactly that reason, and I'd rather say that than pretend the thing is bulletproof. The workaround is a hybrid: pull the data locally first where connectors are reliable, then hand the results to the scheduled session as text, so it only needs the connectors it can count on. And the watchdog checks whether each agent actually delivered. Exit code zero and actual delivery are different questions.

None of this is interesting, and all of it is the difference between a demo and something that runs on Tuesday while you're in meetings.

Verification is the human job

AI output shows up wearing a finished suit. Structured, confident, cleanly formatted, which makes a wrong answer harder to catch than a messy human draft would be.

The example that stuck with me is a billing field returning cents while labeled as dollars. The wrong reading and the right reading look identical on the page. Same number shape, same currency, same date, and nothing in the data flags that you need to divide by 100. The model has no internal sense of whether a magnitude is plausible, so a 100x error ships looking exactly like a correct answer.

The rules I hold are unglamorous:

• Never let the system invent a benchmark or a denominator.
• Say plainly what couldn't be retrieved instead of papering over it.
• Attach a provenance block to anything aggregated: source, pull timestamp, record count, what was unavailable, what was estimated.
• Surface uncertainty instead of polish.

Those exist because the output arrives looking finished, so you stop checking. Speed plus polish is what actually gets past you, because a confidently wrong answer in clean formatting sails right through.

Two more I picked up from Jordan Crawford and now run everywhere. The agent that finds a problem and the agent that confirms it should never be the same agent. And you don't apply a fix to a claim you haven't reproduced yourself, no matter how confident the reviewer sounded.

The average is the slop, and design is where you see it

The clearest version of this principle shows up in design, which isn't where I expected to find it.

Tell a model to build a page like a company you admire and it fetches that page, but a fetch gets the words and nothing else. No pixels, no CSS, no actual computed values. So the model paints the rest from the average of every page it's ever absorbed, and that average is the slop. Same rounded cards, same drop shadows, same gradient, same default typeface, on every AI-built page in the category.

Two fixes, and I use both.

First, capture instead of describe. Render the real page in a real browser, take the screenshot and pull the actual computed values, the real hex codes and radii and shadows, then build from those instead of from a memory of what the page looked like.

Second, a written constraint sheet that names what's banned. Ours for ABM pages and ad creative specifies the exact corner radii allowed and which ones are forbidden, borders instead of shadows on cards, two approved gradients and no others, which typeface is allowed for labels and never for body, and one accent color reserved for primary actions. Every one of those rules exists because the model kept reaching for the generic default, and I learned pretty fast that stating a preference doesn't stick the way an explicit ban does.

Per-account creative works the same way. The variance between accounts comes from a fixed set of concepts crossed with that account's own evidence, so the account supplies the difference. Ask the model to be creative fresh each time and you get variety that all looks the same, which is a strange sentence and also exactly what happens.

Personal OS before company OS

The adoption path I'd recommend is the one I took by accident. Build the personal system first. It's the proving ground, the blast radius is you, and you find out fast which workflows were actually worth automating. Then the ones that survive graduate into a shared repo the team can run.

Go the other direction, standing up a company-wide AI operating system before anybody's proven a workflow, and you get a governance document instead of a capability.

I'll say the honest thing about where this lands on an org chart too. It's turning into a real role. The toolkit has consolidated fast, the headcount is growing, and it sits apart from RevOps, which owns process and reporting. GTM engineering owns the systems that produce GTM outcomes: designing the pipes, writing the prompts, owning the instruction files, shipping systems other people consume. I currently absorb that function inside a demand gen seat, and absorption has a ceiling. The more agents, scheduled jobs, and data wiring you run, the more it becomes somebody's actual job.

What I'd look at first

• Whether anyone can name the three workflows worth automating, and whether those are workflows the team could already grade by hand.
• Whether context lives in files or in people's chat histories.
• Whether corrections accumulate anywhere, or get applied once and forgotten.
• Whether any number an AI workflow produced has ever been checked against its source.
• Whether the scheduled jobs have a watchdog, or whether you'd find out they stopped when somebody noticed a Slack post missing.

The teams getting real leverage built the boring layer underneath, and they can usually show it to you in about four minutes.