use case · support # Support where the agent knows what it doesn't know An online subscription service: customers write in through a messenger and by email. An agent answers first, from the support knowledge base. If there's no ready answer, it doesn't make one up. It asks a human — through a task in SKEIN. Here SKEIN isn't a ticketing system; it's **support's memory**: what people asked, what was decided and why. customer **Writes in the messenger** “can't connect after paying” support agent **Answers from the knowledge base** a “symptom → ready answer” tree SKEIN **Doesn't know → “knowledge gap” task** what was asked, in which chats, what's already known, a question for a human SKEIN · branch **Widespread issue** the same complaint from many people at once — a rule goes in only on the owner's word SKEIN · branch **A defect in the agent itself** a bug with examples goes to the development project; the agent doesn't touch code without permission operator **Decides in a comment** “ok”, a clarification, or “that branch already exists” next customer **Gets an answer right away** this question no longer reaches a human SKEIN **Task closed with the edit's location** outcome: done · knowledge base section in the summary support agent **Verbatim edit to the knowledge base** file, section, text of the branch — applied only after an unambiguous “ok” SKEIN · branch **Observation → investigation** a note with a file, extended cycle after cycle; linked to the rule 1. **A customer writes in.** Through a messenger or by email. The support tool pulls in the account context: subscription, payments, connections. 2. **The agent answers from the knowledge base.** It works in cycles, several times an hour, and answers from a “symptom → ready answer text” tree. Security, money and promises on behalf of the service go straight to an operator. 3. **No ready answer — the agent doesn't make one up.** It hands the chat to an operator and creates a “knowledge gap” task in SKEIN, under a standing epic. Another request about the same thing doesn't spawn a new task — it's added as a comment to the existing one. 4. **The status shows whose move it is.** Open — the operator's move. In progress — the operator has had their say, the agent's move. The operator opens the list of open tasks and sees their queue, with anything about money and trust at the top. 5. **The agent comes back with a verbatim edit.** Knowledge base file, section, exact text of the branch. The agent treats an ambiguous reply as a remark, not as approval. 6. **Closed with a location.** Outcome: done — and the summary records exactly where in the knowledge base the edit lives. If the operator decided no edit is needed — won't do, with an explanation. A repeat — duplicate, with a link to the original. 7. **The next customer gets an answer right away.** A question a human answered yesterday is handled by the agent today. The history of the decision stays in the task — search will find it. 8. **The loop is closed.** Here SKEIN is the operator's decision queue and a log of how support's knowledge changed. What people asked, what was decided and why. 9. **Branch: a widespread outage.** The same complaint from many people at once. The agent gathers facts — symptoms, what was checked against the data — but doesn't introduce a new outage rule on its own: only on the owner's word. While the task is open, the rule overrides the usual branches. Once the outage is over, the rule is removed and the task is closed. 10. **Branch: an observation becomes an investigation.** When the picture doesn't fit a rule, the agent creates an investigation note with a file and extends it cycle after cycle: new cases, counterexamples, corrections to its own earlier conclusions. The rule and the investigation are linked: you can see what grew out of what. 11. **Branch: the agent found a defect in itself.** It noticed that it had stopped being able to read customers' screenshots, which caused unnecessary escalations. It filed a bug — with scope, examples and acceptance criteria — in the project where it's developed. Later it refined the diagnosis itself and described a workaround, but it didn't change the code without permission. ## What SKEIN does here **Standing epics.** “Knowledge gaps” and “Widespread issues” are never closed: every case is a child task, and closed children become history. Counters aren't cluttered by an “eternally open epic”. **Status as a traffic light.** Open — the human's move, In progress — the agent's move. You can see who's holding things up without a separate field. **Types.** “Decision” — a verdict is needed, “task” — knowledge needs an edit, “note” — an observation or investigation, “bug” — a defect in the knowledge or in the tool. The operator filters “where I'm expected to decide” apart from “just background facts”. **Origin.** The agent files gaps from the live queue on its own; registries and investigations are created at a human's direct request — on assignment. You can see what the agent found itself and what it was asked to do. **Comments tagged with their author.** Human and agent replies are told apart even under the same account. A thread reads like a dialogue; search can pull out just the human's replies. **Close outcome.** Done with the edit's location, won't do (“that branch already exists”), duplicate with a link. You can see how many gaps were closed by a knowledge edit and how many were false alarms. **Links.** Rule ← investigation, new gaps ← rule. You can see what grew out of what. **Search.** The agent cites past cases, the operator finds their own past decisions. The registry works as a knowledge base about *why* the knowledge is the way it is. **A short story about trust.** The agent found its own defect, filed a bug with examples — and didn't touch the code without permission. The human decides, the agent executes. This is one of the processes we live by. The rest are on the home page. ← All use cases Use case: end-to-end development →