AI agents that write your knowledge base: Einstein Knowledge Creation and the closed loop with Agentforce

Every serious Agentforce deployment eventually hits the same ceiling, and it’s not the model. You ground the service agent on your knowledge base, it answers well on the questions the knowledge base covers, and then a customer asks something nobody wrote an article about, and the agent, at best, escalates, and at worst improvises. The reflex is to blame the agent. The real problem is upstream: your knowledge base is a static asset that a human team maintains in their spare time, which is to say barely, while the questions customers ask move faster than anyone documents. An agent grounded on a stale, thin knowledge base is a stale, thin agent.

The fix isn’t a better retriever. It’s closing the loop, capturing the knowledge that resolved this conversation so it grounds the agent on the next one. Salesforce’s tool for the capture half is Einstein Knowledge Creation: generative AI that drafts a Knowledge article from a resolved interaction, which a human reviews before it ever publishes. It’s deliberately unglamorous, and it’s the difference between a knowledge base that decays and one that compounds. This post is what it does, how it wires into the Agentforce grounding loop, and, the part that matters most, the governance that stops an AI-drafted mistake from becoming the thing your agent confidently tells the next thousand customers.

Produce versus consume: name the feature correctly first

The single biggest source of confusion here is that Salesforce ships half a dozen “Einstein” knowledge features and teams blur them together. They split cleanly along one line, produce versus consume, and your whole architecture depends on knowing which is which.

Consume (retrieve and answer from existing articles):

Agentforce Data Library / Ground with Knowledge: the RAG path: articles chunked, embedded, indexed into a Data 360 retriever, read by the agent at reasoning time.
Einstein Search Answers, extracts an answer from Knowledge to deflect a question.
Einstein Article Recommendations, surfaces relevant existing articles to a human rep on a case.
Einstein Service Replies, drafts a suggested reply to the customer, optionally grounded on a knowledge library.

Produce (create and maintain the articles themselves):

Einstein Knowledge Creation, drafts a new article from a resolved conversation.
Revise Knowledge Articles with Einstein: a distinct, later capability where a rep highlights article text and asks Einstein to fix grammar and readability.

Almost every post and demo you’ll find is about the consume side, because grounding is the exciting part. But grounding is only as good as what there is to ground on, and the produce side is what keeps that pool from going stale. This post is about produce feeding consume, the loop most teams leave open.

Grounding your agent on the knowledge base is table stakes. Feeding the knowledge base from resolved conversations is the part almost nobody operationalizes, and it’s why their agent’s coverage flatlines three months after launch. The retriever isn’t the bottleneck. The empty article is.

What Einstein Knowledge Creation does

Strip it to the mechanic. When a service rep resolves an interaction, Einstein reads the conversation transcript and drafts a Knowledge article capturing the problem and the resolution. The rep reviews and edits that draft, and only then does it get saved as a draft article headed into your normal publishing process. Setup surfaces this as a wrap-up component on the messaging session record page and a quick action, the capture happens in the flow of closing the work, not as a separate documentation chore nobody has time for. It’s the Knowledge-Centered Service (KCS) principle made mechanical: knowledge as a by-product of solving cases, rather than a project you never staff.

Two design details make it more than a novelty.

First, it’s not a single blob of text. It maps to your article schema. Einstein tailors its output to the response types you configure and an admin maps those to specific Knowledge fields and record types. The documented example is the useful one: from the same resolved conversation, you can generate a customer-facing article (issue, process steps, resolution) and an internal troubleshooting record: a different record type with fields like issue, environment, problem, resolution, root cause, and troubleshooting steps. One conversation, two audiences, correctly structured. That field-mapping step is also the most technical part of the setup, and it presupposes you already have a clean, well-structured Knowledge schema. If your article types are a mess, the AI’s output inherits the mess.

Second, and this is the load-bearing fact for anyone worried about AI in front of customers, it drafts, it does not publish. Salesforce’s own documentation is explicit that the article is finalized only after the service rep fact-checks and reviews the Einstein draft. There is no auto-publish path. That single design choice is what makes the whole thing safe to turn on, and it’s the answer to the objection everyone raises first.

Setup: the prerequisite chain

This is not a toggle, and pretending otherwise is how implementations stall. The chain, in order:

Lightning Knowledge, properly structured. Enabling Lightning Knowledge changes your data model so record types replace legacy article types. You need record types, page layouts, data categories, and Knowledge user access configured first. The quality of this schema determines the quality of every AI draft downstream.
Einstein Generative AI turned on. In Setup’s Einstein configuration. These generative features run on the Einstein Trust Layer, which itself requires Data 360 (formerly Data Cloud) to be provisioned, a platform dependency worth knowing before you promise a go-live date.
Turn on Einstein Knowledge Creation, and map the response types to your article record types and fields. This mapping is the real work.
Grant reps access through a permission set, and add the wrap-up component to the relevant record page.

On licensing and editions, correct a common bit of stale advice: Knowledge Creation requires the Einstein for Service add-on (the consolidated license that merged the old Service Cloud Einstein and Einstein GPT for Service add-ons), and it’s available on Enterprise and Unlimited editions. It was Unlimited-only early on and later extended to Enterprise, so “you need Unlimited” is out of date, but “it’s a paid add-on gated to the higher editions” is very much true, and it’s a real cost consideration for smaller orgs.

The closed loop into Agentforce

Here’s where the two halves connect, and it’s the whole reason to bother. The lifecycle:

Resolve a conversation.
Draft: Einstein Knowledge Creation generates a Draft-status article from the transcript, mapped to the right record type.
Review and publish: a rep or SME fact-checks, edits, and runs it through your publishing and approval process; standard Lightning Knowledge gives you Draft → Published → Archived states, versioning, and approval processes to gate the publish.
Index, the published article flows into the Agentforce Data Library / Data 360 retriever that grounds your service agent.
Ground: the next customer’s question retrieves that article, and the agent answers from knowledge that didn’t exist yesterday.

That’s the loop: a question the agent couldn’t answer on Monday, resolved by a human, captured, reviewed, published, and grounding the agent by Wednesday. Run it consistently and your agent’s coverage climbs on its own instead of plateauing. This is the operational discipline behind the assistive-to-autonomous progression, the agent gets more autonomous because the humans keep feeding what they resolve back into its grounding.

One current-events note that belongs in your planning: if part of your knowledge lives in external systems, Unified Knowledge is being retired in Summer ‘27, replaced by Enterprise Knowledge powered by Data 360. We covered that transition and what replaces it separately; the point for this loop is that your grounding substrate is consolidating on Data 360, so build the capture-and-publish habit now on a foundation that’s moving the right direction.

The governance that keeps a bad draft from poisoning the agent

This is the part that separates a healthy loop from a self-inflicted wound, and it’s the section to read twice. The closed loop has a failure mode that’s the exact inverse of its value: a wrong AI-drafted article, once published, becomes grounding for the agent, so a single bad article doesn’t mislead one customer, it misleads every customer whose question retrieves it. Garbage in, at scale, out. The data-quality problem that decides every agent’s fate shows up here as knowledge quality, and it compounds because the agent treats a published article as truth.

Three disciplines keep the loop honest, and none of them is optional:

The human review is the control, not a formality. Because drafts never auto-publish, the reviewing rep is your accuracy gate. Treat it that way: an SME sign-off for anything customer-facing, and approval processes to gate publishing on the article types that carry the most risk. The temptation under volume is to rubber-stamp AI drafts; resist it, because rubber-stamping is how a hallucinated resolution enters the agent’s grounding wearing the authority of a published article.
Fight duplicate and stale sprawl deliberately. Auto-drafting from every resolved case can flood the base with near-duplicate articles, and duplicates are poison for retrieval, the agent can’t tell which of three overlapping articles is authoritative. Use data categories, archive aggressively, lean on versioning to supersede rather than accumulate, and put someone on a recurring de-duplication pass. A knowledge base that grows without curation gets worse at grounding, not better.
Tag AI-originated articles so you can measure them. There’s no built-in “this was AI-drafted” flag, so add your own field. Then you can answer the question that justifies the whole program: are AI-created articles improving deflection? Pair Case Deflection dashboards, Knowledge custom report types, and the Service Intelligence Knowledge dashboard, filtered to your AI-tagged articles, and watch confirmed deflections and most/least-helpful rankings. If your AI articles cluster in “least helpful,” your review gate is too loose. Fix the gate, don’t blame the feature. The same measurement discipline you’d apply to testing the agent applies to the knowledge feeding it.

What to do

If you’re running an Agentforce service agent and its coverage has plateaued, the missing piece is almost certainly the produce side of the loop. Confirm you have the Einstein for Service add-on on Enterprise or Unlimited, get your Lightning Knowledge schema clean first because every draft inherits its structure, then turn on Einstein Knowledge Creation and invest the real effort in mapping response types to your article record types. Wire the publish step into the Data Library that grounds your agent so a newly published article reaches the retriever. Make the human review a genuine SME gate, not a rubber stamp, because a published article is agent grounding and a bad one scales. Tag AI-originated articles and measure their deflection so the program earns its keep. And put someone on curation, because an uncurated base of AI drafts degrades retrieval instead of improving it.

Do that, and you turn every resolved hard conversation into grounding for the next one, which is the only way an agent’s coverage grows without a documentation team you don’t have. The retriever was never the bottleneck. The empty article was, and this is how you stop writing them by hand.

Understanding the basics

What is Einstein Knowledge Creation?

Einstein Knowledge Creation is a Salesforce Service Cloud feature that uses generative AI to draft a Knowledge article from a resolved customer conversation. A service rep reviews and edits the draft, which then enters the normal publishing process. It never auto-publishes. It can tailor output to multiple response types mapped to different article record types and fields, so one conversation can produce both a customer-facing article and an internal troubleshooting record. It went generally available in Spring ‘24 and requires the Einstein for Service add-on on Enterprise or Unlimited editions, with Lightning Knowledge and Einstein generative AI enabled.

How does it improve an Agentforce agent?

It closes the knowledge loop. An Agentforce service agent grounds on your knowledge base, so its answer quality is capped by what the base covers. Einstein Knowledge Creation captures the resolution of conversations the agent couldn’t answer, a human reviews and publishes them, and the published articles flow into the Agentforce Data Library / Data 360 retriever that grounds the agent, so its coverage grows from real resolved cases instead of plateauing. Produce (Knowledge Creation) feeds consume (grounding); most teams operationalize only the consume half.

Does Einstein Knowledge Creation auto-publish articles?

No, and that’s the key safety design. Salesforce’s documentation is explicit that the article is finalized only after a service rep fact-checks and reviews the Einstein draft. It creates a Draft-status article that goes through your standard Lightning Knowledge publishing and approval process. Because a published article becomes grounding for your agent, that human review is your accuracy control. Treat it as a real SME gate, since a wrong article, once published, can mislead every customer whose question retrieves it.

How is this different from grounding an agent on knowledge?

They’re opposite halves of the same loop. Grounding (via the Agentforce Data Library, Search Answers, or Article Recommendations) consumes existing articles, retrieving and answering from them. Einstein Knowledge Creation produces new articles from resolved conversations. Grounding makes the agent answer well from what exists; Knowledge Creation is how “what exists” keeps growing. A service operation that only grounds will watch its agent’s coverage flatten; one that also produces closes the loop and compounds.

Grounding an Agentforce agent but watching its coverage plateau, and want the capture-review-publish loop built so your knowledge base feeds the agent instead of decaying? Talk to us. Closing the knowledge loop, with the governance that keeps a bad draft out of the agent, is exactly the work we do.