Feature Requests

There does not seem to be a way to move assets for an employee to a different person when their employment is terminated (in a similar way that Onedrive move, shared mailbox, password vault migrations etc) and there does not seem to be a way to even see if someone has agents and workshop items that the business could be relying on. Please provide the ability to move resources to a different user. Ideally this would function the same way that Keeper or Onedrive does, where all assets show up under a FromUserX tag/folder.

Please add options either at a Partner Admin or tenant level options to configure credit limits/alerts. With 8000 users across our tenants our admin accounts are being inundated with credit limit alerts and notifications. Under tenant settings, please add an option of email notifications with the selection of either user or role based. Adding a user to a role will allow them to receive the alerts.

Hatz already offers a native Autotask integration, which covers our PSA. The other two Kaseya products we run daily — Datto RMM and IT Glue — have no integration, and Kaseya doesn't publish a first-party MCP server for either, so the only path today is building and maintaining a custom MCP wrapper. Requested capabilities: Datto RMM (API v2): look up devices/sites, pull alerts and audit data, view open alerts per site, and optionally run approved components — so agents can triage tickets with live endpoint context. IT Glue: search organizations, configurations, flexible assets, and documents (passwords excluded or read-restricted), so agents can answer "how is X set up at client Y" from our documentation. This request already has strong community support on your feature board: https://hatz-ai.canny.io/feature-requests/p/itglue-integration Why it matters: With Autotask + Datto RMM + IT Glue connected, a Hatz agent could take a ticket, pull the affected device's status, and reference the client's documentation in one conversation. That's the core MSP workflow, and it would make Hatz significantly stickier for Kaseya-stack MSPs.

We have multiple staff members report that the Hatz platform delivers noticeably slower response times compared to competing LLM platforms (ChatGPT, Claude.ai , Perplexity), with a key frustration being the visibility of verbose internal tool calls, reasoning chains, and processing steps that clutter the UI and delay perceived response time. This issue persists across multiple LLM models within the platform, indicating a systemic platform-level UI/rendering problem rather than a model-specific issue. We recommend optimizing response delivery to hide or defer tool calls and reasoning logic from the primary output stream by default, allowing users to see clean, actionable results immediately, with detailed reasoning available only on demand via an expandable section or user preference toggle.

We need a tree view of branching so that we can track branching and sub-branching tracks. I use branching quite often and it's hard to find the branching points to review info in the various branches.

I'd like to see a way to save or export the settings for a Workflow/App to document a "last known good" configuration in case Hatz system changes or bad user changes breaks an important operation for a customer.

Platforms like Claude have popularized "skills" — structured, multi-file AI instruction packages that go well beyond a basic system prompt. A skill bundles a core instruction file, reference documents the model loads on demand, supporting assets, and a trigger description that controls when it activates. Users are building skills for everything from technical playbooks to domain-specific mentors to operational runbooks, and this pattern is becoming the standard way power users encode reusable expertise into AI. Currently, there's no way to import these into Hatz. Users who've built skill libraries on other platforms have to manually recreate them as separate Apps or Agents, losing the multi-file structure and progressive context loading in the process. For MSPs onboarding teams onto Hatz, this creates unnecessary migration friction and duplicated effort. The core ask is a skill import pipeline that accepts a standard skill package (ZIP with a SKILL.md at root + optional reference files and assets) and converts it into Hatz-native Workshop items — mapping instructions to Agent system prompts, reference files to knowledge sources, and descriptions to Workshop metadata. Unsupported components would be flagged during import so the user knows what needs attention. The bigger unlock is skill routing in Chat. Once skills exist as first-class objects, Hatz could evaluate a user's message against available skill descriptions and automatically load the right expertise context — no manual app or agent selection required. This would transform Chat from a general-purpose LLM interface into a context-aware assistant that knows which domain knowledge to pull in based on the question. Long-term, this naturally extends into multi-tenant skill distribution and a community marketplace — the same management model Hatz already does well with Apps and Agents, applied to portable, versioned expertise packages that MSPs can build once and deploy across all their tenants.

Workflows were to be apps that can be strung together. If you already have several apps that perform the steps you want for a full workflow, you have to recreate them in the workflow. When creating a workflow, we can [+ prompt section], how about a [+ App ID] (select our app name or id) and then our app becomes part of the flow. Use case for his is there are 6 apps that are used with each other to analyze data for a report - we use a combination of these 6 apps monthly. A different person has created each of the apps. Sometimes you would use Apps 1, 2, 3, 4, 5, and 6. Other times you would only need apps 2, 4, and 5. While other times you would need apps 1 and 6 only. The first prompt (prompt 0) could be your selection of which ones you needed and the login in the workflow would take this input along with your document (any other input) and begin the process by calling the apps you selected. This is done today using power automate manual run with inputs and then the power automate flow calls the appropriate app IDs via API, gets the output and passes to the next app id, etc. Will be great when an entire Workflow can be automatically launched via the workflow ID just the like the apps are with their AppID.

So we can have a default off if we want, especially during onboarding.

===================== Current Behavior: ===================== Tool, model, and file/artifact settings within a chat do not reliably persist between sessions. For example, if Auto-Tool is enabled in a chat and the user navigates away and returns, the setting may revert to its previous state — or the inverse may occur. The same applies to other per-chat settings such as model selection and file/artifact configurations. Each return to a chat may require the user to re-verify and re-apply these settings before continuing work. ===================== Desired Behavior: ===================== Each chat should store its tool, model, and file/artifact settings as persistent variables tied to that specific chat. Whenever a setting is changed, the stored value is updated immediately. When a user returns to a chat, those settings are restored exactly as they were left — no manual re-application required. This should be consistent regardless of how much time has passed or how many other chats have been opened in between. ===================== Use Case: ===================== When working within a specific chat that has been configured with a particular model, tool set, or artifact context, it is disruptive to return to that chat and find those settings have reset. This creates unnecessary friction — especially for chats that are revisited frequently or are part of an ongoing workflow where the configuration is intentional and meaningful. With persistent per-chat settings, a user could confidently leave and return to any chat knowing it will be in the exact state they left it, reducing setup overhead and preventing errors caused by working under the wrong model or toolset without realizing the settings changed.