What is Katara?
Our Mission
We've built a data unification platform that essentially mines data from several sources including fragmented community platforms (i.e. Discord, Forums, etc.) and other communication platforms (i.e. Slack, Telegram, etc.) for the purpose of informing and ultimately generating relevant and customized content - while also pulling in a projects existing published “corpus” which could include websites, blogs, technical docs, markdown files, code, whitepapers, and any other information that may be in-scope. In the future, we will also support “on-chain” data via partnerships with 3rd party data providers and/or other data providers/services.
How we do it
It starts with learning about what the community is asking about, what questions do they have, what topics are of interest, how are those interest changing over time - and then moves towards understanding the sub-audiences within a community so we can start helping teams generate very specific content targeted at those sub-audiences. Eventually we may even want to offer “onboarding packages” to new community members directly.
It has been the founders experience, validated by over countless interviews with developer relations, community moderators, heads of marketing and others in similar job functions that community & content live in silos - Katara will fix this by extracting data and analytics from both silos and providing automation to tackle increasingly more complex DevX workflows as our underlying technology platform matures.
Think of Katara as a hub - linking community and content together, providing advanced analytics about both, and then vertically integrating with many other platforms and services to drive complex automated workflows. Something like this:
What do we mean by DevX
We define DevX as a catch-all term for any community facing role at project with a slight bias towards “developers” and/or technical audiences - yes, indeed some teams have a large portion of non-technical community members and that is ok, they need information as well - but our goal is to lean into the more technical side as much as we can.
Why are we doing this
During interviews we heard over and over again the following main pain-points:
Content creations is a major headache for teams, marketing has its own agenda that typically does not line up with sub-audience and/or community needs so teams hire “developer relations” staff who must create the missing content:
Team are missing information about their communities - everything from sub-audience identification to topics of interest, they complain about “flying blind” as their is so much platform fragmentation and not enough tooling built out for these kinds of workflows
Hiring DevRel’s and other community facing roles is expensive and solid people are very hard to find - they want more automation to help existing teams become more effective
Why is this important?
There is a direct correlation between a projects ability to onboard and retain technical audiences and the subsequent success of the project (in terms of overall value creation) - there have been several published papers and reports about this, for example:
Who is Katara for?
We based Katara on the DevRel persona - that said, keep in mind that DevRel is a spectrum, at some times this is a role that covers the entire community - from non-technical to very-technical - at larger projects it can be wholly focused on “developers” while non-technical support is off-loaded to “community moderators” or similar.
Simple (naive) corpus building (I wouldn’t call this Corpus Management yet)
Basic agent deployments to Discord & Telegram (+ the Slack Beta)
Basic Data Capture - Questions, Community Handles, Timestamps, Platform/Channels
I would refer to this as our Trojan Horse - the suggestion being that we start small and expand quickly - more data capture, more analysis and data enrichment, more complex management and configuration tooling and then ultimately an entire suite of generative and collaboration features.
What this means is that our audience will expand over time - from DevRel/Community Mods to Operations, Marketing, Content Writers, etc. and the ultimately BizDev & Partnership teams - we should have something for everyone as we grow our capabilities.
Data is the key!
From Reactive to Proactive with AI
To better understand where we want to go with Katara it is good to think about it in terms of reactivity vs. proactivity - here is an example scenario:
Today - when a community member/developer asks a question on Discord it is a highly transactional experience - more senior community members or the team itself will respond with an answer - or perhaps they are running our agent and we respond with a simple summary and citations to the original content. It’s 1-and-done. A few weeks later the content changes - same person has to come back and ask the follow-up - how does this change impact me? Remember, Some of these communities are huge (70K+ members in the AVAIL Discord!) Supported by a team of 3-5 people, 24/7. There are no proactive follow-ups or check-back-ins.
Future - with Katara AI - same situation, only this time, we deliver the summary + citations - but a few weeks later we notice the content of a cited URL changed during a automated refresh, so we create a new updated answer to the original question and deliver a response to the user calling out the change and the impact. The proactive update keeps the community informed on a much more timely manner while making the project more sticky (would you leave if getting this kind of support? Probably not!) Also, the project team itself doesn’t need to answer any of those follow-up questions leaving them more time for other things - a Win-Win for both the project and the community member.
Web3 and Beyond
We made a strategic decision to start in Web3 due to a few factors that included:
Burning pain-points we felt we could address
Access to open-source data - which meant we could be a little less buttoned up on the security side and backend
High willingness to experience with new tech
Team (founders + investors) had a ton of contacts
Our goal was the get to PMF (or as close as possible) and then move into Web2 acknowledging that we would need to make some changes, take data handling and security into stronger considerations and integrate with new/different platforms - we also understand that our definitions may change as would deployment scenarios - what do we mean by this?
Our platform could support a more ridged definition of “community” - that could just be limited to “customers” or “partners” if we are talking about a large multi-national technology company with a host of regional resellers for example - but patterns may look the same - the teams need updated and timely content and everyone has slightly different requirements for it. We can help here as well with some simple modifications of our platform.
Katara is Modular
When architecting the solution - lets try when we can to keep things as modular as possible understanding that future pivots (i.e. into Web2) may require swapping out one or more components or may require a hybrid implementation of some of our tech merged with a companies existing systems - we may even want to support an “on-prem” implementation or a company trained foundational model (some Web2 organizations may not want to share data with external LLMs) - these ideas are not actionable at present - but when faced with a design choice, and if resources and timelines allow, let’s try and default to the option that keeps us the most flexible in the future.
Last updated