Documentation Index

Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

Autonomy + self-learning

1. crews.autonomy_level — per-crew trust dial: strict | guided | trusted | full
2. crews.behavior_mode — per-crew response posture for behavior-monitor anti-pattern hits: warn | block
3. agents.self_learning_enabled — per-agent boolean: whether keeper-evaluator ALLOW decisions auto-apply or queue for operator approval

​

Why three knobs, not one

• A crew where every action needs approval BUT a specific senior agent in that crew can evolve on its own (operator-trusts-bot-A-not-bot-B)
• A crew that auto-executes most things BUT blocks any anti-pattern hard (relaxed autonomy + strict behavior posture)
• A crew that warns on anti-patterns but does NOT auto-promote lessons (governance-strict per-agent learning, relaxed at the crew level)

• What can the agent do without asking? → autonomy_level (crew-wide)
• How does the system react when the agent does something the behavior monitor flags? → behavior_mode (crew-wide; orthogonal to autonomy because warning vs blocking is a response policy not a permission policy)
• Can the agent update its own long-term posture without approval? → self_learning_enabled (per-agent because long-term posture is per-agent)

​

autonomy_level — what an agent can do without asking

​

Strict-mode use cases

• Compliance-bound workspaces (financial services, healthcare, regulated build pipelines) where every agent action has to be operator-traceable to an explicit approval
• New crews during onboarding where operators are still building the inbox approval reflex
• Crews that act on production infrastructure — the cost of one bad call is high enough that the operator prefers the friction

​

Full-mode use cases

• Power-team developer workflows where the operator pre-approves the crew’s mandate and wants minimal friction
• Background routine crews (nightly health checks, scheduled reports) where every action would otherwise generate noise the operator never reads
• Crews with a narrow, well-understood mandate (e.g. “rotate API keys quarterly”) where the autonomy_level matches the scope

​

behavior_mode — what happens when the monitor fires

• warn (default) — DENY lands as a non-blocking inbox notification; the agent’s tool call proceeds. The operator sees the warning and decides whether to tighten autonomy or update the agent’s persona. Recommended for new crews — false positives don’t break workflows.
• block — DENY interrupts the agent’s next tool call AND opens a blocking inbox approval. The operator has to confirm before the agent can proceed. Recommended for crews with established behavior-monitor confidence (the operator has seen the warn-mode signal pattern for weeks and is ready to trust DENY as a real signal).

​

Forbidden combination

​

self_learning_enabled — per-agent override on auto-apply

• F4.4 negative-learning — when the evaluator decides the agent should learn from a failure (writes a kind=negative row to lessons.md)
• F6 persona-suggest — when the agent proposes an update to its own PERSONA.md

• self_learning_enabled = 1 → ALLOW auto-applies (lesson lands, persona updates)
• self_learning_enabled = 0 → ALLOW queues a blocking inbox row with the full proposal payload; operator approves before the change lands

​

When to flip self_learning ON

• A long-running maintainer agent in a trusted crew that you’ve watched for weeks and trust to refine its own persona
• An agent whose persona drift has historically been benign (the operator has been approving every persona-suggest proposal anyway — the inbox approval is just noise)
• An agent whose mandate is well-defined enough that even a wrong lesson auto-applied is recoverable without operator cost

​

When to keep self_learning OFF

• New agents during onboarding (default — operators see what the agent proposes before it lands)
• Agents that act on production data where a wrong lesson could compound across many future interactions
• Compliance crews where every learning signal needs an operator’s name attached

​

Composition — worked examples

​

Example 1: trusted crew + self_learning OFF agent

​

Example 2: full crew + self_learning ON agent (max autonomy)

​

Example 3: strict crew + self_learning ON agent

​

Where to set them

​

autonomy_level + behavior_mode — per-crew settings

• Renders the four autonomy options as a 2×2 grid with descriptions
• Greys out the forbidden combination (block option when autonomy=full is selected)
• Requires a reason field whenever the policy values are dirty (audit trail)
• Shows the last change timestamp + reason at the bottom

crewship policy set my-crew --autonomy trusted --behavior warn \
  --reason "team has built confidence over Q2"

​

self_learning_enabled — per-agent setting

​

Audit history

• crews.autonomy_set_by_user_id / autonomy_set_at / autonomy_reason — last policy change (single row, last-write-wins)
• agents.self_learning_set_by_user_id / self_learning_set_at / self_learning_reason — last flag change
• keeper_requests — every decision the evaluators make (request_type, decision, reason, prompt, raw LLM response)

SELECT request_type, decision, reason, decided_at
FROM keeper_requests
WHERE requesting_agent_id = ?
  AND decided_at > datetime('now','-30 days')
ORDER BY decided_at DESC;

​

Cross-references

• Keeper guide — what the keeper does and how to write Phase-1 access/execute rules
• Inbox guide — operator workflow for approving the proposals these knobs route to inbox
• Agent memory — the memory tiers self_learning gates writes to
• Threat model — Tenant isolation — the F4 endpoints these knobs flow through