How many seats do we have left is a question about live data, and an agent trained on your wiki will answer it from a document somebody wrote in March. The answer will be confident, specific and wrong, which is the worst combination available for a number that drives spending decisions.
TL;DR
- Licence and seat questions need live data. A document-trained agent has none and will answer from whatever stale figure it finds.
- Never put a seat count in a wiki page. It is wrong within a week and somebody will plan around it.
- Separate the four questions hiding here: do we own it, how many, how many are in use, and can I have one.
- Three of those four are answerable from documents or policy. Only the in-use count needs a connection to something live.
- The honest configuration is a decline that names where the real number lives, which is more useful than a plausible guess.
- Reconciling owned against assigned seats quarterly usually finds more savings than any answering tool will.
Why the wiki answer is always wrong
Somebody documents the licence position once, usually while setting up a new tool, and the page records that the company has 50 seats with 38 assigned. That page is accurate for about a week.
Then eleven people join, four leave, the plan gets uplifted at renewal, and nobody edits the page because nobody has ever thought of a seat count as a document. An agent reading that page answers with a figure that is out by a wide margin and cites a real source, which makes it harder rather than easier to doubt.
The failure is not retrieval. The content was correct when written and became wrong without changing, which is the one kind of staleness no ingestion schedule catches.
Four questions, one sentence
| Question | Where the answer lives | Can an agent answer it |
| Do we own this tool at all | Approved software list | Yes, from a document |
| Who is eligible for a seat | Policy, by role or function | Yes, from a document |
| How do I request one | Process, with an approver | Yes, from a document |
| How many seats are free right now | Vendor console or asset system | Only with a live connection |
| What does a seat cost | Contract, changes at renewal | Partly, as a basis rather than a figure |
| Can I have one | An approver, not a system | No, and it must not imply an outcome |
Four of the six rows are static facts and the queue is mostly made of them. The one row that genuinely needs live data is also the one people assume is the whole question, which is why this gets filed as an integration problem when it is largely a documentation one.
The cost row deserves care. Record the basis, such as per user per month on an annual commitment, rather than the figure. The basis survives a renewal and the figure does not.
What to do instead of documenting the number
The instinct when an agent answers a seat question badly is to write a better page. Resist it, because a better page decays at exactly the same rate.
What to do:
- Remove every seat count from every wiki page and knowledge article, including the ones in screenshots.
- Replace each with a sentence saying availability is confirmed at approval, which is true indefinitely.
- Record the cost basis rather than the price, so a renewal does not silently invalidate the page.
- Have the agent decline the live question and name where the real figure lives and who can read it.
- Keep the other three questions documented properly, since they are most of the volume.
- Reconcile owned against assigned seats quarterly, as a separate exercise from anything to do with answering questions.
The first item is easy to half-do. A figure inside a screenshot of a vendor console is unreadable to retrieval and perfectly readable to a person, which means the page still misleads somebody even after the text is fixed.
The reconciliation nobody runs
Separate from the answering question, there is usually real money sitting in the gap between seats owned and seats in use.
Pull the licence count from each vendor console, pull the list of accounts actually signing in, and compare both against current staff. Three findings come up almost every time: seats assigned to leavers, seats assigned to people who have never signed in, and a plan tier uplifted for a project that finished.
That exercise takes a morning per quarter and routinely returns more than the cost of any tool discussed on this site. It also produces the only trustworthy answer to the seat question, which is why it belongs in this article rather than in a procurement one.
Where an agent earns its place here
Having ruled out the main question, the remaining role is still worth having. Most contacts in this category are not really about availability at all.
People want to know whether the company has something before they ask for it, whether they are the sort of person who gets one, and what the request process is. Those three answered well remove most of the queue, and they are stable facts that do not decay between renewals.
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It is relevant here mostly through its limits, which decide the answer: it has no free tier, it answers questions rather than actioning tickets, and it is not an ITSM platform, so it answers from documents and cannot read a vendor console. Its strict mode declines rather than guessing, which is the correct behaviour for a live-data question, and it is priced flat at $29, $69 and $199 a month with unlimited seats, which removes seat counting from at least one tool. The options are compared in our IT support chatbot comparison.
Final thoughts
Licence questions get treated as a gap in the agent’s knowledge. They are a category error: the number lives in a vendor console and a document-trained system has no access to it, so a documented figure is a snapshot that goes wrong without changing and gets cited with full confidence.
Strip the counts out of every page, replace them with the sentence about confirming at approval, document the three stable questions properly, and let the agent decline the live one while naming where the real figure sits. Then run the owned-against-assigned reconciliation quarterly, which is where the actual value in this topic has been the whole time.
Frequently asked questions
Why can an AI agent not answer how many licences are left?
Because the number lives in a vendor console or an asset system and a document-trained agent reads neither, so it answers from whatever figure somebody once wrote on a wiki page. That page was accurate when written and became wrong without being edited, which is the one form of staleness no ingestion schedule detects, and the resulting answer is confident, specific and cites a real source.
Should you document seat counts in the knowledge base?
No, because the figure is wrong within about a week once joiners, leavers and renewal uplifts start happening, and somebody will plan a purchase around it. Replace every count with a sentence saying availability is confirmed at approval, which is true indefinitely, and record the cost basis such as per user per month on an annual commitment rather than the price itself.
Which licence questions can be answered from documents?
Whether the company owns the tool at all, who is eligible for a seat, and how to request one, which together are most of the volume in this category. Only the live availability question requires a connection to a vendor system, and the request-outcome question needs an approver rather than any system, so the queue is largely a documentation problem wearing an integration problem’s clothes.
What should the agent say when asked about availability?
Decline, and name where the real figure lives along with who can read it, because a plausible guess about a number that drives spending is considerably worse than an honest redirect. State that availability is confirmed at approval, which is accurate, and point at the request process rather than estimating from anything in the corpus.
What does a licence reconciliation usually find?
Three things, almost every time: seats still assigned to people who have left, seats assigned to people who have never signed in at all, and a plan tier uplifted for a project that has since finished. Pulling the vendor licence count, the list of accounts actually signing in, and current staff, then comparing all three, takes about a morning per quarter and frequently returns more than the cost of the tooling discussed here.
What is the easiest thing to miss when removing seat counts?
Figures inside screenshots, which are invisible to retrieval and perfectly readable to a person, so the page continues to mislead a human reader after the text has been corrected. Check images as well as prose when stripping counts, and prefer describing what a console shows over pasting a picture of it, since the picture cannot be updated as part of any normal review.
