When One Message Lists Ten Jobs: How AI in the CRM Handles Work It Cannot Do All at Once
Watch how people actually write to an assistant: not one request at a time, but a stream. Create an expense for the client meeting, move the deal to the next stage, remind me about the invoice on Friday, send the report to the accountant. Four things in one message, and each one is a different module with different rules. The expectation is also human: it should all be done, and it should not take a second attempt to explain anything.
A chat assistant usually answers such a message in one of two bad ways: it does the first thing and forgets the rest, or it does all four badly because it jumped between them. Firmspace solves this by not pretending the work is instant. The assistant recognises that the message contains several separate tasks and hands them to a queue instead of trying to finish everything inside one answer.
The mechanism is a separate tool for queuing. It is called once, with every task written out as a complete instruction in the original order: names, amounts and dates stay as they were written, and words like it or that are replaced by the actual thing. There is a hard limit of twelve tasks in one queue and up to six hundred characters per task, so a message the size of a quarterly plan is not silently truncated — it simply does not fit the queue format.
Then the tasks run one at a time in the background. Not in parallel, deliberately: each task should see what the previous one did, otherwise the phrase this card becomes a guess. Each finished task immediately gives the person its own result, so there is no need to wait for the slowest of the ten. In the web interface the page polls the job and shows results as they land; in Telegram the bot answers as each task is ready, so the queue feels like a conversation rather than a batch process.
A separate story is a task that turns out to be bigger than one pass. The assistant has a step budget per answer, and for queued work that budget is deliberately larger than in an ordinary dialogue. If a task still does not fit, it is not dropped: the system starts a continuation, describing what has already been done, and gives it up to two more attempts. The results of the interrupted pass are not lost either — they are added to the final answer of that task, so a long job ends with a report rather than with a shrug.
The summary at the end is honest and countable, and it comes in the language of the request. It says how many tasks were completed out of the total, how many failed and how many are waiting for confirmation. That last figure matters most in practice: some actions the assistant performs immediately, others it prepares and shows as a card that a human confirms. In a queue these two kinds of results are not mixed into one green check mark.
How a person is supposed to use this, so that the queue works for them and not against them. One message, one list: write the tasks as separate sentences in the order you want them done. Do not mix a request and a question about the result in one line — first the actions, then, in a separate message, the check. And do not repeat the same request twice in one message: the queue will honestly do it twice, because a complete instruction is a complete instruction.
And now the part that is usually left out of AI descriptions. The queue lives in the memory of the process, not in the database. A queue survives an hour, after which its records are cleared. If the container restarts while tasks are running, the person will simply see what has already arrived and will ask for the rest again. This is a deliberate trade of reliability for simplicity, and it is important to know before you hand over a chain of twenty actions to the assistant at five minutes to closing.
There is also a limit on how much AI a company gets in a day. Ordinary dialogue and queued tasks spend the same daily quota, so ten queued jobs are ten AI runs, not one. This is why a queue is a tool for real work, not for cleaning up the whole CRM every evening just in case. When the quota is used up, the assistant says so plainly instead of quietly returning empty answers.
The same assistant has a second mode — autonomous. In an automation rule, the AI action step works without a human nearby: the rule fires on an event, the model looks up what it needs and performs at most one write action, and if the instruction is unclear it does nothing and explains why. A queue is for a person who is present and will read the answers. These are two different tools, and mixing them up is where disappointed expectations come from.
A queue does not make the assistant smarter, and it does not replace a planned process. It removes a specific, very human failure: a long message with five requests, of which four got lost. If you usually write to people in lists, you can write to the assistant the same way — and the answer will come back in parts, exactly as the work was actually done.