I didn’t expect to revisit that problem twenty-something years later. At Rhythm Software, a 35-person association management software company, we get a lot of the same questions — and the answers all live in people’s heads. Our CEO had charged the team with finding a way to capture that knowledge to power an AI chatbot that could deflect support tickets. We’d been at it for a while, trying the obvious approaches — long-form prose, recorded walkthroughs, transcripts fed to the AI. Nothing was working well enough.

Two days ago the framing shifted: what if instead of capturing knowledge as prose, we captured it as structured records? I didn’t find a solution so much as stumble into a system.

We’re calling it the ATHENA Knowledge Management System.

What We Tried First

We’re a small team — we knew we couldn’t take on anything that required sustained effort from the people who were already at capacity. So everything we tried was optimized for low overhead. We started with written explanations. When that proved too slow, we tried having people record video walkthroughs instead — talk through a module, transcribe it, feed the transcript to the AI. Lower cost of capture, same idea.

It failed on two fronts.

The first problem was that even with video, we were still asking busy people to produce something comprehensive on a topic they lived in day to day. The recordings were useful but incomplete — you get what someone thinks to mention, not necessarily everything that matters.

The second problem was quality. Even when we had decent prose, the chatbot answers weren’t great. An LLM retrieving a long narrative document and trying to answer a specific question from it produces vague, inconsistent responses. The document might explain how auto-renewal works in general — but if the answer to “why isn’t my membership auto-renewing?” depends on three specific configuration fields all being true simultaneously, a prose paragraph probably doesn’t surface that cleanly.

Prose is written for human readers navigating a document. It’s not structured for a machine trying to answer a precise question. I needed something different.

Then I looked more carefully at something we already had. Rhythm’s API documentation is some of the best I’ve encountered in my career — exhaustively detailed, consistently structured, covering every endpoint, every field, every status value across all fifteen modules. A huge amount of product knowledge is already encoded in it. If I could harvest that, I’d have a foundation that didn’t depend on anyone finding time to write or record anything.

The question was how. Feeding raw API docs into an LLM had the same problem as prose — too much noise, not enough signal. But what if instead of transforming API docs into long-form explanations, I transformed them into something more granular? Not documents, but discrete facts. Typed records with defined fields. Something structured enough that a machine could reason about it precisely.

That’s where the schema came from.

The Schema

I landed on seven record types that together cover everything you’d want to know about a software product:

• Concepts — what a thing is and how it behaves
• State Machines — how a record moves through its lifecycle
• Rules — behavioral constraints, dependencies, and gotchas
• Configurations — what a given field does and what each value means
• Procedures — step-by-step workflows for specific actors
• Errors/Exceptions — known failure modes and how to resolve them
• Integrations — how the system connects to the outside world

These aren’t articles. They’re not written for any audience. They’re facts, captured in a form that a machine can query and reason about. An LLM reading a Rule record doesn’t get a paragraph explaining the rule to a customer — it gets the condition, the behavior, the exceptions, and the common misconceptions. It figures out how to explain that to whoever’s asking.

Every record also carries governance metadata: an owner, a status (needs-review, current, deprecated), a last reviewed date, and a review frequency. Knowledge has an expiry date. The system should know what needs to be checked.

I didn’t arrive at that schema alone — Claude helped me work through it, challenging my initial thinking and suggesting record types I hadn’t considered. With the structure defined, the next question was: how quickly could it actually be populated?

From Schema to Working Chatbot

Rhythm publishes OpenAPI specs for all fifteen modules of our platform, so I started there. I fed those specs into Claude and asked it to translate them into structured knowledge records — not to summarize the documentation, but to extract the facts and represent them in the schema I’d defined. Concepts, rules, state machines, configurations, procedures. Claude did the translation; I validated the output.

The speed was honestly shocking. Within hours I had a structural foundation across all fifteen modules — 847 records. I stored everything in a headless CMS — a highly configurable content store that exposes everything via API. That API supports MCP, a protocol that lets Claude connect to the records directly as a live data source. Once I had that connection in place, I had a working chatbot prototype answering real product questions. The whole thing came together in about three hours.

Those records are also cross-referenced — 1,042 links connecting related records across modules. A chatbot answering “why isn’t my membership auto-renewing?” needs more than a definition of auto-renewal. It needs to know that auto-renewal depends on three specific configuration fields all being true simultaneously. That’s a relationship, not just a fact — and without those connections, you get an AI that answers questions in isolation rather than one that reasons about how things fit together.

Adding the Behavioral Layer

The OpenAPI specs gave me the structural layer fast — endpoints, fields, status values, workflows. But API docs describe what the product does. They don’t capture how it behaves in practice. The gotchas. The edge cases. The things you only learn from actually using it.

That knowledge exists — it’s just scattered. It lives in screen recordings and demo transcripts, in internal documents and Slack threads, in support calls and the heads of people who’ve been working with the product for years. The challenge isn’t that it doesn’t exist — it’s that it’s unstructured and inaccessible.

So I built a second ingestion pattern alongside the API specs one. For each source — a recording, a transcript, an internal document, a Slack thread — I feed it through Claude with the existing records as context and ask it to extract knowledge nuggets that aren’t already captured. Claude maps each finding to the appropriate record type — a new Rule, an augmented Concept, a missing Configuration — and flags it for review.

I tested it with screen recordings of someone walking through the Accreditation module. The results were immediate. The recordings surfaced things that aren’t anywhere in the API documentation:

• A 60-second intentional delay before a membership-drop cascades to team candidate records — designed to give staff time to catch mistakes before a hundred records get updated
• Two distinct paths for adding team candidates, with meaningfully different behavior depending on which one you use
• The fact that evaluations can only be created in the portal — console staff can view and edit them, but not create them

Every one of those is the kind of thing that causes a support ticket. None of them are in the specs.

Each source type tends to produce different kinds of knowledge. Demos surface behavioral context. Support calls surface failure modes. Internal docs surface decisions and policies. That’s why the multi-source approach produces something richer than any single source could.

The API specs give you the skeleton. Everything else gives it life.

Where Things Stand

The knowledge layer is live and the chatbot prototype is working. Next step is an internal pilot — putting it in front of implementation and support staff with real questions and watching where it falls short.

The schema has already evolved once from real use. Someone posted a question in our internal #knowledge channel asking about our WCAG 2.1 compliance posture. I went to add the answer and realized I had nowhere to put it — it wasn’t product behavior, it wasn’t a configuration, it was a business decision that affects how we build and what we commit to customers. So I added an eighth record type: Policies. Things like accessibility commitments, data retention rules, support response standards.

That question didn’t just reveal a gap in our knowledge — it revealed a gap in the schema itself. Which is exactly the kind of signal the system is designed to surface. The schema isn’t finished. It grows as real questions expose what’s missing.

To make that signal flow reliably, I vibe-coded an internal chat interface — a React app that connects to the knowledge system and gives team members two ways to interact with it. They can ask a question and get an answer drawn from the published records, or they can proactively share something they know isn’t documented yet. In both cases, the bot captures what they share, structures it into a draft record, and queues it for the knowledge manager to review. Nothing goes live without human sign-off, but the capture happens in the conversation itself — no separate tool, no form to fill out, no ticket to file.

I’m not a developer. But with Claude doing the heavy lifting, building and iterating a working solution took a few hours.

How It Works in Practice

Here’s what using it actually looks like.

Correcting a wrong answer:

The bot answers the original question twice — once from the published record, once from the draft — so the team member can confirm the correction landed before the session ends.

Sharing something that isn’t documented yet:

The knowledge never existed in any document. Now it does — structured, typed, and queued for review. The team member just had a conversation.

A System That Compounds

Every documentation system I’ve ever worked with has the same fundamental problem: it starts accurate and drifts. The product changes, the docs don’t, and eventually they’re worse than useless — they’re actively misleading. The only fix anyone has ever found is to throw human effort at it on a recurring basis, which is expensive and doesn’t scale.

I was stuck on that reality when a radical thought hit me: what if the chatbot itself is how the knowledge stays current?

When a staff member gets a wrong or incomplete answer, they don’t file a ticket or flag it for someone to review later. They just correct the bot in the conversation — “actually, that’s not right, here’s how it works.” The chatbot takes the correction, immediately structures it into a proposed knowledge record update, and surfaces it to the knowledge manager for review. The knowledge manager iterates if needed and approves it. The record gets updated. The system gets smarter.

The knowledge manager is the human in the loop — nothing gets published without their sign-off — but the heavy lifting of translating a correction into a structured update happens automatically. The staff member just has a conversation. The chatbot and the knowledge manager do the rest.

Every interaction is a potential improvement. The more people use it, the more corrections surface, the more it reflects reality. It doesn’t decay over time. It compounds.

And that one role — a knowledge manager reviewing a stream of AI-generated updates triggered by real questions, not scheduled review cycles nobody has time for — makes the company’s knowledge genuinely accessible at scale. Support stops answering the same questions repeatedly. The people who know the product inside and out stop carrying the invisible labor of filling in everyone else’s gaps. The knowledge becomes infrastructure: available to anyone, at any time, without the tax on the people who hold it.

The Bigger Picture

I spent the early part of my career building structured content systems — and they worked. DITA and AuthorIT delivered on their promise. The same content really did render cleanly to a help site, a PDF, and an in-app tooltip. But it required a dedicated team of trained writers to make it happen. That was fine for large enterprises with documentation budgets. For everyone else, it was out of reach.

What I stumbled into with Athena goes further than what those systems could do — and turns out to be practical for teams of any size.

Capture knowledge once as structured facts — not content, not prose, just facts — and let the LLM render it for whoever’s asking. The same verified records that power the chatbot can render a KB article for a customer, a training module for a new consultant, an RFP response for a sales team, an in-app help system for a portal user. You capture the knowledge once, and the presentation takes care of itself.

Together with a feedback loop that keeps the knowledge current, you get something that hasn’t really existed before: a single canonical knowledge layer that serves every audience, in every format, and gets more accurate the more it’s used. Not by design — that’s just what happened when the pieces came together.

Any organization with complex knowledge and multiple audiences has this problem. The gap between what you know and what you can make usable has always been the bottleneck.

That gap just got a lot smaller.

Technical Notes

For those curious about the architecture: the whole system runs on three pieces that connect cleanly.

Sanity is the knowledge store. It’s a highly configurable headless CMS with a flexible schema and a full API — which matters because the records need to be queryable by both humans (via Sanity Studio, where the knowledge manager works) and machines (via API, where Claude retrieves them). One thing worth noting: the Sanity Studio interface is defined in code, which would normally put it out of reach for someone without an engineering background. I’m a product leader with more coding familiarity than most, but I’m not a developer. Claude wrote the schema configuration. That matters for who this approach is available to — you don’t need an engineering team to build it.

MCP (Model Context Protocol) is the bridge. Sanity exposes an MCP server that lets Claude connect directly to the knowledge records as a live data source — not a static document dump, but a structured, queryable store. When the chatbot answers a question, it’s retrieving the most current version of the relevant records in real time.

Claude does two distinct jobs. On ingestion, it acts as a translator — taking a source (an OpenAPI spec, a transcript, a Slack thread) and extracting structured knowledge records in the defined schema. On retrieval, it acts as a renderer — taking structured records and translating them into whatever the audience needs: a conversational answer, a KB article draft, a training outline. The same model, doing opposite things, with the knowledge layer in between.

The insight that made this work is that separating ingestion from retrieval — using Claude for both but keeping the structured records as the stable layer in the middle — is what gives the system its flexibility. Change the audience, change the format, change the channel. The knowledge stays the same.

The post Discovering Athena: Letting Go of Content to Unlock Knowledge appeared first on Will Sansbury.

In the early days of digital product design, we honored that. We sketched with Sharpies. We ran design charettes to generate ideas. We moved fast, threw things away, and stayed loose. Then came Photoshop, Fireworks, Sketch, and Figma. These tools gave us polish—but also made it easier to converge too soon. Once something looked “real,” it became harder to change. Stakeholders got attached. Designers got fixated. Exploration slowed. Premature convergence set in.

Now, we’re entering a new era—one where AI tools don’t just generate mockups, but actual front-end code. You type a prompt, and out comes a working UI. Not a sketch. Not a wireframe. Code. This is a leap in capability—and in risk. When a design is already functioning in code, it doesn’t just look finished—it is finished, at least to many stakeholders. And that makes it harder to step back, rethink, and explore alternatives.

This is how the creative process gets short-circuited. Teams skip the first diamond entirely—jumping to solutions without understanding the problem. They build interfaces that are functional but misaligned. Products become polished but shallow, fast but fragile. Design becomes reactive instead of reflective.

The damage isn’t always immediate. But over time, it compounds. You ship faster, but learn less. You optimize for delivery, not discovery. You stop asking “what if?” and start asking “how fast?” Eventually, you lose the space where real innovation happens.

AI tools aren’t the enemy. They’ll make great designers even better—especially those who can resist the gravitational pull of polish and code. But for teams without that discipline, or for stakeholders who equate working code with final product, these tools could quietly erode the very process that makes design valuable.

Without divergence, we don’t explore possibilities. We don’t test assumptions, challenge defaults, or uncover better paths. We don’t design with empathy—we just rush to solutions. And when that happens, we are shortchanging more than the process; we are shortchanging the people we’re designing for.

Design’s power has always been its focus on outcomes. If we reduce the value of design to visible output, we give away its superpower.

Speed at the cost of value is no bargain.

The post AI and Design: Embrace Change, But Don’t Forget What Matters appeared first on Will Sansbury.

A few quotes from What the f*ck is strategy? by Ro Fernandez:

🔥”Business isn’t about making money. It’s about creating value so compelling, people can’t wait to pay for it. And you will see how money come because of that.”

🔥🔥🔥 “You don’t rise to the level of your goals — you fall to the level of your systems.”

🔥🔥🔥🔥🔥 “The better your principles, the less you need rules.”

The post A Must Read: What the f*ck is strategy? appeared first on Will Sansbury.

If you’re stuck in an environment where breaking out of output-focus seems impossible, Melissa Perri has your back with her excellent book Escaping the Build Trap: How Effective Product Management Creates Real Value (Bookshop.org link).

The post Letting Go of “Release” appeared first on Will Sansbury.

How tragic it is to not understand that often the value lies not in the task getting done but in the process of doing it. In the doing, we learn. We gain context and understanding, and it is from that context and understanding that disruptive insights emerge.

For decades, we’ve struggled with this unspoken, unquestioned belief that more work in the done column is inherently a good thing. I don’t think it is. A high Jira ticket completion rate tells me nothing except that you’ve moved a lot of bits and bytes through Atlassian’s servers.

The Agile manifesto addresses this confusion between output and outcomes directly in its tenth principle: “Simplicity—the art of maximizing the amount of work not done—is essential.” Agile values mindfulness—understanding the present, with its context of what you learned yesterday, and prioritizing what is most valuable given everything you know and have learned. Inevitably, work we scope at the beginning of a project becomes less important, even unimportant, as we work. In the doing, we learn, and what matters changes.

If we fully offload the doing to AI, we get the satisfaction of a pile of completed tasks, but at what cost? AI can check the box on the to do list, but will it have the eureka moment as disparate threads suddenly weave into a rich tapestry? Will it tell you if it does?

Don’t get me wrong. AI is a powerful tool. Agents will be—and already the are being—revolutionary in so many fields and industries.

But for those of us who create value by solving problems, a little skepticism about AI is a good thing. If we leverage AI to do the work we need to do to learns we can end up painfully mediocre.

It’s in the doing, not the done, that we find creativity, innovation, and disruptive ideas.

The post When “Doing” Matters More Than “Done” appeared first on Will Sansbury.

Rodger wrote this in his post Fits and Starts Are the Formula:

Left to my own egoic devices, my preference is zero to 60 in 6 seconds. A total 180. Burn it all down and start from scratch.

Over the years, mostly through failures and missteps, I’ve learned that such an approach doesn’t tend to work out so well. For several reasons: A) It’s not kind to others involved. Most people are not early adopters. Most need adequate to time to get onboard. B) It’s not speed that guarantees healthy change. After all, cancer cells can tend to grow pretty quickly. Impatience is not an asset. And, C) It’s not realistic in most cases. Real change must occur in reality—where humans actually live.

My role is not is not to simply be a leader who causes change, but to be a pastor who shepherds change to be as kind, patient, and realistic as possible.

I have been guilty in the past (perhaps even recent past) of forgetting that change is about the people first and foremost. For change to stick, it has to come about from collaboration with everyone involved. Change inflicted on people as an act of dominance is change destined to fail in the long term.

A good reminder for me, and I suspect for leaders everywhere.

If you want to follow Rodger’s thoughts, I encourage you to do so. While the religious context might not be your jam, Rodger is a fantastic and thoughtful leader with lessons that matter in any arena.

Cover photo by Suzanne D. Williams on Unsplash

The post Reminder: Change Requires People appeared first on Will Sansbury.

The post Being “Right” is Wrong appeared first on Will Sansbury.

— Dieter Rams

The post Rams’ 10 Principles for Good Design appeared first on Will Sansbury.

Misanthropy often disguises itself as critique or challenge or prophetic voice in the wilderness. It hides behind a facade of being a truth-speaker. And misanthropes often do speak truth. But truth, like everything powerful, can be used to build or to destroy.

My admiration will always lie with the people who respond to being dealt an unexpected hand by immediately asking, “What is my best play with the cards I’ve got?” We may not be able to make things perfect, but we can always strive to make things better. We just have to care enough—about the cause, the mission, or the people—to try.

Photo by Nastia Petruk on Unsplash

The post On Misanthropy appeared first on Will Sansbury.

You never change anything by fighting it; you change things by making them obsolete through superior technology. Telstar replaced five hundred tons of transoceanic cable. It used to take us three years to circumnavigate the globe in a wooden-hulled ship. It took three months in a steel ship, ninety minutes in a space capsule and now instantaneously with telecommunications.

As told by Mike Vance and Diane Deacon in Think Out of the Box

The post R. Buckminster Fuller on Making Change appeared first on Will Sansbury.