Understand your work OS
Missions: keep the promise with the next step.
Who is waiting, what did you promise, and what needs to happen first? Keep the reason, owner and next step together so a follow-up remains understandable when someone else takes over.
A received enquiry is not a completed action.
The customer application collects enquiries. Missions organise subsequent work, ownership and approvals within the selected internal functions. They are not all automatically included in the customer base scope.
Everyday work
“Call the customer.” About what, and why now?
A reminder gives you a date. The work also needs its reason: a missing approval, a revised quote or an unanswered question. A Mission keeps that context with the commitment.
Follow the commitment, through the blocker.
Prepare the visit
Signed authorization
Léa
01The commitmentKnow why the follow-up exists.
“We’ll prepare the visit once we have the signed access authorization.”
Customer: Camille. Owner: Léa. Next step: request the signed authorization before arranging the visit.
A supported signal or an explicit request can initiate the mission.
02The blockerSee what needs to arrive first.
“Why is Camille’s visit still waiting?”
The authorization is missing. Léa can prepare a reminder explaining which document is needed and why.
A prepared reminder is not a delivered message.
03The next stepContinue from the new information.
The document arrives. The person responsible reviews it before proceeding.
Authorization received, content to check. If suitable, prepare the booking invitation with the access details.
Receiving a document does not automatically approve it or close the mission.
Fictional example, not a product screenshot. Sources and access require configuration; illustrated answers use the information shown.
A colleague can take over the work, not just its title.
The team can recover the commitment, the person responsible and the reason it is waiting. An authorized manager can review open work within their scope. Reassignment keeps responsibility explicit.
See how responsibility and collaboration workOn this page
Why a mission exists
Small actions get lost: call a customer back, send a promised quote, request a document, confirm a meeting, apply a decision or respond with the approved procedure. The information may remain in a call, a message or someone’s memory.
A mission connects what happened to what needs to be done. It preserves the people involved, the reason, deadline, owner, expected approval and next step.
A mission is not a task without a story
“Call Marc” is not enough. A useful mission explains that Marc requested a Friday callback after reviewing the proposal, that he expects a revised version and that an explanation of deployment needs to be prepared.
The mission explains why to act and what can be prepared. It can concern a callback, follow-up, document, quote, appointment, internal action or group decision.
Manual creation and signals from work
A mission can be created from an explicit request or prepared from a supported signal: “call me tomorrow” during a call, “send the document” in a message, a responsibility assigned in a meeting, a procedure to update in a group or a file to prepare before an appointment.
The signal must be received, linked to the right context and clear enough. Not every sentence becomes a mission. Missing information needs clarification.
Preparation, confirmation and result
AlefOS can prepare a message, summary, meeting proposal or another available action. The user retains the decision within the intended workflow. A pending mission can be confirmed, rejected or archived according to its state.
Confirming a mission initiates its execution flow; it is not simply viewing it. A rejected mission must not execute. Archiving a mission without further action does not mean sending its proposed message.
What the employee can review
Missions help retrieve today’s callbacks, open promises, missing documents, ready messages, overdue follow-ups and items awaiting approval. Each detail must stay connected to the contact, original signal and, where applicable, the appointment.
Example: a signed document is needed before a visit. The mission keeps the outstanding document, customer, follow-up date, any draft and tracking status together.
What the manager can review
Within their scope, a manager can examine open actions, delays, waiting customers, blockers and unexecuted preparations. Missions can reveal recurring difficulties: the same missing document, slow approval or unassigned responsibility.
These findings depend on available data and filters. The documentation does not promise a calculated performance indicator if the product does not provide it.
Assignment and the company queue
A mission can be assigned to a responsible member, reassigned with the required permissions or returned to the company queue. Removing an individual assignment does not delete the work or its context.
Taking over must be explicit. The owner’s identity stays visible and assignment changes are recorded. A manager view does not grant access to files outside its scope.
Read the state before continuing
A useful mission answers six questions: where did the request come from, why does it matter, who owns it, when is it due, what is blocking it and what happens next? A reminder can carry a time; a mission keeps the commitment and its available context.
Pending, executed, rejected and archived are not interchangeable. Confirming a pending executable mission can run its action; archiving does not prove the customer was contacted. Read the source and result before reporting completion.
Operational reference
Modules, tools and access conditions
This reference describes MCP operations and their effects. The list exposed to your assistant depends on the deployed server, enabled modules and permissions. Reading, preparing and executing are distinct operations.
Missions and responsibility
Read the source and execution state before acting. Confirming executes a pending mission; rejecting and archiving have different effects. Assignment follows company roles.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
missions. | List the current user’s missions, optionally grouped by contact. |
missions. | Read a mission’s source, related objects and execution state. |
missions. | Confirm and execute a pending mission. |
missions. | Reject a pending mission without executing it. |
missions. | Archive a mission without executing or deleting its action. |
missions. | Assign from the company queue or reassign with the required role; changes are audited. |
Signals and controlled actions
Adding a signal can enrich memory and prepare pending work without executing an outbound action. An action_id identifies prepared work; its execution and result must remain distinguishable from a read-only answer.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
signals. | Search extracted signal titles and content by keyword. |
signals. | Read an accessible signal, its participants and linked missions. |
signals. | Enrich memory from a structured note or source; missing details can require clarification. No outbound action is executed. |
signals. | Correct or enrich an existing signal without creating another one. |
alefos. | Read a compact briefing across visible actionable work and recent context. |
alefos. | Read a summary for one local calendar day within the current scope. |
actions. | Execute previously prepared work identified by action_id after confirmation. |
The scenarios on this page illustrate workflows, not real customer data or guaranteed outcomes. Connections and capabilities must be enabled and verified for your environment. Official business systems retain their responsibilities.
Continue exploring
A capability of your company’s environment. Your team can use this capability from a compatible assistant through its configured MCP access. The deployment defines the enabled tools and permissions. Understand your AI connection ↗