Core concepts

Sally is one workspace for project management, CRM, marketing automation, and commerce — built so humans and AI agents work from the same brand memory under one permission and approval model. This page explains the objects everything else is built on: the account and tenancy hierarchy, the unified role model, the two identity tiers, memory and context, and the governance layer that keeps agent work safe.

The structure

Sally nests four containers, from your company down to a single unit of work:

1. Customer account — the billing and tenancy root. It owns your brands, team memberships, subscription, security settings, API/MCP keys, and SAML configuration. Its status (active / suspended / archived) gates access to everything below it.
2. Brands (workspaces) — the main collaboration boundary. Each brand has its own projects, CRM, marketing, memory, and members. Pricing is per brand: your plan sets how many brands you can run. In the data model and API a brand is a workspace — the two words mean the same thing.
3. Projects — work containers inside a brand. Each has its own Kanban statuses, tasks, labels, members, timesheets, and an optional link to a CRM organization (a "client"). Creating a project seeds five default statuses (Backlog, In Progress, Blocked, Review, Done).
4. Tasks — the unit of execution: a title, rich Markdown description, priority, due date, people, labels, checklist, comments, dependencies, and time entries.

The brand rail switches between the brands you can access; each brand opens onto its own projects, CRM, marketing, and memory:

Kraft Fabrik Media Ltd.        ← customer account (your company)
├─ Aurora Coffee               ← brand / workspace  ·  switch from the rail
│  ├─ Q3 Product Launch         ← project
│  ├─ Website relaunch
│  └─ Wholesale outreach
├─ Northwind Tea               ← brand / workspace
└─ Fjord Studio                ← brand / workspace

A "customer account" is your company; an account is a single person's login. One account can belong to several customer accounts and several brands.

The unified role model

Every human, API key, MCP key, and agent identity resolves to a single Sally account, and every request is bounded by the same layered role and scope checks. An agent's reach is never broader than the credential behind it — this is Sally's "one permission model for humans and agents."

Permissions are evaluated across four layers:

• Customer-account roles — Owner, Admin, Billing, Member. Owner and Admin manage the team, security, and brands; Billing manages the subscription without broader admin access; Member works only in the brands they are granted.
• Workspace (brand) roles — Owner, Member, Viewer, plus an optional billingAccess flag and optional custom roles. Owner manages workspace structure and membership; Member does normal project, CRM, and marketing work; Viewer is read-only with people/assignee details hidden. Custom roles define finer read/write/admin permissions across the Projects, CRM, Marketing, and System areas.
• Project roles — Owner, Member, Viewer, layered on top of workspace access. A Member sees only tasks they own or participate in; a Viewer is read-only with people fields hidden and no access to timesheets. This is how you give a client read-only access to one project without exposing the rest of the brand.
• Agent identities — a connected agent authenticates with an MCP key or OAuth token tied to a real account, then passes the same checks as the web app on every call. Agent API keys additionally carry their own scopes (for example projects:read, tasks:write, handoff:create, approval:request), and a hosted MCP key can be pinned to a single workspace so cross-workspace access is denied.

Because all four layers resolve to one account, an agent appears in task participation, activity, and audit history exactly like a person, and can be restricted per workspace or revoked at any time.

Humans and agents sit in the same member model, each with a role and, for agents, additional per-key scopes:

Member	Type	Role	Access
Sam Rivera	Human	Owner	Full brand
Priya Shah	Human	Member	Projects + CRM
Codex	Agent identity	Operator	projects:read, tasks:write, handoff:create, approval:request

The agent authenticates as a real account with a workspace-pinned MCP key, so it appears in task participation, activity, and audit history exactly like a person — and can be scoped or revoked at any time.

Two identity tiers

Sally separates who a person or company is from what they are to a given brand:

• Global relationship graph — a cross-brand identity layer (relationship organizations, people, and activities) that is not workspace-scoped. It lets Sally recognize the same real person or company across brands: "we already know this person from another brand."
• Per-workspace CRM — each brand's own CRM organizations, people, deals, activities, and follow-ups. Each CRM record can point up to a relationship record, and a relationship context scopes a person or org into a specific brand (with a role, relevance, and notes).

The relationship graph is read-only over MCP (relationship.person.list, relationship.organization.list); its records are created implicitly through the memory-intake flow rather than a direct create tool.

Memory and context

Each brand accumulates typed operational memory — the "brand brain." Memory items are durable, categorized records (facts, decisions, constraints, preferences, brand voice, and more) that agents read before acting and write after. Verified items can be semantically searched when embeddings are configured, and fall back to keyword and recency ranking otherwise. See Memory.

The fastest way for an agent (or a human reading its work) to get grounded is a single sally.context call, which returns verified memory, active projects, open deals, overdue follow-ups, recent CRM activity, and standing instructions in one response. Sally's guidance to agents is to call it first in every session, before planning or acting. Two narrower context calls exist for focused work: project.runtime_context (a project's summary, statuses, open and blocked tasks, relevant memory, pending approvals, and trust policies) and task.resume_context (the latest handoff, evidence, open blockers, and a computed recommended next action for a single task).

Governance

Agents don't act blindly. When an agent wants to do something, it submits a typed proposal; Sally evaluates the brand's trust policies and either auto-executes safe, reversible work or holds risky work for human approval — with full evidence and an audit trail. This is Sally's "safe autonomy" model, surfaced in the Control Center.

The core objects:

• Proposals — an agent's typed set of actions plus evidence. Sally evaluates a per-brand, per-source trust policy (with optional per-agent scope, daily and per-proposal caps, and an evidence requirement). Safe actions — creating memory, notes, tasks, comments, drafts, or a handoff — can auto-execute; risky actions are quarantined.
• Approvals — typed approval requests (publishing, live deploy, credentials, customer or payment data, client decisions, destructive actions) with a question, options, and a recommendation, waiting for a human decision.
• Blockers — structured "cannot proceed until a human resolves X" records with a type (credential, access, ambiguity, and more) and status. Raising one moves the task to Blocked.
• Evidence and operational events — handoffs and proposals carry normalized evidence (sources, checks performed, decisions, assumptions, risks, outputs, confidence, next steps), and every decision appends an entry to an operational-event ledger plus the audit log.

Risky actions — email.send, newsletter.send, publish.external, data.export, record.delete, code.deploy, and bulk updates — are approval-only by design: Sally holds them for a human rather than executing them inside a proposal. Agent-relevant tools include proposal.create, proposal.list, proposal.get, proposal.resolve, and task.handoff.create. See Governance.

How agents connect

Agents reach all of the above through Sally's hosted MCP endpoint (/mcp), a first-party, stateless remote MCP server. The recommended path is a one-click OAuth connector in Claude or ChatGPT; hosted MCP keys and a stdio bridge (sally-mcp on npm) are also supported. Every path resolves to a Sally account and is bounded by the role model above. See Connect your agent.

Notifications

Sally notifies you about task assignments and comment mentions, in-app and by email, with per-user preferences. Notification links carry brand context, so they resolve correctly even when you currently have another brand selected.

Roadmap

• Passkeys — passkey registration is available today; passkey sign-in is still being finished, so keep another sign-in method configured. See Security.
• External work-item sync — Sally can reference external work items, but only native Sally items are wired end to end; Jira, Linear, and GitHub sync are not yet live.