How the assistant works
You no longer have to pick the right module yourself. Describe what you need, and the assistant decides what to run, in which order, and shows you its progress.
What changes
Every message you send now goes through a routing step. Before answering, the assistant reads your request, compares it to what the modules can produce, and draws up a plan. It may decide to simply talk, to run a module, or to do both.
In practice: “prepare my framing meeting about the portal redesign” is enough. You no longer need to open the “Meeting prep” chip yourself, even though it is still there.
It chains several steps
One request can hold two. “Prepare my meeting, then write the user stories” produces a two-step plan, run in the order you gave, and therefore two deliverables. Each step starts from the conversation context, not from the previous step’s output.
If a step fails, the following ones are still attempted: you do not lose the work already produced because one module did not make it.
What you see in the thread
The thread narrates the run as it happens, inside a single answer: the line “Meeting prep running…” appears as the step starts, then gets replaced by “Meeting prep: deliverable ready.” followed by an Open the deliverable link. A purely conversational answer, on the other hand, streams in word by word with no waiting line.
The deliverable is saved to the deliverables library the moment its step ends, not at the end of the plan. An interruption therefore does not cost you what was already produced.
One answer, not one per step
The whole plan lives in a single bubble from the assistant: lines are appended as it goes, they do not create new messages. That is also what you find when you reopen the conversation later.
The questions it asks you
For a process, the assistant does not model in a vacuum: it starts by asking the questions it is missing, in the thread, and stops there for that turn.
Your reply is tied to its questions
Answer normally, in prose: your next message is understood as answers to those specific questions, not as a new request. The assistant then builds the process structure, computes the BPMN 2.0 diagram and saves the deliverable.
One thing to know: as long as questions are waiting, your next turn is attached to them. To switch subject entirely, open a new conversation.
What it does not do
It does not make you review before producing. When you open a module by hand, it first shows what it understood and waits for your validation. On this path, the assistant chains analysis and generation with no stop: faster, but the review happens after, on the deliverable. If the context is delicate, open the module yourself.
It does not invent context. What feeds a step is still what you wrote, attached, or set in the project context. What is missing is flagged as an assumption, not quietly filled in.
It does not act autonomously. If you read elsewhere that Elicira is an “agent”, it is in the sense that it plans and executes instead of merely answering. It does not restart its own steps, does not fix itself, and does not step outside the three modules: there is no background work you would not see in the thread.
It is not unlimited in time. A module takes one to two minutes. A two-step plan is fine, chaining three modules in a single message risks being cut short. When that happens, ask for them in two messages.