When we designed the Asterminds early-access program, we set a 90-day minimum engagement window. The reason was not arbitrary. Short pilots of knowledge-mapping tools tend to produce maps, not insights. You need enough operational time to see whether a team actually uses what it learns, whether the knowledge picture changes under normal organizational churn, and whether the initial data surfaces anything that causes real decisions to shift.
Over the first half of 2026, we completed 90-day structured pilots with three enterprise business units. The three were different in sector and internal structure, which was intentional. We wanted to test whether the same fundamental approach would hold across different organizational patterns, not just in the one type of environment we knew best from our own backgrounds. What follows is an account of what we saw, including the parts that surprised us. We are sharing this because we think the patterns will be recognizable to HR and operations leaders working in similar environments, and because honest product learning is more useful than a case study that makes everything look clean.
Note on methodology: all findings described here are drawn from our own structured check-ins during the 90-day periods and should be understood as early pilot observations, not controlled research. We are reporting patterns, not publishing claims.
The first team: operations in a large manufacturing context
The first team was an operations group within a manufacturing organization that employed several thousand people across multiple facilities. Their stated problem going into the pilot was succession risk: they had a set of senior specialists approaching retirement and no clear sense of how much of what those individuals knew existed elsewhere in the organization.
What the knowledge map revealed was a concentration pattern that was more severe than the team had assumed, but in a different location than they expected. The specialists they had been worried about were retirement-eligible and did carry significant unique knowledge. But the more acute gap the map surfaced was in a mid-career technical role that no one had flagged. That role sat at the intersection of two process areas and had been held by the same two people in rotating succession for twelve years. Both were still active employees. Neither was on any watch list. But the knowledge of how those two process areas interacted under specific edge conditions was almost entirely concentrated in that pair.
When we presented this finding at week six, the team lead's first response was to double-check the underlying data. Once they confirmed it, the conversation shifted to a decision they were planning to make in Q3 about restructuring one of those process areas. That decision had not previously accounted for the knowledge dependency at all. The map changed that specific planning conversation in a way that was concrete and traceable.
The second team: corporate functions at a financial services firm
The second team was a corporate functions group at a financial services organization. Their interest in the pilot was different: they were preparing for a multi-department integration and wanted to understand where knowledge overlap existed across the departments being merged, and where the integration would create genuine capability gaps rather than just headcount redundancy.
This use case put our data-source integrations under more pressure than the manufacturing pilot had. Corporate functions teams at financial organizations tend to have information spread across a larger number of systems with more access controls between them. We ended up with a narrower knowledge graph than we had hoped, but what it covered was actionable.
The most useful finding here was not concentration or gap identification but rather what we called knowledge shadow: capabilities that existed in one department but that the other department did not know were there and would have hired for externally during the integration. In three instances, the map surfaced that the adjacent department had people with overlapping background. In two of those three cases, the integration planning team confirmed they had not been aware of those people and agreed they were relevant to the integration structure. We cannot claim the map changed the final integration decisions, but it changed the information that went into at least two of those decisions.
The third team: a cross-functional product group
The third pilot was the most challenging. The team was a cross-functional product group with members drawn from several parent departments. Cross-functional structures create a knowledge-mapping problem that is structurally different from single-department mapping: the reporting lines do not trace back to a single organizational node, the tenure patterns are mixed, and people's real working relationships cross the formal structure in ways that vary week to week.
We adapted the approach here by focusing on project history as the primary signal rather than organizational structure. Who had worked on what, when, and with what outcome was a more reliable indicator of real expertise in this context than any hierarchical data source. The resulting map was sparser than the other two pilots produced, but the people the map identified as knowledge connectors (individuals whose expertise spanned multiple functional areas in ways that were not visible from the org chart) were consistently confirmed as accurate by the team when we reviewed them.
The operational change this pilot produced was smaller but specific: the team lead revised how they scoped project kickoffs for a new initiative that started in the final weeks of the pilot. They used the connector map to identify two people from adjacent functional areas who should be in the early conversations. Both attended. One contributed a constraint that changed the scoping approach. The team lead told us in the week-twelve check-in that they would not have found either person through their normal process in the same timeframe.
What held across all three
Three patterns appeared in all three pilots and are worth noting because they will likely appear in other enterprise contexts.
First, the most important findings were almost never the ones the team had nominated going in. Every team came in with a specific concern. In every case, the map surfaced a more urgent or unexpected gap alongside the expected one. This suggests that knowledge-mapping should be framed as discovery, not just confirmation.
Second, the data integration step was consistently underestimated. Every team assumed we would connect to their systems quickly. In every case, access, data quality, or scope limitations meant the initial map was narrower than intended. That did not prevent useful findings, but it adds time. Organizations planning similar initiatives should expect to spend the first three to four weeks primarily on data scoping rather than on analysis.
Third, the question of what to do with the findings was the hardest one. Surfacing a knowledge gap is not the same as closing it. All three teams left the 90-day period with a clearer picture of their knowledge landscape and a set of unresolved questions about what changes to make. That is an honest account of where a knowledge analytics tool sits in a larger planning and decision process. We can inform the decision. We cannot make it.
