WeKnora: Grounded Knowledge, Agents, and Wiki

A knowledge runtime, not just a document chatbot

WeKnora is best understood as a runtime for turning enterprise documents into operational knowledge. The same knowledge base supports three levels of work: cited retrieval for a direct factual question, a tool-using agent for a multi-step task, and an editable Wiki for knowledge that should be synthesized across documents and maintained over time. These are related products of one system, but they are not the same execution path.

This review is based on the v0.9.0 source snapshot. The main service is written in Go with Gin, the web application uses Vue 3, and a Python document service parses files and returns Markdown, images, and OCR through gRPC. The default deployment keeps business data, BM25 keyword search, and pgvector embeddings in ParadeDB/PostgreSQL. Redis and Asynq coordinate asynchronous parsing, enrichment, and Wiki jobs. Teams can replace the retrieval layer with Elasticsearch, OpenSearch, Milvus, Weaviate, Qdrant, Doris, or Tencent Cloud VectorDB when scale or existing infrastructure calls for it.

One evidence base behind three distinct workflows

Quick answer follows a conventional retrieval-augmented generation pipeline. It interprets and rewrites the question, retrieves knowledge chunks and optionally web results or graph entities, reranks and merges the candidates, builds a bounded context, and streams an answer over SSE. Citations are retained as part of the retrieval and context model, so the interface can connect an answer statement back to the document and the specific chunk that supported it.

Workflow	What it is for	Execution boundary
Quick answer	Find evidence and produce a direct cited response	Retrieval pipeline; it does not run an open-ended tool loop
Smart reasoning	Read, retrieve, call tools, inspect files, and complete a task	ReAct loop constrained by tools, iteration limits, and permissions
Wiki	Synthesize linked, traceable, reversible knowledge pages	Asynchronous Map-Reduce pipeline with source references and revisions

The workflows share spaces, knowledge bases, and access control, but the system does not blur reading with changing the world. Retrieval may operate in read-only scope. Wiki writes, shell commands, MCP tools, and automations each pass through resource authorization, an execution permission level, and when required, a human approval gate. That separation is one of the most important engineering boundaries in the project.

Ingestion creates retrieval assets, not only chunks

After an upload, the application records the document and enqueues parsing. The document service supports PDFs, office files, spreadsheets, web pages, EPUB, images, and more, while preserving rendered pages and image results. The processing pipeline creates structural or parent-child chunks, batches embedding requests, and writes keyword and vector indexes. Additional jobs then add summaries, generated questions, entities, and image descriptions to chunk metadata. A document is not considered complete until those child tasks finish.

As a result, searchability is not reduced to the presence of raw text in a table. A child chunk can recover its parent context, an image can carry OCR and a generated description, and adjacent content can be expanded when a short hit is insufficient. Knowledge bases that enable multimodal embeddings can place text and images in a shared vector space. If the response model supports vision, matched images can be included with their source identity. This is closer to enterprise material than a text-only index, but it also makes parsing, model usage, and indexing costs scale with document and image density.

Hybrid retrieval depends on rank fusion and several quality gates

WeKnora performs hybrid fusion above the storage-specific search engines. Vector and keyword retrieval run separately, their scores are normalized to the zero-to-one range, and the ranked lists are combined with weighted Reciprocal Rank Fusion. The default vector weight is 0.7 and the keyword weight is 0.3. A chunk is represented by its best rank within each retriever family rather than by summing incomparable raw engine scores. If only one retrieval family is available, the system skips dual-path fusion.

The fused candidates are then reranked. The default rerank threshold is 0.2. If every result falls below threshold but the best candidate reaches 0.15, that candidate can be kept as a fallback. If no result survives, the system retries once with the threshold multiplied by 0.7, without going below 0.3. The final composite score is 60 percent model relevance, 30 percent retrieval base score, and 10 percent source weight. Maximal Marginal Relevance then selects a useful set with a default relevance-to-redundancy balance of 0.7 to 0.3.

The parameters are useful because they expose separate points of failure: recall, fusion, reranking, diversity, and context assembly. Raising the keyword weight does not automatically improve answer quality. A representative question set is still needed to evaluate the full pipeline.

After reranking, the system merges sequential chunks, expands short passages with neighboring content, and removes near duplicates across knowledge bases. Wiki chunks receive a 1.3 multiplier when the relevant knowledge base has Wiki enabled, reflecting the fact that a page is a model-synthesized view of several source chunks. The citation path remains tied to the underlying document fragments, so the boost changes retrieval priority without erasing provenance.

Quick answer and ReAct solve different problems

Quick answer tries to get one bounded response right. Query understanding can rewrite the question, infer intent, extract entities, and describe attached images. Retrieval can combine knowledge-base chunks, web results, and graph entities. Generation streams through an event bus into a shared stream manager, which allows clients to resume after a disconnect. The pipeline also handles context compaction, citation aliases, fallback responses, and provider-side truncation.

Smart reasoning enters a ReAct loop. The engine reconstructs conversation history from the database on every turn instead of caching state across turns. The model selects a tool, observes the result, and continues until it can answer or reaches its iteration limit. Built-in tools cover knowledge retrieval, document reading, web search, MCP services, Wiki operations, skills, browser control, sandbox commands, background jobs, and long-term memory. The tool registry validates parameters, truncates oversized output, and cleans up resources. Event delivery exposes thoughts, calls, results, and final answers, while Langfuse traces each agent round and tool execution.

Long tasks need more than a large context window. WeKnora adds token estimation, history compaction, iteration guards, and steering while a run is active. A new user constraint can enter the current task instead of waiting for a separate turn. The design emphasizes recoverability: tool results, approvals, history, and run events have durable representations, so a broken connection or service event does not imply that the right next action is to replay everything blindly.

Child agents receive a complete assignment, not the parent's implicit context

Multi-agent collaboration uses a deliberately narrow context boundary. A child agent receives a self-contained assignment and does not inherit the parent's full history, attachments, or unstated preferences. This forces the delegating agent to specify the goal, source locations, constraints, and completion criteria, but it prevents irrelevant context from being copied into every subtask. The parent remains responsible for decomposition, progress tracking, and synthesis of the child results.

The boundary has a practical consequence for prompt design. An instruction such as “continue the work above” is not sufficient. The assignment must carry its own working set. In an enterprise setting, that makes execution easier to audit: each child has an explicit input, tool scope, and output, rather than depending on a hidden shared train of thought.

Permissions and automation constrain what the agent can change

Execution permission has three levels: read only, confirm before modification, and automatic write. Read-only mode cannot use a one-off approval to gain write access. Confirm mode pauses normal writes for approval. Automatic write permits ordinary writes, but destructive operations still require confirmation, and tools marked for mandatory approval cannot be bypassed by a normal grant. Space roles and resource ownership are checked separately, so an execution permission never grants access to a knowledge base the actor could not otherwise edit.

An automation runs as its creator and uses only resources that creator can currently access. It does not preserve a permanent user credential, and later role or resource changes affect the next run. Scheduled jobs default to a 30-minute execution limit, with a maximum of four hours. Approval waits can last up to seven days. A task pauses after three consecutive failures so that a bad configuration does not keep consuming models and tools indefinitely. Failed or interrupted jobs remain visible for review rather than being silently replayed as unknown writes.

The sandbox is useful, and its security boundary must be stated plainly

Skills and command tools can run in Docker, E2B, or Cube sandboxes with configurable networking, credentials, file exchange, and background jobs. A session-scoped sandbox is the safer default for isolated work. A user-scoped shared sandbox reduces startup and preparation cost, but it changes the security model. The project documentation explicitly states that commands run as root, sessions on the same machine have no operating-system isolation, processes and disks are visible, and one session can access another session's directories.

Docker deployments need an additional warning. A tool with access to the host Docker socket is effectively close to host-root control and should not be treated as an ordinary container permission. The README recommends private-network deployment, firewalls, access controls, and regular upgrades. A careful production design should separate networks, constrain mounts and credentials, deny unnecessary egress by default, and avoid sharing an execution host among mutually untrusted users.

Wiki generation is an asynchronous Map-Reduce pipeline

When Wiki indexing is enabled, new documents create separate jobs. The first pass extracts candidate entities and concepts. The next pass classifies source chunks against those candidates and discovers new page titles. The reduce pass merges content by page, producing summaries, page bodies, source references, and links. Writes use per-slug locking and snapshot-aware updates so concurrent batches do not overwrite each other without noticing. Prompts require grounding, prohibit self-links, and push the model to preserve evidence rather than invent unsupported claims.

Re-ingestion emits retractions or replacement references when source material changes. A finalization step uses SQL and graph operations rather than another model call to rebuild the index page, remove dead links, add cross-links, prune empty folders, and maintain the graph. Wiki pages record whether a version came from the pipeline, an agent, a human, or a rollback. Every overwrite snapshots the previous page; rolling back creates a new version instead of rewriting history. A soft limit of 50 revisions removes eligible generated history first, while a hard limit of 200 bounds storage for manually maintained pages as well.

Document ingest
  -> candidate page extraction
  -> chunk-level citation assignment
  -> per-page incremental merge
  -> source and link validation
  -> index rebuild, dead-link cleanup, cross-linking

This is the distinction between a Wiki and ordinary document summaries. A summary consumes one source. A Wiki has to reconcile entities across documents, merge duplicate concepts, move evidence, and maintain relationships. It is also not a synchronous transactional view: generation runs in the background and model usage depends on document volume and extraction density. Administrators therefore need to treat cost, latency, freshness, and human review as one configuration problem.

Where it fits, and what deployment still requires

WeKnora fits teams with substantial internal documentation that need cited answers and a shared knowledge artifact, not just another chat endpoint. Engineering notes, product documentation, support material, and project retrospectives can move through the same retrieval and Wiki pipeline. Agents, skills, MCP tools, and automations become useful when those resources must support recurring or cross-application work. The project is less suitable when “connected a model” is treated as the end of deployment. Parsing quality, index rebuilds, model cost, access control, sandbox networking, and human review remain operational responsibilities.

The repository offers Docker Compose, Helm, a Lite single binary, and a desktop form. Model providers, vector stores, and object storage are replaceable, which makes private deployment practical but also means each backend combination needs its own verification. The repository includes evaluation datasets and tooling, but this review did not reproduce a common benchmark and therefore does not claim superiority over other systems. A defensible conclusion is narrower: WeKnora assembles retrieval, agents, and Wiki maintenance into one deployable knowledge runtime and gives citations, authorization, auditability, and revisions first-class roles.

For RobotWorld's taxonomy, the project belongs to agents, agent harnesses, and knowledge management at the same time. Its significance is not a single retrieval constant. It is the end-to-end loop that lets enterprise knowledge be queried, acted on, revised, and traced under explicit operational constraints.