The AI GTM Agent Runs on a Knowledge Base
By the time a B2B buyer talks to you, the decision is mostly made. Forrester's Buyers' Journey Survey found 94% of business buyers now use AI in their buying process, up from 89% a year earlier, and twice as many name generative AI or conversational search as their most meaningful information source than name any other — ahead of vendor websites, product experts and sales. Gartner puts the share of buyers who would prefer a rep-free experience at 67%, up from 61%, and the share of the purchase journey actually spent meeting suppliers at 17%. 6sense's buyer research adds the punchline: the vendor a buyer contacts first wins roughly 80% of the time, and 95% of the time the eventual winner was already on the day-one shortlist.
So the interesting question is no longer how to sell better during the 17%. It is what your AI GTM agent already knows at the moment a mostly-decided buyer shows up. Dr. Sajjan Kanukolanu, VP of Global Operations and Strategy at Position², put an architecture behind that question at AI Engineer in July 2026, drawn from running 75+ agents against 18+ vertical knowledge bases at around 800 runs a month. The part worth stealing is not the agent chain. It is which layer he puts at the centre.
TL;DR — An AI GTM agent is three layers: signals in, buyer intelligence in the middle, action out. Most teams buy vendors for the first and third and skip the middle — and the middle is a knowledge base: ICP definitions, personas, playbooks, disqualifiers, win/loss patterns, written down where every agent reads them. Skip it and you get a chat window that asks "How can I help you?" to a buyer who already read your pricing page twice. MDflow is a markdown workspace where that knowledge base can live — edited in a browser by the revenue team, read by every agent over MCP and an HTTP API, and versioned so you can see exactly when the ICP changed.
What is an AI GTM agent?
An AI GTM agent is a chain that runs on a buyer signal rather than a chat prompt. A visit, a job change, a LinkedIn engagement kicks it off; the chain identifies the visitor, enriches the record, qualifies it against your ideal customer profile, checks it against the CRM, and decides the next action — a Slack alert with a drafted email, an outbound sequence, an ad, or nothing at all. The chat window on your website is one surface of that system, not the system.
Kanukolanu's framing of why most attempts stall is worth quoting directly, because it names three problems and insists they are one problem:
- AI alone does not know your buyer. Bolted onto an existing stack, it has no idea who this person is, what their role means, or what they were doing here last month.
- The old stack cannot carry the signals. CRM context, intent data and what the AI itself observes do not meet anywhere.
- The architecture has to change. Solving one and two without three still leaves you unable to scale.
You can feel which of the three a company solved by reading its chat greeting. "How can I help you today?" is not a friendly opener. It is a system telling a buyer who has already read your docs, compared you against two competitors and half-built an internal business case that it knows none of that.
The three layers
Signals, buyer intelligence, action — and the middle one is where the thinking lives.
| Layer | What it holds | What it is bought as |
|---|---|---|
| Signals | CRM records and deal context, visitor identification, third-party enrichment, social and job-change signals | Vendors |
| Buyer intelligence | The knowledge base, identity records, ICP scoring, the context builder, routing logic | Usually nothing |
| Action | Rep alerts, email drafts, sequence triggers, ad targeting, CRM writeback | Vendors |
Kanukolanu is explicit that the middle layer starts with a knowledge base — "a repository of context that you have about your product, your buyers, the ICPs, the personas, the different titles, different playbooks, different criteria of success." In the implemented version, an ICP filter agent reads that knowledge base and discards contacts that fail on industry, geography, company size or persona before anything downstream sees them. A match agent then checks survivors against the CRM. An action agent decides what happens per person, or per buying committee for a whole account.
Note what that means operationally: the knowledge base is not documentation about the system, it is a runtime dependency of the system. Change the ICP document and the filter behaves differently on the next run. That is a very different artifact from a slide deck that describes your target market.
Signals then compose into a context graph — a connected record per buyer that links persona to account to deal, so the buying committee at an account emerges from the individual signals rather than being maintained by hand. Its job is prioritisation. Without it you have a list of interested-looking people and no principled way to rank them.
Why the knowledge base is the layer that decides
Because every judgment in the chain is a judgment about your business, and none of it is in the model's weights. Whether a 200-person logistics company in Poland fits your ICP, whether a director of platform engineering is a buyer or an influencer, whether "evaluating a competitor" is a strong signal or a waste of a rep's afternoon — a frontier model has no opinion worth having on any of it. Give it nothing and it will produce the statistically plausible answer, which is roughly the average of every B2B SaaS company on the public web.
For GTM teams
A written knowledge base is the difference between a system you can fix and a system you have to file a ticket against. Kanukolanu's third takeaway is a policy engine that is "auditable and adjustable" — where a GTM leader can find the part that is wrong and correct it, rather than queueing behind a developer. That is only true if the rules live in documents, not in prompt strings inside application code.
It is also where institutional memory goes. The disqualifier you learned from a deal that died in procurement, the persona that turned out to be an influencer and not a buyer, the vertical you stopped chasing — these are the highest-value facts your company owns and they are usually stored in three people's heads and a Slack thread.
For AI agents
An agent reading a shared knowledge base gets a stable referent. When the ICP filter and the action agent both evaluate "enterprise fit," they resolve the same written definition instead of two similar-sounding prompt fragments that drifted apart in separate pull requests. In a chain of five agents, that is the difference between a consistent qualification standard and five slightly different ones.
It also gives the loop somewhere to write. Kanukolanu's fourth takeaway is the flywheel: every send, every reply, every closed deal should make the system smarter, which means wins, losses and deferrals have to land back in the knowledge base rather than in a dashboard. That only works if the store the agents read is also a store they can safely write to — with attribution, and with a diff a human can review.
What actually breaks
Four failure modes, each of which shows up months after launch.
1. ICP drift. Your real ideal customer moves and the written one does not. You close a larger deal in an adjacent vertical, and the agents keep scoring against last year's criteria — weeding out precisely the accounts you now want. Nothing errors. The agent confidently returns the wrong accounts, and it will keep doing that until someone rewrites the document. The recommended cadence is a quarterly pass over closed-won and closed-lost.
2. Alert fatigue. If everything is hot, reps stop looking, and once they stop looking the system is dead regardless of how good it is. The knowledge base and the context graph exist to make the not-alerting decision defensible.
3. The identity ceiling. This is a structural limit, not a vendor selection problem. Kanukolanu's operating numbers are around 70% accuracy at company level and 15–20% at person level, and independent 2026 benchmarks land in the same territory — company-level match rates of roughly 30–65% of US B2B traffic and person-level of roughly 5–20%, against vendor claims that routinely start at 80%. Under GDPR, person-level identification without affirmative opt-in is effectively zero for EU traffic. Design the motion around account-level signals; treat a named person as a bonus.
4. The human bottleneck. If the approval queue feels like a chore it becomes a backlog and then a graveyard. Kanukolanu's threshold is blunt and useful: if editing an AI-drafted email takes longer than about 30 seconds, the rep will write their own and the initiative is over. The draft has to be nearly right, which is a knowledge base problem before it is a model problem.
Which teams benefit most
- B2B companies with long, committee-driven sales cycles — where the buying group is real, the research happens off your property, and 17% of the journey is all you get.
- Agencies and services firms running GTM for multiple clients — where the same architecture is instantiated per client and only the knowledge base changes. Position²'s 18+ vertical knowledge bases are exactly this shape.
- Product-led companies with high anonymous traffic — where company-level identification plus a good ICP document turns raw sessions into a ranked account list.
- Sales teams running AI SDR or research agents — which are only as good as the battlecards, disqualifiers and objection handling they can read at run time.
- Marketing teams doing account-based programmes — where routing logic needs a written, arguable definition of fit and stage rather than a score nobody can explain.
- Anyone whose ICP is genuinely moving — a company mid-pivot or moving upmarket, where the drift problem is not hypothetical but this quarter's reality.
How MDflow fits
MDflow is not a CRM, an enrichment vendor or an identity-resolution provider, and it does not store a context graph. Clearbit-style enrichment, visitor de-anonymisation, intent data and CRM records belong in the tools built for them. What MDflow holds is the layer in the middle that usually has no owner: the written knowledge base the agents read.
What already lines up today
Markdown documents both a revenue leader and an agent can read. The ICP, persona definitions, playbooks, disqualifiers and win/loss patterns are prose with structure — exactly what markdown is for. A VP of marketing edits them in a browser; an agent fetches the same bytes. There is no export step and no second copy to drift.
Agents read the workspace over MCP or an HTTP API. The remote MCP server connects Claude, ChatGPT, Cursor and Codex with OAuth or a Personal Access Token, and the HTTP API covers the same object model for cron jobs, orchestration DAGs and CI. mdflow_get_context takes a topic and returns the most relevant documents — so an ICP filter agent asks for "enterprise fit criteria for the logistics vertical" rather than hard-coding a document ID that someone will rename.
Folder descriptions are a deliberate retrieval signal. Every folder carries a description, and mdflow_get_context ranks those descriptions above folder names and document titles. A folder described as "Qualification criteria — one document per vertical, with the disqualifiers and the reasoning behind each" steers retrieval on purpose, which is why folder descriptions beat file names.
Version history is the answer to ICP drift. Every saved change captures the previous version on every write path — editor, API and MCP — with line-by-line diffs and a non-destructive restore. When the qualification rate falls off a cliff, you can see when the definition changed and what it said before. It is a Pro feature, private to the document owner, and deliberately not exposed over the API or MCP, so an agent cannot quietly rewrite the record of its own edits.
The Document Log answers "which run wrote this?" A cross-document activity feed records created, edited, shared and deleted events with the actor on every row — you for browser actions, automated · <token name> for anything arriving over the API or MCP. Give the enrichment pass, the win/loss extractor and the n8n workflow separate tokens and the flywheel becomes auditable instead of mysterious.
A workspace per client or vertical. Workspaces separate unrelated work, each with its own folder tree, which is the natural shape for an agency running many vertical knowledge bases side by side. Team accounts put the same content behind shared membership and per-workspace permissions, with a Team MCP server and an audit feed — the ordinary case of a team knowledge base agents can read.
The action layer already has a node. The n8n integration exposes 22 operations plus a polling trigger, so the routing and writeback steps — draft into a document, publish a share link, react when a new document appears — are canvas work rather than glue code.
Research goes in the way you found it. The Web Clipper captures competitor pages, analyst notes and buyer research straight into a folder as clean markdown, with optional AI-assisted extraction using your own provider key. Battlecards assembled from what you clipped stay in the same store the agents read.
Review items are just checkboxes. /tasks aggregates ordinary - [ ] lines from every document body, so "decide whether mid-market logistics is in the ICP" — written by a quarterly extraction pass — becomes something a person filters, owns and ticks off, with the document remaining the source of truth.
Where we are headed
Direction, not a dated commitment. Two things about this use case interest us. The first is richer structured retrieval over folder descriptions, so an agent asking "what disqualifies an account?" reliably lands on the one canonical document rather than the three most lexically similar ones. The second is narrower agent credentials: a Personal Access Token today reads and writes everything its owner owns, which is enough for attribution but is not least privilege — and a nightly win/loss extraction pass is exactly the case that wants a token scoped to one folder. Neither turns MDflow into a CRM, and that is deliberate.
The bottom line
The buyer arrives late, decided, and having done their research somewhere you cannot see. The three-layer architecture is a reasonable answer to that, but the layer that decides whether it works is the one nobody buys: a knowledge base of ICP definitions, personas, playbooks and disqualifiers, current enough to be trusted and readable by every agent in the chain.
Treat it as a runtime dependency, not documentation. Put it where the revenue team can fix it the day they learn something, keep a history so you can see when the definition moved, and let the agents write back under their own names so the flywheel is reviewable. The models will keep getting better at reasoning. They will never get better at knowing what your company decided last quarter.
Start free · Connect an AI agent · Read the API docs
Frequently asked questions
What is an AI GTM agent?
An AI GTM agent is a chain of automated steps that runs on a buyer signal rather than a chat prompt: identify the visitor, enrich the record, qualify it against your ideal customer profile, check it against the CRM, then decide the next action — an alert, an email draft, an ad, or nothing. The chat window on your site is one surface of it, not the system itself. What makes it an agent rather than a workflow is that each step reasons over context instead of following fixed rules.
Why do AI GTM agents need a knowledge base?
Because every judgment the agent makes is a judgment about your business, and none of it is in the model's weights. Whether a 200-person logistics company in Poland is in your ideal customer profile, whether a director of platform engineering is a buyer or an influencer, what disqualifies an account outright — these are facts about your company that only exist in your organization. Without a written knowledge base the agent falls back to generic plausibility, which is what produces a chat window that opens with "How can I help you?"
What is ICP drift?
ICP drift is what happens when your real ideal customer profile moves and the written one does not. You close a larger deal in an adjacent vertical, sales quietly starts prioritising a new segment, and the agents keep scoring against last year's criteria — weeding out exactly the accounts you now want. It is the most common silent failure in an agentic GTM stack because nothing errors; the agent keeps confidently returning the wrong accounts. The fix is a review cadence, usually quarterly against closed-won and closed-lost, and a knowledge base with version history so you can see when a definition changed and what it said before.
How accurate is anonymous website visitor identification?
Company-level identification is usable and person-level identification mostly is not. Independent 2026 benchmarks put company-level match rates at roughly 30–65% of US B2B traffic and person-level at roughly 5–20%, well below typical vendor marketing. Under GDPR, person-level identification without affirmative opt-in is effectively zero for EU traffic. Plan the GTM motion around company-level signals and treat named-person identification as a bonus, not a foundation.
Should the GTM team or engineering own the agent knowledge base?
The GTM team, with engineering owning the pipeline that reads it. The whole point of separating the knowledge base from the agent code is that the people who learn something new from a lost deal can correct the system the same day without filing a ticket. That only works if the knowledge base is plain documents in a tool a revenue leader will actually open, and if the agents read those documents at run time rather than embedding the rules in prompts nobody can find.
Further reading
- Build the AI GTM Agent That Knows the Buyer — Dr. Sajjan Kanukolanu, Position², at AI Engineer, July 2026
- B2B Buyers Make Zero-Click Buying Number One — Forrester on the Buyers' Journey Survey: 94% AI usage, and generative AI as the most meaningful source
- Gartner Sales Survey Finds 67% of B2B Buyers Prefer a Rep-Free Experience — March 2026
- The B2B Buyer Experience Report — 6sense on day-one shortlists and the first-contact advantage
- Website Visitor Identification Match Rates — independent 2026 benchmarks on the identity ceiling
- From systems of record to systems of context — the same shift, seen from inside the work-management stack
- Your moat is your data model — why the proprietary layer is the one you write down
- Context engineering for AI agents — what to put in front of the model, and why
- MDflow MCP documentation and HTTP API documentation