Appearance
Configuration
Everything on this page lives under Settings → Configuration, which is the screen with the most levers on it and the one most worth understanding before you pull any of them. Changes save immediately and take effect on the next request: nothing here needs a restart.
Three of these settings change how documents are indexed rather than how they are searched, so they only affect documents ingested after the change. Those say so explicitly. If you change one and expect existing knowledge bases to behave differently, re-index them.
Start by changing nothing
The defaults are the values this platform was built and tested against. The settings most worth revisiting for a new deployment are the default model, the context window (which has to match the model you actually serve), and tools that ask first. The rest reward being left alone until you have a specific complaint to fix.
Platform
Document upload limit
Default: 50 MB. The largest document anyone may upload. Anything bigger is refused before it is stored, so an oversized file costs you nothing but the upload.
Raise it if your knowledge bases include large scanned PDFs or long reports. The cost of raising it is disk and ingestion time per file, both of which scale roughly with the number you let through.
Image upload limit
Default: 10 MB. The same cap for images attached to chats or imported into knowledge bases.
Images are kept separate from documents because they cost more than a document of the same size: an image has to be described by a model before it can be searched, which is slower and uses more of the model's budget than reading text does.
Models
Default model
The model that answers when a chat does not name one of its own, and the one that writes research reports. It must be a model your provider actually serves.
Individual agents can name their own model, so this is the fallback rather than a global rule.
Temperature
Default: 0.8. How much the model may vary its wording, from 0 to 1.
At 0 the same question gets nearly the same answer every time, which is what you want for factual lookup and anything that will be cited. Around 0.7 the phrasing loosens up, which reads better when the model is drafting prose. Values above 1 are refused, because the models this platform is built around stop being useful up there.
If your users complain that answers feel repetitive, this is the setting they are describing. If they complain that the same question gives different answers, this is also the setting they are describing, in the other direction.
Context window
Default: 50,000 tokens. The most the model may be sent in one request, counting the system instructions, the conversation so far, and any output from tools.
Set it to what your deployed model actually accepts. Too high and requests exceed what the model can take. Too low and older messages are dropped to fit when they did not need to be, which the user experiences as the assistant forgetting something they said ten minutes ago.
Retrieval
These settings decide what a search finds and how much of it reaches the model. They are where answer quality is usually won or lost, well before the choice of headline model.
Embedding model
The model that encodes documents and questions into vectors for semantic search.
Changing this means re-indexing everything
Vectors made by one embedding model are meaningless to another, and the new model must produce vectors of the same width as the ones already stored. Changing it requires re-ingesting every knowledge base. Plan it as a maintenance task, not a quick edit.
Reranker model
A cross-encoder that re-reads each retrieved passage against the actual question and rescores it, so the best few are kept rather than the ones that merely shared vocabulary. This matters more for answer quality than most people expect.
Set to No reranking and search ranks by keyword and vector fusion alone. If a configured reranker fails mid-search, the fused order is used instead, so a reranker outage degrades search rather than breaking it.
Reranker score floor
Default: 0, which keeps everything. Passages the reranker scores below this are dropped rather than shown.
Scores run from 0 to 1, but where the useful cut sits depends entirely on the model. A capable reranker scores genuinely relevant passages above 0.9 and irrelevant ones near zero, so a floor of 0.3 is comfortably safe. A small reranker may score even an exact match around 0.2, where a floor of 0.3 would throw away every result you have.
So: start at 0, look at the scores your deployment actually produces, then raise it gently. The floor only applies to passages the reranker scored, so it can never empty a search the reranker never saw.
Passages per search
Default: 10. How many passages come back from one knowledge base search.
The model pays for every passage in its context. Past a handful, extra passages dilute the answer rather than improving it: the relevant one is still there, but it is now one of twenty. Raise this if your documents chunk into unusually small pieces.
Reading window
Default: 2. When the assistant reads around a search result to get context, this is how many passages it gets on each side.
Two is enough to recover a sentence that was cut at a chunk boundary. Dense documents whose meaning runs across pages may justify more.
Reading window limit
Default: 10. The most passages one read may return on each side, whatever the assistant asks for.
This is the ceiling that stops an agent pulling an entire book through a tool meant to fetch a paragraph.
Chunk size
Default: 512 characters. How much text one chunk holds when a document is split for indexing. Splitting prefers headings and paragraph breaks, so chunks usually end where a human would end them.
Smaller chunks pinpoint an answer more precisely but lose the context around it. Larger chunks keep context but blur what actually matched. 512 characters is roughly a short paragraph.
Applies to documents ingested after the change. Re-index anything already stored.
Chunk overlap
Default: 64 characters. How much each chunk repeats from the end of the one before it, so a sentence straddling a boundary appears whole in at least one of them.
Ten to twenty per cent of the chunk size is typical; the default is twelve. Overlap costs a little storage and a little embedding time.
Applies to documents ingested after the change. Re-index anything already stored.
AI-written search context
Default: off. Every passage is indexed alongside a line saying where it came from, built from the file name and the headings above it. Switch this on and the chat model also reads the document and writes a description of what each passage is about.
It helps when documents have poor structure, where headings and file names say little. It makes ingestion slower and dependent on the chat model being available, though if the model cannot be reached, ingestion falls back to the built-in line rather than failing.
Applies to documents ingested after the change.
Research
These two sit under Retrieval on the screen, because they govern the long-form research pipeline that retrieval feeds.
Research time limit
Default: 60 minutes. How long one research run may take.
A research job decides for itself how many sections to write and how often to revise them, so a poor plan or a model that will not stop can keep one going indefinitely. This is the bound: from starting a job, or resuming it after an approval, until it finishes or stops for a person.
Time spent waiting for somebody to approve a plan does not count against it. A job parked overnight on an approver is not burning its budget.
Research revisions
Default: 3. How many review-and-rewrite rounds a report goes through before it is accepted as it stands.
Each round is another pass over the draft, so each one costs time and model capacity. Two or three is typical. Zero means the first draft is the final one.
Tools
Tool calls per message
Default: 5. How many tool round-trips an agent may make in response to one message before it has to answer in words.
This is the brake on an agent that would otherwise keep calling tools indefinitely. Raise it for agents that legitimately compose many calls per turn, such as one that queries several systems before it can answer.
Tools that ask first
The tools that stop and ask a person before they run. The agent pauses mid-turn, shows what it is about to do and with what arguments, and waits for an answer in the conversation.
Anything that writes, sends, or cannot be undone belongs on this list: deletions, changes to records in other systems, and anything that sends a message to a human being outside the platform. Approvals are recorded in the audit log like everything else.
The cost of being liberal here is a few extra clicks. The cost of being stingy is an email nobody meant to send.
Settings without a screen
Some settings are deliberately not on the Configuration screen, either because they are set once at delivery or because getting them wrong is disruptive enough that a confirmation step is worth the inconvenience. Your delivery engineer can change any of them through the management API, and they take effect without a restart.
| Setting | Default | What it does |
|---|---|---|
| Audit retention | 90 days | How long audit entries are kept before ageing out. See Audit logging. |
| Feedback retention | 90 days | How long thumbs up and down on answers are kept. |
| Session lifetime | 7 days | How long a sign-in lasts before the person has to sign in again. |
| General rate limit | 60 per minute | Requests one address may make per minute across the platform. |
| Sign-in rate limit | 30 per minute | Sign-in attempts one address may make per minute. |
| Upload rate limit | 30 per minute | Uploads one address may start per minute. |
| Export page size | 500 | How many records are written per batch when exporting. |
| Cleanup interval | 15 minutes | How often orphaned files and expired records are swept up. |
| Unclaimed upload lifetime | 60 minutes | How long a file uploaded but never attached to anything is kept before collection. |
The rate limits are the ones most likely to need attention. The defaults suit ordinary human use; a deployment where a single address fronts many users, such as one behind a shared proxy, may need the general limit raised. Automated test suites driving the platform through one address will certainly need it.
What to change, and when
| Symptom | Setting to look at |
|---|---|
| Answers cite the wrong passage, or miss an obvious one | Reranker model, then passages per search |
| Answers are cut off mid-thought, or context is lost | Chunk size and chunk overlap, then re-index |
| The assistant forgets what was said earlier in a long chat | Context window |
| The same question gives noticeably different answers | Temperature |
| Search returns plausible but irrelevant passages | Reranker score floor, raised gently |
| Documents with poor headings retrieve badly | AI-written search context, then re-index |
| An agent loops on tools instead of answering | Tool calls per message |
| Something was sent or deleted that should have been checked | Tools that ask first |
| Research runs never finish | Research time limit, then research revisions |