Opportunities & autonomy

Sally watches real activity across projects, tasks, CRM, deals, follow-ups, marketing, and memory, and surfaces concrete next actions instead of leaving them buried in tools. Opportunities are computed live from those signals — there is no queue to groom. Around them sits the autonomy layer: agents submit proposals, and per-brand trust policies decide what runs automatically and what waits for a human.

The next-best-action wedges

Sally detects opportunities across six wedges, each grounded in the brand's current data:

Client and project status reporting — active projects, blockers, and next actions worth reporting to a client.
Meeting to memory — unprocessed notes that should become CRM records and durable memory.
Follow-up detection — which client, lead, deal, or project needs attention, and why.
Brand briefing before work — the voice, constraints, decisions, and warnings a worker or agent should read first.
Scope and promise tracking — what was promised against what is actually happening.
Safe agent execution — work a connected agent could take on within approval boundaries.

Each opportunity carries a computed priority, so the list ranks itself.

The Opportunities view with ranked service wedges and priorities — The opportunity engine — it watches project, CRM, marketing, and memory activity and ranks service wedges (reporting, meeting intake, follow-ups) by priority, each with why-now signals and next steps.

List, recommend, execute

Working an opportunity moves through up to three steps:

List — see the current opportunities for a brand, with a stats snapshot, under Brand → Opportunities or over MCP with opportunity.list.
Recommend — request a structured recommendation for one wedge with opportunity.recommend. Sally loads the real context and returns a suggested action, risk notes, and next steps. Recommendations always flag that approval is required — they describe what to do, they do not do it.
Execute — run the safe action directly with opportunity.execute.

Today, opportunity.execute is implemented for the meeting-to-memory wedge only: it captures meeting notes as a CRM activity and a durable memory decision, plus an optional follow-up, and never sends any external message. The other five wedges are recommend-only — Sally tells you (or your agent) what to do, and you act through the relevant tool or through a proposal.

Proposals and trust policies

The autonomy layer is Sally's Control Center. Instead of giving an agent raw access, Sally has it submit a proposal: a titled set of typed actions plus supporting evidence. Sally evaluates the proposal against the brand's trust policy and then auto-executes, holds it for approval, or blocks it.

An agent trust policy is set per brand and per source (for example, the hosted MCP connector, ChatGPT, or a named agent identity). It defines:

allowedActions — the action types this source may run.
requireEvidence — whether evidence is mandatory (on by default).
maxActionsPerProposal and maxActionsPerDay — caps on how much can run at once and per day.
yolo — an explicit opt-in that lets a trusted source auto-execute anything within its caps.

Sally evaluates a proposal in order: it checks evidence, enforces the caps, and then decides. A yolo policy auto-executes. Otherwise, a proposal auto-executes only when the policy covers every action in it and none of those actions are classed as risky. Anything else is parked for human approval.

Pending items in the Control Center with approve and deny controls — The Control Center — proposals and approvals surface here with their evidence and the approve / deny controls a human uses to resolve them.

Safe versus risky actions

The split between auto-execute and approval is built into the action classification:

Safe (auto-executable under an allowing policy) — writing memory (memory.intake.execute, memory.create), logging CRM activity and follow-ups (crm.activity.add, crm.follow_up.add), creating and moving tasks (task.create, task.update, task.move), task handoffs (task.handoff.create), comments, task todos, and blockers. These are reversible and low-blast-radius.
Risky (always held for human approval) — sending email, sending a newsletter, external publishing, data export, record deletion, code deploy, and bulk CRM or marketing updates. These never run straight from a proposal by design.

Every decision is recorded: proposals move through statuses (pending, approved, denied, auto-executed, executed, blocked, cancelled), and each step writes an append-only operational event alongside the audit log. See Governance for the full Control Center model — approvals, blockers, and evidence.

With agents

Opportunities and proposals are both part of the hosted MCP surface. An agent can call sally.context to ground itself, ask opportunity.list and opportunity.recommend what is worth doing for a brand right now, and submit work through proposal.create — then let the brand's trust policy decide what runs. Humans resolve pending proposals with proposal.resolve, and approved-but-not-yet-run work can be triggered with proposal.execute. An agent's reach is never broader than the credential behind it. See Connect your agent and Governance.

Roadmap

Executable wedges beyond meeting-to-memory. The other five opportunity wedges are recommend-only today; direct execution for them is planned.
Finer-grained trust configuration. Trust policies cover per-source allow-lists, caps, and evidence rules today; more granular controls may follow.