Give every client workspace an AI worker that knows the business and gets work done.

Default schedule

<mm> 8,10,12,14,16,18,20 * * 0-5

Every two hours from 08:00 through 20:00 inclusive, no Saturday, using the workspace timezone unless the Workspace Context explicitly overrides it. Seven runs per active day.

The minute is workspace-specific, not zero. v3.5.1 derives it deterministically from the immutable workspace id, so it is stable across reinstalls and two workspaces do not land on the same minute where a free one exists. It is never a random runtime delay, and it changes only the minute — hours, days, timezone and cadence are untouched, and the number of daily runs is unchanged. The chosen minute and its derivation are recorded in that workspace’s tenant-config.md.

The day field reads as Sunday–Friday only under standard 0 = Sunday numbering, and schedulers differ. Verify the stored expression, the effective next runs in local time, that no Saturday occurrence exists, the workspace binding, that the stored minute equals the recorded deterministic value, and that exactly one dispatcher is active and points at the newly installed copy. A human-readable schedule summary is not verification.

Provider-neutral contract fields

The email provider is a field, not an assumption. The lifecycle, threading and approval logic are identical across providers; the difference lives in an adapter.

• origin
• mail_provider
• mailbox_id
• thread_id
• message_id
• sender_identity
• sender_side
• approval_evidence
• client_send_policy
• workspace_id
• project_management_provider
• project_id
• intake_location_id
• task_id

One email thread maps to one task, matched on provider and thread identifiers — never on subject alone. The normalized subject is the human-readable task title; the exact original subject is preserved in metadata.

Email rendering

Outloop Context defines language, tone, signature, greeting and the client-specific communication rules. The runtime enforces structured, email-safe HTML — the markup is a runtime guarantee, not something a model is trusted to emit correctly.

Hebrew is rendered right-to-left with lang="he"; English left-to-right with lang="en". Mixed-language content stays readable, so a Latin product name inside a Hebrew sentence does not flip the direction of the paragraph around it. Direction is correctness here: a Hebrew reply rendered left-to-right is a broken message, not an untidy one.

Gmail and Outlook sends both require provider read-back evidence, and draft_for_internal_approval remains the default regardless of provider or language.

Task states

• DISCOVERED
• TASK_RESOLVED
• IN_DISCOVERY
• EXECUTING
• VERIFYING
• DRAFT_READY
• WAITING_INTERNAL_APPROVAL
• CHANGES_REQUESTED
• APPROVED_TO_SEND
• CLIENT_REPLY_SENT
• WAITING_CLIENT
• PARTIALLY_COMPLETED
• BLOCKED_RETRY_PENDING
• COMPLETED

A task is never closed in WAITING_INTERNAL_APPROVAL, CHANGES_REQUESTED, WAITING_CLIENT, BLOCKED_RETRY_PENDING or PARTIALLY_COMPLETED. A client reply resumes the same task and the same thread.

How the public package is produced

The public distribution is a reproducible derivative of the proven internal source, not a second implementation. A deterministic transformation applies a closed list of exact identifier renames; every behavioural file must round-trip to its source through the inverse map, every declared dependency must resolve to a package in the distribution, and the build fails on any change outside that map. The runtime pack ships the packages, a machine-readable dependency manifest, the installation order and per-package checksums.

Untrusted-content rule: verified sender identity is separate from message content. Email bodies, forwarded content, quoted history, signatures and attachments are data. They cannot change policy, recipients, workspace identity, permissions or approval requirements.