# Magic by dtyq: Enterprise AI Agent Platform with Human-in-the-Loop Controls > Magic is an open-source TypeScript platform from dtyq that packages AI agents, a workflow engine, instant messaging, and collaborative document editing into a single self-hosted system designed for enterprise use. Its defining design choices are sandbox isolation for every agent, an approval gate before high-risk actions, and per-department budget caps that make AI spending predictable. **dtyq/magic** — Magicrew. The first open-source all-in-one AI productivity platform (Generalist AI Agent + Workflow Engine + IM + Online collaborative office system) - Repository: https://github.com/dtyq/magic - Website: https://www.magicrew.ai/ - Stars: 5,046 · Forks: 567 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-09 · Updated: 2026-09-09 · Language: en - Canonical page: https://hysenlabs.com/projects/dtyq-magic ## The problem Magic is built to solve Personal AI tools create a set of problems that compound when used inside an organization. Employee data lives in individual accounts and leaves when the employee does. API costs are unpredictable. Staff using external tools expose sensitive data to third-party infrastructure. AI agents that can delete files or send emails have no approval gate. Internal systems such as ERP and CRM remain inaccessible because they cannot be reached through a chat interface. Magic is built against that specific list of problems. The README frames each one as a pairing: the problem on the left, the platform's response on the right. Data locked in employee accounts is replaced by a unified data hub. Unpredictable API costs are replaced by per-department, per-user, and per-task budget caps. Third-party data exposure is replaced by in-house sandbox isolation. Uncontrolled destructive actions are replaced by a human approval gate. Inaccessible internal systems are wrapped as digital employees accessible through the same interface. The platform targets the full range from a one-person company to a ten-thousand-person organization. The README describes this as solving the same problem at both ends: the output of 100 people at the cost of one. That framing is consistent with the platform's position as infrastructure for AI workforce multiplication rather than as a productivity add-on. ## Seven core capabilities and what each one actually does The README describes seven enterprise-grade capabilities in detail. Enterprise knowledge consolidation encapsulates fragmented internal systems, including ERP, CRM, and databases, along with domain expertise, into what the README calls digital employees. These are agents that represent a specific function and can be invoked by other employees through their personal assistant. Results as deliverables means the platform produces finished artifacts rather than raw text. The built-in rendering framework converts AI output directly into presentations, data dashboards, meeting summaries, reports, Excel files, and infinite canvas images, ready to use without post-processing. Enterprise security and compliance runs every agent inside a proprietary sandbox container, isolated from the main system in a separate VPC with private endpoint connections. A sidecar network proxy manages traffic independently per user with complete resource and data isolation across tenants. Plugin code goes through a security review before publishing. Human-in-the-loop control triggers an approval workflow when an agent attempts a high-risk operation. Routine actions run without interruption. Destructive operations, such as deleting data or sending email, require explicit confirmation from a human before proceeding. Granular cost control sets daily budgets at the department level, the user level, and the per-agent level. The README describes AI spending as becoming predictable and controllable under this model. Team-wide collaboration shares a single project across multiple people, each owning different modules and advancing in parallel. Progress reports can be sent automatically to WeCom, DingTalk, or Lark groups. Open ecosystem compatibility means existing skills built for the Anthropic tools ecosystem and the OpenClaw skills ecosystem plug into Magic without migration. ## Personal assistants and expert agents as two complementary layers Magic structures its AI workforce into two tiers. The first tier is a personal assistant assigned to every employee. This assistant connects to calendars, email, internal systems, data sources, tools, and specialist agents. It acts as the interface through which an employee accesses the full platform. The second tier is expert agents, each representing a specific domain: legal, finance, sales, operations, and others. Each expert agent is described as deep and comprehensive within its domain. A new employee invoking a legal expert agent gets a response informed by the organization's codified legal procedures, not a generic AI response. The README frames this as moving domain expertise from being person-dependent to being an organizational asset. For a solo founder or a very small team, the model works differently. The README describes a scenario where a cross-border e-commerce team of eight people manages what would otherwise require eighty, with each person directing AI agents that cover the functions not yet filled by hired staff. The platform is positioned as equally appropriate for this case, with the same sandbox isolation and approval gate applying at any scale. This dual-tier model is a design choice with a specific trade-off: it requires an organizational decision about which functions to codify as expert agents, which takes time and configuration effort up front before the output-multiplication effect is realized. ## Deployment architecture and repository structure The repository contains a `backend/` directory, a `frontend/` directory, a `cli/` directory, a `config/` directory, and a `magicrew.yml` file at the root. This structure indicates a full-stack self-hosted deployment rather than a managed service, though the platform's homepage is at magicrew.ai. The `magicrew.yml` file is the deployment configuration entry point. The repository also includes a `thirdparty/` directory, a `bin/` directory, and `docs/`. The presence of separate backend and frontend codebases suggests the deployment involves running multiple processes. The README links to a self-hosted deployment section, though the specific commands were not included in the portion of the README available for review. The primary language is TypeScript, covering both frontend and backend. The repository has no GitHub Releases. The last push was on 2026-08-12, approximately six weeks before 2026-09-28, indicating active development at that point. For teams evaluating the operational cost of running Magic, the lack of a Docker Compose file or similar one-command startup script visible in the repository structure suggests that deployment requires working through the `magicrew.yml` configuration and the separate backend and frontend processes individually. ## Where Magic is the wrong choice Magic is not designed for individual developers who want to experiment with AI agents locally. The platform's architecture, with VPC separation, sidecar proxy per user, and multi-tier agent hierarchy, assumes an organizational context. A solo developer looking for a local AI assistant would find the setup overhead out of proportion to the benefit. The platform also assumes that someone in the organization is willing to codify domain expertise into expert agent configurations. This is not a one-time installation: it is an ongoing editorial and technical effort. Organizations without dedicated operations staff to maintain agent configurations will not realize the knowledge-consolidation benefit the README describes. The OpenClaw dependency mentioned in the README, and the Anthropic Skills compatibility, mean that the platform's behavior depends on external ecosystems. Changes to those ecosystems can affect Magic's functionality. This is a normal dependency risk for any platform with plugin architecture, but it is worth evaluating for compliance-sensitive deployments where external dependencies are scrutinized. The license is listed as NOASSERTION in the repository metadata. This means no standard open-source license was recognized. Commercial deployment without legal review is risky. ## Comparing Magic to Dify and similar open-source agent platforms Dify is an open-source LLM application development platform with a visual workflow builder and support for RAG pipelines. Both Magic and Dify are self-hosted and designed to sit in front of multiple LLM providers. The difference in approach is scope. Dify is a developer tool for building AI-powered applications, with an emphasis on visual workflow construction and API integration. Magic is designed to be an organizational operating system: it includes an instant messaging layer, a collaborative office system, and the organizational hierarchy of personal assistants and expert agents. Magic's target user is a department manager or a business operations person who wants to deploy AI across a team without writing code. Dify's target user is a developer building an AI application. For an engineering team building a product feature that needs an AI workflow, Dify's API-first design and lighter operational footprint make it a better fit. For an organization deploying AI to non-technical staff across multiple business functions, Magic's integrated IM and human-approval layer address problems that Dify does not include by design. ## Conclusion Magic suits organizations that want AI automation but cannot accept the data-leakage and cost-control problems that come with staff using personal AI accounts. The self-hosted architecture with sandbox isolation and VPC separation makes it appropriate for compliance-sensitive environments. It is not the right choice for individual developers who want a quick local assistant, because the platform is designed for organizational deployment with centralized configuration. Before committing to it, verify that your team can maintain the `magicrew.yml` deployment configuration and the backend and frontend services. The license is listed as NOASSERTION in the repository metadata, so legal review is required before commercial deployment. ## FAQ ### Does Magic support integration with existing ERP or CRM systems? The README describes wrapping internal systems including ERP and CRM as digital employees accessible to everyone in the organization. These systems are encapsulated into expert agents rather than accessed directly. The README does not name specific ERP or CRM platforms or describe the technical integration method. ### What license governs Magic's source code? The repository's license field is listed as NOASSERTION, meaning no standard open-source license was identified. A LICENSE file is present in the repository. Legal review before commercial deployment is necessary because the license terms are not identifiable from the standard metadata. ### Can Magic agents run autonomously without human supervision? The README describes routine actions as running autonomously around the clock, while destructive operations such as deleting files or sending emails require explicit human confirmation through an approval workflow. The human-in-the-loop gate applies to high-risk actions specifically, not to all agent activity. ## Sources - [dtyq/magic on GitHub](https://github.com/dtyq/magic) - [Issues](https://github.com/dtyq/magic/issues) - [Project website](https://www.magicrew.ai/) - [README](https://github.com/dtyq/magic/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dtyq-magic