The easiest way to understand Kendr is through three common jobs: deep research, multi-step work, and a knowledge base built from material your team already has.
This screenshot is specifically the deep-research experience: the ask in the center, and the research controls on the right for scope, citations, outputs, source families, and private knowledge.
Most research tools handle either the web or your documents, then leave the user stitching everything together manually. Kendr is strongest when a question spans sources, formats, and multiple passes of synthesis.
What users want
A single place to gather evidence, compare sources, preserve citations, and turn findings into a shareable output.
What breaks today
Tabs, PDFs, spreadsheets, and notes are scattered. The user becomes the orchestrator instead of the system.
How Kendr fits
Route across web, files, and local evidence in one run, then keep the result as an artifact instead of a transient answer.
Typical research motion
Input
"Map the vendor landscape, compare claims, and tell me what changed."
Sources
Web pages, PDFs, slide decks, spreadsheets, and internal notes
Output
Cited summary, gaps to verify, reusable session, and a report the team can revisit later
Agentic execution in plain language
The ask
"Turn this research into a plan, run the right tools, and pause before anything sensitive."
What the runtime does
Classifies intent, routes work, builds a plan, checks setup, and pauses for approval when the action matters.
Why users care
They want help moving the work forward, not another answer box that stops at a summary.
The word "agentic" only matters if people trust the product to coordinate steps, route tools intelligently, and stay safe around sensitive actions.
A reusable KB is not just a vector store. For most teams it is simply the place where research, files, and previous runs stay searchable later.
Add
Files, URLs, databases, cloud folders
Persist
Sessions live beyond one run or one user query
Reuse
Ask follow-up questions without rebuilding context
That is why this page uses plain language instead of backend terms. What matters is keeping context alive, not making people re-ingest the same material every time.
View KB-Led WorkflowsWhat KB creation feels like
This language is closer to how buyers and operators think than raw technical feature labels.
Research across multiple sources, keep citations, compare claims, and preserve the result.
Turn a prompt into a plan, route the right actions, and keep the user in the loop when the stakes rise.
Build a knowledge base that survives the session and becomes more useful over time.
Different teams use the same product motion for different reasons. The use-case page now filters by field and workflow instead of forcing one fixed vertical story.