OpenWorker enterprise plan: how a traditional large tech company ships an AI coworker that can deliver finished work

Open-source base vs enterprise rewrite: one comparison table

⚠️ Key judgment: do not overturn OpenWorker’s core architecture (event-stream contract, TurnEngine, inbox, scheduler, permission engine). Replace only the infrastructure layer (model / identity / storage / connector auth). The core architecture is its moat; the infrastructure layer is the enterprise’s moat.

Headcount (peak about 22–28, depending on parallelism)

Reporting and collaboration

• Two-week sprints. At the end of each sprint the architect runs an interface-freeze review (event-stream contract, Provider interface, connector contract must be frozen first).
• The only contract between the engine team and the frontend team is the event stream (Event enum in events.py). The frontend consumes events only—this boundary must be written into the architecture baseline; nobody may bypass it and call into the engine internals.
• Keep an architecture-decision record (ADR) repo. Every choice (model-gateway protocol, storage, permission model) is written down.

3.1 Reuse the open-source base directly (do not rebuild it)

These are cores OpenWorker has already proven. Fork and adapt:

• Python ≥3.10 + FastAPI + uvicorn (pyproject.toml): engine sidecar service, already verified.
• TurnEngine main loop (engine.py:52): async + asyncio.to_thread wrapping blocking calls + concurrent low-risk / serial high-risk (_handle_tool_calls:437) + interruptible from any state (request_interrupt:120) + durable resume (resume:250). This is the heart of the whole project. Keep it as-is.
• Event-stream contract (events.py): TURN_START → ASSISTANT_DELTA → TOOL_PROPOSED → PERMISSION_REQUIRED → TOOL_STARTED → TOOL_FINISHED → ITERATION_END → TURN_END. Every surface (GUI / TUI / Slack) is a consumer of it.
• Five-tier permissions + §25 standing rules (permissions.py:37,62,216).
• Inbox idempotent state machine (inbox.py:61,133,295).
• Scheduler (automation/scheduler.py:23): run-once-catch-up + skip-on-overlap + spawn-don’t-await (_tick:76).
• aisuite tool layer (tools/subagent.py:60): tools use the ai.tool package; ToolMetadata carries risk_level / requires_approval—both the main loop and the permission engine read it.
• In-house provider layer (providers/: three native openai / anthropic / gemini + _openai_compat + router.py + matrix.py + capabilities.py).

3.2 Enterprise rewrite layer (a large company must build this itself)

3.3 Key stack checklist

核心语言：   Python 3.10+（引擎）/ TypeScript 5.5（前端）/ Rust（Tauri+STT）
Web 框架：   FastAPI + uvicorn[standard]（已验证）
Agent 工具： aisuite（工具层，pin 到 fork 的 commit）
模型 SDK：    openai / anthropic / google-genai（原生 provider）
TUI：        textual（已验证，用于内部调试终端）
前端：       React 18.3 + Vite 5.4 + TypeScript 5.5 + Tailwind 3.4
桌面壳：     Tauri 2.x（src-tauri）
语音：       Rust STT 侧车（stt/src/lib.rs）
记忆存储：   SQLite（开发期）→ TiDB/MySQL（生产，抽象 MemoryStore 接口）
对象存储：   内部 COS/OSS（交付物文件）
配置中心：   内部配置平台（替代本地 .env）
消息队列：   内部 MQ（Kafka/Pulsar）驱动事件流到审计/可观测

🧠 One sentence: 80% of the stack stays open-source; 20% is swapped for internal middleware. The largest engineering discipline is—the core engine’s “event-stream contract” must never be broken because you swapped infrastructure.

Module-split overview

┌─────────────────────────────────────────────────────────────┐
│ ① 桌面/Web 壳（React + Tauri）  企业版：加 Web 端 + SSO 登录 │
├─────────────────────────────────────────────────────────────┤
│ ② 接入层 API Gateway          企业版：内部网关 + 鉴权 + 限流 │
├─────────────────────────────────────────────────────────────┤
│ ③ Agent 引擎服务（Python）    基本复用开源，替换存储/模型/身份 │
│    SessionManager · TurnEngine · 权限引擎 · 收件箱 · 调度器    │
│    记忆 · 子agent(explorer) · self-wake · persona · 技能 · MCP │
├─────────────────────────────────────────────────────────────┤
│ ④ 企业基础设施层（新建）                                    │
│    模型网关 · 凭证中心 · 多租户DB · 对象存储 · 审计MQ · 可观测 │
└─────────────────────────────────────────────────────────────┘

Module list (by delivery priority)

Phase 0: charter and technical spike (M1, 4 weeks)

Goal: prove feasibility, freeze core interfaces, get charter budget.

• Technical PoC: run open-source OpenWorker locally, replace BYO key with the internal model gateway, verify TurnEngine can drive a minimal closed loop of “write a file + send a message.”
• Freeze three contracts: ① event-stream Event enum; ② Provider interface (request / response shape); ③ connector contract (ConnectorDescriptor shape in descriptors.py).
• Output: PoC report, ADRs (architecture decisions), milestone plan, headcount budget.

Exit criteria: in the internal environment, using the company model, “help me write a weekly report and save it as a file” runs end to end; the three contract documents pass review.

Phase 1: core engine + model gateway (M2–M3, 8 weeks)

Goal: build the heart. A single machine can run “input → think → tool → approval → deliver.”

• M1 event-stream contract → M2 TurnEngine (transplant engine.py:52 as-is; point provider calls at the internal gateway).
• Permission engine five tiers + §25 (permissions.py) + shell injection defense (_command_allowed:216).
• Model-access team wires the internal model gateway: point base_url of the three native providers such as providers/openai_provider.py at the gateway; router.py routing by provider: prefix stays unchanged.
• Minimal frontend: TUI (textual, already verified) first; GUI later.
• Memory starts as local SQLite (SQLiteMemoryStore reused as-is).

Exit criteria: from the command line, “summarize this week’s GitHub commits and generate a markdown brief”; the engine can run read-only tools concurrently, pop approval on writes, produce a file, and the token-by-token record can be replayed.

Phase 2: frontend GUI + desktop shell + memory rewrite (M4–M5, 8 weeks)

Goal: a usable UI; data starts landing in enterprise storage.

• React GUI: session view, tool cards, approval cards, inbox UI (surfaces/gui/src), rendered by consuming the event stream.
• Tauri shell + orphan guard (keep the COWORKER_EXIT_WITH_PARENT mechanism in server/run.py).
• Abstract SQLiteMemoryStore behind a MemoryStore interface; implement the internal-DB version (multi-tenant, isolated by tenant_id).
• Artifact files land in object storage; the engine returns a shareable link.

Exit criteria: opening the desktop App logs in with SSO; the UI shows think / tool / approval in real time; memory survives restart; artifacts can be shared on the intranet.

Phase 3: inbox + scheduler + connector expansion (M6–M7, 8 weeks)

Goal: the “unattended coworker” exists—it can run on a schedule, and it can park an ask safely in the inbox.

• Inbox (inbox.py:61) wired into the GUI + idempotency key (session_id, tool_call_id) (:133) so durable resume does not double-run.
• Scheduler (automation/scheduler.py:23): run-once-catch-up + skip-on-overlap + spawn-not-await; wired to enterprise cron.
• self-wake (selfwake.py).
• Connector team first ships 5 heads: GitHub, Feishu / WeCom, Jira, Notion, Gmail → expand stepwise to 15+.
• MCP client (mcp/) talks to internal MCP services.

Exit criteria: configure an automation “every weekday at 9am post the weekly report to a Feishu group”; when no one is present, approvals go to the inbox; after a service restart, a stuck turn resumes from the inbox and does not double-run.

Phase 4: enterprise rewrite (SSO / multi-tenant / audit / compliance) (M8–M9, 8 weeks)

Goal: hit the enterprise IT-governance baseline; ready for gray release.

• SSO (WeCom / DingTalk / Feishu / OIDC); secrets.py reads internal credential hosting.
• Multi-tenant isolation: tenant_id threads through DB, object storage, event stream.
• Audit: forward engine.py:_audit:690 audit events to internal Kafka → audit store; wire DLP.
• RBAC: on top of the five-tier permissions, add admin policy for “who may create automations, who may attach a given connector.”
• Observability: TurnEngine phase instrumentation into internal APM / trace.

Exit criteria: pass security/compliance review; one tenant’s data is invisible to another; every “consequential operation” is traceable in the audit store (who, which model, which tool, which result).

Phase 5: ecosystem and optimization (M10–M11, 8 weeks)

Goal: form an ecosystem; prepare for full rollout.

• Persona marketplace (consent gate personas/registry.py:340,:363; :123 is only cowork-builder registration): built-in + directory / git install + default-disabled until authorized.
• Skill system (Anthropic format, progressive disclosure agent.py:262).
• Performance: bounded iteration on long sessions (default 150, config.py:31) + explicit memory, so context does not run away; tune concurrent low-risk tools.
• Cost: model routing (small models for simple tasks), cache, batching.

Exit criteria: internals can install third-party personas / skills; P99 tool-call latency hits the bar; per-session cost is in budget.

Phase 6: gray release and full rollout (M12, 4 weeks)

• Internal seed-team gray (1 BU) → expand gray (3–5 BUs) → full (opt-in for everyone).
• Stand up red-team: security keeps trying to escalate (bypass the shell allowlist, fool approval).

Exit criteria: during gray, no privilege-escalation events, no data-egress events, SLA met; publish an all-hands announcement and a best-practice guide.

Calendar at a glance (Gantt-style)

Topic 1: event-stream contract—the system’s “bus”

Why it is hard: frontend, TUI, Slack connector, scheduler all depend on it. Change the shape once, and every consumer must change in lockstep.

How: - Freeze the Event enum in events.py first; list it as an architecture baseline (mandatory in Phase 0). - The engine only yield Event; it never returns rich objects. The GUI consumes via SSE / WebSocket (open source uses uvicorn SSE). - Events split into two kinds: transport (ASSISTANT_DELTA streamed text) and state (PERMISSION_REQUIRED approval request)—state events must be persistable and replayable, for disconnect reconnect and service-restart recovery. - The enterprise edition adds an “event egress”: mirror state events onto internal MQ for audit / observability consumers (do not pollute the engine’s main path).

Topic 2: TurnEngine concurrency / interrupt / durable resume

Why it is hard: this is where the open-source edition shows its craft (engine.py:52 onward). You must simultaneously: run low-risk tools concurrently, serialize high-risk strictly, interrupt from any state without orphans, and resume after restart.

How (item by item against source): - Concurrent low-risk / serial high-risk (_handle_tool_calls:437): tool ToolMetadata.risk_level="low" and requires_approval=False → asyncio.gather concurrent; otherwise strictly in call order. On landing, make “risk annotation” a required field for connector / tool development; default missing to high-risk. - Interruptible from any state (request_interrupt:120): Stop from any state—mid-stream, mid-tool, waiting for approval. Every unanswered tool_call is filled with an error result, avoiding orphans (_interrupted_tool about :504; _inject_steering about :866 is barge-in injection, a different mechanism). - Streaming bridge (_astream:388): the provider’s blocking stream runs on a thread, enters an asyncio.Queue via call_soon_threadsafe; the main loop races the Stop event—a stuck stream cannot hang the turn. - Durable resume (resume:250): re-process unanswered tool_calls in the last assistant message (_unanswered_trailing_tool_calls:268); already-resolved inbox items return immediately, no re-prompt. This is the foundation of “unattended,” and under enterprise multi-tenant you must add tenant_id to the resume key.

Topic 3: permission engine—coworker-grade governance

Why it is hard: the open-source edition takes “permissions” to coworker grade (permissions.py): shell always asks, connectors skip the ask on an exact target, and the agent is not even allowed to know “how many items the privacy filter hid.” A large company still has to stack RBAC and admin policy on top.

How: - Keep the five-tier modes (discuss/plan/interactive/auto/custom) as-is, as “personal preference.” - Shell injection defense (_command_allowed:216): commands carrying ; & | > < $( ( newline never take the allowlist; after shlex.split, exact token-prefix match. This must have red-team tests before production, simulating git status && rm -rf ~. - §25 standing rules (standing_rule_candidate:62): apply only to external risk (connectors), exact to target, shell never skip-ask. Enterprise edition adds “an admin may revoke all standing rules for a tenant.” - _display privacy bypass (engine.py:_record_result:642): _display in a tool result is for the user only, invisible to the agent—enterprise edition strengthens this to “sensitive-field redaction is unified in DLP; the engine only surfaces category and count.”

Topic 4: inbox idempotent state machine

Why it is hard: a cross-session human-attention queue must “resolve once, first answerer wins, restart does not double-run.”

How (inbox.py): - State machine pending → resolved, idempotency key (session_id, tool_call_id) (:133). - Durable resume that re-prompts the same prompt reuses the existing item (inbox.add idempotency key about :133; :295 is resolve resolves once)—this and TurnEngine’s resume are cause and effect of each other; they must be tested together. - Enterprise edition: add tenant_id to session_id / tool_call_id; inbox queries isolated by tenant; approval actions bound to SSO identity (record who answered). - Attended VIS_INLINE / unattended VIS_INBOX share the same durable record (inbox.py:38-39).

Topic 5: scheduler anti-deadlock

Why it is hard: an automation stuck on inbox approval must never block the scheduler loop, other due jobs, or self-wake recovery.

How (automation/scheduler.py:23): - Tick every 30s; the first tick does run-once-catch-up (backfill what was missed while down). - Every due job only spawn, do not await (_tick:76); _running_ids guards overlap skip. - next_run uses croniter. Enterprise edition puts the “scheduler loop” in a standing service (k8s Deployment), replacing the local thread with internal cron / timers for HA.

Topic 6: Provider abstraction and the model gateway

Why it is hard: the open-source history is “normalize to OpenAI shape,” convert per provider each time (router.py); mid-flight model switch is just changing fields (switch_model:180). The enterprise edition must replace “talk to vendors directly” with “internal gateway” without destroying that flexibility.

How: - Point base_url of providers/openai_provider.py and peers at the internal model gateway; the gateway does auth / rate limit / cost split / fallback. - Keep matrix.py (the list of models verified for tool calling) and capabilities.py (vision / pdf capability) as-is—this is the foundation of “swap models at will + degrade attachments with capability” (engine.py:_outbound_messages:878). - Enterprise edition adds model-routing policy at the gateway: simple tasks to small models, sensitive tasks to privately deployed models, automatic degrade on cost anomalies.

Test strategy

Security and compliance (large-company red lines)

1. Data stays in-domain: connectors go through an internal proxy; external model calls go through the gateway; sensitive tenants are forced onto private deploy.
2. Full audit coverage: every consequential operation enters the audit store (who / model / tool / result); engine.py:_audit:690 is the entry.
3. Least privilege: default interactive mode; write / send / shell always ask; standing rules only for exact external targets.
4. Offboarding recovery: SSO; account deprovision automatically recovers all credentials and automations.
5. Standing red-team: security keeps trying to escalate; find, fix, add a regression test.

Launch strategy

• Gray: seed BU (from M12) → expand → full; each rung watches SLA and security events.
• Rollback: engine and frontend ship independently; raise the frontend only when the event-stream contract is backward compatible.
• Monitoring: TurnEngine phase instrumentation + cost dashboard + escalation alerts.

Three recommendations for the engineering lead

1. Freeze contracts before writing code: event stream, Provider interface, connector contract must be reviewed and frozen in Phase 0—that is the premise of all later parallel development.
2. Transplant the core engine as-is; do not “optimize by rewriting”: TurnEngine / inbox / scheduler are the open-source edition’s moat. Rewrite and you will step in the pits it already stepped in (orphan tool_call, restart double-run, scheduler-loop deadlock).
3. Enterprise rewrite only touches the infrastructure layer: swap model / identity / storage / connector auth for internal middleware; core architecture stays—faster, more stable, and you can always fall back to the open-source baseline.

This plan is written from the real architecture of andrewyng/openworker commit db93d75. Technical judgments are all anchored at file:line; the enterprise-rewrite portions are a large-company delivery projection, for technical decision reference.