Definition: An AI secretary is continuous delegation. You describe a job once; it keeps following up—checking for changes, compiling digests, collecting results in one place—and only pings you when it needs input or an approval. The secretary model in Semibot is designed to replace two habits: scheduling a cron job manually, and repeatedly asking an AI the same question.
Why chatbots drop the ball on ongoing tasks
Chatbots are session-bound. When the session ends, context is preserved in history but the active task is not. Reminders can be set, but they fire at a time without understanding what has changed. Results scatter across different threads. If you want a weekly project digest, you need to remember to ask for it each time—or set up a rigid schedule with a separate tool.
The problem is not that chatbots are bad at answering. It is that ongoing tasks need a different contract: stay watching, interrupt only when needed, and collect results in a predictable place.
How Semibot’s secretary works
- Continuous delegation in plain language. Describe the ongoing job. “Keep an eye on the token-reseller scene and send me your read when something moves” is a valid instruction—no cron syntax needed. If you give a rhythm, it follows that. If not, it proposes a sensible default and says what it is using.
- Scheduled checks. The secretary uses what you told it—plus the workspace and connected services—to check for changes at a rhythm you defined. You can change the rhythm later.
- Results collect in one place. Project digests, material diffs, coding change briefs collect on the secretary page. Each result links back to the session and task it came from.
- Interrupts only when needed. Missing information or an approval request triggers a ping—not every intermediate step. A normal question in a secretary context is answered directly.
Example prompts
These are prompts people actually give the secretary. They are long-running by design.
- Weekly briefing: “Every Friday at 17:00, summarize client A’s weekly progress from this workspace—what moved, what risks, what to plan next.”
- Ongoing watch: “Watch the token-reseller and token-aggregator scene; send me your read when something moves. No need to check every day—just when there’s substance.”
- Repo monitoring: “Keep an eye on failing tests in this repo. Tell me when the picture changes materially.”
- Document tracking: “Monitor this shared document folder. When new drafts appear, summarize the changes and flag what I should review.”
Comparison with other approaches
| Dimension | Chat | Todo / reminders | Semibot secretary |
|---|---|---|---|
| Understands the work | Per session | No | Yes, from your workspace context |
| Keeps following up | No | Time-based only | Change-aware + scheduled |
| Result collection | Scattered in chat | — | Secretary page |
| Approvals | — | — | Asks when required |
| Setup cost | Low | Manual scheduling | Describe in plain language |
Workflow scenarios in detail
The secretary model is best understood through concrete examples. Here are detailed scenarios showing how continuous delegation works across different workflows.
Scenario: Personal research tracker
You are tracking a fast-moving technical field—say, new open-source AI frameworks. You want to know when something significant happens without reading every announcement yourself.
- Tell the secretary: "Watch for major releases or announcements in AI framework repos. Check weekly. Summarize what changed and why it matters."
- The secretary checks GitHub releases, RSS feeds, and connected channels at the rhythm you set.
- Each digest collects on the secretary page with links to sources. You can drill into any item for deeper analysis.
- When a release is significant enough to affect your own project, the secretary flags it with a ping.
- Over time, the wiki mode organizes these digests into an evolving article on the field, with source links you can trace.
Scenario: Meeting preparation pipeline
You have recurring meetings that require preparation—reviewing recent changes, compiling status, and drafting talking points.
- Connect your calendar via the Calendar connector.
- Instruct the secretary: "Before each meeting with client X, prepare a one-page brief. Pull from the workspace: action items from the last meeting, any new documents added this week, and current project status."
- Before each meeting, the secretary compiles the brief and places it on the secretary page. If your calendar event has a link or location, it includes that too.
- After the meeting, you can ask the secretary to draft follow-up emails via the Gmail connector, referencing what was discussed.
Scenario: Code repository health monitor
You maintain a repository and want to stay on top of failing tests or build regressions without checking manually.
- Open the project in Semibot and grant the repo folder.
- Tell the secretary: "Keep an eye on failing tests in this repo. Tell me when the picture changes materially—not every single failure, but trends."
- The secretary runs tests or checks CI status at the configured rhythm and summarizes the health picture.
- When the trend shifts—new failures appear, or a cluster clears—the secretary pings you with a concise brief linking back to the relevant session.
Scenario: Multi-channel team digest
Your team communicates across multiple platforms—Feishu/Lark for project updates, Slack for engineering discussions, and Gmail for external correspondence.
- Connect Feishu/Lark, Slack, and Gmail connectors. Each is managed independently and can be toggled on or off.
- Instruct the secretary: "Every Monday morning, compile a team digest. From Feishu, pull project status updates. From Slack, summarize technical discussions that had decisions. From Gmail, flag any external emails needing response."
- The secretary pulls from each connector, compiles a unified digest, and presents it on the secretary page. Items link back to their source platform.
- If an email needs a response, the secretary can draft one for your approval—using the same approval gates as any other action.
Decision tree: secretary vs other approaches
The secretary is not the right tool for every recurring task. Here is how to decide:
- If the task is a one-time research job that takes 10 minutes, use a normal chat session. The secretary adds overhead that is not justified for a single pass.
- If the task is a simple time-based reminder ("remind me at 3 PM"), a calendar or reminder app is simpler. The secretary is overkill for pure alarms.
- If the task requires ongoing monitoring with judgment ("tell me when something significant changes"), the secretary is designed for this. It understands context, not just timestamps.
- If the task needs specialized methods (a particular research format, a specific code review checklist), pair the secretary with a specialist. The specialist defines how, the secretary defines when and where results go.
- If the task involves multiple data sources (files, connectors, calendar), the secretary can combine them. A simple cron job or chatbot cannot.
Comparison: secretary vs manual scheduling vs plain reminders
| Dimension | Manual scheduling (cron, Zapier) | Plain reminders (calendar, phone) | Semibot secretary |
|---|---|---|---|
| Understands workspace context | No, rule-based triggers | No | Yes, reads workspace and connectors |
| Judgment calls | No, executes on schedule | No | Yes, can decide what is "significant" |
| Result collection | Email or webhook output | Just a notification | Dedicated page with session links |
| Multi-source synthesis | Requires custom pipeline | No | Built-in across connectors and workspace |
| Adapts over time | Manual reconfiguration | No | Yes, learns from workspace changes |
| Setup effort | Medium to high (code or config) | Low | Low (plain language instruction) |
What the secretary will not do
- Bypass approvals. The secretary uses the same approval gates as the rest of Semibot. Folder grants and high-risk actions still apply.
- Dump history into one giant chat. Follow-ups stay bound to the right session. The secretary page shows results, not everything.
- Claim to be watching when it is not. If configuration is missing—no model, no connector, no folder grant—the secretary tells you rather than pretending.
- Replace deep work. The secretary handles routine monitoring and summarizing. Deep investigation or creative work belongs in a focused session.
Secretary vs specialist
A specialist remembers how a recurring job should be done—its methods and standards. The secretary keeps an ongoing watch and delivers results over time. In practice, a secretary task might use a specialist to do the actual research or writing. They are complementary, not competing.
For example: you create a specialist that knows how to analyze quarterly financial data—it follows a specific format, uses particular calculations, and produces a standard report structure. Then you create a secretary task that triggers that specialist every quarter when new data appears in the workspace. The specialist defines the method; the secretary defines the rhythm and delivery.
Boundary conditions: when the secretary struggles
- High-frequency monitoring (sub-minute): The secretary operates on rhythms measured in minutes, hours, or days. If you need real-time monitoring with sub-second alerting, a dedicated monitoring tool is more appropriate.
- Tasks requiring physical presence: The secretary can compile information and draft communications, but it cannot attend meetings, make phone calls, or perform physical tasks. Use it for the digital parts of a workflow.
- Complex multi-step workflows with external dependencies: If a task requires waiting for an external system to complete an action (like a CI pipeline finishing), the secretary can check the status at intervals but cannot subscribe to real-time events from external systems.
- Long-running analysis on very large datasets: If the secretary task involves processing thousands of documents or large files, model context limits may constrain what can be analyzed in a single cycle. Breaking the work into smaller batches helps.
- Conflicting instructions from multiple tasks: If two secretary tasks monitor overlapping data sources with different criteria, they may produce redundant or conflicting results. Clear scoping of each task prevents this.
Real connector workflows for the secretary
Connectors turn the secretary from a local tool into something that touches your external communication channels. Here are concrete connector-powered workflows:
- Feishu/Lark project channel: The secretary monitors a Feishu project channel for status updates and decision threads. Weekly, it compiles a digest and posts it back to the channel—or to a different channel for leadership review.
- Gmail follow-up drafts: After calendar meetings, the secretary drafts follow-up emails referencing the meeting notes in the workspace. You approve before sending—no message goes out without your confirmation.
- Slack engineering channel: The secretary watches a Slack engineering channel for discussions that result in architectural decisions. It extracts those decisions into the knowledge library as reference entries with links back to the original thread.
- DingTalk task tracking: For teams using DingTalk for task management, the secretary pulls task status updates and compares them against project timelines in the workspace. It flags overdue items and blockers.
- Telegram alerts: For personal use, the secretary can send you a Telegram message when a watched condition is met—useful for time-sensitive monitoring when you are away from the desktop.
Limitations
- Needs a model and, optionally, connectors. Without a model provider, the secretary cannot do useful work. Some watches need a specific connector (e.g., calendar).
- Subject to the same network and model limits as everything else. Cloud models need network. Long or complex tasks may hit context limits.
- A young feature. The secretary model is still evolving. Expect changes to how rhythms, delivery, and history are presented.
- Desktop-bound. The secretary runs within the Semibot application. If the app is closed, scheduled checks are missed. This is different from a server-based cron job that runs independently of any client application.
- No real-time event subscriptions. The secretary checks at intervals, not in real-time. For use cases requiring sub-second response to events, a dedicated monitoring or alerting system is more appropriate.
FAQ
Do I need to write cron expressions?
No. Plain language works. If no rhythm is given, a default is proposed and shown to you—you can change it later.
How is this different from a specialist?
A specialist remembers how a recurring job should be done. The secretary keeps an ongoing watch and delivers results over time. They work together.
Where do results go?
They collect on the secretary page, with links back to sessions, artifacts, and tasks.
Can I pause a secretary task?
Yes. Tasks can be paused and resumed. Pending items remain until you handle them or dismiss them.
Does the secretary cost extra?
The secretary uses the same model quota as any other task. There is no separate secretary subscription. Model calls consume your existing quota or your own provider.
What happens if Semibot is closed?
The secretary runs when the application is open. If Semibot is closed, scheduled checks are missed—not queued indefinitely. When you reopen, pending tasks resume based on their configured rhythm. This is a real limitation compared to a server-based cron job.
How many secretary tasks can I run?
There is no fixed limit on the number of secretary tasks. Practical limits depend on your model quota, the frequency of checks, and the complexity of each task. Heavy tasks with large workspace scans will consume more quota per cycle.
Can the secretary send messages through connectors?
Yes, through approved connectors like Feishu/Lark, Slack, Discord, or Telegram. Sending messages still goes through the standard approval gates. You can configure auto-execute for specific actions in a session, but this is marked as a dangerous mode.
Does the secretary work with team accounts?
Semibot is a single-user desktop app. Each person runs their own instance with their own secretary. However, connectors to shared platforms (Feishu/Lark, Slack) mean multiple secretaries can feed results into the same team channels.
Can I change the rhythm after setting it?
Yes. You can update the rhythm at any time by editing the secretary task. The change takes effect on the next cycle. You can also pause a task entirely and resume it later without losing the instruction.
What model does the secretary use?
The secretary uses whatever model provider you have configured—your own API key or the built-in trial quota. There is no separate secretary model. The quality of the secretary's output depends on the model you choose.
Is the secretary's output private?
Results are stored in the local SQLite database on your machine. They are not uploaded to any server. However, the model calls that generate the results do send prompts and context to the model provider. Read the provider's terms for their data handling policies.