How It Works
Stallari runs locally on your Mac and coordinates model-backed work across your vault, plugins, and selected services. The product model is simple: a Chief of Staff helps you understand and act on your own information, while Status and Activity make the system observable and correctable.
Main Parts
Section titled “Main Parts”| Part | Role |
|---|---|
| App | Native interface for Chat, Glance, Watch, Marketplace, and Settings. |
| Helper | Background local process for dispatch, indexing, status probes, and plugin routing. |
| Vault | Human-readable knowledge base and durable record. |
| Plugins | Connectors for services such as mail, tasks, calendars, files, and model providers. |
| Model routes | Local or cloud inference paths selected by policy and configuration. |
The helper can run when the main app window is closed. The app remains the place where you inspect state, change controls, and recover from problems.
Chief Of Staff First
Section titled “Chief Of Staff First”Stallari does not begin by asking users to understand an internal catalog of worker personas. The public mental model starts with a Chief of Staff:
- You ask for help in Chat or enable a workflow.
- Stallari gathers only the context needed for that job.
- A model route is selected.
- Plugins are called only when policy and consent allow them.
- Outputs are recorded in the vault, review queue, notification system, or Activity as appropriate.
Specialized agents exist behind the scenes, but they are earned detail. The first user-facing question is always what Stallari is doing for you and what authority it has.
Work Lifecycle
Section titled “Work Lifecycle”Work can start from several places:
| Trigger | Example |
|---|---|
| Chat | You ask Stallari to explain setup state or prepare a summary. |
| Schedule | A recurring digest or review job runs at a configured time. |
| File watch | A new capture appears in an inbox folder. |
| Plugin event | A configured connector reports new available work. |
| Manual command | You explicitly run a low-level command for debugging or operations. |
Once started, the helper records a durable work entry. Operations shows present-tense progress. Activity shows durable details after a run exists.
Permissions And Consent
Section titled “Permissions And Consent”Stallari separates different kinds of authority:
| Authority | Controlled By |
|---|---|
| Model routing | Provider settings and routing policy. |
| Local data classes | First-party consent surfaces such as Mail indexing. |
| Plugin capabilities | Per-plugin or MCP consent. |
| External side effects | Tool policy, risk class, and review gates. |
| macOS grants | Login Items, Full Disk Access, and App Management prompts. |
Full Disk Access is a broad macOS grant, so Stallari explains the concrete feature first and keeps app-level consent separate. Plugin consent is separate again: approving one plugin does not approve every connector or every action class.
Context Boundaries
Section titled “Context Boundaries”Provider keys do not grant blanket vault access. A model receives the prompt, selected context, and permitted plugin results for a specific job.
Stallari uses several boundaries:
- privacy exclusions for paths and tags,
- plugin capability declarations,
- model routing policy,
- review gates for higher-risk actions,
- and local records that make work inspectable after it runs.
For public documentation, security descriptions focus on user-facing posture rather than internal rule names, thresholds, or bypass details.
Status, Operations, Activity, And Settings
Section titled “Status, Operations, Activity, And Settings”The Watch cluster is split by purpose:
| Screen | Question It Answers |
|---|---|
| Operations | What is happening right now? |
| Activity | What happened, what did it cost, and what tools were used? |
| Status | Is the installation healthy, and what needs attention? |
| Settings | Which controls do I want to change? |
This split matters. Settings should not become a second dashboard, and Status should not hide controls that belong in Settings.
Local Corpus Features
Section titled “Local Corpus Features”Some features index local sources, such as Mail, to make search and classification faster. These features are opt-in. Stallari explains what the feature can do, what it cannot do, where data stays, and how to revoke consent before it triggers the relevant macOS prompt.
Indexes and health state should be visible in Status. Consent controls live in Settings and Setup.
Cross-Machine Use
Section titled “Cross-Machine Use”Stallari can coordinate more than one Mac when configured. A peer can contribute local model capacity, status, or work execution depending on setup and trust.
Cross-machine behavior is always bounded by enrollment, routing policy, local credentials, and explicit user configuration. A second Mac does not automatically gain access to every local source.
Failure And Recovery
Section titled “Failure And Recovery”Failures should be inspectable:
- Status names the unhealthy substrate and the recovery action.
- Activity shows the failed work record when a run started.
- Settings provides the relevant control when the fix is a configuration change.
- Review surfaces preserve human correction paths for classification or action mistakes.
The product expectation is not that automation is invisible. The expectation is that it is observable, correctable, and scoped.
Related concepts
Section titled “Related concepts”- Agency Model — Chief of Staff model, typed primitives, authorised work
- Context And Memory — what an agent sees per job and why
- Legibility And Continuity — observable, correctable, durable records