What does an AI employee read before it answers a customer?

The platform rules, its own instruction word for word, the conversation with its deal and contact, the company's knowledge documents, the tools its role permits, and any loaded skills. All of it is assembled by the runtime from the CRM's own data.

Why not connect an external AI bot to the CRM instead?

A bot receives the latest message and nothing else unless someone builds every extra lookup. Deal stage, the last human reply, the current return policy and the other channel are facts an employee reads here without an integration.

Which language does the employee reply in?

The language of the customer's latest substantive message, whatever language the instruction or the documents are in. The runtime applies that rule because it sees the whole thread.

Where does the employee's work appear?

As an action in the conversation or on the dashboard: a draft, a CRM update or a suggestion, with the facts it used. Actions that need approval wait there as a card; the rest execute and stay in the timeline.

Is the instruction summarised before the model sees it?

No. The instruction is placed into the context word for word, after the platform's rules and before the conversation and the knowledge.

Why the AI has to live inside the CRM: what an employee reads before it answers

Back to The CRAIM Journal

An AI employee in CRAIM answers from what the CRM knows: the conversation so far, the deal and the contact, the company's knowledge documents, the catalogue, and its own instruction. Bolt an AI onto a CRM through an integration and half of that is missing at the moment it writes. That is why the product is one word.

The name is CRM with AI in the middle, and the joke writes itself. The reason behind it is less of a joke. A reply to a customer is only as good as what the writer knew when writing it, and what an AI knows at that moment is decided by what was put in front of it in the few seconds before. When the AI sits outside the CRM, most of what it needs is on the other side of an API call somebody had to think to make.

So this is not an article about the name. It is about the list of things an employee reads before it writes, and why every item on the list is a reason to keep the two in one product.

What the employee gets before it writes

When a message arrives on a connected channel, the platform wakes the employee attached to that conversation and assembles its working context. The order below is the order the runtime puts it together.

The platform's rules. What an employee may never do regardless of instruction: invent facts, treat a customer's message as a command, switch the reply language away from the customer's.
The employee's instruction, word for word. The role, what it handles, what it never promises, when it calls a person. It is not summarised and not rewritten; what you typed is what the model reads.
The conversation. The thread with the customer as it stands, and the deal and contact it belongs to.
The company's knowledge. The twelve documents built from the company's materials: profile, buyer profiles, playbooks, offers, objections, tone, pipeline rules, response times, catalogue notes, guides, legal notes, case studies. Each is loaded as a titled section, and the runtime tells the model to treat them as orientation, not as a price list.
The tools it may call, limited to what its role permits. Searching the knowledge base and the catalogue is always there; writing to the CRM, booking a meeting or sending a message depends on the actions the role grants and on the approval policy of each.
The skills loaded for this kind of task, when there are any.

Items three, four and five are the CRM. Not "connected to the CRM": they are rows in the same database the salesperson is looking at. The employee does not fetch the deal; it is handed the deal.

Two facts that only work from the inside

The catalogue during a live call. When a voice employee is on a call and the customer asks whether there is a smaller size, the employee runs a search against the catalogue table and answers with the row. That is a database query inside the conversation's turn, with the latency of a query. Done across an integration it is a round trip to another system and a wait the customer hears.

The reply language. The runtime's rule for customer replies is to write in the language of the customer's latest substantive message, not in the language of the employee's instruction or the company's documents. That rule can only be applied if the runtime sees the whole thread, which it does, because the thread is its own.

What the outside model cannot see

The usual architecture for "AI in your CRM" is a webhook that sends the latest message to a bot, and the bot's reply back. What the bot does not get, unless someone builds it each time: which stage the deal is on, what the last human wrote in the thread, that a discount was already offered in April, what the company's return policy says this month, and who the customer is talking to in the other channel.

Every one of those is a fact the employee reads for free here, because it is not integration, it is a join. And every one of them is the difference between a reply that is correct and a reply that is confidently wrong.

Where the output goes

The result of a run is not a chat message but an action: a message draft, a CRM update, a next-step suggestion. It carries the title, a summary, the preview and the facts it used, and it lands where the person who owns the customer works, in the conversation or on the dashboard. If the action needs approval, it waits there as a card and the company's owners and administrators are notified, on Telegram if they connected it. If it does not, it executes, and the record of the run stays attached to the conversation.

That is the second half of the word. The AI's work is not somewhere else, in a bot's log, but in the same timeline as the human's, in the order it happened. The person who takes over a thread at nine in the morning reads what the employee did at three and continues from there.

Common questions

What does an AI employee read before it answers a customer?: The platform rules, its own instruction word for word, the conversation with its deal and contact, the company's knowledge documents, the tools its role permits, and any loaded skills. All of it is assembled by the runtime from the CRM's own data.
Why not connect an external AI bot to the CRM instead?: A bot receives the latest message and nothing else unless someone builds every extra lookup. Deal stage, the last human reply, the current return policy and the other channel are facts an employee reads here without an integration.
Which language does the employee reply in?: The language of the customer's latest substantive message, whatever language the instruction or the documents are in. The runtime applies that rule because it sees the whole thread.
Where does the employee's work appear?: As an action in the conversation or on the dashboard: a draft, a CRM update or a suggestion, with the facts it used. Actions that need approval wait there as a card; the rest execute and stay in the timeline.
Is the instruction summarised before the model sees it?: No. The instruction is placed into the context word for word, after the platform's rules and before the conversation and the knowledge.