AI Agents
Independently configurable AI assistants that answer questions grounded in your documents, each with its own personality, knowledge scope, and behavior rules.
What does your HR assistant know? What tone should your technical support bot use? Which documents should your sales FAQ search - and which should it ignore?
I designed agents to be independently configurable because one-size-fits-all never works. Every team has different content, different users, different rules. When I was building Knowably for a government project, the legal team needed citations in a specific format while the public-facing FAQ needed plain Dutch. One agent configuration cannot serve both.
An AI agent is a configurable assistant that answers questions grounded in your documents. Each agent has its own personality, knowledge scope, behavior rules, and search strategy. You create one, point it at the right knowledge bases, and it starts answering questions from those documents.
One workspace can run multiple agents. An HR agent that only sees policy documents. A technical support agent that searches product docs. A sales FAQ that covers pricing and feature sheets. Same platform, different purposes, completely separate configurations.
Agents sit on top of the RAG pipeline and tie together everything: knowledge bases, search tuning, response behavior, and security guardrails - all in a single configurable unit.
Two Ways to Create an Agent
Quick Create
Most teams should start here. I did too, when prototyping new agents.
Provide a name. Select one or more knowledge bases. Optionally connect MCP servers. Done.
Knowably runs an auto-configuration pipeline that samples representative content from your linked knowledge bases, generates a description using LLM analysis, and produces suggested starter queries based on the actual content. The agent card shows a "Configuring" status during this process and switches to "Ready" when it finishes.
Everything else uses sensible defaults. Start there. Tune from real user questions, not guesses.
Advanced Create
Full access to every setting from the start.
For teams who know exactly what behavior they want before going live. Every parameter in the agent configuration guide is available immediately. System prompts, search weights, reranking thresholds, security guardrails - all configurable before the first conversation.
Knowledge Scope and Tools
The knowledge base selection is the most important decision you make. It defines what the agent knows.
One agent can search across several knowledge bases simultaneously. An engineering agent might search both your GitHub documentation and your Confluence technical specs. A customer support agent might combine product docs with your internal troubleshooting guides.
The boundary works both ways. An HR agent that only sees policy documents cannot accidentally surface engineering documentation. This scoping is deliberate - it keeps answers focused and prevents confusing cross-domain results.
Beyond document search, agents can connect to MCP servers for external tool capabilities. This lets them take actions, not just answer questions. Query a database. Look up a customer record. File a ticket. The agent decides when to use a tool based on the conversation context.
System Prompts
How should your agent behave? What should it say - and what should it never say?
The system prompt is your primary lever for response quality. It defines the agent's role, tone, language, citation style, and rules. Be specific. "You are a helpful assistant" is not specific. "You are an HR policy advisor for Acme Corp. Answer in Dutch. Always cite the document name and section. Never speculate about policies not covered in the provided documents." That is specific.
I have seen well-written system prompts fix problems that no amount of search tuning could solve. If the agent keeps adding disclaimers you do not want, the system prompt is where you fix it. If responses are too long, tell the agent to be concise. The prompt shapes every response.
The no-retrieval prompt controls what happens when the agent finds no relevant documents. Without it, the agent will guess. With it, you define a clear fallback: redirect users, explain what the agent can help with, or say "I do not have information on that topic."
This is the difference between an agent that makes things up and one that knows its own limits. Keep this prompt tight and honest - users trust agents that admit what they do not know.
Query Understanding
What did the user actually mean?
Two features handle this, both enabled by default.
Multi-turn conversations make follow-up questions work naturally. When a user asks "What is parental leave?" and then follows up with "How long does it last?" - the agent reformulates that into "How long does parental leave last?" before searching. Without this, the follow-up searches for "how long does it last" with no context. The results are useless.
This reformulation uses the conversation history to resolve pronouns and implied references. It happens automatically. The user writes naturally, the agent figures out the intent.
Retrieval check determines whether a message actually needs a document search. "Hello" and "Thanks" get a direct response without triggering an unnecessary search. Same for "Can you help me?" or "What can you do?" - these are conversational, not informational. This keeps conversations natural and reduces latency on messages that do not need documents.
Query Reformulation
The user typed one thing. Your documents say it differently. Query reformulation bridges that gap before the search even starts.
Query Expansion
Query expansion adds synonyms and related terms to the user's query before searching. A user asks "remote work policy" - the agent also searches for "work from home," "telecommuting," and "flexible work arrangements." Your policy might be titled "Flexible Working Arrangement Guidelines." Without expansion, a search for "remote work policy" misses it entirely.
Document authors and document searchers rarely use the same words. I saw this pattern constantly when testing with real enterprise content. Technical writers use formal terminology. Users use everyday language. Expansion bridges that vocabulary gap.
You can provide custom expansion instructions and examples to teach the agent your domain terminology. Disabled by default. Enable it when your content uses varied terminology. In my experience, that is almost always.
The agent configuration guide covers the full parameter reference for query expansion, including how to write effective custom instructions.
Query Decomposition
Query decomposition breaks complex multi-part questions into separate sub-queries. Each sub-query searches independently. Results are combined.
"What are the benefits and eligibility requirements for parental leave?" becomes two focused searches: one for benefits, one for eligibility requirements. Each finds the right passages instead of one diluted search trying to match everything at once.
This is especially useful for comparison questions. "How does our sick leave policy differ from our vacation policy?" decomposes into targeted searches for each policy. Without decomposition, the search tries to match both concepts simultaneously and often returns mediocre results for both.
Disabled by default. Enable it when users frequently ask multi-part questions. The agent configuration guide explains the configuration options and gives examples of when decomposition helps most.
Hybrid Search
Semantic search understands meaning, but it misses exact terms. Product names, error codes, policy numbers - these need keyword matching that semantic search alone cannot provide. That is why Knowably uses hybrid search: a combination of BM25 keyword matching and semantic vector search.
Two configurable weights control the balance. The default is 80% semantic, 20% lexical - a split that works well for most teams. If your users search for specific identifiers or domain jargon, shift the balance toward keyword matching. Conversational, natural-language queries favor semantic search.
The agent configuration guide has the full parameter reference and recommended weight ranges for different content types.
Reranking and Filtering
You cast a wide net with retrieval. Reranking and filtering keep only the best results.
Knowably uses LLM-based reranking rather than cross-encoder models. The reason: each agent can have its own reranking prompt. You can tell the reranker to prioritize recent documents for one agent and prioritize technical depth for another. That per-agent customizability matters more than the speed difference.
When enabled, the reranker scores each retrieved chunk for relevance. The highest-scoring chunks survive. The rest get discarded before the agent ever sees them. You control the number of surviving chunks and the minimum score threshold.
The recommended strategy: retrieve many chunks, then rerank down to the best. In my experience, this "wide net then narrow" approach works better than retrieving fewer chunks without reranking.
Chunk filtering adds a second quality gate after reranking. An additional LLM pass removes generic introductions, table-of-contents fragments, and tangential content that scored well in retrieval but does not actually help answer the question. Enable it when your content has a lot of boilerplate.
Both are disabled by default. Both add processing time but improve relevance for larger knowledge bases. The agent configuration guide covers thresholds and tuning recommendations.
Generation and Response Behavior
These settings control what comes out the other end - response length, randomness, and tone.
My opinion: keep temperature at 0 for document-grounded answers. Zero means deterministic. Same question, same answer. You want accuracy, not creativity. I have not found a convincing reason to go above 0.3 for anything that needs to be factual.
Avoid commentary suppresses filler phrases. No "Great question!" No "I'd be happy to help!" The agent goes straight to the answer. I enable this on every agent I build. Professional responses do not need cheerleading.
Groundedness scores track how well each response is supported by the retrieved documents. This gives you a measurable quality signal beyond reading the answers yourself.
Full parameter reference with ranges and defaults in the agent configuration guide.
Security Guardrails
Public-facing agents need protection. So do internal ones in regulated industries.
I built the security pipeline while working on a government RAG project. When citizens are sending queries, you cannot afford to leak personal data or let prompt injections through.
Four guardrails, each independently toggleable:
PII detection scans incoming queries for personally identifiable information before they reach the language model. Regex-based pattern matching - deterministic, no probability scores. For PII, I want certainty, not confidence intervals.
Output PII filtering does the same in reverse. If retrieved documents contain PII and it leaks into the generated response, this filter catches it on the way out.
Prompt injection detection identifies attempts to override agent instructions. A configurable sensitivity threshold lets you tune how aggressive the detection is. For public-facing agents, keep it sensitive.
Chunk sanitization cleans retrieved content before it reaches the generation model. Removes zero-width characters, normalizes Unicode, and closes common attack vectors embedded in document content itself.
All guardrails are disabled by default. Public-facing or regulated environments should enable all four.
Embed Widget and Suggested Queries
Two features that complete the agent experience.
Suggested queries are starter questions shown when a user opens a new conversation. Up to four at a time. They lower the barrier to first interaction. Good ones are specific - not "Ask me anything about HR" but "What is the parental leave policy for full-time employees?" You can write them manually or let Knowably generate them from your content.
Embed integration deploys your agent as a chat widget on an external website. You control which domains can load the widget - deny by default. One script tag on your website and the agent is live. The embed runs in a sandboxed iframe with origin validation, so your agent only appears where you allow it.
Getting Started
Start with defaults. Let real users ask real questions. Then tune based on what you observe.
For the full settings reference with parameter ranges, defaults, and configuration recipes from real deployments, see the agent configuration guide.