Skip to content

Knowledge Agent repository assessment

Status: Draft | Last reviewed: 2026-10-09

This assessment separates existing Framework and Tooling capabilities from the work proposed for Knowledge Management Agents. Read it before estimating reuse or choosing an execution engine.

Evidence scope

Framework inspection used the Vanguard working tree based on 8b7ce59f04976814a7971c0590f7359223d5bbf2. The checkout contained unrelated uncommitted changes; no application files were changed for this proposal.

Tooling inspection used SCM revision bd53eaab7173cd1c7d7492c3d8c6ae0d06ec8a3b of Deloitte-US/trueserve-tooling. Its tree records the apps/ragflow submodule at b19cfa7ed01f4de5bfe690d4953946924effd0d9. The submodule's implementation and deployed image were not verified.

The Tooling inventory identified the host and source repository. AWS discovery calls were denied. A read-only SSM source-inventory command was accepted, but both result-reading APIs were denied. SCM access succeeded and supplied the evidence below. These are source findings, not confirmation of the host's currently running code.

Framework reuse

Existing implementation What it establishes Proposed reuse
AnalyticsCanvas Fixed nodes/edges, disabled connections and dragging Card styling, canvas controls, editor conventions
Analytics configuration Agent-owned settings with dataset/release references Separate authored configuration and prepared data
Analytics preparation Immutable complete releases, encrypted sources, leased checkpoints Storage, job, publication, and usage patterns
Feature flags Runtime-only Scene/Analytics opt-ins and route/subtype gates New independently gated subtype
Pipeline types Central subtype registration and legacy type mappings Repository, creation, labeling, serialization integration
Workflow Decisions Visual rules and validated AI assessment Document routing and typed assessment controls
Workflow value editor Visual typed nested values Metadata, structured outputs, test inputs
Knowledge client Source lifecycle, ingestion/query settings, GraphRAG configuration and retrieval switches Existing source UX and native graph integration
Knowledge settings Live tenant connection resolution without environment fallback Tenant-scoped source-service connection
Test case storage Case revisions and snapshots, tied to conversation simulation tables Test UX and revision patterns, specialized knowledge executor
Config schema contract Described, generated configuration schemas Knowledge envelope and discriminated node contracts
Local Neo4j declaration An existing graph-store infrastructure path Later option if native RAGFlow leaves a demonstrated gap; not an initial dependency
Analytics taxonomy editor Existing taxonomy authoring controls Adapted topic hierarchy/review UI

Do not copy AnalyticsCanvas and merely enable dragging. Its graph is derived from a preset definition, not an authored dependency graph. Likewise, reuse Decision controls without inheriting workflow termination behavior that could silently drop a document.

Analytics upload limits documented at inspection are 10,000 files, 100 MiB per file, and 2 GiB per batch. Its source-storage pattern is useful, but those limits and its transcript-shaped processing contract do not establish support for the requested large-volume knowledge ingestion.

The legacy knowledge-engine guide describes a PostgreSQL assertion log with a Neo4j projection, but its app source is gitignored and is not a tracked implementation in this checkout. Treat that as a prior design pattern, not a supported runtime dependency.

Call Drivers and question discovery

Call Drivers offers concrete reuse beyond its canvas:

  • Normalization retains conversation identity, ordered turns, roles, available timestamps, and provenance.
  • The preparation worker redacts before annotation/indexing and publishes complete immutable releases.
  • The annotation schema carries driver, intent, root cause, resolution, friction, escalation, and evidence.
  • The compiler validates vocabulary/turn references and copies rich evidence quotes from canonical turns.
  • The intent hierarchy preserves stable IDs through grouping and category edits.

The annotation result is a conversation classification, not a list of all questions. Add a dedicated request-extraction contract, question grouping/review, and knowledge-support mapping. Reuse an authorized ready transcript release even when optional annotations are absent.

The current transcript preview returns only the first 100 turns per conversation, and annotation has an explicit input ceiling. The transcript discovery plan therefore requires a complete reader and measured long-conversation coverage before using these inputs for evaluation.

Tooling source service

The current source repository uses crawl4ai with CloakBrowser, despite older environment inventory entries and compatibility names that refer to Firecrawl. The crawler client returns Markdown and source metadata and retains a Firecrawl-shaped interface.

The source registry contains website, raw files, S3, GCS, Azure Blob, Salesforce, and Confluence configurations. Framework's source type list currently exposes the same set except Salesforce, and its create-payload switch lacks a Salesforce case. Salesforce acquisition is therefore not a completed Framework knowledge-tool feature.

Source handlers generally create a RAGFlow dataset for each source and start a connector rebuild. Raw uploads use a storage-backed connector. Website configurations can already combine several crawl inputs into one dataset. Combining arbitrary source types into a versioned collection is new.

The knowledge configuration contract already covers:

  • Parser and embedding selections, split size/delimiters, parent context.
  • Metadata extraction, keywords/questions, image/table context, GraphRAG/RAPTOR.
  • Retrieval limits, weighting, reranking, and allowed metadata filters.

GraphRAG/RAPTOR are separately initiated secondary indexes in this contract. They must be included in readiness if a published query profile requires them. Do not assume ordinary parsing completed every configured index.

This is an existing native graph integration, not a missing graph engine. Configuration includes generation model, entity types, entity combination, and cluster summaries; query settings expose graph retrieval defaults/permissions. The contract starts/polls graph work through POST/GET /api/v1/sources/{id}/indexes/graph.

Current upstream has moved to Knowledge Compilation; the provider research distinguishes that newer contract from the inspected Tooling interface. Verify the migration version before deciding which native stages to expose.

The crawler scheduler uploads documents, triggers parsing, and then marks its job successful. Partial source failures can also accompany success. It deletes matching filenames before upload and can continue after listing or deletion errors. Those behaviors are unsuitable as the new product's definition of a complete, atomically published knowledge release.

Reuse acquisition and connector knowledge. Add explicit acquisition output, source identity, manifests, parsing/readiness checks, and generation ownership rather than adopting the scheduler unchanged.

Inspected source Useful pattern Adaptation needed
Transcoder worker FFmpeg, transcription, audio analysis, scene/periodic frames, OCR/vision, job routing Tenant bindings, bounded jobs, exact timestamp provenance
Gallery job worker Separate document/model tasks, retries, enqueueing derived work Knowledge artifact and completeness contracts
Chapter detector Structured chapter output from timestamped transcript and frame signals Full-duration coverage and hierarchy for long media
Document indexer Source-specific extraction and index preparation Canonical document/locator contract
RAGFlow client Upload, parse, retrieve, enumerate chunks, source replacement Versioned writes, typed metadata, robust external-ID reconciliation

The frame extraction implementation estimates scene-frame times by spreading them across the video's duration. Capture actual decoder/presentation timestamps in the new pipeline; approximate times cannot support precise seek citations.

The chapter detector limits transcript/frame prompt text to bounded prefixes. Keep the useful structured-output pattern, but process the whole duration through windows and a higher-level synthesis step. Surface unprocessed intervals.

Some Gallery enrichment is best effort. Knowledge publication instead needs each step classified as required or optional, with optional failures visible in the release. Reuse algorithms and presentation ideas after adapting their contracts.

Tooling knowledge-core

Knowledge-core ingestion provides document writes, provenance, embeddings, and graph-edge helpers for wiki/CRM experiences. Its queue dispatches by experience-prefixed tenant IDs using Arq. This is a useful example of source/derived-document separation, but not a generic editable, per-step-checkpointed knowledge pipeline.

The inspected write helper can proceed when embedding fails. It also uses a different tenant identity scheme from Framework's UUID tenant model. Do not adopt its queue or storage wholesale and imply that it satisfies Framework's publication, tenancy, or evaluation contracts.

Its Neo4j mirror preserves tenant-tagged document relationships but is explicitly best effort. It is an alternative implementation reference, not the first graph backend. Any selected engine must meet source-evidence, generation-consistency, and intermediate-evidence authorization requirements.

Execution options

Option Benefit Gap for this proposal
General workflows Existing Decisions, canvas, node handlers Bulk manifests, chunk lineage, isolated generations, corpus evaluation
RAGFlow ingestion/graph capabilities Existing parsing/chunking/enrichment and native graph work Qualify artifact access, source ownership, review controls, and target-independent evaluation
Tooling data-pipeline Existing acquisition and source management Editable steps, immutable builds, definitive readiness
Tooling knowledge-core Source/derived documents and wiki/CRM patterns General graph semantics and Framework tenant model
Dedicated knowledge worker Direct fit for the proposed contracts New compiler/runtime and integration work

Recommend a dedicated knowledge worker for TrueServe lifecycle and evaluation using shared Framework infrastructure. Reuse RAGFlow's native graph/compilation engine and existing parsing/model implementations through adapters. A managed native node may perform several operations; expose its actual controls and outputs without rebuilding the same engine in TrueServe.

Do not store two independently editable graph definitions. If a later optimization compiles a supported TrueServe subgraph into a RAGFlow pipeline, the TrueServe graph remains authoritative and the compiled graph is a versioned output. Require artifact and evaluation parity before enabling it.

Tooling links below are pinned to the inspected SCM revision.

See also