Digital Employee

简体中文

Digital Employee is a local-first, conversation-first digital-organization workspace. The long-term direction (tracked in Epic #155): turn one business directory into a directly addressable AI team — a directory is one business, a position is one addressable digital employee, and a conversation is work carried out with that position's Context and permission boundary. Positions run on a built-in, TypeScript-native execution engine as the default Host (Epic #165, product direction). The engine/turn core is a released preview in public 0.6.0; the 0.6.1 source tree keeps that runtime unchanged. The complete default-Host Workbench path remains in delivery, and external Agent Host adapters remain an option, not a dependency. The roadmap and strategy live in docs/strategy.md and docs/roadmap.md.

Release availability boundary. This source checkout declares package version 0.6.1. Its manifest, PR, or packed artifacts do not establish npm, tag, GHCR, or GitHub Release availability. The release receipt is the only availability evidence; the recorded public 0.6.0 receipt below is historical.

Where Digital Employee sits

Agent frameworks (Claude Code, Qoder, Qwen Code, CodeBuddy, Codex…) answer how work gets done; multi-agent systems answer how work gets operated. Digital Employee answers who to ask and who is responsible: it maps a business into addressable positions with visible context and permission boundaries, so a user can name the right digital employee for the job instead of orchestrating tools by hand.

The pitch we are moving toward: the barrier to entry is low — a business owner does not need to write prompts or wire up an Agent Host by hand. Name a position, get an answer with its source, and the owner stays accountable for the whole organization. The complete no-command Workbench direction remains planned. Public 0.6.0 includes workspace init, org tree, and org apply as preview surfaces; the 0.6.1 source version changes documentation only. chat @position and its durable Workbench integration remain planned (see the status table below).

Capability status

Warning

Digital Employee is under active development. Interfaces and package formats may change before a stable release.

Capability	Status
init, doctor, validate, eval, one-shot run, setup	Released in public npm 0.6.0 (first shipped in 0.4.0); fixture eval does not prove live model entitlement
package-bound deploy	Released in public 0.6.0 (first shipped in 0.4.0) within its documented fail-closed boundary (HTTP can reach ready; DingTalk reconciliation is externally HOLD)
Employee-package / Skill / Schema / eval contracts, Agent Host Adapters	Released in public 0.6.0 (initial public baseline 0.4.0); Host adapters are preview and fixture-conformant, not live-qualified
standalone-v1 compatibility runtime	Released compatibility path; not the target for new mainline capabilities
Old-track issues after the 2026-08-23 pivot	Disposed per the approved #164 ledger — KEEP 11 / REPURPOSE 9 / PARK 5; see the old-track disposition ledger
workspace init (oss-maintainer template)	Released preview in public 0.6.0 (first published in 0.5.0, #156)
org tree / org apply	Released preview in public 0.6.0 (first published in 0.5.0); applied permissions fail closed
Explicit owner → one direct-report delegation	Released preview / deterministic E3 in public 0.6.0 (first published in 0.5.0); Workbench persistence/UI and per-Host E4 remain unverified (boundary)
chat @position	Planned Workbench integration (Epic #155 first milestone)
Opt-in Memory/Context recall and permission enforcement	Released preview in 0.6.0 as scope-bound engine seams; disabled by default and not a durable product loop
Durable long-term Context, Workbench continuity, and context distillation	Planned; not shipped by the v0.6.0 recall seams
Built-in execution engine	Released preview through the installed root package's ./engine export and turn run; the complete default-Host Workbench journey remains planned (Epic #165)
oss-maintainer showcase (quickstart form)	Planned (Epic #155 M1)
Channel expansion (Lark/WeCom)	Planned later; excluded from the first milestone

Nothing in the planned rows is available today. Do not use a source main checkout, PR, or packed artifact as if it were a published capability.

Run

Requires Node.js 20 or later.

Run from npm

Initialize the workspace:

mkdir digital-employee-workspace
cd digital-employee-workspace
npm init -y

If the release receipt verifies 0.6.1 on npm, install that exact version:

npm install @fullstack-ai-infra/digital-employee@0.6.1

Otherwise, use the recorded public 0.6.0 fallback:

npm install @fullstack-ai-infra/digital-employee@0.6.0

After either installation path:

npx digital-employee doctor --json
npx digital-employee init ./my-employee \
  --recipe minimal-answer.v1 \
  --author your-team
npx digital-employee validate ./my-employee --json
npx digital-employee eval ./my-employee --json

doctor, init, validate, and eval do not invoke a model. A live run requires one supported Agent Host and its service credential:

Engine	Credential
qoder	QODER_PERSONAL_ACCESS_TOKEN
claude-code	ANTHROPIC_API_KEY
qwen-code	OPENAI_API_KEY and OPENAI_MODEL
codebuddy	CODEBUDDY_API_KEY and CODEBUDDY_MODEL

Run from source

git clone https://github.com/bytefolk/digital-employee.git
cd digital-employee
npm ci
npm run build
node ./dist/apps/cli/bin.js init ./my-employee \
  --recipe minimal-answer.v1 \
  --author your-team
node ./dist/apps/cli/bin.js validate ./my-employee
node ./dist/apps/cli/bin.js eval ./my-employee --json

Try the setup command

setup combines the model-free host probe and package scaffolding steps. From a clean workspace:

cd /path/to/empty/workspace
node /path/to/reviewed/digital-employee/dist/apps/cli/bin.js setup --json

Try the deploy command

deploy binds a validated package to a truthful local deployment outcome. This HTTP example requires both the selected Agent Host credential and an explicit HTTP bearer token. It also requires Qoder CLI 1.1.x to be installed:

export QODER_PERSONAL_ACCESS_TOKEN='...'
export DIGITAL_EMPLOYEE_HTTP_TOKEN='...'
node ./dist/apps/cli/bin.js deploy ./my-employee \
  --channel http \
  --engine qoder \
  --runtime agent-native \
  --port 3000 \
  --yes

Only HTTP can currently reach ready. Console returns pending_external_action; DingTalk remains fail-closed pending external provider-contract validation, with no live create or reconciliation claim; Lark and WeCom are unsupported. Do not present fixture-backed provider tests as live-tenant verification. The full outcome, locking, recovery, and secret-handling contract is in Deploy.

Runner on a publisher-owned machine

Every application/service employee runs on the publisher or operator's own computer or server. The private platform stores listing identity, package digest, Quote, lease, events and settlement records. It never stores a local package path, employee package contents or Agent Host credentials, and it never dials into the operator machine.

V0.3 provides an embeddable one-shot Runner executor and a signed-renewal lease state machine. A long-running Runner must use outbound calls only: claim a task, accept a platform-signed lease, resolve the employee package by identity on the local machine, invoke a local Agent Host, and upload hash-chained events plus a signed receipt. A separate platform UsageVerifier must approve billable facts; Runner-attested tokens never debit Credits directly.

See the Runner integration path and ADR 0002. There is no claim that a deployable runner start network daemon exists yet; the seller-owned daemon, durable local replay/outbox, reconnect and outbound platform client remain open-framework work on the old track, which is finished rather than extended; the surviving scope is recorded in the old-track disposition ledger. Server-side device registration, task dispatch, UsageVerifier, Quote, Credit and settlement APIs remain private platform work.

Every runnable adapter is stateless and one-shot. It requires an explicit deployment service credential and never reuses a personal CLI login. Unlike the commands above, run starts a real Agent/model run and may consume the selected provider's credits. For example, the Qoder path is:

export QODER_PERSONAL_ACCESS_TOKEN='...'
node ./dist/apps/cli/bin.js validate ../team-answer --engine qoder
printf '%s\n' '{"message":"What does the approved handbook say?"}' | \
  node ./dist/apps/cli/bin.js run ../team-answer --engine qoder --stdin

Generate QODER_PERSONAL_ACCESS_TOKEN as a Personal Access Token in your Qoder account settings; it is a deployment service credential, not a personal CLI login. If the token is missing, invalid or expired, run fails closed with qoder_service_token_not_configured or qoder_access_token_invalid before any trusted output is produced.

Select claude-code, qwen-code or codebuddy in the same commands after configuring that adapter's service API key. --stdin/--input-file keep task data out of the outer process arguments. Claude Code, Qwen Code and CodeBuddy receive only a sealed, bounded UTF-8 rendering of manifest-selected assets; they run with empty isolated working, home and configuration directories and must attest an empty model-visible tool and MCP surface before output is trusted. Claude additionally attests empty plugins, Skills and slash commands; Qwen disables slash commands and pins its unreachable built-in agent catalog; CodeBuddy denies every built-in tool in the verified version because its empty --tools flag alone is insufficient. Qoder instead receives a minimum read-only file projection and must attest its exact read/search tool set plus empty MCP/Skill/plugin sets. Qoder assistant text is held until process and credential cleanup succeeds, then scrubbed as one value with the exact service credential. Tool values are scrubbed before truncation, credential-bearing tool identifiers and keys are rejected, and schema-bound structured output that would require credential or pattern redaction fails closed. Across all built-in Adapters, structured_output means Adapter-enforced terminal validity against one bounded, immutable, synchronous Schema snapshot, not Host-native constrained generation. Every Adapter validates the unchanged terminal JSON: repair, coercion, defaults, field removal, or redaction cannot manufacture a passing value, and any post-validation safety scrub that would mutate a schema-bound value fails closed. Qoder additionally accepts only synchronous Schemas of at most 16 KiB and compiles them before projection or any Qoder subprocess. An invalid, oversized, or asynchronous Schema therefore short-circuits before even the bounded, credential-free --version readiness probe.

These paths are local/single-tenant technical previews, not a marketplace-ready online employee service. All four reject MCP, attachments, session resume, write tools and approval callbacks. Their model control plane remains reachable, while employee tool/MCP data-plane network access is denied. Conformance fixtures have been run, but live model entitlement has not been tested. The runnable preview is currently POSIX-only so descendant process groups can be terminated and verified before a terminal event is published. Windows is NOT VERIFIED in this milestone and remains a named limit — see Windows status for the anchored governance record and the outstanding evidence gap.

Release status

The 0.6.1 package version in this checkout is not a public-availability claim. The recorded public 0.6.0 release is available through the root and core npm packages, GHCR, and GitHub Releases:

Channel	Command or download
npm (CLI)	npm install --global @fullstack-ai-infra/digital-employee@0.6.0
npm (core)	npm install @fullstack-ai-infra/digital-employee-core@0.6.0
GHCR	docker pull ghcr.io/bytefolk/digital-employee:0.6.0
GitHub Release	Download the root/core packages and checksums from v0.6.0

The standalone @fullstack-ai-infra/digital-employee-core@0.6.0 package is public. Its one-time registry bootstrap is complete, and subsequent versions publish from release.yml through npm Trusted Publishing. A source branch or packed artifact is not itself a published release. Do not retag or overwrite any published version, including 0.6.0, 0.5.0, 0.4.0, 0.3.0, or 0.1.0.

The frozen 0.1.0 compatibility release is distributed through three public channels:

Channel	Command or download
npm	npm install --global @fullstack-ai-infra/digital-employee@0.1.0
GHCR	docker pull ghcr.io/bytefolk/digital-employee:0.1.0
GitHub Release	Download the package and checksum from Releases

That release contains only the historical answer runtime. Its container starts the old HTTP demo and does not contain Qoder or the new package commands:

docker run --rm -p 3000:3000 \
  ghcr.io/bytefolk/digital-employee:0.1.0

The current source Dockerfile installs an already verified npm candidate and defaults to help. It does not rebuild from the source checkout. Follow the candidate build and staging steps, then enter legacy explicitly only when testing the compatibility runtime:

docker build -t digital-employee:candidate .
docker run --rm digital-employee:candidate
docker run --rm -p 3000:3000 digital-employee:candidate \
  legacy serve \
  --config ./node_modules/@fullstack-ai-infra/digital-employee/dist/configs/demo.json \
  --host 0.0.0.0 --port 3000

What the product owns

• the workspace skeleton and organization model: the directory tree is the org chart, and every hire carries a budget (workspace init, org tree, and org apply are released previews);
• position conversation with Context and permission boundaries (the turn, permission, and explicit single-hop seams are released previews; the chat @position Workbench product path remains planned);
• the built-in TypeScript-native execution engine as the default-Host direction, with its S1/turn core released as a preview and external Agent Host adapters retained as an option;
• portable, versioned employee packages and deterministic package digests;
• default-deny Agent Host adapters and runtime policy for one-shot runs;
• sealed local execution inputs, normalized events, and signed receipts;
• truthful deployment outcomes, lifecycle state, and recovery boundaries.

Employees run on the publisher's or operator's own machine; this repository is not a hosted marketplace. Marketplace, billing, settlement and other company-internal transactions stay private.

Documentation

• Install and Agent Host setup
• Employee package contract
• Hire request contract
• Agent Host support policy
• Deploy contract and recovery
• Runner integration boundary
• MemoryPort and pinned mem adapter
• Explicit single-hop delegation boundary
• Architecture
• Strategy and roadmap
• Verification and release process
• Knowledge asset convention and knowledge source quality bar
• Security policy

Community and support

Use GitHub Issues for bugs, feature requests, and reproducible integration reports.

Contributing

Contributions are welcome. Read CONTRIBUTING.md and AGENTS.md before opening a pull request. Please follow the Code of Conduct.

Development

npm ci
npm run check

Release candidates also pass coverage, security, archive, and clean-installed package-consumer gates. A source checkout is not a published release.

License

Licensed under the Apache License 2.0. See NOTICE for attribution information.