Trust,
written as facts
you can audit
All four business lines run in production, and all of them deploy privately. We do not claim to be industry-leading — we write scale as numbers you can count in the repository. Every figure below is open to audit.
01$ zhenbei platform --overview0203 ✓ uiam identity control plane 16 domains · 56 tables04 ✓ uniclaw multi-tenant agent runt 25 modules · 19 tools05 ✓ uniscrm private-domain scrm 132 controllers06 ✓ unilearning modular learning mono 8 domains · 1 binary0708$ zhenbei tools --list0910 legdger encrypted local-first ledger [ios, macos, cli]11 newtool rust algorithm kernel [desktop, cli, mcp]12 pxc capture proxy + relay [macos, windows, cli]1314$ zhenbei deploy --mode private15 100% of business lines support private deployment1617$ zhenbei verify --production18 4/4 business lines in production · 0 external SaaS deps1920$ zhenbei integrations --count21 5 groups · 30 integrations · 6 identity sources · 4 model vendors2223$ _What changes after go-live
Client names are industry-anonymised under confidentiality terms, but every before-and-after is a real delivery outcome: five passwords become one, six deployment units become one, integration time cut in half. Open any story to see where each number comes from.
Replace “scale” with things you can count
“We are big” carries no information. Below are controller counts, table counts, module counts and migrations — every one countable in its repository. We check the code before changing any of them.
Not “available on request” — the default delivery form. No external SaaS dependency; it runs fully air-gapped.
Kotlin, Java, TypeScript, Go, Rust, Swift — different languages, identical boundary rules.
Migration tooling, legacy data import, rollback plans and runbooks ship together with the product.
KotlinUIAM identity kernel · Uniscrm business modules
JavaUniscrm WeCom server side
TypeScriptUniclaw agent runtime · console
GoUnilearning modular monolith · pxc kernel
RustNewTool algorithm kernel · CLI · WASM
Swiftlegdger on iOS and macOS · pxc macOS shell
Not four isolated systems — one kernel with three applications on top
UIAM supplies identity, credentials and authorization. The other three lines share that kernel and connect to each other through token exchange and tool-level grants. The tool matrix shares a single engineering standard: kernel separated from shell, with AI as a first-class citizen.
The identity kernel is not a login shell: tenant filtering is enforced by a jOOQ VisitListener in the query layer, agent delegation runs through RFC 8693 token exchange, and tool calls must pass tool-level authorization.
UIAMUniclawIdentity issuanceAgents register as MACHINE principals; credentials, scopes and tool permissions are issued by the identity kernel and can be revoked instantly
UIAMUniscrmEmployee identityThe internal account system connects to unified identity, converging login, roles and permissions in one place
UIAMUnilearningremote modeSwitching the auth domain from local to remote completes the integration, with no changes to any other domain
UniclawUniscrmDigital workersAgents handle common enquiries in service scenarios, and past conversations become their knowledge source
UniclawUnilearningAI gradingOne LLM abstraction layer: Unilearning uses it to draft grading, and the teacher makes the final call
UniscrmUnilearningCustomer trainingPrivate-domain customers can become learners, with orders and progress unified in one customer view
Running internally before they ship, sharing one engineering standard with the business lines
Four business lines, one engineering standard
Each line has its own kernel and runtime, but they share one set of principles: contract-driven, boundaries enforced by the compiler or framework, private-deployable, observable. Behind every line is real code already running in production.
A unified identity control plane for people, service accounts and AI agents. Built on Kotlin, Spring Boot 4 and Spring Security 7 with an embedded OAuth2 authorization server: 16 data domains, 56 tables and 77 controllers covering everything from tenant isolation to tool-level authorization for agents, homogeneous across MySQL and PostgreSQL.
Consolidate the accounts, permissions and audit trails scattered across every business system into one governable identity kernel.
Digital workers that think, remember and grow. Built on NestJS 11 and Prisma 7: 25 business modules covering the cognition loop, three-tier memory, a five-layer persona, skill evolution and multi-agent collaboration; 19 built-in tools ready to use; multi-channel access via WeCom, Feishu, DingTalk, web chat and API.
Not another chatbot shell — an agent runtime with a cognition loop and long-term memory.
Turn WeChat and WeCom user assets into a private-domain growth engine you can operate, measure and replicate. Built on Java / Kotlin and Spring: 16 WeCom business modules and 132 controllers covering customer assets, conversation archiving, group operations, QR-code acquisition, content marketing, customer service and risk control.
From the first friend request to repeat purchase — the whole journey is traceable, measurable and reviewable.
An online learning SaaS for enterprises, institutions and individuals, rebuilt as a Go modular monolith: 8 business domains (auth / cms / eas / ocs / oms / osm / quiz / ai) aggregated in-process, folding 6 microservices into 1 binary and 1 container, with domains communicating only through api contracts and the internal wall enforced by the compiler.
From course publishing to AI-assisted grading, every step of the teaching loop is a business domain that can evolve independently.
The same questions, asked of all four lines
This is not a feature list — it is one set of engineering questions answered across four lines. Some cells read “partial” or “n/a”. We do not smooth the numbers into a single story; the differences are the point.
| Dimension | ||||
|---|---|---|---|---|
Tenant isolation Is the tenant boundary enforced in the data access layer | ||||
Private deployment Can it run inside the customer network, fully air-gapped | ||||
Dual-database parity One codebase running on two databases | ||||
Compile-time boundaries Out-of-bounds access rejected by the compiler or framework, not by documentation | ||||
Agents as first-class citizens Identity, credentials and read-only interfaces reserved for AI agents | ||||
Structured audit Key actions recorded, searchable and replayable | ||||
Versioned migrations Database changes repeatable and rollback-able | ||||
MCP / tool authorization AI connects over a standard protocol, with calls constrained by permissions | ||||
Legacy data migration Existing data importable with IDs preserved |
30 integrations across 5 categories
Identity sources, collaboration channels, models, data and middleware, gateways and runtimes. The four lines are written in different languages, but their infrastructure converges on one set of standard parts — which lowers the operational load on our customers.
Identity sources & social login
uiam-connectorQR-code login and directory sync; the org structure becomes the identity source, and join/leave events drive account lifecycle.
OAuth2 authorization code + directory callbackWeChat login and user profile retrieval, unifying consumer membership across platforms.
OAuth2 authorization codeMini-program session exchanged for a unified identity, so app, mini program and web share one membership.
code2session + identity bindingInternal office integration, with employee records and org relationships as the authoritative source.
Incremental directory syncSocial login for engineering collaboration, used by internal tools and external partners.
OAuth2International social login, sharing one connector admin console with GitHub.
OAuth2 / OIDCCollaboration & reach channels
uniclaw-channel · uniscrmConnected in SCRM pull mode to reach customers inside the WeCom ecosystem; Uniscrm also handles external contacts and conversation archiving.
pull + callbackPush API for outbound messages plus event reception — suited to internal assistants and approval flows.
Event subscription + message pushPush API for outbound messages, sharing one channel adapter abstraction with Feishu.
Event subscription + message pushReal-time bidirectional WebSocket communication, embeddable in your own product as a conversation entry point.
Persistent WebSocket connectionCalled directly by business systems to embed agent capability into existing product flows.
REST / streaming SSEShort-link redirects, mini-program configuration and H5 pages form the private-domain distribution chain.
Short link + mini-program configurationModels & intelligence
uniclaw-llm · unilearning-aiA unified abstraction in the llm module: any service speaking the OpenAI protocol can connect, including privately deployed ones.
HTTP / streamingOptional for long-context and tool-calling scenarios, sharing one calling abstraction with other vendors.
Vendor adapterUsed for multimodal and retrieval-augmented scenarios, with available models configured per tenant.
Vendor adapterDomestic models connect over the compatible protocol; the default candidates for AI grading.
OpenAI-compatibleLocal inference for fully intranet scenarios, so grading depends on no external service.
OpenAI-compatibleThe vector retrieval foundation for memory and knowledge, privately deployable, with vectors never leaving the intranet.
gRPCData & middleware
Shared across product linesThe primary database for UIAM and Uniscrm, with migration files maintained per dialect.
JDBC + LiquibaseSupported homogeneously with MySQL; PostgreSQL is the preferred dialect for Unilearning.
JDBC / gormSessions, tokens and rate-limit counters, supporting the low-latency token validation requirement.
RESPAsync tasks and message delivery, absorbing peaks in WeCom sync and notifications.
AMQPAssets, media and courseware resources; Unilearning supports real AssumeRole temporary credentials.
S3-compatible / OSS STSDelivered as a single image or Compose with consistent environments — the standard private-deployment form.
Image / ComposeGateways & runtimes
integration · runtimeToken validation happens at the gateway, so business services only see authorized identities and authentication moves to the traffic entry point.
Wasm plugin / external authorizationThe standard integration protocol for AI agents: UIAM authorizes tools, Uniclaw calls them, NewTool exposes algorithms.
streamable HTTPThe runtime for the identity kernel and the WeCom server side, using virtual threads for high-concurrency authentication.
JVMThe agent platform runtime, with LangGraph driving the cognition-loop state machine.
Node.jsThe modular monolith and the capture kernel, delivered as a single binary — fast to start, few dependencies.
Static compilationThe algorithm kernel compiles to native and wasm targets, so one implementation serves every platform.
Native / wasm32Boundaries are not a matter of discipline
Any constraint that can be baked into the compiler, the framework or the query layer does not go into a document for people to remember. Sensitive data stays on the user device or inside the customer network by default — every business line supports private deployment.
The minimum boundary for endpoint products. Data at this layer has no upload path by design — it is not switched off by a toggle.
- All legdger ledger data: encrypted locally, only ciphertext reaches the cloud
- legdger on-device AI statistics and Q&A: inference runs on the device
- NewTool desktop and wasm forms: the algorithm kernel has no IO, so data never leaves the process
- pxc captured traffic: the kernel runs locally and does not pass through third-party services
The boundary for private deployment. Models, vectors, business data and audit records are all deployed inside the customer’s own network.
- Uniclaw memory and knowledge vectors: self-hosted Milvus, never leaving the intranet
- Uniclaw model services: can connect to privately deployed compatible-protocol services
- UIAM identity and audit data: the whole deployment sits inside the customer boundary and can run fully air-gapped
- Uniscrm assets and media: object storage can connect to the customer’s own OSS
- Unilearning courseware and learning records: delivered as a single container, with data under the customer’s control
The only things needing external network access are sync and external channels, and what travels is ciphertext or already-desensitised messages.
- legdger cross-device sync: uploads only the latest ciphertext, and the server keeps no history
- Uniscrm WeCom channel: communicates with official WeCom interfaces and uses official archiving capability
- Uniclaw channels: Feishu / DingTalk push APIs, with content isolated per tenant
- NewTool remote calls: transported over MCP, while the algorithm kernel itself makes no network requests
Any constraint that can be baked into the compiler, the framework or the query layer does not go into a document for people to remember. Tenant isolation is enforced by a query-layer listener; domain boundaries are rejected at compile time by Go’s internal mechanism.
jOOQ TenantScopeVisitListener · Go internal 墙Sensitive data stays on the user device or inside the customer network by default. All four business lines support private deployment, and legdger does not even send AI analysis off the device.
legdger 端侧 AI · Uniclaw 自建 Milvus · Unilearning 单容器Agents never share human credentials, servers never hard-code long-lived keys, and endpoint integrations use revocable tokens. Any credential can be revoked on its own without affecting other principals.
UIAM MACHINE 主体 · OSS STS AssumeRole · ledger-cli 令牌Authentication, authorization, tool calls and captured traffic all produce structured records. We keep them not for compliance theatre but so that incidents can be replayed.
uiam-audit · collaboration-logger · pxc 会话记录Delegation is expressed with the act claim — who acts for whom — with permissions intersected at every hop. Audit can answer which user authorized which agent, which tool it called, and with which permissions.
RFC 8693 Token Exchange · agent_tools 注册表Database changes go through versioned migrations that produce the same result on repeat; application releases are single-image swaps, so rollback means switching back to the previous image.
Liquibase · 各域方言迁移 · Docker 单镜像From one identity system to four business lines and a toolkit
The timeline only records milestones backed by deliverables. We do not write “aspires to be” sentences — only what was actually built.
It began with one identity system
Zhenbei’s first business line was unified identity. The starting point was concrete: customers ran several business systems, each maintaining its own accounts, with mismatched permission semantics and no audit view to show. We started from the identity kernel, getting OAuth 2.1 / OIDC, tenant isolation and fine-grained authorization right.
The identity boundary moved from people to AI
As agents entered enterprise systems, the existing identity model could not hold them: agents worked with human tokens, and incidents could not be attributed. So machine principals, delegation chains, multi-hop propagation and MCP tool authorization became first-class capabilities of the kernel.
One business line became four
Beyond identity, customers raised needs in private-domain operations, online learning and AI applications — all sharing the same underlying judgements: where data should live, and who should guard the boundary. Four business lines took shape, in different languages but under one engineering standard.
Turning “good enough” into “holds up”
Once products ran in production, the real pressure came from operations and iteration. We did two structural rebuilds: Unilearning folded 6 microservices into 1 modular monolith, and Uniscrm rebuilt customer relationships from “friends inside an employee’s WeChat” into a company asset that can be inherited.
The toolkit: built for ourselves, used by ourselves, then shipped
Across four business lines in production we accumulated a set of internal tools sharing one trait: kernel separated from shell, with AI treated as a first-class citizen. We polished them into products — running internally first is what made us willing to ship them.
What kind of company Zhenbei is
The four lines look unrelated — identity, agents, private-domain CRM, online learning. What connects them is not an industry but a way of working.
The four lines differ in language and shape, but share one set of constraints: contract first, boundaries enforced by the compiler or framework, every action traceable.
UIAM's api/biz layering and Unilearning's api/internal layering are the same rule expressed in two languages
Every product reserves an identity, credential and read-only interface slot for agents. AI gets structured output, not screenshots.
UIAM's four Agent IAM pillars; Uniclaw's 19 built-in tools; legdger's read-only ledger-cli token
Any constraint that can be baked into the compiler, the framework or the query layer does not go into a document for people to remember.
Tenant filtering is enforced by a jOOQ VisitListener in the query layer; Go’s internal wall makes cross-domain imports fail to compile
Sensitive data stays on the user’s own device or inside the customer network by default; the cloud only does what it must. Every business line supports private deployment.
legdger runs AI on-device with local encryption; Uniclaw can self-host models and memory; Unilearning ships as a single container
How we build products
Not methodology slogans — hard constraints written into each repository’s AGENTS.md and enforced on every commit.
Product capability lives in a testable, reusable kernel; the UI is just a shell. Algorithms are written once and shared by people and AI alike.
Sensitive data stays on the user’s device by default; the cloud only handles what it must — sync and collaboration.
Kernel and shell agree on exactly one contract — a /v1 API, a CLI envelope or an algorithm manifest — so behaviour is identical across platforms.
Every product reserves an integration point for agents: identity, credentials, a read-only CLI and structured output, so AI can work safely.
Once a data model is settled it is never overturned. Load-bearing walls are fixed; everything else is free to iterate quickly.
From identity audit to captured traffic, every action is traceable, replayable and shareable. Debugging stops relying on word of mouth.
Not just conclusions — the method is public too
Our scale claims are open to audit because the method is public too. Each note records one concrete trade-off: why we chose it, how we verified it, and what it cost. If a technical article cannot state its cost clearly, we do not publish it.
Tools we built for ourselves first
These tools run internally before they ship. The common thread: kernel separated from shell, AI integrated as a first-class citizen, and structured CLI output.
Obsidian for bookkeeping: local-first, an on-device AI finance copilot, and a plugin system open to any AI. All ledger data is encrypted on the machine and AI analysis never leaves the device. Only sync requires an account and a fee; local capability is free forever.
01$ ledger-cli doctor02{ "ok": true, "store": "ledger-mac.store", "readonly": true }0304$ ledger-cli stats --month 2026-0905{ "monthExpense": 12483.20, "monthIncome": 32000.00,06 "netWorth": 486210.55, "wallets": 7 }A kernel-first developer toolbox: a Rust algorithm kernel underneath (the newtool CLI) and a Tauri 2 desktop app with a React shell on top. One kernel serves three consumers — AI (skill packages / MCP), humans (desktop app) and the browser (wasm).
01$ newtool list --json02{ "count": 3, "algorithms": ["base64", "jwt.decode", "uuid.v7"] }0304$ newtool run jwt.decode --params '{"token":"eyJhbGci..."}'05{ "ok": true, "data": { "header": { "alg": "HS256" } } }A capture proxy benchmarked against Proxyman that turns debugging sessions into a shared team asset. The only contract between the Go kernel pxc-core and the platform shells is a /v1 HTTP/WS API: macOS Swift, Windows WinUI and Flutter all share the same kernel.
01$ pxc sessions --host api.github.com --status 500 --limit 2002[ { "id": 42, "method": "POST", "path": "/v1/pay", "status": 500 } ]0304$ pxc bp respond 7 --status 201 --body '{"ok":true}'05{ "released": true, "mode": "mock" }Private deployment is the default, not an option
Four delivery models cover the whole path from quick validation to long-term co-building. Every step has a defined deliverable, and the goal of a POC is to falsify, not to demo.
The whole system runs inside the customer’s own network boundary, with no external SaaS dependency and full air-gap operation. This is the default delivery form for all four business lines, not an option.
Finance, government, manufacturing — wherever data cannot leave the intranet
- Infrastructure from standard parts: database, Redis, message queue, object storage
- Versioned migrations, idempotent upgrades with rollback, records kept in-database
- Delivered as a single image or Compose, with consistent environments
- Connects to the customer’s existing monitoring, logging and backup systems
Ready out of the box — bind your organisation and start using it. Suited to validating value first and deciding on a delivery form afterwards.
Fast roll-out of private-domain SCRM and online learning
- Self-service sign-up and enterprise authorization binding
- Multi-tenant isolation with data governed at tenant boundaries
- Suite configuration and callbacks provisioned automatically
- No servers to run and no operations overhead
Business data is private, sensitive data stays on the endpoint, and only collaboration and sync pass through the cloud. Delivery form can even be chosen per module within a single business line.
Organisations that need collaboration efficiency and a hard data boundary
- Endpoint data never leaves the device (legdger encrypts everything locally)
- Business systems are private; only the sync path reaches the network, carrying ciphertext
- Model services can be privately deployed or called out under control
- Configured per tenant and per module
For teams with their own engineering capability: we deliver the code and the engineering standard, the customer team carries evolution forward, and we provide architecture support and an upgrade path.
Group customers with an independent engineering team and deep customisation needs
- The full repository and engineering standard (including AGENTS.md constraints)
- Architecture decision records and data model documentation
- Documented migration and upgrade paths
- Architecture review support at key milestones
A six-step delivery path
Every step has a defined deliverable, and anything we cannot do is written down during solution design — not after.
We lay out the current state, constraints and goals. We do not rush to pitch — first we check whether this is the kind of problem we are good at solving.
We map the real structure of the existing system — data model, interface inventory, identity system and integration points — and assess the migration path and its risks.
We provide the architecture layering, data model and migration path, and write the trade-offs down explicitly — including what we cannot do.
We run the critical paths on real data and validate performance and edge conditions. The goal of a POC is to falsify, not to demo.
Rollout in batches — core paths first, peripheral modules after. Every batch has a rollback plan and acceptance criteria.
A stable kernel and backward-compatible interfaces; changes go through versioned migrations with audit and rollback. New requirements enter the roadmap rather than becoming patches.
7×24 on-call; P1 in 2 hours, P2 next business day
All four business lines, no exceptions
Breaking changes go into a major version, announced one cycle ahead
No data lock-in; standard formats for export and migration
Versioned migrations plus single-image replacement — rollback is swapping back
Compliance and certification material provided with delivery projects
What people usually ask first
These come up most often. If we do not have an answer, we will not improvise one.
They share the same underlying judgements: who guards the boundary, where data should live, and how AI should connect safely. UIAM is that judgement at the identity layer, Uniclaw at the agent layer, Uniscrm at the customer data layer and Unilearning at the domain boundary layer. Different languages, one engineering standard.
Hand the complexity of identity, agents and private domain to one governable kernel
Whether you are replacing an existing IAM, building an agent platform, or trying to make private-domain operations actually work — start with a 30-minute architecture call. We will first judge whether this is the kind of problem we are good at, and say so plainly if it is not.