Tables, not prompts.
AI applied to go-to-market.

Most of the go-to-market work I do now runs through an LLM. The analysis first, then outbound, SEO, Google Ads and Meta Ads.

The tools connect in an afternoon. Getting the model to think like an operator took months.

What does an LLM need in front of it to give me a channel plan I'd put money behind?

The answer I landed on is boring. Tables.

One thing up front. I haven't run the clean test, the same brief as a prompt and as a table chain, judged on the numbers. What follows is the mechanics and the reasons, and the mechanics are what I put money through.

Not tables as output, to make the thing look tidy. Tables as the way the model thinks: one stage at a time, with a place for every answer.

The brief to myself was one line: tables applied to GTM to keep the LLM focused on what matters.

This piece is the how. Enough of it that you can build the same chain for whatever GTM job you run.

Start with a well-written prompt. The company, the budget, a request for a Google Ads plan with sources cited and uncertainties flagged, and ten lines of preferences.

What comes back is a document. Headings, a few keywords, a budget split that looks reasonable, a confident tone all the way through.

It reads well. That's the problem. Reading well is what the model was trained for, and a plan that reads well is not the same thing as a plan that's right.

Three things go wrong, and they go wrong quietly.

The gaps are invisible. If the model doesn't know the account's conversion volume, it writes around it. You find out when the campaign runs.

Your ten lines get diluted. Some get honoured, some quietly don't, and nothing in the document tells you which.

And you can't check it. There's no row to mark PASS or FAIL. You read 800 words and nod.

Now the same job as a table chain.

Stage one is an intake table. One row per thing the plan depends on: budget, target CPA, conversion tracking, geography, languages, brand terms.

Two columns: what we have, and what breaks if this is wrong. Every unknown is written as MISSING.

Stage two is the keyword inventory. Thirty to 150 rows, one keyword each. Intent in one column, fit in another, then a verdict in words: Keep, Negate, Park.

Stage three is the master table. Every kept keyword gets a match type, an ad group, an ad and a bid. One row, one decision. A row with no ad group is a row the model has to explain.

Then a budget split. Then a negatives list. Then a self-check that walks every rule and writes PASS or FAIL next to it.

Same model. Same information. What changed is where a mistake can hide. A gap is a cell. A skipped rule is a cell. Padding has nowhere to go.

scroll the table sideways →

A table chain is still prompting. Four things change.

The questions are fixed in the columns. Evidence is required per cell. The verdict is forced into a closed set. And the job runs in sequence, one stage at a time.

A long prompt can ask for all of that. What it can't do is show you what was left out. A cell can, because an empty cell is a visible fact and a missing paragraph isn't.

And a table doesn't stop the model being wrong. It can fill every cell with plausible nonsense.

What it can't do is hide where it did it. That's the gain: mistakes you can find in twenty seconds, not on a second read.

The words in the cells matter too. PASS and FAIL. Keep and Negate. A fixed vocabulary stops the model inventing a fourth verdict that sounds like a compromise.

And the output of one table is the input to the next. The model never carries the whole job in its head. It carries one table.

That cuts both ways. A mistake in stage two walks into stage three with a straight face. It's why the source tags travel with the row: the next stage can re-check the fact, not just inherit the verdict.

Still, one table at a time is the part I'd underline. A lot of what goes wrong on long jobs is the model losing the plot partway through.

A chain of small tables has no partway. There's this table, and then the next one.

Analysis runs first, always. Four questions in ten stages. What the business does and why anyone pays for it. Who buys. Who else sells to them, and how. Which channels come first.

It ends in a master table that works for every business and that can be used to summarize every business.

Twenty-one fields, the same for a retail SaaS in Zurich and a food app in Jakarta. Two companies sit side by side. A third joins as a column.

Channels get ranked last. A ranking built on fit is an opinion. Competitor evidence turns it into a bet: how many SDRs they hire, what's in their ad library, what they rank for.

Three or more SDRs at a competitor and outbound is worth a bet in that category. It says the category funds outbound, not that outbound pays back there. It's the cheapest signal I know, and it's a starting bet, not a verdict.

Every channel stays on the table for every business. One exception: no cold email to consumers.

Outbound starts from one line: the core criteria has to be RELEVANCE.

One ICP is one industry plus one title. Title is a cheap proxy for the seat on the buying committee, and the seat is what the email is written for.

A VP Sales and a CRO can share a row. A VP Sales and a Head of IT can't, and an email written for both lands with neither.

Apollo, Lusha and Hunter are simply LinkedIn big scrapers, but the data is there (who does what), paired with email guessing. So you segment on the titles, and you only send to the emails that verified.

Subject lines start from a number and a name the reader knows. That's the default I test against, not a law. Authority is numbers and names.

And a how-it-works in three or four steps beats any adjective. A mechanism reads as true; a claim reads as marketing.

SEO reads intent from the live results page, logged out and in the target country, never from the keyword.

Google Ads keeps campaigns for budget, bidding, geo and language, never as folders for themes. Ad groups do the relevance work.

Meta runs a small set of campaigns with one job each. Four today. The count follows the platform; the one-job rule doesn't. Table 2 has the rest.

scroll the table sideways →

Above every table, four rules.

Say what a row is. Fill every cell, or write MISSING. Tag every fact with where it came from. Give verdicts in words.

A fact with no tag is an assumption. Prose is two lines between tables, never a paragraph that restates one.

Gaps show up as MISSING instead of hiding inside confident paragraphs. That's most of the trick.

The rest is one row at the end of every stage: open questions. A table only finds what it asks for, and the thing that isn't a column needs somewhere to land.

Chart 1. The chain: the analysis file feeds four channel files, and every stage ends in a table

The mechanics above are enough to run on. The research explains the problem they answer. It doesn't prove the answer, and I'll keep the claims to what was measured.

Models don't read long inputs evenly. Put the answer in the middle of twenty documents and accuracy drops; with enough documents GPT-3.5 did worse than with none at all.^[1]

Chroma tested 18 current models in 2025 and every one got worse as input grew, even on trivial tasks. Shuffling the text so it lost its flow made retrieval better.^[2]

The narrow lesson is the useful one. Isolate the next question, keep the format stable, and don't put the whole job in one window. A table chain does those three things. It doesn't follow that prose is the wrong format for everything.

They're touchy about format. Change spacing and separators, same meaning, and accuracy swung by up to 76 points in one study and 40% in another.^[3][4]

Fixing the format removes one source of noise. It doesn't pick the best format for you: the same study found the format that works best differs by model, so swapping the model means re-checking the tables, not just plugging it in.

Instructions get dropped as they pile up. Given 500 constraints, the best model in mid-2025 kept 68% and favoured the early ones.^[5] Twelve rules in a brief is a smaller problem, and newer models do better.

The QA table is there for a different reason. A rule with its own row and its own verdict gets checked. A rule buried in a prompt gets averaged in with everything else.

And errors compound. Get each step right 90% of the time and a ten-step job fails two times in three.^[6] Small tables, a verdict at the end of each, nothing unverified carried forward. Chart 2 is why.

The same paper shows reasoning models stretching that horizon on their own. One stage per table is a 2025 answer to a 2025 problem, and section 06 says which rows I expect to drop as models improve.

scroll the table sideways →

Chart 2. How many steps a model gets through before it fails, as a function of single-step accuracy

Humans found the same thing years ago. A 19-item surgical checklist cut deaths from 1.5% to 0.8% across eight hospitals.^[7] Structured interviews predict job performance about twice as well as unstructured ones.^[8]

Same move each time. Fix the question, force the answer.

Put the five files next to each other and the same eight moves show up in every one.

Nothing new in the eight. Any careful channel runs them. The point is making the model run them in that order and stop at each one.

Route the request. Take the brief. Check the data against reality. Build the inventory. Score it and say the verdict in words. Build the deliverable. Run the QA table. Review weekly against thresholds.

The columns change with the channel. The chain doesn't.

scroll the table sideways →

The thresholds are operating points, not discoveries. The market data says they sit in a sane range.

Instantly's 2026 report has the average cold email reply rate at 3.43%.^[9] Belkins, counting replies against total sends to strangers, gets 0.45%.^[11] Two thermometers, not one trend.

Small lists beat big ones. 5.8% reply under 50 recipients, 2.1% above 500.^[12]

Top senders keep bounces under 2%. The average is above 5%. Google's complaint ceiling is 0.3%.^[10][12][13]

The weekly review acts at 2% bounce, 1.5% replies and 1% positives, after 300 delivered. Each threshold names the first thing to change, not the only cause. A bad list shows up in all three.

Two rows I'd add: a complaint threshold, and a shorter sequence, since four or more emails triple the complaints.^[14]

scroll the table sideways →

Three layers. The tools, the model, the files.

The tools are plumbing. Apollo, Instantly, Ahrefs, Search Console, the ad platforms, connected wherever there's an API.

The model is rented by the token. A better one arrives every few months, and it swaps in without touching a table.

The files are where the value is. But not all of the files, and it took me a while to see the split.

Some rows exist to cover for the model. One table per stage, so nothing gets lost in the middle. A QA table, because the model drops constraints. Verdict words, because it invents compromises.

Every release needs fewer of those rows.

Some stay anyway, because I need them. To compare two plans on the same rows. To approve a plan in a minute. To see later why a decision was made.

Other rows carry judgment. Not the rules themselves; most of those you can read in any decent playbook, and a good model has read the playbooks.

The judgment is which evidence counts for this business. Where the thresholds sit. When a rule has stopped working, which only the weekly review can tell you.

So the asset isn't the tables, and it isn't the rules either. It's the loop: rules, numbers, revised rules. The files are where the loop lives today, and the format will change before the loop does.

The format does help, for now. A skill costs about 100 tokens until it's needed, then a file under 5,000, then references only when a stage asks for them.^[15] Karpathy called the job "filling the context window with just the right information for the next step".^[16]

Outbound is where the loop matters most. AI SDRs send more emails from the same prompt. Nothing in the prompt reads the reply column and changes the next one.

scroll the table sideways →

Four objections worth taking seriously.

Sutton's Bitter Lesson. In AI, methods that lean on computation keep beating methods that encode human knowledge.^[17] Half of these files is human knowledge. The other half exists to cover for the model's weaknesses.

If the next model reads a company page and ranks twenty channels on its own, those rows go, and they should. The judgment rows stay until the market changes.

Forcing a strict output format can make a model reason worse. Tam and colleagues measured it: the tighter the format, the worse the reasoning, and strict JSON was the worst case.^[18]

So the files separate the two steps. The model explains its reasoning in prose first, then it fills the verdict cell. The format constrains the answer, not the thinking behind it.

A table that isn't used changes nothing. When Ontario made the surgical checklist mandatory in 101 hospitals, mortality didn't move. Follow-up work found the checklist was mostly not being run in the operating room.^[19][20]

The same applies here. The chain only works if every job goes through it, with no shortcut around it.

The verdict column can be wrong. A QA table only finds the gaps it was told to look for.

Someone with the sources in front of them has to check the rest. The tags on each row are there so that takes minutes, not an afternoon.

• A table is a prompt with the questions fixed, the evidence required and the verdict forced. Write that.
• Check the verdicts. A table makes mistakes visible; it doesn't make them go away.
• Four rules over every table: say what a row is, fill every cell or write MISSING, tag every fact, give verdicts in words.
• Same skeleton for every channel: route, brief, reality check, inventory, verdict, build, QA, weekly review.
• Analysis before channels. Competitors before ranking. Every channel stays on the table except cold email to consumers.
• Outbound is relevance. One buying-committee seat per row, with industry and title as the proxy; a number and a name in the subject; a how-it-works in three or four steps; verified emails only.
• Every stage ends in an open-questions row. The thing that isn't a column needs somewhere to land.
• The model is rented. The asset is the loop: rules, numbers, revised rules. Rows that cover for the model go when it stops needing them. Rows for the reader and judgment rows stay.

Some rows are there for the model, and they'll go. Some are there for me, so I can read and approve the work. The rest carry a rule and the number that tests it. Those are the ones worth writing down.