UniEmployee

What UniEmployee does

UniEmployee is an enterprise platform for building and running AI digital employees. The README describes it as turning staff experience, business processes, and judgment into always on, configurable, approval gated, and fully observable AI employees. Rather than a set of personal productivity tools, the goal is to encode whole roles, such as customer service, sales, data analysis, and HR, into employees that can take on organizational work. The project is presented in both Chinese and English, with the English README summarizing the same points.

The design rests on a five layer capability model: Employee, Workflow or SOP, Skill, Connector, and Tool. An Employee is assembled from a persona, a model, skills, tools, a knowledge base, SOPs, and connectors, all configured through pages. Workflows and SOPs capture procedures, with key business flows fixed as state machine workflows that can include human approval nodes so multi step processes run correctly. Skills are stored as SKILL.md specifications that the model consults on demand instead of guessing from memory. Connectors bring in external systems through the MCP standard, and Tools are atomic actions such as tickets, search, document generation, and data analysis. By stacking these layers, the platform orchestrates a large language model into a worker that can be assigned a specific job rather than used as a generic chatbot.

Building and running employees

Building an employee is page driven. The README says persona, model, skills, tools, knowledge base, SOP, and connectors are all configured in the admin UI, and at runtime the catalog is the source of truth. Five example employees ship built in: customer service, data analysis, sales advisor, HR, and business analysis, and they support soft delete and recovery. The compilation step reads the employee configuration and assembles tools and connectors, seeds skill content into a store, and stitches together the system prompt before producing a runnable agent.

The runtime isolates memory and cache by the pair of employee and user, and routes skills and memory to different namespaces through a composite backend. The documented core flow has six steps: create the employee, configure its abilities from the resource center, start a conversation, watch execution and observability in the trace view, intervene at approval nodes when needed, and keep operating as long term memory accumulates. The README also lists a conversational workbench where streaming answers show the thinking and tool call process, and the skill and knowledge base load dynamically at runtime. This page based, catalog driven approach is what lets non engineers assemble a working employee without writing agent code by hand.

Knowledge, memory, and observability

Knowledge is treated as a structured business ontology rather than plain document search. The README explains that knowledge is organized by topic, rule, playbook, and source into semantic assets with business meaning, so an employee answers from real material and cites its origin. The current version already connects a product FAQ base, a markdown product wiki, and a deeper RAGFlow knowledge base, with concept typing and retrieval debugging still in progress. Source tracing means an answer can be followed back to the original document and section.

Memory spans sessions and is isolated by user and employee, persisted to store.db so it survives restarts. Conversations that grow long are auto compressed: when context hits an 85 percent window ratio, or a 170,000 token threshold otherwise, old messages fold into a summary while the full history is written to disk for later review. Tool parameters are slimmed first, and if the model still reports over budget the system compresses and retries, so long chats do not break. Every conversation or approval resume is recorded as a run that captures LLM and tool inputs, outputs, timing, and token use, and can be replayed. High risk actions trigger human in the loop approval, pausing mid flow until a person approves and the process resumes automatically.

Operations, security, and licensing

The stack is Python 3.12 or newer on the backend and Vue 3.5 or newer on the frontend, with a FastAPI service and PostgreSQL storage. Docker Compose brings up the database, which on first start creates seven business databases: catalog, conversations, checkpoints, store, traces, approvals, and ontology, each with a stated role. A single process serves the full app including static frontend files, and a health endpoint returns status ok. Tests use pytest with fixtures that swap in a temporary SQLite database so real data is never touched, and slow tests that need network or a browser are marked and skipped by default.

Security has a defined baseline. All interfaces require a bearer token, anonymous requests return 401, and login is rate limited per IP and username. The JWT secret must be changed to a long random string, and the admin default password forces a change on first login. LLM output from the frontend is passed through an HTML sanitizer to prevent cross site scripting. The README also lists environment variables for the model, database, logging, and RAGFlow, and a roadmap covering multi replica deployment, the knowledge ontology, a recycle bin UI, forced password change, multi tenant isolation, and group chat with multiple employees. The project is MIT licensed and credited to ZJ-Unicom-AI.

Editorial conclusion

UniEmployee is published under the MIT license and requires Python 3.12 or newer, with the source at github.com/zj-unicom-ai/UniEmployee.