Biz AI: Proactive AI Employees for Enterprise Systems, With Write Access Still in Human Hands

Meta's Muse, launched last September, showcased a new form of personal agent: it works in the background triggered by schedules or events, remembers prior conversations, can act on your behalf, and pops up approval cards before sensitive operations. Now, an open-source project called Biz AI brings this model into enterprise business systems—giving each employee an AI employee that runs in the chat tools they use daily and strictly adheres to that employee's own permissions.

From Personal Assistant to Enterprise Employee: Porting the Muse Model

According to the project's introduction on Reddit, Biz AI aims to make AI a "proactive colleague" within enterprise systems rather than a passive Q&A bot. It notices changes in business systems—overdue checks, new requests, unhandled approvals—and notifies only the relevant people. It then asks the right people questions, follows up on matters, sends approval cards with reply codes, drafts proposals, and remembers preferences and past conversations. It can also generate reports on a schedule.

The key to this design is the balance between being "proactive" and "restrained." The AI doesn't wait for users to ask questions but proactively pushes information based on business events; yet its scope of action is strictly limited to reading and proposing.

Core Principle: AI Never Writes; Humans Retain Final Decision-Making Authority

The project's most distinctive stance is: AI cannot perform write operations. Every write is a proposal that must be accepted by a human; confirmations, approvals, and amount-related operations are always completed by humans. The AI can only read what the employee already has permission to read (based on a combination of roles and lists), and "who should be notified" is determined by the business system itself.

This design addresses the most practical concern when enterprises deploy agents: if AI can directly modify data, once errors or permission overreach occur, responsibility and losses become difficult to control. Biz AI returns write access to humans, keeping AI in the role of "advisor," thereby lowering the trust barrier.

Role-Based Access Control (RBAC) and list-based authorization are two common forms of enterprise permission systems. RBAC grants permissions by job role—simple but coarse-grained; lists (ACL/allowlist) authorize specific resources item by item—fine-grained but costly to maintain. Biz AI combines the two: roles determine which category of resources an employee can access, and lists further restrict specific entries, precisely narrowing the AI's read scope to the set of "what the employee themselves can see." The significance of this approach is that AI doesn't introduce a new permission surface but reuses the enterprise's existing authorization decisions—what AI can read is entirely derived from the employee's original permissions, keeping the security boundary consistent with manual operations and requiring no separate modeling for AI during audits.

Event-Driven and Permission Isolation: Keeping Proactive Behavior Within Bounds

Biz AI's proactivity is built on a reliable event mechanism. The project documentation mentions that events and business changes are written in the same transaction (outbox pattern), so notifications cannot appear out of nowhere or be lost. This means every "proactive reminder" from the AI corresponds to a real business change, not a product of model hallucination.

Regarding permissions, the AI's read scope is limited to the employee's own visibility, constrained jointly by roles and lists. The business system determines who receives information; the AI is merely the channel for executing notifications. This layered design returns security responsibility to the enterprise's existing permission system rather than relying on the AI to judge for itself.

The outbox pattern is a reliability pattern widely used in microservices and event-driven architectures. Its core approach: business data changes and "pending events" are atomically written in the same database transaction—events are first persisted to an outbox table, then asynchronously read by a separate delivery process and forwarded to a message queue or notification system. Because both share the same transaction, they either succeed or roll back together, preventing inconsistency such as "data changed but notification wasn't sent" or "notification sent but data wasn't changed." Compared to directly calling messaging middleware within business logic, the outbox pattern decouples "event generation" from "event delivery," allows retries on delivery failure, and naturally provides at-least-once semantics. The article's statement that "events and business changes are written in the same transaction" relies on this mechanism to ensure every proactive reminder from the AI corresponds to a real business change.

Up and Running in Three Minutes: A Demo Environment Without an API Key

The project offers an extremely low-barrier way to experience it. According to the author, just three commands are needed to run the demo locally: clone the repository, install dependencies, run the demo. The demo uses a real agent runtime, scripted models, simulated chat, and a disposable PostgreSQL (inside Docker), requiring no API key.

The minimal example is a single file of about 300 lines and passes a conformance test suite of 52 checks. The project is built as a DeepSeek^Ad Harness plugin, uses the Apache-2.0 license, and states it is not affiliated with Meta.

Cross-Verification from Multiple Sources

The core facts above are consistently presented in the project repository and the author's technical write-ups: writes require human approval, reads are constrained by roles, and events and business changes are written in the same transaction—these points corroborate each other across the Reddit post and the dev.to article. The author also actively invites questions from people with real enterprise deployment experience, indicating the project is still at the feedback-seeking stage rather than a mature commercial product.

DeepSeek Harness refers to the agent runtime framework/plugin system built around the DeepSeek series of models, providing foundational capabilities such as tool calling, session management, and event integration; developers extend business logic on top of it as plugins. Biz AI's choice to build as a plugin means it reuses the host framework's model invocation and runtime while implementing enterprise business logic, permission constraints, and approval workflows at the plugin layer, thereby decoupling from any specific model. The Apache-2.0 license is a permissive open-source license that allows commercial use, modification, and redistribution, requires retention of copyright and license notices, and includes a patent grant clause—suitable for projects seeking enterprise integration.

Why "AI Can't Write" Is Actually the Key to Enterprise Adoption

The obstacle to enterprises adopting AI employees is often not technology but the boundary of responsibility. Once AI has write access, auditing, compliance, and error rollback all become complex. Biz AI chooses to position AI as a "proposer," letting humans retain confirmation, approval, and amount decision-making authority—effectively trading product design for trust space.

This approach is in line with Meta Muse's approval cards, but Biz AI goes further: it binds the permission model directly to the enterprise's existing role system rather than letting AI judge for itself who should know what. For teams attempting to integrate agents into real business systems, this open-source project provides a constraint framework worth referencing.

The project's code and documentation are publicly available on GitHub, and the author welcomes discussion with people who have enterprise deployment experience.

One-line Summary

Open-source project Biz AI brings Meta Muse-style proactive agents into enterprises, insisting AI is read-only and writes require human approval.

Paragraph Summary

Biz AI is an open-source project that ports Meta Muse's proactive personal agent model into enterprise business systems, equipping each employee with an AI employee running in chat tools. It works proactively on schedules or business events, notifying only relevant people, and can ask questions, follow up, send approval cards with reply codes, draft proposals, and generate reports. Its most distinctive principle is that AI never writes: every write is a proposal requiring human acceptance, and confirmations, approvals, and amount decisions are always made by humans; read scope is constrained by employee roles and lists, and notification recipients are determined by the business system. Events and business changes are written in the same transaction via the outbox pattern, avoiding fabrication or loss. The project offers a three-minute local demo requiring no API key, is built as a DeepSeek Harness plugin, uses the Apache-2.0 license, and the author is inviting feedback from those with enterprise deployment experience.