Technology & Software
Putting Past Work to Work
Turning years of client experience into shared knowledge our Team and AI tools can use.
Overview
Every client relationship teaches us something. We learn how an organization works, why its systems are configured a particular way, which problems recur, and what has helped before. Much of that experience is recorded somewhere: in tickets, project documents, time entries, and conversations. Bringing it together usually falls to whoever handles the next problem.
We built a process to do that work systematically. It gathers relevant records, connects related information, and produces client references checked against their sources. Our support agent reads those references before investigating a ticket, and Team Members can inspect, correct, and add to them.
The goal is to shorten the path to resolving a problem and make the experience gained along the way useful again. Work completed for a client should give the next person a better place to start.
The Team
Experience the whole Team can use
A technician who has worked with a client for years brings context that takes time to acquire. They know which unusual arrangements are deliberate, what has already been tried, and which questions remain unresolved. That understanding shapes where they look and what they recommend.
Making more of that context available helps colleagues take on unfamiliar work. It also gives experienced Team Members a way to contribute beyond the tickets they handle themselves. A useful explanation or correction can inform later investigations, instead of depending on someone remembering to ask the same person again.
The references are designed to support that exchange. They bring relevant history together in a form people can review and our AI tools can use. Experienced colleagues continue to supply the judgment and context that the records do not contain.
The Harvest
Bringing the records together
We began with a year of helpdesk tickets, documents, time entries, approved recommendations, and Team conversations. From roughly 226,000 items, we produced 174 reference documents for 46 clients.
The useful information was often spread across several sources. A ticket might describe the problem, a time entry record the work, and a later conversation explain what finally resolved it. Reading those records together makes it possible to preserve the lesson.
Different parts of that work call for different tools. Scripts remove obvious clutter and duplicates. A small model helps identify relevant material. A more capable model brings the selected evidence together and drafts the references. This keeps the process practical to repeat while reserving the more demanding work for the tool suited to it.
Once assembled, the same client history can support many investigations. See the technical design for the source-by-source numbers and what the work cost.
Checking
Keeping the evidence attached
A shared reference needs to be open to scrutiny. Each factual statement carries evidence from its source, and a separate review checks whether that evidence supports what was written. Unsupported details are corrected or removed.
One correction came up again and again: a fix that had worked was recorded as if it explained the problem. Restarting a device can restore service without telling you why it failed. The next technician needs to know both things: what worked last time, and that the cause is still open.
We preserve that distinction throughout the references. Documented facts, previous remedies, and working theories each have a place, so a useful possibility does not quietly become an accepted explanation.
Harvest to Habit
Making knowledge part of the work
The initial harvest establishes a starting point. Keeping it useful depends on what happens afterward.
Investigations now read the client’s reference and record new findings as they work. Team Members can correct the record, with their contributions dated and attributed. That gives knowledge a regular path from an individual investigation into something later work can use.
A weekly update process gathers recent activity and proposes changes to the references. Those changes are checked against their evidence before being incorporated, which makes maintaining this knowledge part of normal operations rather than a project.
The references are in daily use. Investigations record what they find, Team Members correct what they know, and the weekly update folds in what changed.
For Clients
Putting your own experience to work
Many organizations have a similar opportunity. Years of completed work contain decisions, exceptions, and lessons that could help the next project or request. Making those records useful can give people more room to apply their expertise.
Some knowledge can be recovered from existing material. Other knowledge still needs to come from the people who understand the business. A useful system gives them a place to contribute it and a reason to keep improving it: their experience becomes available to more of the work.
The same approach can begin with one part of your business: a recurring request, a project handoff, or a body of client knowledge. We help identify the useful records, establish how they should be checked, and put them where the next task can benefit.
Three Facts
The short version.
Every figure on this page comes from our own logs and records, except where it is marked as an estimate.
- About 226,000 records became 174 reference documents for 46 clients
- 15,745 lines checked against their sources; 2,405 corrected or removed
- Facts, past remedies and working theories kept apart, each traced to its source
Technical Notes
How the harvest was built
The source-by-source numbers, how each small-model judgement was tested, the four writing passes, what the checks corrected, and the full diagram.
Technical Notes
How the harvest was built
For readers who want the detail behind the story above. Every figure here comes from our own logs and records, except where it is marked as an estimate.
The harvest ran as a sequence of narrowing steps. Scripts first removed what could never teach anyone anything: pictures, fonts, installers, automated alerts and duplicates. That left about 63,000 documents, 4,000 resolved tickets, 6,500 time entries, 101 approved recommendations and 457 conversations across 191 client folders. Jev, a small model from TypeSafe that answers narrow questions with a confidence score, then read each remaining item and answered a few questions about it: is this document useful, would this ticket teach the next person something, which ticket does this time entry belong to, which client is this conversation about. Its answers narrowed the set to 5,092 items for the 46 clients in our two largest service classes.
| Source | We started with | Claude read |
|---|---|---|
| Helpdesk tickets | 57,094 from a year | 1,269 |
| Drive files | 155,356 in client folders | 663 |
| Time entries | 10,359 | 2,883 |
| Approved recommendations | 182 | 101 |
| Team chat | 457 conversations, 2,734 replies | 167 threads |
Before any of Jev’s answers were allowed to decide anything, each kind of judgement was tested against examples with known answers. Time entries that already named their ticket showed whether it could link the ones that didn’t: right 76 of 80 times when the true ticket was among the candidates. Conversations that linked a ticket showed whether it could tell which client was being discussed: right 84 of 86 times. One score that looked useful, a rating of how likely a document was to mislead, turned out not to match Claude’s judgement and had been filtering out current network details, so it now only lowers a document’s rank.
Why not have Claude read everything? The text Jev judged came to about 140 million tokens by our logs. Read once by Claude at list price, that is about $560, against about $6 billed for Jev (estimated). More to the point, Claude did this work as an agent, re-reading everything it held on every turn: the harvest took about 3.3 billion input tokens to read, write and check 5,092 items, so 226,000 was never a realistic number. Jev’s largest pass judged 63,478 documents in 13 minutes; Claude’s work on a fraction of the items took two days. The harvest ran inside the same one-month premium Claude plan that covered the ticket-flow build, and its own extra cost was about $6 of Jev.
Writing and Checking
From evidence to checked references
Claude did the writing in four passes, each handled by many short-lived agents working on one bundle or one document at a time. Readers took a bundle of related items, a ticket with its time entries, the documents about it and the chat around it, and wrote down every fact with a verbatim quote and the ids of its sources: 8,607 facts in all. Writers took one client’s facts and produced one document per client and skill, 174 documents, the longest under 35,000 characters. Checkers then read every document against its quotes and against an evidence pack holding every source it cited: 15,745 lines, of which 2,351 were corrected and 54 removed. Finally an audit per client reconciled its documents with each other, fixing 192 contradictions and trimming 810 repeated passages to pointers.
The corrections were mostly specifics a source did not support (902), statements a later source contradicted (391), the wrong person or device named (367), facts that had gone out of date (186), and fixes written up as proven causes (174). An earlier test, run before every fact had to carry its quote, found problems on 35% of the lines it checked, which is why the quote became a requirement.
Checking is where the context window mattered. A checker holds the whole document, the facts it came from and every source it cites at once, because the errors it exists to catch are contradictions between them. 114 of the 245 checkers needed more than 200,000 tokens of context, so that step ran with Claude’s largest window. Checking was also where we tested a cheaper model, with the same three drafts checked by Claude Opus and by Claude Sonnet 5.5. Sonnet took more turns and about 1.6 times the tokens, flagged two to three times as many lines, and on the hardest document missed 12 of the 27 corrections Opus made. Both models charge the same for re-reading cached context, which is most of an agent’s usage, so Sonnet would have cost more here, not less. Opus’s corrections were the reference and the disputed lines were not independently judged, so this is a finding about this work, not a rule about the models.
In Short
The harvest, in short
Scripts cleared about 226,000 records down to what could teach anyone anything. A small classifier screened the rest to 5,092 items across tickets, documents, time entries, recommendations, and chat, for about $6. Claude read those items in bundles, wrote down 8,607 facts with their quotes, produced 174 reference documents for 46 clients, checked 15,745 lines against their sources and corrected or removed 2,405, and reconciled each client’s documents with one another. A weekly update now folds in what changed, and Team Members correct what the records could never know.
Your organization’s history is sitting in the same kinds of places: a ticketing system, shared drives, time records, chat. We can run this process on your records, under your permissions, and leave you with references your people and your AI tools can use. Tell us where the knowledge lives today, or start with how we assess the work.
Put Experience to Work
What does your team keep having to rediscover?
Tell us where useful experience gets scattered or depends on finding the right person. We’ll help you bring it together, check it, and put it to work.
Let’s TalkRelated
For the connections and controls underneath it, see:
For the fundamentals behind models, tokens and context windows, see our University guides: