[Epic] O2: prove one governed digital-employee team

[PeterGuy326]

schemaVersion: requirement-record.v1
revision: R1
status: needs-design
priority: P1
productOwner: "@PeterGuy326"
technicalOwner: "unassigned"
userOutcome: "A builder can observe and operate a governed team of named digital employees with durable attributed conversations, explicit peer handoffs, live operator control, bounded recurring work, and MCP capabilities without weakening position authority or user-owned memory."
requirements:
  - REQ-001
  - REQ-002
  - REQ-003
  - REQ-004
  - REQ-005
acceptanceCriteria:
  - AC-001
  - AC-002
  - AC-003
  - AC-004
  - AC-005
  - AC-006
parent: "https://github.com/bytefolk/.github/issues/6"
dependencies:
  - "https://github.com/bytefolk/.github/issues/7"
  - "https://github.com/bytefolk/digital-employee/issues/165"
  - "https://github.com/bytefolk/digital-employee/issues/219"
supersedes: []
lastDecisionAt: "2026-09-01T07:35:50Z"

Preflight

• Searched open and closed organization Issues for governed teams, peer handoff, live steering, agent-to-agent work, and Pantheon.
• Checked the organization vision, O1 proof, execution-engine graph, MCP runtime work, completed single-hop delegation contract, and workbench MCP grant gap.

Context

Hermes Agent v0.21.0, the Pantheon release, makes a useful product-level comparison point: named bot identities and group/peer conversations, persistent cron continuity, live subagent steering, and an MCP command center are presented as one coherent operator experience. The comparison is pinned to release v2026.8.31 and commit 29112bef099274229cadff79cdff7bf7b99c4b77.

ByteFolk already has stronger governance primitives than that product shape: position-scoped authority, approval and audit contracts, fail-closed execution evidence, and memory grant/revoke/forget/provenance. O1 intentionally proves one durable employee, while the current delegation proof is explicit and single-hop. What is missing is one end-to-end, observable team proof that composes those primitives without bypassing them.

Problem and desired outcome

A builder can configure multiple named employees today only as separate pieces. There is no organization-level acceptance record proving that durable peer conversations, governed handoffs, live child control, recurring continuity, and MCP operations work together across restart and failure boundaries.

The desired outcome is a credential-free local proof of one small digital-employee team. An operator can see who acted, who delegated to whom, which authority was effective, what is running, what changed after steering or stopping, which recurring state was reused, and which MCP tools were actually exposed.

Product decision

This Issue is O2, a sibling of O1 under the organization vision RFC. O1 remains the proof of one durable employee; O2 owns the team/operator outcome and does not expand O1 silently.

We will adopt four observable product patterns from the pinned Hermes release:

1. durable named employee and peer-conversation identity;
2. explicit peer handoff with live list, steer, and stop controls;
3. bounded recurring-job continuity with checkpoint/notepad state and unchanged-input suppression; and
4. an MCP operating surface that exposes lifecycle, effective tools, health, confirmation, and usage evidence.

This is a clean-room product adaptation. The upstream release is prior art for behavior and UX shape, not a source transplant or an authority model.

Scope and repository ownership

Repository	Owned slice	Boundary
digital-employee	Portable employee/position/peer-event envelopes; delegation and live-control contracts; effective-authority evaluation; MCP client/supervisor integration	Does not own desktop-local thread storage or team UI
org-workbench	Named roster and group/direct-thread UX; durable local conversation/task projections; list/steer/stop controls; recurring-job and MCP health/usage surfaces	Local storage and UI projections do not become the portable runtime contract
mem	Explicitly granted long-term continuity, scoped checkpoint/notepad records, revoke/forget behavior, and provenance	Does not become a chat store, scheduler, or orchestration engine

The parent owns the end-to-end outcome. Repository children will own one implementation slice and link exact input/output contracts in both directions.

Requirements

REQ-001 — Durable team identity and attributed conversation

• Statement: The system MUST preserve stable employee, position, conversation, turn, run, sender, recipient, correlation, causation, and timestamp identity for user-to-employee and employee-to-employee events across process restart; group and direct-thread projections MUST remain attributable and queryable.
• User value: A builder can tell exactly who said or did what without confusing a UI participant with a generic model session.
• Priority: MUST
• Owner: This Issue

REQ-002 — Governed peer handoff and live control

• Statement: A peer handoff MUST be explicit and the effective authority MUST be the intersection of delegator authority, recipient position authority, task policy, and tool policy. Running child work MUST expose list, steer, stop-request, completion, failure, and partial-result events with idempotency and stale-command rejection; authorization failures MUST fail closed.
• User value: An operator can redirect or stop work without creating hidden authority or duplicate execution.
• Priority: MUST
• Owner: This Issue

REQ-003 — Bounded recurring continuity

• Statement: A recurring job MUST persist only scoped checkpoint/notepad continuity, MUST suppress model invocation and delivery when the monitored input hash is unchanged, MUST resume safely after restart, and MUST use explicit memory grants whose revoke/forget semantics remain effective.
• User value: Repeated work is economical and continuous without turning all conversation history into shared mutable memory.
• Priority: MUST
• Owner: This Issue

REQ-004 — MCP operating loop

• Statement: The built-in engine MUST own MCP loading, supervision, capability projection, and failure state; the workbench MUST expose configured server health, effective tool schema/mode, confirmation state, and bounded usage evidence. Configuration or write-capability changes MUST use preview, approval, idempotency, and audit, with no silent delegation to an external host.
• User value: A builder can see and control the real tool surface instead of trusting configuration claims.
• Priority: MUST
• Owner: This Issue

REQ-005 — Portability, safety, and evidence

• Statement: The proof MUST run locally without DingTalk, provider, or model credentials for its deterministic path; MUST not widen default concurrency, filesystem, network, or tool scope; MUST keep secrets and user payloads out of logs and public evidence; and MUST produce current-revision deterministic and independent verification mapped to every acceptance criterion.
• User value: The team proof remains self-hostable, reviewable, and safe to reproduce.
• Priority: MUST
• Owner: This Issue

Dependency DAG

• Parent: bytefolk/.github#6 at R2.
• Blocking prerequisite: bytefolk/.github#7 at R2 proves the durable single-employee path that O2 composes.
• Blocking runtime contract: bytefolk/digital-employee#165 at R4.
• Blocking MCP contract: bytefolk/digital-employee#219 at R1.
• Existing non-blocking foundation: bytefolk/digital-employee#158 at R3 proves explicit single-hop delegation but not team peer messaging or live child control.
• Existing related work: bytefolk/org-workbench#89 owns the narrower MCP grant-at-hire gap and must be linked or superseded by, not duplicated in, the future workbench child.
• Children: none yet. Exact repository children are created only after the open decisions below are frozen.

No self-loop or bidirectional blocking edge was found in the current graph.

Acceptance Criteria

AC-001 — Team identity and conversations survive restart

• Verifies: REQ-001
• Given: a credential-free local fixture with three named positions and empty durable stores.
• When: a user addresses one employee, that employee sends one direct peer message and performs one explicit handoff, and the workbench/runtime are restarted.
• Then: the same roster, direct/group thread identities, sender/recipient attribution, correlation chain, and ordered events are queryable with no synthetic or duplicated turn.
• Evidence required: test+CI+manual

AC-002 — Live control is ordered, idempotent, and fail closed

• Verifies: REQ-002
• Given: one running delegated child and fixtures for an unauthorized recipient/tool, a duplicate command, and a stale command.
• When: the operator lists children, steers the authorized child once, and requests stop.
• Then: lifecycle events are ordered and durable; the steer is applied at most once; stop produces an explicit terminal or partial outcome; duplicate/stale commands do not re-execute; and unauthorized paths produce audit evidence with zero tool execution.
• Evidence required: test+CI+security-review

AC-003 — Recurring work preserves only bounded continuity

• Verifies: REQ-003
• Given: one monitor job, a scoped checkpoint/notepad, and an explicitly granted memory record.
• When: identical input is checked twice, changed input is checked once, the process restarts, and the memory grant is revoked.
• Then: the identical second check invokes no model and sends no delivery; changed input produces exactly one run; restart produces no duplicate; checkpoint/notepad access remains job-scoped; and the revoked memory is no longer recalled.
• Evidence required: test+CI+manual

AC-004 — MCP lifecycle and effective tools are observable

• Verifies: REQ-004
• Given: a local stdio MCP fixture declared by an employee profile with position-scoped tool modes.
• When: the engine loads it, the operator inspects it, an approval-gated configuration change is attempted, and the server crashes.
• Then: only the authority intersection is exposed; the workbench shows deterministic loading/ready/error health, effective schemas/modes and usage counts; the change requires exact preview and approval; and crash handling leaves zero partially exposed tools or silent fallback.
• Evidence required: test+CI+security-review

AC-005 — The proof is portable and secret safe

• Verifies: REQ-005
• Given: a clean checkout with no channel, model, or service credentials.
• When: the deterministic proof and sensitive-information scan run.
• Then: the proof completes locally; no default permission or concurrency limit is widened; and no credential value, private URL, host path, user payload, or production log is emitted in artifacts.
• Evidence required: test+CI+security-review

AC-006 — Current-revision evidence is independently replayable

• Verifies: REQ-001, REQ-002, REQ-003, REQ-004, REQ-005
• Given: merged full SHAs, AC-linked commands, deterministic E3 artifacts, and a clean independent host.
• When: the current revision is replayed from a clean checkout.
• Then: every AC has an immutable PASS/HOLD ledger with environment, time, verifier, command, result, and artifact permalink; unreleased main baselines are distinguished from tagged releases; and no local-only run is treated as acceptance.
• Evidence required: CI+manual+independent-review

Non-goals

• Autonomous recipient selection, learned routing, or hidden delegation.
• Recursive or unbounded delegation graphs, fan-out orchestration, or an increased default concurrency limit.
• Shared mutable memory across employees or automatic promotion of conversation text into long-term memory.
• A general scheduler product beyond the bounded proof.
• Raw browser/CDP control, hosted multi-tenancy, marketplace, billing, or provider catalog work.
• Reimplementing document collaboration or changing O1 acceptance criteria.
• Copying upstream source or mirroring upstream internal architecture.

Status and open decisions

• Status: needs-design
• Priority: P1
• Product owner: @PeterGuy326
• Technical owner: unassigned
• Reason: the end-to-end outcome and repository boundaries are explicit, but the portable peer-event envelope, live-control command semantics, scheduler ownership boundary, and exact child-Issue DAG are not yet frozen.
• Exit to ready: approve those four contracts, create and link one owner per repository child, remove any overlap with existing Issues, and revise this record semantically to R2 through an exact approved mutation.

Open decisions:

1. Which peer-conversation fields are portable runtime facts versus workbench-local projections?
2. What are the exact control command IDs, safe points, timeout semantics, and partial-result rules?
3. Does the runtime own recurring-job execution while the workbench owns schedule UX, or is a narrower adapter boundary required?
4. What is the smallest E2 implementation order: peer identity/control first, recurring continuity second, MCP operating surface third?

Supporting evidence

• Upstream prior art: Hermes Agent v0.21.0 / v2026.8.31, fixed commit 29112bef099274229cadff79cdff7bf7b99c4b77.
• ByteFolk development baselines inspected on 2026-09-01: digital-employee@f220a5588d4eabd5014d2e6d4ec723233b421fbe, org-workbench@4d20c6ae82851488f9e6f8231ffbdae6077d58cd, and mem@10d4bf7a48fd5ab0ce6fc67caa407a717f81830e. These are main baselines, not release claims.
• Exact-phrase organization searches found no duplicate open or closed Epic for a governed team, peer handoff, live steering, or Pantheon. Existing narrower records are linked in the DAG above.

Compatibility and risk

• Event and control schemas require explicit versioning and migration rules before ready.
• Peer messages and recurring state can leak context unless recipient, memory, and retention scopes are enforced at every read and write.
• Live steering and retries can duplicate tool execution unless command and action idempotency are separate and observable.
• MCP stdio/remote configuration is security-sensitive; only environment-variable names, never values, may enter a public manifest or evidence record.
• UI health and usage are projections of runtime evidence and must not claim readiness from stale local state.

Change history

Revision	Effective time	Decision	Superseding comment
R1	2026-09-01T07:35:50Z	Create O2 as a needs-design sibling to O1; adopt clean-room product patterns from the pinned Hermes release while preserving ByteFolk authority, memory, and evidence boundaries	initial body