Settings vs Knowledge

Sarudo has two separate places where it remembers things: the knowledge base and the settings store. They look similar from the outside — both are ways to tell your AI employee something and have it remember for later — but they are optimized for different kinds of information, and using the right one matters for reliability. The knowledge base is for facts about your business: pricing, decisions, contact preferences, style guides, what you learned in a meeting. The settings store is for operational state: the ID of the active content-calendar sheet, the current blog voice, which CMS your blog is on, your timezone. The rough line is "knowledge" vs "configuration."

The knowledge base is vector-indexed, which is why semantic search works so well — "what is ClientCo's billing preference?" finds the right fact even if you never used the word "billing preference" when you stored it. But that same semantic-fuzzy matching is a liability for operational state. If three near-duplicate knowledge entries existed for "active sheet ID" (one from last month, one updated this month, one from a bug you fixed), a semantic query might return any of them on any given run, and a workflow that wrote to the wrong sheet could silently lose data. The settings store exists specifically to avoid that failure mode. It is a flat key-value table keyed on (category, key), indexed for exact lookup, with no fuzzy matching and no ranking. You always get exactly the value you stored, or a missing-key response — never a near-miss.

You rarely need to decide yourself — your AI employee picks the right store based on what you are telling it. "We just agreed on a $175 hourly rate for new enterprise clients" is a fact with context and goes in the knowledge base. "My timezone is Asia/Kolkata" is operational and goes in settings. "Use this sheet for next month's content calendar" is operational and goes in settings. "The launch is set for June 15" is a fact and goes in the knowledge base. The broad heuristic: if asking "what is X" should return one exact answer, it belongs in settings. If it should return "here is what I know about X, with context", it belongs in knowledge.

Settings are organized by category + key. Common categories include `client` (company name, timezone, working hours, primary email, blog URL), `content_calendar` (active sheet ID, blog voice fact reference), `voice` (default voice persona for calls), and per-integration categories like `stripe`, `notion`, `publer` for configuration flags specific to each integration. Your AI employee can list settings by category if you ever want to see them — "show me every setting under client" returns the full list with values.

If an earlier conversation stored something in the knowledge base that really belongs in settings (for example, an "active sheet ID" that got written as a fact), it can be migrated. Your AI employee has an explicit migrate endpoint for this — it reads the fact from the knowledge base, writes it to the settings store, and optionally removes the original knowledge entry to prevent the duplicate-entry drift. This is a maintenance operation you rarely need to think about, but if a workflow ever fails because of a stale knowledge entry that should have been a setting, the fix is a single conversational instruction.