Kota CMS is now in private preview. It's Hyperbound's approach to agentic content management for revenue teams: one governed place for the knowledge your team sells with, read by Kota and applied across everything it does in Hyperbound.
Every revenue team has a methodology, a set of personas, current messaging, and a way of qualifying deals. All of it is written down. Almost none of it is in one place. The persona guide is in Notion, the messaging deck is in Drive, the qualification methodology is a PDF enablement maintains, and the battlecards are in a content platform reps stopped opening.
That was tolerable when people were the only readers. It breaks when an agent is. Kota can build bots, scorecards, and feedback, but it built them from a general understanding of sales, not from your team's material, because your material wasn't reachable. Whoever asked for the resource translated the docs in by hand. The next person did it differently. Over a quarter, a workspace ends up with several interpretations of one methodology and no trail back to the source.
Content platforms weren't built for this either. They store files for humans to find. They don't know which document applies to which job, and they don't hand an agent the rules for using it.
Kota CMS is designed to be that missing layer: centralize the knowledge, govern it, understand where each piece applies, and put it to work.
The private preview focuses on the foundation. Two layers, one place, under Workspace settings as the Knowledge Base.
Connectors are the broad layer. Connect Notion, Google Drive, SharePoint, Seismic, Highspot, or any app in the library, and Kota can read from it anywhere in Hyperbound: building a bot, building a scorecard, or pulling a doc to check something on a call. You decide what Kota can do inside each app. Every connector exposes its tools individually, so Kota can search and read pages in Notion without permission to create or edit them.
Guidelines are the granular layer. Each workflow Kota builds for has its own set of instructions it follows every time it creates or edits that type of resource:
When creating cold call bots, assume we sell to a VP Sales persona at mid-market SaaS companies who has already evaluated a competitor.
When creating scorecards, use BANT: Budget, Authority, Need, and Timing. Weight Need and Timing over Budget on first calls.
Write them yourself, or upload up to five files and Kota drafts them. A persona guide becomes rules about who the bot is. A methodology deck becomes rules about how the scorecard grades. Your documents were never written as instructions for an AI; Kota does that translation, and you review the result before it applies.
Governance and version control run through both layers. The Knowledge Base records which files generated each set of Guidelines, who changed them, and shows before and after side by side. Every app connected and every file uploaded is logged, by whom and when. Nothing Kota does should be a mystery to the team relying on it.
The preview covers Practice: bots and scorecards. It's the narrowest version of a bigger idea.
A traditional content system stores files and waits for a person to find the right one. It knows a file's title and folder, not what it means or when it applies. Once an agent is the reader, the store has to carry the meaning too.
That's the biggest piece of what we're building: a content model where your revenue knowledge lives as structured, related pieces rather than a pile of documents. This persona connects to these objections, this qualification rule applies to first calls but not renewals. Those relationships are what let Kota reason about the material instead of searching it, and choose what to use based on the persona, the deal stage, and what the rep just said. It's how the same source reaches Perform and Activate: the feedback on a live call, the recommendation in a seller's workflow, and the practice bot all draw from one place.
Kota will run longer, multistep jobs on that knowledge, across connected systems and through integrations such as MCP, inside the guardrails you set and with a log of what it used and why. Those logs are also how you'll see which knowledge is doing work and what reps keep needing that nobody has written down yet.
Private preview capabilities, scope, and availability are subject to change as we continue development and incorporate customer feedback.
Use Cases
Legal
