| Ecosystem |
| 1 |
| 0 |
| Match Graph | 0 | 0 |
| Pricing | Free | Paid |
| Capabilities | 12 decomposed | 14 decomposed |
| Times Matched | 0 | 0 |
Stores project tasks as markdown files in .knowns/tasks/ directory with Git-friendly format, enabling AI agents to maintain persistent memory across sessions. Tasks include acceptance criteria, implementation plans, and @doc/path/@task-N references that create a context graph. When an AI agent is assigned a task, it parses all embedded references, recursively follows links to documentation, and builds a complete context graph before implementation — solving the stateless AI problem where context must be re-explained each session.
Unique: Uses Git-tracked markdown files with @reference syntax for context linking instead of a centralized database, making the entire knowledge base human-readable, version-controlled, and portable. The reference resolution happens at read-time (when AI agent accesses a task) rather than at write-time, enabling dynamic context graphs that adapt as documentation changes.
vs alternatives: Unlike Jira or Linear which store context in proprietary databases, knowns makes task context Git-trackable and AI-readable; unlike simple markdown folders, it provides structured reference linking and recursive context resolution for AI agents.
Implements a Model Context Protocol (MCP) server that exposes the task and documentation system to AI agents via standardized protocol bindings. When an AI agent connects via MCP, it can query tasks, resolve references, and retrieve full context graphs without parsing markdown directly. The MCP server translates internal FileStore operations into MCP resource and tool endpoints, enabling seamless integration with Claude, GPT, and other MCP-compatible agents.
Unique: Implements MCP as a first-class integration point rather than an afterthought, making the entire task/doc system queryable via standard protocol. The MCP server translates FileStore operations into protocol-native endpoints, enabling AI agents to resolve context graphs without understanding knowns' internal markdown structure.
vs alternatives: Provides standardized MCP integration vs. custom API endpoints; enables any MCP-compatible agent to access context without custom adapters; follows protocol standards for interoperability.
Implements knowns as a TypeScript codebase that compiles to JavaScript and runs on Node.js, Deno, and browser runtimes. The build system uses Vite for bundling and supports multiple entry points (CLI, server, web UI). Core logic is runtime-agnostic, with platform-specific adapters for file I/O, HTTP, and other system operations. This enables the same codebase to run as a CLI tool, HTTP server, web application, and embedded library.
Unique: Implements a single TypeScript codebase with runtime-agnostic core logic and platform-specific adapters, enabling deployment as CLI, server, and web application without code duplication. Vite-based build system supports multiple entry points and targets.
vs alternatives: More flexible than single-runtime tools (CLI-only or server-only); enables code reuse across platforms; simpler than maintaining separate implementations for each runtime.
Provides a React-based web interface that renders the same task and documentation data as the CLI. The web UI includes a Kanban board for visual task management, a documentation browser for exploring linked docs, and a task detail view with full context. The UI communicates with the knowns server via HTTP API and WebSocket for real-time updates. All UI state is derived from the FileStore, ensuring consistency with CLI and other interfaces.
Unique: Implements web UI as a separate React application that communicates with knowns server via standard HTTP API and WebSocket, rather than embedding UI logic in the server. This enables independent UI updates and scaling.
vs alternatives: Lighter than Jira/Linear UI (no complex state management) but more polished than plain CLI; provides visual overview for non-technical stakeholders while maintaining CLI-first developer experience.
Parses @doc/path and @task-N reference syntax embedded in task descriptions and documentation, then recursively resolves all linked documents to build a complete context graph. When an AI agent requests a task, the system traverses the reference tree, fetches all linked documentation, and returns a flattened context structure. This enables AI agents to understand not just the immediate task but all architectural decisions, patterns, and related work that inform implementation.
Unique: Uses a simple @reference syntax embedded directly in markdown rather than a separate link database, making references human-readable and editable. Resolution happens at read-time with recursive traversal, enabling dynamic context graphs that adapt as documentation changes without requiring index updates.
vs alternatives: Simpler than graph database approaches (no schema, no query language) but more powerful than flat document lists; enables AI agents to discover context through reference chains rather than requiring explicit context specification.
Provides a command-line interface (knowns/kn commands) for creating, updating, and organizing tasks and documentation with built-in Kanban board state management. Tasks move through predefined states (backlog, in-progress, review, done) tracked in markdown frontmatter. The CLI supports batch operations, filtering, and status transitions. A companion web UI (React-based) renders the same data as a visual Kanban board, with both interfaces operating on the shared .knowns/ file store.
Unique: Implements a dual-interface design where CLI and web UI operate on the same file-based storage, avoiding database synchronization issues. Kanban state is stored in markdown frontmatter, making workflow status Git-trackable and mergeable.
vs alternatives: Lighter than Jira/Linear (no server, no database) but more structured than plain markdown folders; CLI-first design appeals to developers while web UI provides visual overview for non-technical stakeholders.
Maintains a version history of all task and documentation changes using a VersionStore layer that tracks file mutations over time. Each change is recorded with timestamp and metadata, enabling rollback to previous states. The versioning system operates transparently on top of the FileStore, capturing all mutations whether they come from CLI, web UI, or API calls. This enables audit trails and recovery from accidental deletions or edits.
Unique: Implements versioning at the FileStore layer (below CLI/web UI) rather than as a separate feature, capturing all mutations regardless of interface. Version history is stored alongside data files, making it portable and Git-compatible.
vs alternatives: Provides version history without relying on Git commits; enables rollback without understanding Git; simpler than full Git integration but less powerful than Git's branching model.
Stores project documentation as markdown files in .knowns/docs/ with YAML frontmatter for metadata (title, tags, created, updated). Documentation supports standard markdown syntax plus knowns-specific reference syntax (@doc/path, @task-N) for linking to other docs and tasks. The system treats documentation as first-class entities that can be queried, linked, and versioned alongside tasks. A documentation browser in the web UI enables visual navigation of the doc structure.
Unique: Treats documentation as first-class entities with structured metadata and reference linking, rather than as unstructured markdown files. Documentation is queryable, linkable, and versionable alongside tasks, creating a unified knowledge system.
vs alternatives: Simpler than wiki systems (no database, no special syntax) but more structured than plain markdown folders; enables AI agents to discover and link documentation through reference chains.
+4 more capabilities
Automatically loads and parses documents from diverse sources (PDFs, Word docs, HTML, Markdown, code files, databases) into a unified in-memory representation using format-specific loaders and node-based document abstractions. Each document is decomposed into Document objects containing metadata, content, and relationships, enabling downstream processing without format-specific handling in application code.
Unique: Provides a unified loader abstraction (BaseReader interface) that normalizes 100+ data source connectors into a single Document/Node API, eliminating format-specific branching logic in application code. Loaders are composable and chainable, allowing sequential transformations (e.g., load → split → extract metadata → embed).
vs alternatives: Broader out-of-the-box loader coverage than LangChain's document loaders and more structured node-based decomposition than raw text splitting, reducing boilerplate for multi-source RAG pipelines.
Splits documents into semantically coherent chunks using multiple strategies (character-based, token-aware, recursive, semantic) with configurable overlap and chunk size. Preserves document hierarchy and metadata through a node tree structure, enabling retrieval systems to maintain context relationships and enable hierarchical re-ranking or parent-document retrieval patterns.
Unique: Implements a node-tree abstraction that preserves document hierarchy and enables parent-document retrieval patterns. Supports multiple splitting strategies (recursive, semantic, code-aware) with pluggable custom splitters, and automatically propagates metadata through the node tree.
vs alternatives: More sophisticated than LangChain's text splitters because it preserves hierarchical relationships and supports semantic splitting; better for complex document structures than simple character-based splitting.
LlamaIndex scores higher at 40/100 vs knowns at 36/100. However, knowns offers a free tier which may be better for getting started.
Need something different?
Search the match graph →© 2026 Unfragile. Stronger through disorder.
Processes documents containing mixed content (text, images, tables, code) by extracting and understanding each modality separately, then synthesizing information across modalities. Uses vision models for image understanding, specialized parsers for tables and code, and integrates results into a unified document representation for retrieval and generation.
Unique: Integrates vision models, table parsers, and code extractors into a unified multi-modal document processing pipeline that synthesizes information across modalities. Preserves modality-specific structure (table schemas, code formatting) while enabling cross-modal retrieval and generation.
vs alternatives: More comprehensive multi-modal support than text-only RAG; built-in vision integration reduces boilerplate for document understanding compared to manual vision API calls.
Enables streaming of LLM responses token-by-token and real-time retrieval updates, allowing applications to display partial results as they become available. Supports streaming from retrieval (progressive document discovery) and generation (token-by-token output) with backpressure handling and cancellation support for responsive user experiences.
Unique: Provides first-class streaming support for both retrieval and generation with automatic backpressure handling and cancellation. Enables progressive result display without custom async/streaming code in application layer.
vs alternatives: More integrated streaming support than manual LLM API streaming; built-in retrieval streaming and backpressure handling reduce complexity compared to custom streaming implementations.
Tracks API costs for LLM calls, embeddings, and other operations with per-query and per-session cost attribution. Provides cost optimization recommendations (e.g., batch processing, model selection, caching) and enables cost-aware query planning to balance quality and expense. Integrates with multiple LLM providers to normalize cost tracking across models.
Unique: Provides automatic cost tracking across multiple LLM providers with per-query attribution and cost optimization recommendations. Integrates with query execution to enable cost-aware planning without manual cost calculation.
vs alternatives: More integrated cost tracking than manual API billing review; built-in optimization recommendations reduce guesswork for cost reduction.
Enables building custom RAG pipelines by composing modular components (retrievers, synthesizers, agents, tools) through a declarative or programmatic API. Supports complex workflows with branching, loops, and conditional logic, with automatic dependency resolution and execution optimization. Pipelines are reusable, testable, and can be deployed as APIs or batch jobs.
Unique: Provides a flexible pipeline composition API supporting both declarative and programmatic definitions, with automatic dependency resolution and execution optimization. Enables complex workflows with branching and conditional logic without custom orchestration code.
vs alternatives: More flexible pipeline composition than fixed RAG architectures; better workflow support than manual component chaining.
Generates embeddings for documents/nodes using pluggable embedding providers (OpenAI, Hugging Face, local models) and stores them in a unified vector store interface that abstracts over multiple backends (Pinecone, Weaviate, Milvus, FAISS, Chroma, etc.). The abstraction layer enables switching vector stores without changing application code, and handles batching, retry logic, and metadata indexing.
Unique: Provides a unified VectorStore interface that abstracts 10+ vector database backends, enabling zero-code switching between providers. Handles embedding batching, retry logic, and metadata propagation automatically. Supports both cloud and local embedding models through a pluggable EmbedModel interface.
vs alternatives: Broader vector store coverage and more seamless provider switching than LangChain's vectorstore integrations; better abstraction consistency across backends than using raw vector store SDKs directly.
Retrieves semantically similar documents from vector stores using embedding-based similarity search, with optional re-ranking, filtering, and fusion strategies (hybrid search combining dense and sparse retrieval). Supports multiple retrieval modes (similarity, MMR, fusion) and enables custom retrieval logic through a pluggable Retriever interface that can combine multiple strategies.
Unique: Implements a pluggable Retriever abstraction supporting multiple retrieval strategies (similarity, MMR, fusion, custom) that can be composed and chained. Built-in support for re-ranking via LLM or cross-encoder, and hybrid search combining dense and sparse retrieval without custom integration code.
vs alternatives: More flexible retrieval composition than LangChain's retrievers; built-in re-ranking and fusion strategies reduce boilerplate for advanced retrieval pipelines.
+6 more capabilities