What a chief of staff reads for you, and what it leaves alone
Opitor is an AI-native operating system for small companies, where every person gets their own AI chief of staff. Everything useful it does starts with reading. It cannot follow up a deadline it has not seen or draft a reply to a thread it does not know about.
Which makes the edges of that reading the first thing worth being clear about. Not as a policy document, but as the plain answer to a question anybody sensible asks in the first minute: what is it looking at.
What it reads
Three things, and the list is short on purpose.
Your messages, direct and group. The conversations you are part of. This is where commitments get made in a small company, so it is where most of the useful material is.
Your todos and their deadlines. What you have said you will do and when it is due, laid out on a calendar by due date. This is what lets it tell the difference between a busy week and a week where you have promised three things on the same day.
The company’s quarterly goals. The OKR the administrators manage. This is the context that makes the difference between a chief of staff that can only see your inbox and one that can tell whether what is filling your week has anything to do with what the company said it was doing this quarter.
That is not a complete data-flow inventory. The production routes, connected services, model providers and data each receives still need to be documented and checked against the deployed version.
What it leaves alone
Conversations you are not a member of. The deployed revision is unknown, and production administrator/non-member checks across all private-message read paths remain pending. A source-level check does not prove a product-wide access boundary.
Memory controls. Current production evidence does not establish how records are created or used, which roles can read them, what reaches a model provider, or how deletion affects stored data, logs and backups. Keep each of those questions separate; a confirmation button or a missing entry in the interface cannot answer them all.
What it does with what it reads
Three things, and again the list is short because the limits are the point.
It may suggest. Product materials describe suggested todos and memory. The current review does not establish which production message content reaches the chief of staff or how the Memory feature is created, used, or controlled.
It drafts. It writes the reply you were going to write, knowing the thread and knowing what you already said. Getting from an empty box to a decent draft is most of the work in a message, and it does that part.
It reminds. It follows up your todos and their deadlines, so the thing you agreed to on Tuesday is still in front of you on Friday rather than depending on your memory of a scrolled thread.
What it does not do with it
The published sending boundary. Opitor’s public materials say AI replies remain drafts that you choose whether to send, and that they are signed in purple. They also say a reminder you create for yourself can be scheduled to send automatically, while one created by somebody else requires approval. This review has not verified the deployed revision or configuration for those paths.
It does not decide. It can tell you that three deadlines land on Thursday. It cannot tell you which one to miss, because that depends on which customer is fragile this month and which colleague you promised last time. That is your judgement and it stays yours.
Memory controls need evidence. Confirmation, model use, role-based visibility and deletion are separate behaviors. None should be inferred from a memory panel or from the one reviewed message-read route.
Put those together and the shape is the same as the human job the name comes from. A chief of staff in a real company reads along, chases what was supposed to happen, prepares the material and writes the first version. They do not take your meetings or make your calls, and the reason is not modesty about their ability.
Why the boundary is what makes it usable
A company of ten has nobody whose job is to evaluate this. There is no security review, no procurement, no policy person. One person reads a page, forms a view in a few minutes, and either tries it or does not.
Under those conditions a long list of capabilities is not reassuring. What makes a decision possible at this size is knowing which boundaries have evidence and which still need checking: the deployed revision is unknown, and administrator/non-member comparisons across private-message read paths remain unverified. The production model context and Memory controls also need verification.
That is four sentences. You can repeat them accurately after reading them once, which matters because the second person to use it in your company will hear about it from the first person rather than from a page like this one.
There is a second reason, which is about what people are willing to write. Every small company has conversations that are useful and uncomfortable: this is not working, I think we are wrong about the customer, I am struggling. Those happen somewhere. If the company’s own tool might be readable by the company, they move to a personal channel where nobody who could act on them will ever see them.
How to check it rather than take it on trust
Run a short evaluation in a test account or an environment the vendor has approved, using synthetic messages and harmless test records rather than customer or colleague conversations.
- Check whether an AI reply stays a draft until you approve it. Review scheduled reminders separately, since their sending rule may differ.
- Compare each proposed todo with a conversation you can access. Record whether the owner, action and date are supported by what was said.
- If the product has memory, use a harmless test entry. Check what the interface says was confirmed and where the vendor says that entry can be used.
- Remove the test entry through the documented control. Confirm what disappears from the interface, then ask separately how deletion applies to databases, logs and backups; an empty panel does not prove every copy is gone.
Keep the results for an evaluation week before inviting colleagues. This can verify visible behavior in that account; it cannot replace a written data-flow explanation or production access tests for roles you do not control.
Where Opitor fits
Public Opitor materials describe a chief of staff that reads a person’s messages, todos and deadlines, and company goals; they also describe suggested todos and Memory, drafted replies and deadline follow-up. Treat these as product descriptions, not proof of every production behavior. The latest upstream source review includes a central current-session and membership check for private-message routes, but it does not identify the deployed revision or replace production access tests across all read paths. Memory has distinct flows, so this guide makes no blanket claim that every memory requires a separate confirmation step. Deployed confirmation, model access, role visibility and deletion beyond the interface remain unverified. The public site directs new users to its invitation waitlist; see what is an AI chief of staff and the questions and answers page for the current product description.
Updated 2026-09-25