Platform · Data · The grounding layer

Knowledge Bases

An agent that guesses at policy is a liability with good grammar. Generic RAG bolted onto a chatbot retrieves the wrong clause from a stale PDF and states it with confidence. Grounding here is first-class: workers retrievebefore they answer, retrieval runs semantic and full-text search fused together, the corpus is read-only to every run — and when your documents change, the answers change with them.

Create a knowledge base Tables: read-write state
At a glance
  • Retrievalvector + full-text, RRF-fused
  • Whenat run time, before the answer
  • Answersdrawn from retrieved passages
  • Ingestionauto-chunked · deduplicated
  • Deletionpropagates to the index
  • To workersread-only, always
  • Updatesre-index, no redeploys
IN A SOLUTION PACK

In a pack, knowledge bases arrive stocked: sources indexed and wired to the agents that need them.

See Solution Packs →
app.turtlecoworker.com/knowledge
The knowledge base library: one card per base with document and chunk counts, sync health, and the workers attached to each
The library: every base with its corpus size, its sync health, and the workers grounding on it.
Why it's built this way

A confident answer without
a source is a liability.

The failure isn't that ungrounded models are wrong often — it's that they're wrong fluently. Invented policy, a stale price, the wrong clause of the right document, delivered in the same confident register as the truth. Nobody catches it until it's been said to a customer.

So grounding here isn't a bolt-on. Retrieval runs before the answer, searches by meaning and by exact term, and the answer draws on passages you can check against the source. The corpus is read-only to every run, deduplicated as it's maintained, and honest about deletion — what it holds is exactly what your workers can say.

See it work

Five ways grounding pays off.

Each is the same mechanism — retrieve first, answer from the retrieved text — applied where a wrong answer costs real money.

A customer asks about a refund past the 30-day window. An ungrounded model improvises something plausible. A grounded worker retrieves the actual clause and answers from it.

01Both searches run

Vector search finds passages about refund timing; full-text search pins the exact terms — '30 days', the policy section number. RRF fuses the rankings.

02The reply is drafted from the retrieved text

The worker answers from the refund-policy manual's own words, citable to the passage — not from what refund policies usually say.

03Every channel answers the same

All support workers on the base ground identically, so the policy is stated once, correctly, everywhere.

2
searches behind every retrieval — semantic and full-text — fused so the exact clause outranks the plausible one.
How it's embedded

Ground every worker in the same truth.

Bring your knowledge in once; every agent, team and employee retrieves from it at run time — and none of them can write to it.

You connect
PDFs & docsWebsites (crawled)Google DriveNotionPasted text
internal & external: your systems
Knowledge Bases
your documents, retrievable by meaning and by exact term
Your workforce uses it
Agentsretrieve before answering
Teamsa shared grounding layer across sub-agents
Employeesground replies in the corpus, read-only
Anatomy of the grounding layer

Your documents in. Defensible answers out.

Six properties that separate a grounding layer from RAG bolted onto a chatbot.

01 · Grounding

A worker that retrieves before it answers.

An ungrounded model answers policy questions from its training data — fluently, confidently, and sometimes wrong. Attach a knowledge base and the worker searches it at run time first: the passages that actually match the question are retrieved and the reply is drafted from them, with the retrieved material available as evidence. The answer stops being an assertion and becomes a claim with a source.

  • Retrieval happens at run time, before the answer — not as an afterthought
  • Answers draw on specific retrieved passages, citable back to the source
  • Every agent, team and employee attached to a base grounds the same way
A worker's reply alongside the retrieved passages it drew on: the answer text and the matching source chunks with their document names
The answer and its evidence, side by side
02 · Hybrid retrieval

Semantic search that doesn't miss the exact term.

Pure vector search is famous for a specific failure: it retrieves what's similar and misses what's exact — the SKU, the clause number, the error code. Retrieval here runs two searches in parallel: dense vector search for meaning, and full-text search for the literal terms. The two candidate lists are fused with reciprocal-rank fusion, so a chunk that both searches agree on outranks a chunk only one found.

  • Vector + full-text search in parallel, not vector alone
  • Rankings fused with reciprocal-rank fusion (RRF) — agreement wins
  • Exact identifiers, clause numbers and codes surface alongside paraphrase matches
A retrieval inspection view: the query, the fused result list, and per-chunk indicators of vector and full-text match
Two searches, one fused ranking
03 · Your content

The corpus is your material, not the model's memory.

Point a base at what you already have: pasted text, uploaded files (PDF, DOC, TXT, MD), a crawled website, or synced sources from Google Drive and Notion. Everything is chunked and embedded automatically — there is no pipeline to build and no index to tune. Mix source types in one base and scattered institutional knowledge becomes one searchable thing.

  • Files · websites · pasted text · Drive and Notion syncs, mixed in one base
  • Automatic chunking and embedding — no RAG pipeline to build or maintain
  • New content is searchable once processed, without touching any worker
A knowledge base's source list: uploaded PDFs, a crawled site and a synced source, each with processing state and chunk count
One corpus, mixed sources, each row indexed on its own
04 · Deduplicated ingestion

Re-syncing doesn't multiply your documents.

The quiet way RAG rots: every re-upload and re-sync adds another copy, and retrieval starts surfacing three versions of the same paragraph. Ingestion here fingerprints content by hash — an unchanged document is recognized and skipped, and a re-sync re-processes only what actually changed. The index stays one-copy-per-truth instead of accreting duplicates.

  • Content fingerprinted on ingestion; unchanged documents are skipped
  • Re-syncs re-embed only what changed — no duplicate chunks piling up
  • Retrieval quality holds as the corpus is maintained, instead of degrading
A re-sync result on a base: changed documents re-processed, unchanged documents marked skipped as already indexed
A re-sync that touches only what moved
05 · Deletion that propagates

Remove a document and its chunks actually leave.

In a bolted-on RAG stack, deleting a file often deletes the file — and leaves its embedded chunks answering questions for months. Here deletion propagates: removing a source removes its vectors from the index, so a retired policy can't be retrieved and quoted after it's gone. What the corpus says is what your workers can say.

  • Deleting a source deletes its vectors — not just its listing
  • A retired document cannot be retrieved into an answer
  • The index reflects the corpus as it is, not as it accumulated
Deleting a source document from a base, with the confirmation showing its indexed chunks will be removed from retrieval
Gone means gone: the chunks leave with the document
06 · Read-only by design

Workers search it. Nothing a run does can write it.

A knowledge base is read-only at run time — workers retrieve and cite; no run can mutate the corpus. That's a governance property, not a limitation: one misbehaving or prompt-injected worker can never poison the reference the rest of the workforce depends on. Retrieved chunks are also among the untrusted content the platform's injection shield can screen before they re-enter a model's context. Data workers should read and write lives in Tables, under per-verb permissions.

  • Read-only at run time — no run can modify the corpus
  • One worker can never corrupt the reference the others ground on
  • Updating the corpus is a human, auditable act — not a side effect of a run
A knowledge base card showing its read-only status and the roster of agents, teams and employees attached to it
One curated truth, many readers, zero run-time writers
One question, worked through

A refund question hits a grounded support worker.

A support org grounds its workers in two bases — the product docs and the refund-policy manual. A customer asks for a refund 45 days after purchase. Here's what the system does with that question.

Retrieve
Two searches run against the policy base
Dense vector search finds passages about refund eligibility and timing; full-text search pins the exact terms — "45 days", "refund", the section identifiers. Neither search alone is trusted with the answer.
Fuse
The rankings merge with RRF
The candidate lists are deduplicated and fused with reciprocal-rank fusion. The clause governing refunds past the 30-day window — which both searches surfaced — outranks the adjacent, semantically-similar clause about exchanges that a pure vector search might have led with.
Answer
The reply is drafted from the retrieved text
The worker states the policy as the manual actually writes it, drawing on the retrieved passages — traceable back to the document. Not what refund policies usually say; what this one says.
Hold
The corpus stays untouched
Nothing in the run wrote to the base — no run can. The retrieved chunks are themselves untrusted content the platform's injection shield can screen before they re-enter the model's context.
Update
Next quarter, the policy changes
The team replaces the manual and re-syncs. The changed document re-embeds; unchanged ones are skipped by content hash; the old version's chunks leave the index. Every support worker answers from the new policy on the next question — no redeploys, no agent edits.
A support worker's answer to a refund question with the retrieved refund-policy passages beside it, source document and section visible
The reply and the clause it stands on, from the manual itself
Properties you get

Eight properties of first-class grounding.

Run-time retrieval

Workers search the base before answering; replies draw on retrieved passages, traceable to their source.

Hybrid search + RRF

Vector and full-text search run in parallel and fuse with reciprocal-rank fusion — meaning and exact terms both surface.

Any source

Files, crawled websites, pasted text, Drive and Notion syncs — chunked and embedded automatically, mixed in one base.

Dedup ingestion

Content is fingerprinted; unchanged documents are skipped on re-sync, so the index never accretes duplicates.

Deletion propagation

Removing a source removes its vectors — a retired document can't be retrieved into an answer.

Read-only corpus

No run can write the base. Updates are deliberate, human acts; the reference can't be poisoned mid-run.

Re-index without redeploys

Update the corpus and re-sync; every attached worker answers from the new material with no config change.

Shared grounding

One base attaches to many workers — agents, teams, employees — so the same question gets the same grounded answer.

The payoff
2
searches behind every retrieval — vector and full-text — fused with RRF so exact terms and meaning both count.
0
run-time writes: the corpus is read-only to every worker, so no run can poison the reference.
0
redeploys to update what the workforce knows — change the corpus, re-sync, answers follow.
1
copy per document: ingestion is deduplicated by content hash, and deletion propagates to the index.
From the live catalog

Built on Knowledge Bases.

All templates
Procurement Ops Control Tower Pack
Solution Pack · Operations

End-to-end procurement operations solution pack with vendor registry, purchase request review, contract path assessment, embedded review team, and AI employee coordination.

3 agents3 tables1 employee
Official · ~35 min
CA Firm: Compliance & Practice Pack
Solution Pack · Professional Services

Complete operating system for a Chartered Accountant practice. Tracks clients, engagements, statutory deadlines, and IT/GST notices. Includes AI agents for notice triage, GST reconciliation, filing reminders, and client communication. Comes with an AI Employee (Priya) who coordinates compliance work end-to-end.

4 agents5 tables1 employee
Official · ~15 min
Recruiting and Staffing Ops
Solution Pack · Recruiting

Move candidates faster without cutting corners on fair hiring. Riley, your AI recruiting coordinator, screens each new candidate against the job's must-haves with must-have-by-must-have reasoning, coordinates interview scheduling by drafting availability requests, drafts honest candidate outreach and status updates, builds submittal packages for hiring managers or clients mapping experience to requirements, and gives the team a daily pipeline read. Screening never considers anything beyond skills and qualifications, and it never rejects a candidate or extends an offer; those stay human decisions. Everything else is draft-and-approve: candidate messages are prepared for a human to send, and interview times are proposed, never confirmed, by the agent. Four tables hold your job orders, candidates, interview scheduling, and pipeline metrics. A knowledge base holds your screening standards, submittal format, communication voice, and compliance guardrails, which every assessment and message follows. Automations included: new candidates are screened on arrival, plus an optional daily pipeline digest. Works out of the box with the roles and candidates you add; connect an ATS or job board later to sync candidates, and Gmail and Calendar to send outreach and confirm interviews from the platform. Best first step: replace the placeholder screening standards and compliance rules with your own and add an open job.

5 agents4 tables1 employee
Official · ~20 min
Sales Engine
Solution Pack · Sales

A complete outbound-to-pipeline sales engine for a small team. Define your ideal customer profile once in the ICP Profiles table and paste your product details into the Product Knowledge Base, then Sasha, your AI SDR, discovers and vets target accounts, enriches prospects, researches companies, scores leads, and drafts outreach, all grounded in your data. Inbound leads and your deal pipeline live in tables the founder can watch. Automations included: new prospects are auto-enriched on arrival, and an optional daily discovery run finds fresh accounts from your Active ICP. Requires an LLM provider plus the Apollo, Serper, Exa, and Google Search connectors. Replace the sample knowledge base content and the example ICP row with your own.

6 agents5 tables1 employee
Official · ~20 min
Customer Support Ops
Solution Pack · Support

Answer more support tickets, faster, without losing the human touch. Sam, your AI support specialist, classifies every incoming ticket by category, sentiment, and priority, drafts an accurate reply grounded only in your knowledge base, and escalates anything it is not confident about instead of guessing. It matches recurring problems to approved canned responses, mines new tickets into known issues so answers stay consistent, tracks the feature requests buried in tickets, and produces a weekly insights digest of volume, deflection, and top drivers. Everything is draft-and-approve: replies are prepared for a human to review and send, and sensitive tickets (anger, churn, refunds, account deletion, legal or privacy) are always escalated. Four tables hold tickets, known issues, feature requests, and daily metrics. A knowledge base holds your help-center content and support voice, which every reply cites. Automations included: a reply is drafted the moment a ticket arrives, plus an optional daily sweep of anything still unanswered. Works out of the box with no external tool; connect Gmail later to send from the platform and Slack for the digest. Best first step: replace the placeholder knowledge base with your real help-center articles or URLs.

5 agents4 tables1 employee
Official · ~20 min
Sales Engine Pro
Solution Pack · Sales

A complete, full-lifecycle sales engine for a growing team, spanning outbound prospecting and account management across one shared data layer, with a companion inbound concierge. Outbound: Sasha, your AI SDR, discovers and vets accounts, enriches prospects, scouts buying signals, researches companies, scores leads, and drafts cold email, LinkedIn, and nurture outreach. Account management: Maya, your AI Account Manager, qualifies opportunities, drafts and reviews proposals, flags pipeline risk, forecasts renewals and expansion, and keeps the CRM clean. Seven tables hold ICP profiles, target accounts, prospects, website leads, CRM contacts, opportunities, and customer accounts. Automations included: new prospects are auto-enriched on arrival, and an optional daily discovery run finds fresh accounts from your Active ICP. For the inbound engine, install the companion Website Sales Concierge team template, which routes visitor questions to product, pricing, and objection specialists and captures leads into the Website Leads table. Requires an LLM provider plus the Apollo, Serper, Exa, and Google Search connectors. Replace the sample knowledge base content and the example ICP row with your own. Outreach and proposals are drafted for a human to review and send.

15 agents7 tables2 employees
Official · ~25 min
Questions

The details, up front.

How is this different from 'RAG support' every AI product claims?
Three verifiable ways. Retrieval is hybrid — dense vector search and full-text search in parallel, fused with reciprocal-rank fusion — so exact terms like clause numbers and SKUs surface, not just semantic neighbors. Ingestion is deduplicated by content hash, so maintenance doesn't degrade the index. And deletion propagates to the vector store, so retired documents actually stop answering. Bolted-on RAG typically has none of the three.
Why does hybrid retrieval matter for real documents?
Because business questions hinge on exact strings. 'What does section 4.2 say about refunds after 30 days' contains an identifier and a number that pure vector search treats as noise. Full-text search pins those exact terms; vector search catches the paraphrase; RRF fusion ranks highest the chunks both agree on. The wrong-clause-stated-confidently failure is precisely what this addresses.
Can an agent write to a knowledge base?
No. Bases are read-only at run time by design — workers retrieve and cite, and nothing a run does can mutate the corpus. That means one compromised or misfiring worker can't poison the reference everyone else depends on. Corpus changes are deliberate acts by people. For state agents should read and write, use Tables, where access is granted per verb.
What happens when a policy document changes?
You update the source and re-sync — no redeploys, no worker edits, no prompt updates. Ingestion fingerprints content, so only the changed documents are re-processed; unchanged ones are skipped. Every worker attached to the base answers from the new material on its next retrieval. And if a document is removed, its vectors are removed with it.
How do I know an answer came from the corpus and not the model?
Retrieval is passage-level: the worker draws on specific retrieved chunks, and the answer is traceable to the documents they came from. That's what makes a grounded answer auditable — the question is not 'does the model seem right' but 'is this what the cited document says', which anyone can check.
What content can I bring in?
Pasted text, uploaded files (PDF, DOC, TXT, MD), crawled websites, and synced sources from Google Drive and Notion — mixed freely in one base. Everything is chunked and embedded automatically; there is no embedding pipeline to build, tune or maintain.
Next rung on the ladder

Knowledge is what workers read. Tools are how they act.

Tools & Integrations Governance