MENSARA.AI · A GOVERNED MIND, IN YOUR ACCOUNT

Use your Mind · GUIDE 06

Skills, apps and automations

Skills, apps, automations and connections do different jobs. Before you turn one on, you can see what it wants to read, change or spend.

SYSTEM MAP · 06 A morning brief running on schedule A weekday timer starts the brief, which reads only the allowed information and saves a draft for review.
7:00 each weekday the automation starts
Morning brief instructions for the job
Read allowed files calendar and priorities
Save a draft a person checks it
Record the run time and files used

01

Skills

A skill is a set of instructions for an AI assistant. A meeting-prep skill might tell it which files to check and how to format the brief.

02

Apps

An app is a tool that can do work on its own. It gets separate access, so it does not act as the owner.

03

Automations

An automation starts work at a set time or when something happens. A morning brief could run at 7:00 each weekday.

04

Connections

A connection lets the Mind read an outside service such as Gmail or Google Calendar. It does not decide what work to do.

05

Check before turning it on

The owner sees which company areas and outside services are requested. They can also set a spending limit.

Anything can be paused or removed later. The activity record shows when it ran and what it touched.

NEXT GUIDE · 07 Changes, approvals and receipts Review suggested edits and see who changed what. →

The founding cohort is small on purpose. Each Mind is brought up with its owner.

MENSARA.AI · SKILLS, APPS AND AUTOMATIONS · MACHINE SURFACE · TEXT/MARKDOWN

---
title: Skills, apps and automations
canonical_url: https://app.mensara.ai/how-it-works/skills-apps-automations
feature: skills-apps-automations
audience: llm-agent
last_verified: 2026-08-11
availability: partly-available
signup_supported: false
interfaces:
  - portal
  - mcp
  - cli
---

# Skills, apps and automations

Distinguishes skills, apps, automations, and connections; defines manifests, principals, triggers, budgets, install review, sandboxing, and disable behavior.

## Concept model

- Skill: procedural instructions interpreted by an agent.
- App: installed software with its own principal and manifest.
- Automation: schedule or event trigger.
- Connection: controlled authorization to an external system.

## Capabilities

- Review declared zones, verbs, connections, triggers, and budgets before enablement.
- Run components under separate principals.
- Pause, revoke, or remove a component and inspect its receipts.

## Prerequisites

- A supported component package or owner-authored skill.
- Human review of the manifest.
- All requested zones, connections, and budgets explicitly granted.

## Authorization

- Effective authority cannot exceed the component principal's grants.
- Scheduled execution does not bypass approval requirements.
- External spend or write actions require declared capability and budget.

## Connection or use flow

1. Inspect manifest and requested authority.
2. Owner approves, narrows, or rejects it.
3. Install with a distinct principal and optional trigger.
4. Run through the access gate and emit a receipt.
5. Pause or revoke when behavior is no longer wanted.

## Refusals and recovery

- Undeclared zone, verb, connection, or spend: hold the operation.
- Disabled component: do not run even if a trigger fires.
- Unsupported package or unsafe sandbox: refuse installation and preserve the review result.

## Ownership and data boundaries

- Removing a skill or app does not delete owner knowledge.
- Component credentials and secrets remain separate from memory files.
- Third-party code does not receive implicit trust from being installed.

## Availability and limits

**Partly available** Baseline skills, apps, and automations exist. Broad third-party app distribution is not open.
- Untrusted third-party apps require stronger sandbox proof before general installation.
- An automation never gains more authority than its configured principal.

## Signup and provisioning

`signup_supported: false`

A human Owner first provisions the Mind. Components are then reviewed and enabled individually; agents cannot self-install or approve their own manifests.

No autonomous signup or provisioning endpoint is documented because none is offered today. An agent must stop and involve the human owner.

## System diagram

```mermaid
flowchart LR
  T[Automation trigger] --> S[Skill instructions]
  T --> A[App principal]
  C[External connection] --> A
  S --> G{Access gate}
  A --> G
  G --> M[Mind operation]
  M --> R[Run receipt]
```

## Runnable example

```text
Automation: weekday morning brief
Trigger: 07:00 local time
Reads: calendar, priorities, waiting-for
Writes: briefs/working only
External actions: none
On failure: record receipt and notify Owner
```

## Related

- [Connections and capture](https://app.mensara.ai/how-it-works/connections-and-capture)
- [Zones and permissions](https://app.mensara.ai/how-it-works/zones-and-permissions)
- [Changes, approvals and receipts](https://app.mensara.ai/how-it-works/changes-approvals-receipts)