ADR-050: Agent permission tiers gated by sync_score

Status: Deferred (revisit when triggers fire — see end of doc) Date: 2026-05-09 Context: On the May 9 cici×coachj 1:1, Cici surfaced a meaningful product framing that doesn't currently exist as a captured decision: sync_score should function as the user's trust threshold for delegating actions to the agent.

The current product positioning of sync_score is "how aligned you are with your twin" — descriptive but not operational. Cici's reframe is operational: at higher scores, the agent earns autonomy on more action classes; at lower scores, it has to ask before doing things. The score becomes a trust budget with a concrete user benefit (unlocked agent capabilities) attached to growing it.

This ADR captures the framing now, deferred for implementation, so it doesn't silently decay. There's no agent action surface in production yet to apply it to — the Sync Hermes work (per the brief) currently delivers context retrieval (read-only) and is months away from agents taking real actions on users' behalf. Implementation of permission tiers should land alongside or shortly after the first agent skill that does something beyond reading the profile.

At a glance

What it decides: treat sync_score as a trust budget that gates which agent action classes can run without human approval — a higher score unlocks more autonomy. Deferred — revisit when the first non-read-only agent skill ships (Hermes Phase 3 writes), an external user asks "can my agent do X without asking?", a demo/pitch needs the framing live, or ADR-011 implementation kicks off.

• Core mechanism — three tiers per action class: act-and-tell, act-and-report, ask-first; the meaningful split is "needs approval" vs not.
• Score thresholds unlock lower-risk classes (e.g. internal scheduling at ≥60, external drafting at ≥80); high-risk classes (sending, financial, governance) are always ask-first.
• Per-user override is non-negotiable — the user is the trust authority, not the score; defaults are suggestions only.
• Main rejected alternative — a single binary agent on/off toggle; too coarse to express "draft but don't send."
• Why deferred — no agent action surface exists yet (Hermes is read-only) and the action-class taxonomy needs real usage to validate; building now would be theater.

Decision

Decide later. Capture the framing, set explicit revisit triggers, do not implement now.

When the trigger fires, the implementation should follow this shape:

Three-tier permission model (Cici's framing)

Each action class an agent can take falls into one of three permission tiers per user:

1. Act and tell — agent does the thing, reports it after the fact. No approval required.
2. Act and report — agent does the thing, sends notification (slightly stronger than tier 1, e.g., a Slack DM rather than a log entry).
3. Ask first — agent proposes the action, waits for human approval before executing.

(Cici's original framing had "act without telling me" / "act and tell me" / "ask first" as three tiers — collapsed here because "act without telling" and "act and report" are essentially the same tier with different notification mechanisms; the meaningful distinction is "needs approval" vs "doesn't.")

Action classes (initial taxonomy proposal)

Different action classes carry different risk and should default to different tiers. Initial proposal — to be refined with real usage data:

Action class	Risk	Default tier
Read the user's own profile	Negligible	Act-and-tell
Read team-scoped data	Low	Act-and-tell
Internal scheduling (calendar, todo)	Low-medium	Act-and-tell at high score, Ask-first at low
Drafting external content (emails, posts)	Medium	Ask-first universally
Sending external content	High	Ask-first universally
Financial actions (payments, allocations)	Critical	Ask-first universally, no override
Cross-user / governance actions	Critical	Ask-first universally, no override

Threshold mapping

Action classes that can be unlocked by score thresholds get them. Specifically: - Internal scheduling unlocks act-and-tell at sync_score ≥ 60 - External content drafting unlocks act-and-report at sync_score ≥ 80, ask-first below - Higher-risk actions never unlock automatically; ask-first is the floor

These numbers are starting estimates. Tuning happens with real usage; per-user override is non-negotiable so users who trust their agent more (or less) than the defaults can adjust.

flowchart TB
    LOW["Low sync_score"] --> AF["Ask-first (default floor)"]
    MID["sync_score ≥ 60"] --> S["Internal scheduling: act-and-tell"]
    HIGH["sync_score ≥ 80"] --> D["External drafting: act-and-report"]
    CRIT["High-risk: send / financial / governance"] --> NEVER["Always ask-first — never auto-unlocks"]

Higher scores unlock lower-risk action classes; high-risk classes stay ask-first regardless of score. Per-user override applies throughout.

Per-user override

Every user gets explicit per-action-class control in their settings. The defaults above are suggestions, not enforcement. A user can: - Lower an unlocked action back to ask-first regardless of their score - Raise an action above default if they trust their agent more than the system's defaults imply

This isn't optional — it's required for the system to be ethically defensible. The user is the trust authority, not the score.

Connection to existing ADRs

• ADR-011 (delegation map: per-context authority) is the policy-axis complement. ADR-011 says delegation should vary by decision context; this ADR says it should vary by action class. Together they imply a 2D policy surface: action class × context. Future implementation should account for both.
• ADR-047 (SKILL.md output style) governs how the agent talks back once it's acting. This ADR governs what the agent is allowed to do in the first place. Orthogonal contracts; both needed.
• project_skills_lock_rollback memory captures the enforcement layer (lock specific skills against drift, rollback unwanted mutations). Permission tiers are the policy layer (what's allowed). Both ship together when the time comes.

Rationale (for the framing, not the implementation)

The reframe matters because it answers the "what is sync_score actually for?" question with a concrete user benefit instead of a descriptive label. Three product wins:

1. Discoverability mechanism for sync_score growth. Users see locked actions ("your agent can't post on your behalf yet — sync_score 65/80"). That's a more compelling "play more" hook than the abstract dimension scorecard alone.
2. Resolves the trust gap at the heart of the product. Cici and others have repeatedly said they don't actually delegate to their agents because they don't trust them. The trust gap isn't a feature problem; it's an agency problem. Permission tiers + sync_score as the threshold provide a structured way to grow that trust.
3. Pitches cleanly to external audiences. "Sync is a trust calibration system for AI agents" is a much sharper pitch than "Sync builds a behavioral profile of how you decide." Same product, different framing — but the trust calibration framing is the one that makes investors and partners lean forward.

Why deferred (not Proposed or Accepted)

Two reasons, both real:

1. No agent action surface to apply this to yet. The current Sync Hermes work delivers context retrieval (read-only). Adding permission tiers to a read-only system is theater. The Phase 2-3 work that introduces agent skills like capture_decision, tag_outcome, find_relevant_voices is when this becomes implementable, and that work hasn't started.

2. Action class taxonomy needs real usage to validate. The proposed taxonomy above is a guess. Until users are running real agent actions (drafting emails, writing content, etc.), we don't know what the actual classes are or where the natural risk boundaries fall. Implementing now would mean building a permission system on speculative classes, which is the path to wasted refactoring.

The right move is to capture the framing (so it doesn't decay) and act when the trigger fires (so we don't build speculatively).

Alternatives Considered

• Implement immediately with a placeholder action class. Rejected. No real action surface = no real signal on whether the tier model fits the actual risk distribution. Would build a system we'd refactor before users hit it.

• Single binary trust toggle (agent on / agent off). Rejected. Too coarse — users want to delegate some things and not others. Cici was specific: she'd give external comms permission at high score but not financial. A single toggle can't express that.

• Sync_score-only with no per-class override. Rejected. A single threshold can't distinguish "I trust my agent to write emails" from "I trust my agent to send them" — those are different actions with different risk. Plus per-user override is ethically required.

• Skip score thresholds, ask-first everything. Rejected on UX grounds. The whole point of the trust calibration is that users earn delegation. Universal ask-first defeats the value proposition.

• Wait for ADR-011 implementation first. Considered. ADR-011 has been in "Recommended" status for ~7 weeks without implementation; tying this ADR to that one risks both rotting together. Better to capture this ADR independently with its own triggers and revisit when either ADR's conditions fire.

Triggers for revisit

This ADR moves from Deferred to Proposed when any of the following fire:

1. First agent skill ships that takes a non-read-only action. The Sync Hermes brief's Phase 2 (find_relevant_voices) is read-only; Phase 3 (capture_decision, tag_outcome) is the first phase with write actions. When that lands, permission tiers should land with it.

2. An external user explicitly asks "can my agent do X without asking?" Real demand from beyond the Beacon team — pilots, partners, anyone evaluating Sync as a trust system. That's signal that the trust calibration framing is resonating and needs a concrete implementation.

3. A planned demo / pitch needs the trust calibration framing live. Specific upcoming moments (Ryan Sarver-style users, MetaGov, fundraising) where the abstract framing won't carry; implementation matters.

4. ADR-011 implementation kicks off. The 2D policy surface (action × context) means these two ADRs should be designed and implemented together if either gets started. Force a co-design rather than two parallel partial systems.

If none of these fire by Q4 2026, revisit anyway with a hard-stop check: is this still a real product direction or has it been superseded by a different agent contract framing?

Consequences

• Until trigger fires: sync_score remains positioned as "alignment with your twin" in user-facing surfaces. The trust calibration framing lives in this ADR + the project_sync_score_as_trust_threshold memory but doesn't ship to users.
• No implementation work on agent permissions, action class taxonomy, or override UI. Don't speculatively design these.
• Watch: any feature or pitch that implies sync_score-as-trust without this ADR landing — that's a warning sign of premature product positioning. Pull back to "alignment" framing externally until the implementation is live.
• When Phase 2-3 of Sync Hermes work begins, this ADR's status should be checked first thing as part of scoping. If trigger #1 has fired, this ADR moves to Proposed and the implementation is in scope.

Memory: - project_sync_score_as_trust_threshold — captures Cici's original framing in conversational context. - project_skills_lock_rollback — the enforcement-layer companion (lock + rollback for individual skills under agent-driven updates).

Key files (when implementation triggers): - New schema for agent_permissions per (user_id, action_class, tier) — only when needed. - Wire into Sync Hermes orchestrator skill execution path — only when needed. - Per-user settings UI for tier overrides — only when needed. - Sync (Play) "locked actions" surface tied to sync_score — only when needed; depends on Cici's twin redesign accommodating this.