Bot Operating Model

This page explains how Octocom's AI bot works from first principles — what it really is under the hood, what shapes its behavior, and, just as importantly, what it cannot do.

It's written for two kinds of readers:

Power users configuring their own bot who understand what a large language model (LLM) is but haven't been told exactly how ours is wired together.
AI agents reading this through Octocom MCP to understand what's possible before setting up or debugging a bot.

If you've ever wondered "can I just add a rule that tells the bot to check back in two hours?" or "does the bot know my whole catalog?" — this page answers those questions, and explains why the answers are what they are.

One architecture. At its core, the Octocom bot is a single thing: a flexible, agentic LLM loop with tool-calling. Everything on this page describes that one model. There's no second mode or hidden variant to reason about.

The core idea: it's an LLM loop

Strip away everything else and the bot is a straightforward loop, the same shape as any modern LLM agent:

A customer sends a message.
We call an LLM with three things: a system prompt (its instructions), the conversation so far, and a set of tools it's allowed to use.
The model thinks. It may call one or more tools — look up an order, search products, search the knowledge base — and we feed each tool's result back to it.
It can call more tools based on what it learned, looping until it has what it needs.
Finally it writes a text reply to the customer. That ends the turn.

That's it. There is no hidden machinery beyond this. The model reasons over its instructions and the conversation, optionally gathers information through tools, and produces a reply.

customer message
      │
      ▼
┌─────────────────────────────────────────┐
│  LLM call                                │
│  • system prompt (instructions)          │
│  • conversation history                  │
│  • available tools                       │ ◄────┐
└─────────────────────────────────────────┘      │
      │                                           │
      ├── wants to call tool(s)? ── run them ─────┘
      │        (loops, up to a limit)
      │
      └── writes text reply ──► sent to customer (turn ends)

A few consequences fall straight out of this shape, and they matter:

The bot only runs when a message arrives. The loop is triggered by an incoming customer message. Between messages, nothing is happening — there is no background process inside the bot watching the clock or waiting for events.
The loop is bounded. The bot can chain a number of tool calls within a single turn, but there's a hard ceiling (around ten tool-call rounds). It can't loop forever.
The model decides what to do. Within the rules you give it, the model chooses which tools to call and what to say. You shape that behavior through the system prompt; you don't script it line by line.

What's in the system prompt

The system prompt is where you control the bot. Octocom assembles it fresh for every response from a number of sections. Most are configurable; some are filled in automatically from runtime context.

Here are the sections that matter most when you're configuring a bot.

Persona and writing style (the preamble)

The top of the system prompt establishes who the bot is and how it should write. These are individual, separately editable instruction blocks — you can leave them on their sensible defaults or override any of them:

Task / persona — who the bot is and its core job (e.g. "You are a support agent for Acme").
Safety — high-level guardrails (stay on-topic, don't make unauthorized commitments).
Instruction following — how to prioritize between its various sources of truth.
Tone — e.g. "friendly and warm."
Writing style — separate styles for chat vs. email.
Output syntax — formatting rules (markdown, no raw HTML, etc.).
Language & grammar — reply in the customer's language, and so on.

Where to configure: Dashboard settings → AI & Automation → Configuration. Each of these is a field you can override; if you leave one blank, the bot uses Octocom's default for that block.

Bot rules

Bot rules are short, always-on behavioral guidelines injected directly into the system prompt — things like "always offer the newsletter discount to first-time buyers" or "never promise next-day delivery." Each rule is a title plus a block of instructions, and rules can be scoped to specific channels (web chat, email, etc.).

Rules are pure instructions. They guide the model; they don't run code and they don't grant the bot any new capabilities. (For when a rule is the right tool versus a workflow, see Workflows.)

Workflows — and where tools come from

Workflows are the bot's playbooks for specific situations ("customer wants to cancel an order"). They're covered in depth in Workflows, but there's one point that's essential to the operating model and easy to miss:

The bot's tools come from workflows. A workflow declares which actions it's allowed to use. Those actions only become available to the model once that workflow is in play. No workflow, no tool.

There are two ways a workflow puts its instructions and tools in front of the bot:

Embedded workflows are written directly into the system prompt every turn. Their instructions are always visible, and their actions are always available to the model.
Non-embedded workflows are not written out in full. The system prompt only lists them by name with a one-line "when to follow this." When the model decides one applies, it calls a built-in tool (getWorkflowInstructions) to load that workflow. Only then are the loaded workflow's instructions — and its actions — added to what the bot can use.

A workflow can have one variant or several (the variant chosen depends on conditions evaluated at load time). When a non-embedded workflow is loaded, the tools the bot gains are the ones belonging to the selected variant.

Loading happens once per conversation, not once per turn. When the bot loads a non-embedded workflow, that workflow's instructions and tools stay available for the rest of the conversation — the bot doesn't have to reload it on every subsequent message, and the tools it unlocked remain usable. So the set of available tools tends to grow over the course of a conversation as more workflows get pulled in.

The practical takeaway: at the very start of a conversation, the bot can only directly use tools from embedded workflows. Everything else has to be loaded first, but only once — after that it sticks around. This keeps the prompt small and focused early on, and it's why a brand-new conversation won't have every possible action sitting in front of the model.

Loading non-embedded workflows on demand is part of what makes the bot agentic — the model actively decides what to pull in, rather than being handed everything up front.

Knowledge base

The knowledge base is your bot's reference material. The most common source is articles (FAQ-style entries you write), but it can also be built from scraping your website or from uploaded documents — all of it ends up in the same searchable knowledge base.

The bot does not have this content memorized or dumped into its prompt. Instead it's given a single tool — searchKnowledgeBase — and a note about how much content exists. When it needs to answer something factual, it searches, reads the returned chunks, and answers from them. It retrieves knowledge on demand, the same way a person would search a help center. The bot is only as good as what it can find — if the answer isn't in the knowledge base, searching won't conjure it.

This section is automatic. As long as there is at least one knowledge base entry, the bot automatically gets this section and the searchKnowledgeBase tool — it's not something you toggle on. If the knowledge base is empty, the section and the tool simply don't exist for the bot.

Products

Product handling works similarly, and follows one of two styles depending on catalog size:

Small catalog (roughly a hundred in-stock products or fewer): a compact index of every product — id, name, price, a few flags, a short summary — is written into the system prompt. The bot still calls a tool (getProductsByIds) to pull full details before it talks about a specific product.
Larger catalog: nothing is listed inline. The bot gets search tools (searchProducts by semantic meaning, by keyword/SKU, or by URL) plus getProductsByIds to fetch full details. It searches, then hydrates.

The bot does not "know" your products. This is one of the most common misconceptions. For anything beyond a small catalog, the bot has no memorized list of products — it searches for them, just like the knowledge base. It only ever knows about the products it has surfaced through a search in the current conversation. If a search doesn't return a product, the bot effectively doesn't know it exists.

This section is automatic too. Just like the knowledge base, the product section and the product tools appear automatically as long as at least one product has been loaded through the product sync system. You don't toggle it on. If no products have synced, the section and the product tools simply don't exist for the bot.

Runtime context

Finally, the system prompt is topped up automatically with context for the current conversation: the current date and time (in your business timezone), the channel, and — when available — the customer's email, recent orders, active subscriptions, recently viewed products, and browsing history. You don't configure these; they're injected when present so the bot has situational awareness.

What this means: the bot's real limitations

Because the bot is just this loop — a model, a system prompt, and tools — its limitations follow directly. These trip people up constantly, so they're worth stating plainly.

The bot has no sense of elapsed time and can't act on its own schedule. You cannot write a rule or workflow that says "if the customer doesn't reply, follow up in two hours" and expect the core loop to honor it. The bot only runs when a message comes in. It has no timer, no background job, no way to wake itself up later. Telling it to "wait" or "check back" in an instruction does nothing — there's nothing in the loop that can carry that out.

The bot can only do what its tools allow. It cannot browse your admin panel, poke around your systems, or "go look it up" anywhere it hasn't been given a tool for. If there's no tool for an action, that action is impossible — no instruction can will it into existence. Its entire ability to do things (as opposed to say things) is the set of tools currently available to it.

The bot can't reach the open web. It has no general internet access. It knows what's in its prompt and what its tools return — nothing more.

The bot doesn't have your catalog or knowledge base memorized. As above, it searches. Its knowledge of your products and articles is limited to what it retrieves in the moment.

The bot can make mistakes. Like any LLM, it can occasionally get something wrong or state something that isn't supported by what it retrieved (a "hallucination"). Instructions reduce this; they don't make it impossible.

Instructions are guidance, not guaranteed code. Rules and workflow steps strongly shape behavior, but they're natural-language directions to a model, not deterministic program logic. Write them clearly and they'll be followed reliably; treat them as if-this-then-exactly-that code and you'll be surprised at the edges.

When you need something to be guaranteed, move it out of the prompt and into code. For anything that must hold every single time — strict authentication/identity checks, verifying state against a third-party system, enforcing exact time, monetary, or conditional logic — don't rely on instructions. Express it with condition providers (deterministic code that evaluates external state and decides which workflow variant the bot follows) and custom Python actions (real code the bot calls to do the work). The model still drives the conversation, but the parts that must be exact run as code, not as the model's judgment.

Important: these limits describe the core loop only

Everything above is about the bot's bare LLM loop in isolation — and that's deliberate. The point of this page is to give you an honest mental model of the engine itself.

Octocom layers features around that loop that extend or safeguard it. So several limitations stated above are true of the raw loop but not the full product:

"The bot can't follow up later" is true of the loop — but Octocom has dedicated features for scheduled follow-ups and event-driven automations that can make the bot reach back out when something happens. That capability lives outside the per-message loop, not in a bot rule.
"The bot can hallucinate" is true of the model — but Octocom runs validation and hallucination checks around the loop (for links, language, transfer commitments, and more) that catch and correct a class of these before a reply ever reaches the customer.

The distinction to hold onto: don't try to solve a loop-level limitation with a system-prompt instruction. A rule that says "respond later" won't work, because the loop has no concept of later. The right move is to reach for the feature built for that job. When you understand where the boundary of the core loop sits, it becomes clear which problems are solved by instructions and which need a dedicated feature.

Debugging: the loop is fully observable

Because the bot is just this loop — a system prompt, a set of tools, and the model's tool calls and reasoning — there's nothing hidden to guess at. Octocom exposes the complete picture of every single bot turn, so when a reply surprises you, you can see exactly what the model saw and did.

In the dashboard

Open a conversation, hover over any bot message, and click the bug icon ("Debug this message"). The Response debugging information panel shows everything about that turn:

System prompt — the full, exact system prompt sent to the model for that turn, with its token count and build time.
Tool calls — every tool the bot called, with its arguments, the result it got back, execution timing, and any internal logs from the call.
Reasoning — the model's reasoning trace for each LLM call, when the model exposes one.
Available actions — the complete set of tools the bot had access to on that turn, including each tool's description and parameter schema.
Response metadata — the message content and response time.

This is the same information described throughout this page, made concrete for one specific reply. If the bot "didn't know" about a product, you can confirm whether a search was even run; if it ignored a workflow, you can check whether that workflow's instructions and tools were actually present.

Through MCP

If you manage the bot through Octocom MCP, the same observability is available programmatically. For any bot message you can call:

get_response_system_prompt — returns the full raw system prompt that went into the LLM for that message.
get_response_tool_calls — returns the available actions, the tool calls (with arguments, results, and logs), and the per-call reasoning traces.

(To find the message ID, use get_conversation, which lists the conversation's messages along with bot-response debug info.) This lets an AI agent inspect a real turn end-to-end — read the exact prompt, see which tools were available, and trace what the bot called — when diagnosing behavior or verifying a configuration change.

You can see the full raw input. Between the system prompt and the conversation messages, the complete input that was fed to the LLM is recoverable — there is no opaque step between "what the customer said" and "what the bot replied."

Putting it together

To configure this bot well, think like this:

Shape who it is with the persona and writing-style blocks in the bot configuration.
Set standing guidelines with bot rules.
Give it playbooks and capabilities with workflows — remembering that tools arrive with workflows.
Let it find facts and products through the knowledge base and product search, rather than expecting it to "just know."
Reach for dedicated features — not prompt instructions — for anything the core loop can't do on its own, like acting later or guaranteeing correctness.

Get that model right and the bot's behavior stops being mysterious. Almost every "why did it do that?" or "why won't it do that?" comes back to one of the facts on this page: it's an LLM, looping over a system prompt and a set of tools, triggered one message at a time.

Bot Operating Model

On this page