learn_from_attempts
Store lessons from successes and failures to automatically recall the best solution in future sessions.
Instructions
Store a lesson learned from a failed or successful attempt. Call this AFTER completing any non-trivial task (deploy, debug, fix, architecture decision). The lesson will be recalled automatically in future sessions via recall_best_solution. Fields: topic (short slug like "deploy:web"), outcome ("success"|"failure"), what_worked (what solved it), what_failed (what did NOT work), context (extra details). Supports structured metadata: severity, file_paths (files involved), commands (working commands), tags. Deduplication: if a lesson for this topic already exists, it is updated with full audit trail. Contradiction detection: warns if new outcome conflicts with existing lesson outcome. Confidence: lesson starts at 1.0, decays after 5d (→0.7) and 10d (→0.5) without recall. Example: learn_from_attempts(topic="deploy:api", outcome="success", what_worked="nohup docker compose up -d --build", what_failed="docker compose up hangs on SSH timeout", severity="critical", commands=["nohup docker compose up -d --build"])
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Topic tags for filtering (e.g. ["bash", "deploy", "env"]) | |
| group | No | Optional team scope — restricts this lesson to a named group/sub-team (e.g. "backend", "security"). Only members of that group (managed via team_grant_scope) and admins see it in smart_recall. Orthogonal to visibility: a team-wide lesson has no group; a private lesson is author-only regardless of group. | |
| topic | Yes | Short slug, e.g. "deploy:web", "debug:redis-tls", "fix:generate-series" | |
| author | No | Name or handle of the person storing this lesson (e.g. "alice", "bob"). Used for Team Telepathy — teammates see each other's lessons in session_start. Also powers brain_who_knows and team_expertise_map. | |
| context | No | Additional context, error messages, root cause (optional) | |
| outcome | Yes | Did it work? | |
| service | No | The service or system this lesson concerns (e.g. "prometheus", "cachly-web", "auth-service"). Builds a Service node in the knowledge graph linking the people who operate it and the files that run in it. Powers brain_service_map for instant incident triage. | |
| commands | No | Commands that worked or failed (e.g. ["rsync -avz ...", "docker compose up -d"]) | |
| severity | No | Impact severity: critical (blocks work/deploy), major (significant slowdown), minor (nice to know). Default: major. | |
| depends_on | No | Prerequisites this lesson depends on (e.g. ["node:>=20", "docker:running", "wireguard:active"]). When a dependency is marked stale, all dependent lessons get needs_review. | |
| file_paths | No | Files involved in this lesson (e.g. ["infra/deploy.sh", ".env"]) | |
| visibility | No | Who can see this lesson. "team" (default) = all team members. "private" = only accessible via exact recall_best_solution, never surfaced in smart_recall or team_recall. "public" = same as team (public syndication planned). | |
| instance_id | Yes | UUID of the cache instance | |
| what_failed | No | What did NOT work (optional but valuable) | |
| what_worked | Yes | What solved the problem or what approach succeeded | |
| service_kind | No | Whether `service` is an application service ("service", default) or infrastructure ("system", e.g. prometheus, kubernetes, redis). Shown as 🛰️/🖥️ in brain_service_map. |