Use cases
What people ask, once the assistant can reach the answer.
The interesting thing about opening a system to an assistant is not the technology. It is that a question somebody used to queue for now takes a sentence. These are the three places that shows up first, written as what the work looks like rather than as outcomes we are claiming on anybody's behalf.
Read them as scenarios, not case studies. No client is named on this site without written consent and none has been given yet, so nothing below is a customer story. Each page ends with the same section: what has to be true before that scenario is real for you, including the parts that are not true here yet.
The three
Different questions, one decision layer underneath.
The same grant, the same four gates and the same audit trail serve all three. What changes is which system answers and which written rules apply to the answer.
Finance and planning
"What moved in the payroll plan since last week, and who changed it." The planning model answers live, and the answer names the environment it came from, because a test figure and a production figure look identical in a conversation.
Delivery operations
"Does this statement of work match what we signed." Your own written process, approved by a named person, applied to a document by somebody who has to record the check they made.
Consultants on several clients
One person, four clients, four separate estates. Belonging to several is normal here and governed, rather than the ambiguity that makes most systems fail closed or, worse, guess.
What binds them
The part that does not change between them.
A use case is usually where a vendor stops being specific. These three describe different work and rest on exactly the same four properties, which is the argument for a layer rather than three integrations.
True in all three
- Nothing is copied. The read happens against your system at the moment somebody asks.
- One person, one grant. Access is a row somebody created, not a shared login.
- Writes are off. Everything below is reading. Changing a number is a separate decision nobody has taken yet.
- Refusals are recorded too. "It would not tell me" is data, and it is usually the more useful half.
Different in each
- Which system answers, and therefore whose access rules narrow the result before ours do.
- Which written rules apply, approved by a named person on your side, in your vocabulary.
- What a good answer looks like, which is the part only somebody who does the job can define.
Not on this list, and why
Two obvious use cases we are not writing yet.
Both are modelled, both have a connector, and neither is honest to describe as a use case today. Naming them here costs us two pages and saves you finding out in week three.
Document retrieval
The connector reads document libraries through Microsoft Graph, which is the strongest permission story we have: the person's own access narrows the result and we store no credential for it. The delegated sign-in that makes it work is not configured yet, so a page describing people searching their documents would be describing something you cannot do on day one.
Sales and CRM
The CRM connector works, and the narrowing is ours rather than the vendor's: a read returns only the records that person owns, and reading the whole pipeline is a separate tool somebody has to grant on purpose. That is a real answer and it belongs in a security review before it belongs in a use case. It is published on whose permissions apply.
Twenty-six systems are modelled and four have working connectors. That ratio is the honest state of the connector estate, and it is the number to ask about first if the system holding your answer is not one of the four.
Tell us the question your people keep queueing for.
It is a better opening than a demo, because it decides in one conversation whether the system that holds the answer is one we can reach today or one we would be building for.