1
Master onboarding agent controlling progression and state.
Valletta
OpenClaw
Onboarding v1.7
State-Embedded Queue Model
Multi-Level Onboarding Architecture
Level 1 shows OpenClaw multi-agent orchestration where queue is embedded in onboarding state. Level 2 shows internal execution contracts for each agent/tool binding.
Master process owner: Onboarding Agent
Queue = state.pending_actions[] (not external)
Tools are adapters with explicit confirmations
Worker = agent with a tool binding
Single-page artifacts with modal preview
Program Metrics
3
Worker agents: Admin, Document, Consultant (agent + tool model).
1
Queue implementation: pending_actions[] inside state.
16
Concrete adapter tools listed and mapped to execution actions.
Level 1: Actor and Agent Interaction Map
Primary orchestration path
Worker to adapter execution
Fallback or escalation channels
Risk control layers (queue, idempotency, security)
Level 2: Internal Flow Inside Each Agent
Select an agent to inspect its low-level execution sequence, inputs, outputs, and handoff contracts.
Onboarding Agent (Master)
Owns process progression, state writes, stakeholder communication, and escalation decisions.
Critical Integration and Approval Gates
| Gate | Condition to Pass | Evidence | If Not Passed |
|---|---|---|---|
| Routing Gate | Start payload arrives in approved Slack context | Validated payload and onboarding id | Reject and request strict template correction |
| Account Provision Gate | Google/Jira/Slack/VPN actions confirmed | adapter evidence ids and refs | move to manual_required with admin escalation |
| Contract Selection Gate | Deterministic rule match found | rule id, template id, registry id | contract_selection_review_required and HR/Legal review |
| Signed Contract Gate | Signed copy verified and stored | signed contract URI and notifications | follow-up cycle and accounting escalation |
| Completion Gate | Contract, English, handoff, and required tails complete | completion event record | stay open or transition to manual takeover path |
OpenClaw Skills and Integration Overlay
Architecture is mapped to OpenClaw-native capabilities where possible, and to explicit custom adapters where native coverage is not guaranteed.
| Architecture Block | OpenClaw Capability | Delivery Mode | Control Notes |
|---|---|---|---|
| Routing + Recruiter Start | Thread context, strict payload parser prompts, policy docs | native + config | Approved channel only; RM-thread ignore rule enforced. |
| State Machine + State Layer | JSON state schema, append-only event log, pending_actions[], state adapter contract |
custom adapter on OpenClaw workspace | No stage transition without state-machine validation. |
| Agent Action Loop (No External Queue) | Onboarding-agent runtime picks and processes pending_actions[] |
agent runtime logic | Agent owns pick/execute/retry/update cycle and evidence validation. |
| Calendar + Mail + Docs | Google connector family (calendar, mail, storage) or delegated API adapters | native if available, otherwise custom adapter | All outputs must return event id / uri evidence. |
| Admin Provisioning + Account Manager | Admin adapter and command bridge to ACL-restricted account-manager path | custom adapter | Mandatory feedback loop: pending/confirmed/failed written back to state. |
| Contract and Storage Flow | Template registry adapter, storage adapter, deterministic rule file | custom adapter | Document worker returns structured result only, no direct state writes. |
| Heartbeat + SLA | OpenClaw heartbeat/cron scheduling plus SLA checker logic | native scheduler + custom rules | Each state has deadline checks and escalation targets. |
| Error/Escalation + Security | Runbook automation, masked observability logs, manual takeover templates | policy + custom pipeline | Sensitive data stays in restricted storage and masked audit logs. |
OpenClaw Simplified Execution Model
| Rule | Implementation | Why It Matters |
|---|---|---|
| Queue is not external | state.pending_actions[] in onboarding state JSON |
No hidden queue service; full traceability in one source of truth. |
| Tools act as adapters | Deterministic calls like admin_adapter.create_google_user |
Agent does not improvise external actions. |
| Agent owns action loop | Pick next pending action, execute, retry, update state, append event | Prevents false success and uncontrolled progression. |
| Worker = agent with a tool | Admin/Document/Consultant workers are scoped tool-bound agents | Specialization without process ownership fragmentation. |
Concrete tool bindings used in this architecture:
| Worker or Layer | Concrete Tools | Expected Confirmation |
|---|---|---|
| State Layer | state_adapter.write_current_state, state_adapter.append_event |
state version/hash and event id |
| Admin Worker | admin_adapter.create_google_user, admin_adapter.invite_slack, admin_adapter.invite_jira, admin_adapter.create_vpn_ticket, admin_adapter.resolve_account_manager_status |
pending/confirmed/failed with evidence |
| Calendar Layer | calendar_adapter.create_event |
event id and meet link |
| Document Worker | contract_adapter.select_rule, contract_adapter.generate_contract |
rule id, registry number, contract uri |
| Storage Layer | storage_adapter.create_candidate_folder, storage_adapter.store_document, storage_adapter.store_signed_contract |
folder and artifact uris |
| Notification Layer | notification_adapter.send_slack, notification_adapter.send_email, notification_adapter.send_tg_fallback |
delivery status and message id |
Real Example: Ivan Ivanov (John Maltovich)
Below is a real execution walk-through in this exact OpenClaw model.
| Input Field | Value |
|---|---|
| Candidate full name | Ivan Ivanov |
| Display name | John Maltovich |
| Role | Backend Developer |
| Start date/time | 2026-05-12 10:00 |
| Personal email | ivan@example.com |
| Telegram | @ivan_ivanov |
| VPN required | yes |
| Interview link | provided |
Execution flow:
| Step | What Happens | State and Tools |
|---|---|---|
| 1 | Recruiter sends strict start payload in onboarding Slack entrypoint. | Routing sends request to onboarding-agent. |
| 2 | Agent creates onboarding record. | onboarding_id=ONB-2026-0512-IVANOV, status=created, state_adapter.write_current_state. |
| 3 | Agent validates fields and initializes process shell. | status=preboarding_initialized, initial pending_actions[] created. |
| 4 | Calendar actions are added and executed. | calendar_adapter.create_event for AI and Tech events, save event ids and meet link. |
| 5 | Agent requests access stack. | Pending actions for Google, Slack, Jira, VPN via admin adapter tools. |
| 6 | Admin worker executes account actions. | admin_adapter.create_google_user, invite_slack, invite_jira, create_vpn_ticket. |
| 7 | Account manager feedback loop is reconciled. | admin_adapter.resolve_account_manager_status, statuses move through pending|confirmed|failed. |
| 8 | Preboarding package is sent. | notification_adapter.send_email/send_slack, candidate_preboarding_sent=true. |
| 9 | Heartbeat checks deadlines before start. | Reads state and SLA windows, escalates only if blocked. |
| 10 | Candidate sends first Slack message at start time. | Conversation guard validates stage, set candidate_started=true. |
| 11 | Agent runs contract questionnaire. | contract_questionnaire=collecting then completed. |
| 12 | Candidate uploads documents. | storage_adapter.store_document, documents_status=received|partial. |
| 13 | Document worker runs deterministic contract flow. | contract_adapter.select_rule, contract_adapter.generate_contract, structured output only. |
| 14 | Agent sends generated contract to candidate. | status=awaiting_signed_contract, notification tools used. |
| 15 | Candidate signs and returns contract. | storage_adapter.store_signed_contract, set contract_signed=true. |
| 16 | Recruiter/accounting are notified. | notification_adapter.send_slack, notification_adapter.send_email. |
| 17 | English written and FAQ/checklist are completed. | Structured score saved in state, optional April School request. |
| 18 | Tech onboarding handoff is sent from stored event artifact. | tech_onboarding_link_sent=true. |
| 19 | Post-onboarding tails are closed and process is finalized. | post_onboarding_status=completed, final status=completed. |
Control points in this example:
| Control Point | What Must Be True |
|---|---|
| CP1 Start | State created and onboarding id assigned. |
| CP2 Access | Google/Slack/Jira/VPN are confirmed by tool evidence. |
| CP3 Show-up | First candidate Slack ping is recorded in state. |
| CP4 Contract pre-send | Questionnaire and required docs are complete. |
| CP5 Signed contract | Signed file is stored and notifications are sent. |
| CP6 Completion | Post-onboarding tails are complete before final close. |
Artifact Viewer (Single Page with Modal)
All artifacts are viewable here without leaving the page. Click Preview to open content in modal.