AtlasClaw Release Notes

Provider instance boundaries are explicit during selection and execution

The core now separates Provider type from Provider instance. The type describes an integration capability, while the instance identifies a concrete system or data source.

That distinction matters when one AtlasClaw deployment connects to several systems of the same kind. A team can configure development CMP, test CMP, and production CMP as separate SmartCMP instances, or connect multiple Markdown Vault instances for product docs, operations runbooks, and project delivery material.

• Capability selection, tool projection, and execution keep the chosen Provider instance in scope.
• Provider scripts receive only the active instance configuration, which avoids leaking unrelated instance settings into the script environment.
• User-facing capability lists hide internal Skill snapshots and expose a cleaner set of selectable capabilities.

Multi-step flows rely less on fixed confirmation phrases

Earlier workflow continuations could depend on fixed confirmation wording. v0.9.11 moves that decision closer to the model and the available runtime evidence.

• An activated Provider Skill can stay active across follow-up turns when the conversation still belongs to the same flow.
• When a question does not need another tool call, AtlasClaw can keep a direct answer path grounded in existing evidence.
• Generated files and intermediate artifacts stay inside the user workspace so they remain traceable.

Conversation replay and private model compatibility are cleaner

This release fixes several details in history handling and model adaptation, including preserving the user's original wording, keeping runtime system prompts out of replayed history, and normalizing system prompts for OpenAI Chat API-compatible models.

• Multi-turn conversations are less likely to be affected by stale runtime instructions.
• Original user wording is preserved more completely during error recovery and evidence tracing.
• vLLM, Qwen, and other local or privately deployed models receive system prompts in a more compatible form.

Long-running deployments get more runtime controls

The production configuration set continues to grow. v0.9.11 adds practical operational pieces for container logging, VM service management, and database connection health.

• Container logs can follow standard rotation policies, reducing unbounded log growth in long-running deployments.
• VM deployments can use the systemd and logrotate templates as a starting point for service management and log retention.
• MySQL connection pool pre-ping can be configured for environments where network behavior or database timeouts require explicit connection checks.

Multiple Markdown knowledge bases can be queried directly at runtime

Markdown Vault moves from database-indexed retrieval to runtime Markdown file scanning. After configuring the vault path, include and exclude rules, and context budget, teams can expose internal documents, runbooks, design notes, or Obsidian notes as read-only AtlasClaw knowledge sources.

• SQLite or MySQL index tables are no longer required for Markdown Vault retrieval.
• A single AtlasClaw deployment can keep product documentation, operations runbooks, and customer project material in separate vault instances.
• Search and get outputs are treated as internal evidence; the agent generates conclusions, rationale, and references from that evidence instead of returning raw retrieval blocks.

Request field contracts reduce cloud automation failures

The SmartCMP Provider now carries clearer Compute and VM request field rules. For example, `systemDisk` must be submitted as an object, such as a JSON object containing the disk size. It should not be reduced to a number or string, and it should not be moved under `params`.

• System disk, flavor, image, network, and security group fields now map more closely to the SmartCMP API contract.
• Field names declared in generated Markdown should be preserved exactly, which reduces failures caused by rewriting request parameters.
• The contract improves resource request, approval, and automated delivery success rates.

Core stays neutral while Providers own system-specific rules

The release keeps the Core and Provider boundary strict. Core owns runtime selection, orchestration, and permission framing; Providers own authentication details, field structures, business semantics, and retrieval behavior for each target system.

• Markdown Vault remains a read-only knowledge boundary and does not automate document writing or Obsidian operations.
• Provider metadata stays runtime-neutral instead of encoding concrete business systems into Core rules.
• New enterprise systems can reuse the Provider package structure and Skill constraints without pushing system assumptions into the Core.

Long-term memory makes repeated agent work continuous

The core now supports long-term user preferences and usage profiles. When permissions allow it, the agent can remember work habits, preference details, and recurring context so future conversations start with useful context already in place.

Memory is isolated by user. That isolation is essential for enterprise deployments where multiple employees, teams, and external entrypoints share the same platform.

• Useful for internal knowledge collaboration, personal assistant workflows, operations Q&A, and ongoing project follow-up.
• Reduces repeated prompting when users return to similar tasks.
• Prevents user profile data from crossing account boundaries.

Ownership and write checks make the multi-user boundary easier to reason about

Enterprise agents need to be useful without becoming over-permissive. This release strengthens agent run ownership checks, session creation validation, memory write validation, and the common authentication provider foundation.

• Separates user identity, session ownership, memory access, and skill execution rights more clearly.
• Improves the foundation for teams, departments, web users, IM users, and webhook callers using the same deployment.
• Makes authorization behavior easier to audit and explain.

Sessions are more stable across web, IM, and webhook traffic

The session and gateway layers now handle session keys, external session identifiers, idempotency caching, and runtime user paths more reliably. These changes are not headline features, but they make real enterprise entrypoints behave more predictably.

• Web UI, IM channels, and webhook entrypoints can coordinate against cleaner session state.
• Tool selection is more stable during multi-step tasks.
• History replay is cleaner and less likely to include runtime noise.

IM and webhook interactions fit real-time enterprise workflows

When users send requests through enterprise chat channels such as WeCom, Feishu, or DingTalk, AtlasClaw can return immediate acknowledgement that the request was received and is being processed. Webhook integration also gains configurable shared-secret support.

• Improves perceived responsiveness for alerts, approvals, automation requests, and enterprise robot workflows.
• Strengthens system-to-system invocation with a clearer shared-secret boundary.
• Keeps webhook AI integration suitable for real-time operational scenarios.

Administration and deployment are better suited for daily operations

The frontend management experience received refinements around session history, runtime panels, role-permission display, and deletion confirmations. Deployment assets now cover standardized runtime logs, log rotation, Docker, systemd, and logrotate patterns.

• Helps long-running deployments with troubleshooting, maintenance, and audit work.
• Makes day-to-day admin panels more predictable for operators.
• Improves the handoff from local evaluation to production operations.

Markdown Vault provider turns existing documents into agent-ready knowledge

The new markdown-vault provider connects AtlasClaw to local Markdown repositories. It supports document parsing, knowledge retrieval, and question answering grounded in local material.

• Team handbooks, operations knowledge bases, project documents, and internal wiki exports can be reused directly.
• Organizations can make existing document assets conversational and searchable without a heavy system rebuild.
• The capability fits local-first and controlled-knowledge deployments.

Resource request, approval, and operations flows gained depth

SmartCMP provider work expanded the full resource lifecycle: natural-language request capture, approval assistance, resource operations, compliance evidence, and resource views shared across operational skills.

• Resource requests now support same-type multi-instance requests, schema-driven multi-instance input, and more reliable matching among services, packages, and parameter specifications.
• Approval capabilities include pre-approval support, approval detail lookup, pending-list display, specification-name normalization, and more structured approval output.
• Operations workflows support parameter-free resource changes, resource evidence lookup, and selecting compliance-analysis targets by name or list index.

Authentication, GitHub, and document skills broadened integration coverage

The provider repository added stronger SmartCMP provider token authentication and webhook robot execution profiles. It also added a GitHub provider with token-based authentication and expanded shared document-generation skills.

• Webhook callers can run skills under clearer robot identities and credential boundaries.
• GitHub integration establishes a foundation for issue, pull request, and repository workflows.
• Text generation, XLSX spreadsheet handling, and presentation artifact access bring documents, tables, reports, and slides closer to the agent workflow.

Thin Core, Rich Providers became the platform boundary

AtlasClaw keeps the core responsible for routing, lifecycle management, and execution coordination. Business logic lives inside provider packages instead of accumulating in the core runtime.

• New systems can be connected through provider packages rather than core-code changes.
• Each provider owns its authentication model, exposed skills, execution scripts, and audit conventions.
• Provider-qualified names such as {provider}:{skill} keep capabilities explicit and avoid collisions.

The flagship provider covered cloud management operations end to end

SmartCMP integration grew into 11 skills covering core cloud management scenarios: resource pool lookup, asset management, host lifecycle operations, resource self-service requests, approvals, alert analysis, cost optimization, compliance assessment, and webhook-driven pre-approval review.

• Users can describe a resource request in natural language and let the agent help structure the platform request.
• The provider connects request creation, approval flow, and operational follow-up instead of stopping at form submission.
• Cost, alerting, and compliance workflows gained a shared provider context.

Project management became conversational while staying mapped to controlled skills

The Jira provider defined five skill areas for project management: issue operations, advanced JQL search, bulk actions, field and agile configuration discovery, and worklog and reporting capabilities.

• Implemented issue management supports creating, querying, updating, and closing issues.
• Planned advanced operations include saved filters, export, bulk state changes, bulk assignment, and cloning.
• The provider model keeps Jira-specific fields and workflow semantics out of the core.

Engineering workflows entered the AtlasClaw execution model

The GitHub provider work brought code collaboration systems into the same provider framework. Token-based authentication gives users a path to handle issue creation and management, pull request collaboration and review, and repository information lookup through the agent conversation.

• Teams can begin moving routine engineering operations into governed agent workflows.
• The provider approach avoids treating repository operations as personal, unbounded tool calls.
• Issue, PR, and repository actions become candidates for permissioned enterprise execution.

Community skills expanded what the agent can produce

Beyond provider integrations, the ecosystem added shared skills for generating work products and supporting agent development.

• Document generation covered Word, PDF, and PowerPoint outputs.
• General skills included GitHub operations, brainstorming, long-text summarization, provider and skill scaffolding, skill quality checks, and output humanization.
• The shared-skill layer makes AtlasClaw useful for both system operations and knowledge-work artifacts.

Multiple access patterns made the agent available where employees already work

AtlasClaw connected enterprise chat channels and embedded iframe surfaces so employees do not need to learn a new tool before reaching the agent.

• IM access supports familiar workplace channels such as Feishu, DingTalk, and WeCom.
• Embedded iframe layout allows an agent conversation window to live inside existing business systems.
• The same execution layer can serve web, IM, embedded, and webhook entrypoints.

Enterprise controls became architectural features, not add-ons

The platform introduced security and governance capabilities required by enterprise deployment rather than treating them as optional wrappers.

• Authentication supports local auth, OIDC JWT, OIDC login, social login such as Google and GitHub, and enterprise SSO such as Keycloak, Okta, and Azure AD.
• Sensitive data is stored with AES-256-GCM encryption.
• Agent execution inherits real user permissions, tenant isolation uses path prefixes and tool policy filtering, and write operations require user confirmation.

LLM-first routing and workflow orchestration reduced hard-coded behavior

The v0.9.x line introduced an LLM-first routing model and a workflow engine. Together they make the agent better at deciding which tool or skill to use and how to organize multi-step, cross-system work.

• LLM-first routing lets the model infer the right tool or skill instead of relying only on hard-coded name matching.
• Workflow orchestration supports multi-step business processes across systems.
• Providers can define their own workflow patterns while the core keeps one execution model.

Lifecycle hooks and deployment options made customization practical

The hook system grew to cover 17+ phases of the agent lifecycle, while deployment options covered embedded and standalone use cases.

• Hooks support configuration-driven script handlers, typed runtime events, per-user state persistence, and script fault isolation.
• Deployment supports embedded mode inside existing products and standalone mode as a unified enterprise AI entrypoint.
• Container, database, and model choices include Docker/docker-compose, SQLite for development, MySQL via Alembic migrations for production, public model providers, and private Ollama deployments.