This article is auto-synced from its in-app version in Tai.

Coming soon. This feature isn't available to your company yet.

Knowledge items give agents grounded, up-to-date content to draw on — help articles, procedures, FAQs, and other documents.

Knowledge will let an agent answer questions from your company's own content rather than relying on general training alone — for example, your cancellation policy so the Customer Care agent can cite it accurately, or a product FAQ so agents give consistent answers about your offering.

When Knowledge is available, here's how it will work:

A body of knowledge is rarely one file. When you choose FILE, the picker takes as many documents as you select, and each one becomes its own knowledge item — so a ten-document handbook is one trip through the form, not ten.

If a file is too large or of an unsupported type, its row says so and it's left out — the rest still go through. If an upload fails, that row keeps the reason and the button becomes Retry, which picks up only what didn't land; the documents that already succeeded aren't created twice.

Writing a good description is fiddly, especially for a document or a site you haven't read end to end. A Generate button under the Description field will summarise the source's own content into a short draft.

The draft lands in the field for you to review and edit, with an Undo next to it if you'd rather keep what you had. Nothing is saved until you save the item. If a draft had to be cut mid-sentence to fit the length limit, it ends in an ellipsis (…) so you can see where it was cut.

For a WEBSITE item, click Test connection under the crawl settings. It fetches only the start page and reports back in a couple of seconds:

It also flags the two problems that are easiest to miss: a sign-in page, which returns a normal response but has nothing worth indexing — the crawler refuses to index a sign-in screen rather than filling your index with it (see below for what happens then); and a start URL that redirects out of scope — to a different address, or to one your exclude patterns drop — which leaves the crawl with nothing to read.

The test reads only the start page, so treat it as a strong signal rather than a guarantee: a site whose home page is mostly images can still crawl well from its other pages. Nothing is saved by testing, and a warning doesn't stop you saving — it's there so you can fix the address before the first crawl runs.

A crawl stops when it has read the whole site — or when it reaches one of its limits, whichever comes first. If a limit came first, the item shows a Partial index badge next to its embedding status, and the sync-history chart highlights the runs it happened on. This is a different fact from a Many sign-in screens badge (see below): Partial index means the crawl stopped early on a limit, while Many sign-in screens means a large share of what it did reach was refused as sign-in screens. The two are independent, and a source can carry both at once.

The badge tells you which limit was reached and what to do about it:

This matters because the page count on its own can't tell you the difference. Without the badge, a source that indexed the first 200 pages of a 5,000-page site looks exactly like one that indexed a 200-page site in full — and agents would answer from the smaller picture without anything saying so.

The badge covers limits the crawl ran into. Pages it skipped one at a time are reported separately — see below.

Under Index size, a website source reports what its last crawl kept and what it left out — for example "120 pages · 500 chunks · 44 skipped" — with a breakdown of the reasons underneath.

Skipping is normal. A crawl of a real site constantly passes over PDFs and images, dead links, and pages that turn out to have no readable text; a source that skipped nothing simply says nothing. The number is there for the times it isn't normal — a large count next to blocked by robots.txt, could not be fetched, or a sign-in screen usually means something changed on the site rather than in the crawler.

The reasons you may see:

The count is of pages the crawl actually reached. If the run also stopped at a limit — the Partial index badge — then pages beyond that limit were never reached at all, and aren't counted here.

The crawler never indexes a sign-in screen — an index whose content is "Sign in to continue" is worse than a smaller one. What happens next depends on the rest of the site:

Usually the start page is what gives it away: one that is itself a sign-in screen settles it for the whole site. Where the start page can't be read — it errors, isn't a web page, redirects to a sign-in service on another address, or has no readable text — the crawler judges the site by the pages it could read instead: if as many of them are unmistakably sign-in screens as are real content, the site is treated as gated and the sync fails the same way.

Where the start page redirects, the crawler reads the page it lands on too. A sign-in screen there weighs on the sign-in side of that balance — the site chose to send you to it, so it says something about getting in — and where nothing else could be indexed at all, the sync fails as a sign-in screen rather than as a redirect out of scope, which is the more useful of the two answers. An ordinary page there weighs on neither side: a bare domain that redirects to its www address or to a regional home page says nothing about whether the rest of the site is open.

A start page that opens fine doesn't exempt the rest of the site, but it isn't ignored either: it counts twice toward real content, so it takes that many more sign-in screens to tip the balance. So a public home page above a members area keeps its public pages and leaves the members area out of the index, while a single "How to log in" support article on an otherwise open site is still indexed as the content it is — as is an ordinary page that merely carries the sign-in form your site's template puts on every page.

A site that moved behind a sign-in wall between crawls is the usual cause. It's also worth checking that the page really is a sign-in screen — a page titled something like "Log in to your account", sitting next to a sign-in form, can occasionally be read as one. If that's what happened, point the source at a different page.

Content sources are re-checked periodically. If a check fails, the person who set the source up receives an email with the reason and a link to the item — for example the site could not be reached, its robots.txt now blocks crawling, or it sits entirely behind a sign-in screen.

A failed check doesn't take the source away from your agents. They keep answering from the last version that indexed successfully, and the item shows a Stale badge instead of its usual status — so what they know simply stops moving forward until an update succeeds. Re-checks keep running in the background, and a source that starts working again picks itself back up without you doing anything. If the reason needs a fix at your end — a new address, a crawlable URL — make it and re-sync.

Some sources have no earlier version to fall back on, so agents cannot use them at all until an index succeeds. These show Failed rather than Stale:

You'll get one message per failure, not one per retry, and no further messages once the source updates successfully again.