What happened
Cosmicstack Labs released Mercury Agent v1.4.1 on October 24, 2026. The release is framed around three changes: Mercury learning how a person prefers to work, saving repeatable procedures as its own skills, and making its free web search return relevant results again. It also includes terminal fixes affecting pickers, session state after /new, and the status row.
The preference feature, described as ADR-026, changes memory into what the release calls beliefs with evidence. A belief has supporting evidence, a confidence level that fades if it is not encountered again, and a status: candidate, held, confirmed by the user, contested, retired, or forgotten. Mercury can learn preferences such as desired reply length, whether to ask before acting, whether to offer options or a recommendation, tone, and domain-specific expertise. The release says it will not learn health, religion, politics, or credentials. When learning changes behavior, Mercury ends a reply with a Noted line; “forget that” reverses it. Users can inspect or edit the stored material through /memory learned, /memory beliefs, /forget <text>, and the dashboard. Identity details remain in identity.owner in mercury.yaml, while memory.learning.provider can select a model for extraction independently of the chat model. On first start, the upgrade backs up second-brain.db, performs a one-time migration, and quarantines rather than deletes junk rows created by the old extractor.
ADR-027 covers self-made skills. Once a multi-step task that Mercury would repeat has completed end to end, the agent can save that procedure as a skill and reuse it. These skills are stored in ~/.mercury/skills/self-made/, listed separately from user-created skills, and reviewable with /skills self-made. They become dormant after 30 days without use, and Mercury limits the shelf to 40 skills. The release also says that skill categories and intent routing work again after a discovery bug had been wiping them.
The release replaces a failing keyless search path. Bing’s web RSS feed was returning unrelated pages to automated requests and DuckDuckGo was blocking them. Mercury’s web_search now queries Brave Search first, then Wikipedia, Hacker News, Bing News, and Google News, retaining only results that mention the query. fetch_url on a search-results page now performs a search rather than returning a block page. An installed DuckDuckGo-scraping web-search skill is replaced by the built-in implementation, while the original is retained as SKILL.md.replaced.bak. Mercury also fixes picker input in an attached terminal, ensures /new no longer leaves the interface permanently “Thinking,” and standardizes a status row showing session, permission mode, daily budget meter, and model. The npm upgrade command is npm install -g @cosmicstack/mercury-agent@1.4.1; standalone users can run mercury upgrade.
What the archive adds
This is a new fact on a known Mercury story. Mercury Agent 1.4.0 adds a plugin system with WhatsApp voice-call and Optimus computer-use plugins covered the preceding release. Version 1.4.1 moves from extending Mercury through plugins toward adapting its behavior and retaining its own procedures.
Trend signal
The release supports the pattern that skills become a portable capability layer, but also illustrates why the pattern depends on provenance, review, and behavioral evaluation. Mercury gives self-made skills a separate location, a visible review command, a dormancy rule, and a cap. Those are useful lifecycle controls, though the release does not establish that the generated skills are safe or correct.
Why now
Mercury 1.4.1 arrived one day after the 1.4.0 plugin release. The source does not give a broader market rationale, but its sequencing is notable: immediately after broadening the system’s plugin surface, the project added mechanisms for retaining user preferences and successful procedures across future work.
Connections to other events
Earlier archive material described Hermes Agent turning completed work into memory and new skills after a background analysis of conversations and tool calls. Mercury’s implementation is narrower in the supplied release notes: it saves a procedure after an end-to-end multi-step task works, then exposes the resulting skill shelf for review. Archive material also noted skill shadowing as a risk when a system has many skills; Mercury’s 40-skill cap and 30-day dormancy rule are relevant operating constraints, not proof that it avoids that failure mode.
Why it matters
Teams often accumulate agent behavior in prompts, chat history, or undocumented operator habits. Mercury’s change proposes a more explicit operational unit: a learned preference with status and evidence, plus a repeatable procedure captured as a skill. That can reduce repeated setup work when the same agent handles recurring tasks.
The practical value depends on governance. Builders should treat automatically saved skills as proposed operational artifacts, not as trusted automation. The visible shelf, separate directory, expiry behavior, and user-facing forgetting path make review more feasible than opaque personalization. Yet a team still needs to decide who approves a generated procedure, what permissions it receives, how it is tested, and when it should be retired.
What happens next
- Mercury will add more controls around reviewing or promoting self-made skills. (3 months, 60%). Watch for: approval, export, versioning, or test-related commands.
- Users will report whether the evidence and confidence states make preference learning easier to correct than ordinary memory. (6 months, 55%). Watch for: changes to belief states, evidence display, or forgetting workflows.
Limits and uncertainty
The release notes describe intended behavior but provide no benchmark, adoption data, task-success measurement, or security evaluation. They do not specify how Mercury determines that a multi-step task has worked “end to end,” what a generated skill contains, or whether it can call tools with the same privileges as its originating session. The stated exclusions for sensitive preference categories do not establish that unwanted inference cannot occur. Similarly, the search description lists sources and filtering behavior but does not measure relevance, coverage, latency, or reliability. The migration backup and quarantine behavior are described by the project; this source does not independently verify them.
Skill to build now
Create a small review loop for any agent that persists procedures. This week, select one recurring multi-step task, define what counts as a successful completion, and require a human to inspect the generated procedure before it is reused. Record its inputs, tool permissions, expected output, and a rollback or deletion path. Then run the same task again and compare the saved procedure with the original execution. That turns “self-improvement” into an observable artifact rather than an unexamined memory change.
Reader takeaway
Mercury 1.4.1 makes personalization and skill capture more concrete: preferences are represented as editable beliefs, and completed workflows can become bounded reusable skills. The useful question for a team is not whether an agent can remember, but whether its remembered behavior can be inspected, tested, approved, and removed.
Open question
What evidence threshold causes Mercury to save a self-made skill, and what permission and review model applies when that skill is reused?