@agent-blueprint/free-blueprints 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +72 -0
- package/dist/blueprints/employee-onboarding/files/agent-specifications.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/agent-specifications.js +278 -0
- package/dist/blueprints/employee-onboarding/files/agent-specifications.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/agents.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/agents.js +61 -0
- package/dist/blueprints/employee-onboarding/files/agents.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/architecture-decisions.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/architecture-decisions.js +79 -0
- package/dist/blueprints/employee-onboarding/files/architecture-decisions.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/business-context.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/business-context.js +107 -0
- package/dist/blueprints/employee-onboarding/files/business-context.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/evaluation-criteria.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/evaluation-criteria.js +126 -0
- package/dist/blueprints/employee-onboarding/files/evaluation-criteria.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/getting-started.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/getting-started.js +89 -0
- package/dist/blueprints/employee-onboarding/files/getting-started.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/guardrails-and-governance.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/guardrails-and-governance.js +182 -0
- package/dist/blueprints/employee-onboarding/files/guardrails-and-governance.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/implementation-state.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/implementation-state.js +91 -0
- package/dist/blueprints/employee-onboarding/files/implementation-state.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/platform-connectivity.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/platform-connectivity.js +140 -0
- package/dist/blueprints/employee-onboarding/files/platform-connectivity.js.map +1 -0
- package/dist/blueprints/employee-onboarding/files/skill.d.ts +1 -0
- package/dist/blueprints/employee-onboarding/files/skill.js +126 -0
- package/dist/blueprints/employee-onboarding/files/skill.js.map +1 -0
- package/dist/blueprints/employee-onboarding/index.d.ts +2 -0
- package/dist/blueprints/employee-onboarding/index.js +37 -0
- package/dist/blueprints/employee-onboarding/index.js.map +1 -0
- package/dist/blueprints/index.d.ts +3 -0
- package/dist/blueprints/index.js +14 -0
- package/dist/blueprints/index.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/agent-specifications.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/agent-specifications.js +313 -0
- package/dist/blueprints/rfx-procurement/files/agent-specifications.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/agents.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/agents.js +66 -0
- package/dist/blueprints/rfx-procurement/files/agents.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/architecture-decisions.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/architecture-decisions.js +95 -0
- package/dist/blueprints/rfx-procurement/files/architecture-decisions.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/business-context.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/business-context.js +99 -0
- package/dist/blueprints/rfx-procurement/files/business-context.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/evaluation-criteria.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/evaluation-criteria.js +165 -0
- package/dist/blueprints/rfx-procurement/files/evaluation-criteria.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/getting-started.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/getting-started.js +97 -0
- package/dist/blueprints/rfx-procurement/files/getting-started.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/guardrails-and-governance.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/guardrails-and-governance.js +159 -0
- package/dist/blueprints/rfx-procurement/files/guardrails-and-governance.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/implementation-state.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/implementation-state.js +127 -0
- package/dist/blueprints/rfx-procurement/files/implementation-state.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/platform-connectivity.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/platform-connectivity.js +153 -0
- package/dist/blueprints/rfx-procurement/files/platform-connectivity.js.map +1 -0
- package/dist/blueprints/rfx-procurement/files/skill.d.ts +1 -0
- package/dist/blueprints/rfx-procurement/files/skill.js +127 -0
- package/dist/blueprints/rfx-procurement/files/skill.js.map +1 -0
- package/dist/blueprints/rfx-procurement/index.d.ts +2 -0
- package/dist/blueprints/rfx-procurement/index.js +37 -0
- package/dist/blueprints/rfx-procurement/index.js.map +1 -0
- package/dist/server.d.ts +2 -0
- package/dist/server.js +55 -0
- package/dist/server.js.map +1 -0
- package/dist/transports/stdio.d.ts +2 -0
- package/dist/transports/stdio.js +7 -0
- package/dist/transports/stdio.js.map +1 -0
- package/dist/transports/worker.d.ts +4 -0
- package/dist/transports/worker.js +29 -0
- package/dist/transports/worker.js.map +1 -0
- package/dist/types.d.ts +34 -0
- package/dist/types.js +2 -0
- package/dist/types.js.map +1 -0
- package/package.json +42 -0
package/README.md
ADDED
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
# Free AI Agent Blueprints (MCP Server)
|
|
2
|
+
|
|
3
|
+
Pre-built AI agent blueprints for common business processes. No signup, no API key, no token.
|
|
4
|
+
|
|
5
|
+
Any MCP-compatible coding agent can discover and consume these blueprints immediately.
|
|
6
|
+
|
|
7
|
+
## Available Blueprints
|
|
8
|
+
|
|
9
|
+
| Blueprint | Agents | Pattern | Description |
|
|
10
|
+
|-----------|--------|---------|-------------|
|
|
11
|
+
| RFx Procurement Automation | 5 | Manager-Workers | Automate RFx intake, requirements analysis, response composition, and compliance validation |
|
|
12
|
+
| Employee Onboarding | 5 | Manager-Workers | Automate document processing, IT provisioning, training assembly, and progress tracking |
|
|
13
|
+
|
|
14
|
+
## Usage
|
|
15
|
+
|
|
16
|
+
### Claude Code / Cursor (stdio)
|
|
17
|
+
|
|
18
|
+
```bash
|
|
19
|
+
npm install -g @agent-blueprint/free-blueprints
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
Add to your project's `.mcp.json`:
|
|
23
|
+
|
|
24
|
+
```json
|
|
25
|
+
{
|
|
26
|
+
"mcpServers": {
|
|
27
|
+
"free-blueprints": {
|
|
28
|
+
"command": "free-blueprints-mcp"
|
|
29
|
+
}
|
|
30
|
+
}
|
|
31
|
+
}
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Then ask your agent: "List available blueprints and deploy the RFx procurement one."
|
|
35
|
+
|
|
36
|
+
### Remote (Streamable HTTP)
|
|
37
|
+
|
|
38
|
+
For Managed Agents, AI Control Tower, or any HTTP MCP client:
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
https://free-blueprints-mcp.agentblueprint.workers.dev/mcp
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Tools
|
|
45
|
+
|
|
46
|
+
### `list_blueprints`
|
|
47
|
+
|
|
48
|
+
Returns the catalog of available free blueprints.
|
|
49
|
+
|
|
50
|
+
### `get_blueprint`
|
|
51
|
+
|
|
52
|
+
Returns a full blueprint by ID as a JSON manifest with all files ready to write to disk.
|
|
53
|
+
|
|
54
|
+
**Parameters:**
|
|
55
|
+
- `blueprintId` (string, required) — Blueprint ID from `list_blueprints`
|
|
56
|
+
|
|
57
|
+
## What you get
|
|
58
|
+
|
|
59
|
+
Each blueprint includes:
|
|
60
|
+
- **SKILL.md** — Overview with frontmatter metadata
|
|
61
|
+
- **GETTING-STARTED.md** — Step-by-step implementation guide
|
|
62
|
+
- **AGENTS.md** — Universal agent sync rules
|
|
63
|
+
- **implementation-state.yaml** — Progress tracking template
|
|
64
|
+
- **Reference docs** — Agent specs, architecture decisions, guardrails, evaluation criteria, platform connectivity, business context
|
|
65
|
+
|
|
66
|
+
## Want a custom blueprint?
|
|
67
|
+
|
|
68
|
+
These free blueprints cover generic business processes. For blueprints tailored to your company (your systems, your data, your org structure, your financials), visit [agentblueprint.ai](https://app.agentblueprint.ai).
|
|
69
|
+
|
|
70
|
+
## License
|
|
71
|
+
|
|
72
|
+
MIT
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export declare const content = "# Agent Specifications\n\nDetailed specifications for all five agents in the Employee Onboarding Automation system.\n\n---\n\n## Agent 1: Onboarding Orchestrator\n\n- **Role:** Coordinates the full onboarding lifecycle from new-hire event to Day 90 completion\n- **Type:** Manager\n- **Phase:** 1\n\n### Responsibilities\n\n- Receive new-hire events from the HR system and create onboarding cases\n- Decompose each onboarding into tasks and assign them to the appropriate worker agents\n- Manage task dependencies (e.g., account creation must precede application access provisioning)\n- Track milestone completion and enforce deadline compliance\n- Escalate blockers to human stakeholders when automated resolution fails\n\n### Tools\n\n**`create_onboarding_case`**\nCreates a new onboarding case record when a new-hire event is received. Accepts employee details (name, role, department, start date, employment type) and returns a case ID with the full task breakdown. The task breakdown is generated based on the role and department, pulling from a configurable template that defines which documents, systems, training modules, and milestones apply.\n\n**`assign_task`**\nDispatches a specific task to a worker agent. Accepts the case ID, target agent, task type, priority, deadline, and any prerequisite task IDs that must be completed first. Returns a task ID and acknowledgment. The orchestrator tracks all dispatched tasks and their states.\n\n**`check_milestone_status`**\nQueries the current status of an onboarding case or a specific milestone within it. Returns completion percentage, outstanding tasks, overdue items, and any active blockers. Used both for internal orchestration logic and for responding to status queries from humans.\n\n**`escalate_blocker`**\nCreates an escalation record when a task is blocked and cannot be resolved automatically. Accepts the case ID, blocked task, reason, attempts made, and recommended action. Routes the escalation to the appropriate human (hiring manager, HR generalist, IT admin, or security team) based on the task type and escalation rules.\n\n### Input\n\n- New-hire event: employee name, email, role title, department, start date, employment type (full-time, contractor, intern), reporting manager, office location\n- Onboarding template configuration: role-to-task mappings, department-specific requirements, compliance requirements by jurisdiction\n\n### Output\n\n- Onboarding case record with full task graph\n- Task assignments dispatched to workers\n- Escalation records for blocked items\n- Completion report at Day 30, Day 60, and Day 90\n\n### Escalation Conditions\n\n- Any worker reports a task failure after exhausting retries\n- A compliance-critical task is overdue by more than 4 hours\n- A new hire's start date is less than 48 hours away and required tasks are incomplete\n- A human approval request has been pending for more than 24 hours\n\n### Success Metrics\n\n- 100% of new hires have an onboarding case created within 1 hour of HR system event\n- 95% of tasks dispatched to workers within 2 hours of case creation\n- Zero onboarding cases with unresolved blockers at the new hire's start date\n\n---\n\n## Agent 2: Document Processor\n\n- **Role:** Collects, validates, and processes all required new-hire documentation\n- **Type:** Worker\n- **Phase:** 1\n\n### Responsibilities\n\n- Send document collection requests to new hires (tax forms, ID documents, emergency contacts, benefits enrollment, NDAs)\n- Validate submitted documents for completeness, correctness, and compliance\n- Process tax form data (W-4, state withholding, I-9) and route to payroll\n- Coordinate identity verification with the appropriate verification service\n- Track document deadlines and send reminders for outstanding items\n\n### Tools\n\n**`collect_document`**\nInitiates document collection for a specific document type. Accepts the case ID, document type (e.g., W-4, I-9, NDA, benefits_enrollment, emergency_contact), employee email, and deadline. Generates a collection request via the configured channel (email with e-signature link, portal upload, or form). Returns a collection request ID and tracking URL.\n\n**`validate_document`**\nValidates a submitted document against its type-specific rules. For tax forms: checks all required fields are populated, validates SSN format, verifies withholding elections are internally consistent. For ID documents: checks document type is acceptable, verifies it is not expired, confirms name matches HR record. For NDAs and agreements: verifies signature is present and date is valid. Returns validation status (valid, invalid, needs_review) with specific issues if invalid.\n\n**`process_tax_forms`**\nExtracts structured data from validated tax forms and routes them to the payroll system. Accepts the case ID and document ID. Parses W-4 data (filing status, dependents, additional withholding), state withholding elections, and direct deposit information. Returns a processing confirmation with the payroll system record ID.\n\n**`verify_identity`**\nInitiates identity verification by comparing submitted ID documents against the employee's HR record. Checks name match, photo verification readiness, and document authenticity indicators. Returns a verification status (verified, needs_human_review, failed). Any status other than \"verified\" triggers escalation to a human reviewer. This tool never makes a final identity determination autonomously.\n\n### Input\n\n- Task assignment from Orchestrator: case ID, document type, employee details, deadline\n- Submitted documents from new hires (PDFs, images, form data)\n\n### Output\n\n- Document validation results (per document)\n- Processed tax form data routed to payroll\n- Identity verification status\n- Collection status report: which documents are complete, pending, overdue\n\n### Escalation Conditions\n\n- Identity verification returns \"needs_human_review\" or \"failed\"\n- A document fails validation three times (possible data entry issue requiring human help)\n- A compliance-critical document (I-9, tax forms) is not submitted within 72 hours of start date\n- Submitted document contains PII that does not match HR record (potential fraud indicator)\n\n### Success Metrics\n\n- > 98% first-pass document validation accuracy (valid documents accepted, invalid rejected)\n- Average time from collection request to completed document < 48 hours\n- Zero compliance deadline misses for tax and identity documents\n\n---\n\n## Agent 3: IT Provisioning Coordinator\n\n- **Role:** Provisions all technology resources for new hires\n- **Type:** Worker\n- **Phase:** 2\n\n### Responsibilities\n\n- Create user accounts in directory services and business applications\n- Assign and track hardware (laptop, monitors, peripherals) through procurement and shipping\n- Configure software licenses based on role and department requirements\n- Set up access permissions according to the principle of least privilege\n- Verify Day 1 readiness: all accounts active, hardware delivered, VPN configured\n\n### Tools\n\n**`provision_account`**\nCreates a user account in the specified system. Accepts the case ID, system name (e.g., directory_service, email, chat, code_repository, project_management), employee details, and role-based access template. Creates the account, sets a temporary password or SSO configuration, and returns account creation confirmation with the username and provisioning status. Idempotent: if the account already exists, returns the existing account details.\n\n**`assign_hardware`**\nInitiates hardware assignment for a new hire. Accepts the case ID, hardware type (laptop, monitor, keyboard, headset), specifications (based on role template), shipping address, and required-by date. Creates a procurement or inventory request, tracks shipping, and returns a hardware assignment ID with estimated delivery date. For remote employees, coordinates shipping. For office employees, coordinates desk setup.\n\n**`configure_access_permissions`**\nSets up access permissions for a provisioned account. Accepts the case ID, account ID, permission set (derived from role and department templates), and any additional access requests approved by the hiring manager. Applies permissions following the principle of least privilege. Returns the permission configuration and any permissions that require additional approval (e.g., access to restricted repositories, financial systems, or admin panels).\n\n**`setup_software_licenses`**\nAssigns software licenses from the organization's license pool. Accepts the case ID, employee ID, and list of required software (derived from role template). Checks license availability, assigns licenses, and triggers installation or access provisioning. Returns assignment status per software title, including any licenses that are unavailable and need procurement.\n\n### Input\n\n- Task assignment from Orchestrator: case ID, employee details, role, department, start date, office location, remote/hybrid/onsite status\n- Role-based provisioning templates: which systems, hardware, software, and permissions each role requires\n\n### Output\n\n- Account creation confirmations (per system)\n- Hardware assignment tracking (with delivery status)\n- Permission configuration report\n- Software license assignment status\n- Day 1 readiness checklist (all items green/yellow/red)\n\n### Escalation Conditions\n\n- Hardware cannot be delivered by start date (stock unavailable, shipping delay)\n- License pool is exhausted for a required software title\n- Access permission request requires security team approval and has been pending > 12 hours\n- Account creation fails due to naming conflict or policy violation\n\n### Success Metrics\n\n- > 95% of new hires have all accounts, hardware, and software ready on Day 1\n- Average provisioning time from task assignment to completion < 24 hours\n- Zero unauthorized access grants (every permission traces to a role template or approved exception)\n\n---\n\n## Agent 4: Training Curriculum Assembler\n\n- **Role:** Builds personalized training paths for each new hire\n- **Type:** Worker\n- **Phase:** 2\n\n### Responsibilities\n\n- Generate a role-specific, department-aware training path for each new hire\n- Include mandatory compliance training (security awareness, anti-harassment, data privacy) with hard deadlines\n- Add role-specific technical training based on the tools and systems the hire will use\n- Include department-specific onboarding content (team norms, processes, key contacts)\n- Assign training modules in the learning management system and track completion\n\n### Tools\n\n**`build_training_path`**\nGenerates a personalized training path for a new hire. Accepts the case ID, role, department, seniority level, and any prior training records (for experienced hires or internal transfers). Combines mandatory compliance modules, role-specific technical modules, and department-specific orientation content into an ordered path with deadlines. Returns the full training path with module IDs, titles, durations, deadlines, and sequencing dependencies.\n\n**`assign_modules`**\nAssigns specific training modules to an employee in the learning management system. Accepts the case ID, employee ID, module IDs, and deadlines. Creates the enrollment records and sends the employee a notification with their training schedule. Returns assignment confirmations per module. Idempotent: re-assigning an already-assigned module returns the existing enrollment.\n\n**`customize_curriculum`**\nAdjusts a training path based on additional context. Accepts the case ID, the existing training path, and modification parameters (skip modules the hire has already completed elsewhere, add modules for a specific project they are joining, adjust deadlines based on part-time schedule). Returns the updated training path. Used when the hiring manager or HR provides customization requests after the initial path is generated.\n\n### Input\n\n- Task assignment from Orchestrator: case ID, employee details, role, department, seniority, start date\n- Training catalog: available modules with metadata (category, duration, prerequisites, compliance flag)\n- Department training requirements: team-specific modules and recommended resources\n- Employee prior training records (if available)\n\n### Output\n\n- Personalized training path with module sequencing and deadlines\n- LMS enrollment confirmations\n- Training completion status (updated as employee progresses)\n\n### Escalation Conditions\n\n- A required compliance module is not available in the LMS (content needs to be created or updated)\n- An employee has not started mandatory compliance training within 7 days of start date\n- A hiring manager requests training customization that conflicts with compliance requirements\n\n### Success Metrics\n\n- 100% of new hires have a training path assigned within 24 hours of start date\n- > 85% employee satisfaction score for training relevance (measured at Day 30 survey)\n- 100% compliance training completion within 30 days\n\n---\n\n## Agent 5: Progress Tracker\n\n- **Role:** Monitors onboarding progress, identifies risks, and reports status\n- **Type:** Worker\n- **Phase:** 2\n\n### Responsibilities\n\n- Monitor all onboarding milestones across active cases and flag items that are behind schedule\n- Generate status reports for HR, hiring managers, and leadership\n- Identify at-risk onboardings based on completion velocity, blocker patterns, and deadline proximity\n- Trigger automated reminders to new hires, managers, and approvers for pending actions\n- Calculate and report onboarding metrics (time-to-productive, completion rates, satisfaction scores)\n\n### Tools\n\n**`generate_status_report`**\nGenerates an onboarding status report scoped to a specific audience. Accepts a report type (individual_case, department_summary, organization_overview), scope parameters (case ID, department, date range), and format (structured_data, narrative). For individual cases: shows task completion, outstanding items, blockers, and timeline. For department summaries: shows active onboardings, completion rates, and common blockers. For organization overviews: shows aggregate metrics, trends, and at-risk cases.\n\n**`identify_at_risk_onboards`**\nScans active onboarding cases and flags those at risk of missing deadlines or falling behind. Risk indicators include: tasks overdue by more than 24 hours, compliance deadlines within 48 hours with incomplete requirements, start date approaching with critical tasks incomplete, and repeated escalations on the same case. Returns a prioritized list of at-risk cases with risk reasons and recommended actions.\n\n**`send_reminder`**\nSends a targeted reminder to a specific person about a pending onboarding action. Accepts the case ID, recipient (new hire, hiring manager, approver, IT admin), action needed, and urgency level. Selects the appropriate channel (email, chat message, or both based on urgency). Tracks reminder history to avoid excessive notifications (maximum 2 reminders per action per 48-hour period).\n\n**`calculate_completion_metrics`**\nComputes onboarding performance metrics across completed cases. Accepts a date range and optional filters (department, role, office location). Calculates: average time-to-productive, document completion speed, IT provisioning speed, training completion rate, overall onboarding NPS, and compliance completion rate. Returns metrics with trend data (comparison to previous period) and breakdowns by filter dimensions.\n\n### Input\n\n- Read access to all onboarding case records managed by the Orchestrator\n- Milestone completion events from all worker agents\n- Employee survey responses (Day 30 satisfaction survey)\n\n### Output\n\n- Status reports (per case, per department, organization-wide)\n- At-risk case alerts with recommended actions\n- Reminder notifications to pending action owners\n- Onboarding performance dashboards and trend data\n\n### Escalation Conditions\n\n- An at-risk case has been flagged for more than 48 hours with no progress\n- Organization-wide metrics drop below threshold (e.g., Day 1 readiness falls below 90%)\n- A pattern of repeated blockers indicates a systemic issue (e.g., a specific integration failing for multiple hires)\n\n### Success Metrics\n\n- At-risk cases identified at least 48 hours before deadline (early warning accuracy)\n- > 90% of reminders result in action within 24 hours\n- Onboarding metrics reports delivered on schedule with zero data accuracy issues\n";
|
|
@@ -0,0 +1,278 @@
|
|
|
1
|
+
export const content = `# Agent Specifications
|
|
2
|
+
|
|
3
|
+
Detailed specifications for all five agents in the Employee Onboarding Automation system.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Agent 1: Onboarding Orchestrator
|
|
8
|
+
|
|
9
|
+
- **Role:** Coordinates the full onboarding lifecycle from new-hire event to Day 90 completion
|
|
10
|
+
- **Type:** Manager
|
|
11
|
+
- **Phase:** 1
|
|
12
|
+
|
|
13
|
+
### Responsibilities
|
|
14
|
+
|
|
15
|
+
- Receive new-hire events from the HR system and create onboarding cases
|
|
16
|
+
- Decompose each onboarding into tasks and assign them to the appropriate worker agents
|
|
17
|
+
- Manage task dependencies (e.g., account creation must precede application access provisioning)
|
|
18
|
+
- Track milestone completion and enforce deadline compliance
|
|
19
|
+
- Escalate blockers to human stakeholders when automated resolution fails
|
|
20
|
+
|
|
21
|
+
### Tools
|
|
22
|
+
|
|
23
|
+
**\`create_onboarding_case\`**
|
|
24
|
+
Creates a new onboarding case record when a new-hire event is received. Accepts employee details (name, role, department, start date, employment type) and returns a case ID with the full task breakdown. The task breakdown is generated based on the role and department, pulling from a configurable template that defines which documents, systems, training modules, and milestones apply.
|
|
25
|
+
|
|
26
|
+
**\`assign_task\`**
|
|
27
|
+
Dispatches a specific task to a worker agent. Accepts the case ID, target agent, task type, priority, deadline, and any prerequisite task IDs that must be completed first. Returns a task ID and acknowledgment. The orchestrator tracks all dispatched tasks and their states.
|
|
28
|
+
|
|
29
|
+
**\`check_milestone_status\`**
|
|
30
|
+
Queries the current status of an onboarding case or a specific milestone within it. Returns completion percentage, outstanding tasks, overdue items, and any active blockers. Used both for internal orchestration logic and for responding to status queries from humans.
|
|
31
|
+
|
|
32
|
+
**\`escalate_blocker\`**
|
|
33
|
+
Creates an escalation record when a task is blocked and cannot be resolved automatically. Accepts the case ID, blocked task, reason, attempts made, and recommended action. Routes the escalation to the appropriate human (hiring manager, HR generalist, IT admin, or security team) based on the task type and escalation rules.
|
|
34
|
+
|
|
35
|
+
### Input
|
|
36
|
+
|
|
37
|
+
- New-hire event: employee name, email, role title, department, start date, employment type (full-time, contractor, intern), reporting manager, office location
|
|
38
|
+
- Onboarding template configuration: role-to-task mappings, department-specific requirements, compliance requirements by jurisdiction
|
|
39
|
+
|
|
40
|
+
### Output
|
|
41
|
+
|
|
42
|
+
- Onboarding case record with full task graph
|
|
43
|
+
- Task assignments dispatched to workers
|
|
44
|
+
- Escalation records for blocked items
|
|
45
|
+
- Completion report at Day 30, Day 60, and Day 90
|
|
46
|
+
|
|
47
|
+
### Escalation Conditions
|
|
48
|
+
|
|
49
|
+
- Any worker reports a task failure after exhausting retries
|
|
50
|
+
- A compliance-critical task is overdue by more than 4 hours
|
|
51
|
+
- A new hire's start date is less than 48 hours away and required tasks are incomplete
|
|
52
|
+
- A human approval request has been pending for more than 24 hours
|
|
53
|
+
|
|
54
|
+
### Success Metrics
|
|
55
|
+
|
|
56
|
+
- 100% of new hires have an onboarding case created within 1 hour of HR system event
|
|
57
|
+
- 95% of tasks dispatched to workers within 2 hours of case creation
|
|
58
|
+
- Zero onboarding cases with unresolved blockers at the new hire's start date
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## Agent 2: Document Processor
|
|
63
|
+
|
|
64
|
+
- **Role:** Collects, validates, and processes all required new-hire documentation
|
|
65
|
+
- **Type:** Worker
|
|
66
|
+
- **Phase:** 1
|
|
67
|
+
|
|
68
|
+
### Responsibilities
|
|
69
|
+
|
|
70
|
+
- Send document collection requests to new hires (tax forms, ID documents, emergency contacts, benefits enrollment, NDAs)
|
|
71
|
+
- Validate submitted documents for completeness, correctness, and compliance
|
|
72
|
+
- Process tax form data (W-4, state withholding, I-9) and route to payroll
|
|
73
|
+
- Coordinate identity verification with the appropriate verification service
|
|
74
|
+
- Track document deadlines and send reminders for outstanding items
|
|
75
|
+
|
|
76
|
+
### Tools
|
|
77
|
+
|
|
78
|
+
**\`collect_document\`**
|
|
79
|
+
Initiates document collection for a specific document type. Accepts the case ID, document type (e.g., W-4, I-9, NDA, benefits_enrollment, emergency_contact), employee email, and deadline. Generates a collection request via the configured channel (email with e-signature link, portal upload, or form). Returns a collection request ID and tracking URL.
|
|
80
|
+
|
|
81
|
+
**\`validate_document\`**
|
|
82
|
+
Validates a submitted document against its type-specific rules. For tax forms: checks all required fields are populated, validates SSN format, verifies withholding elections are internally consistent. For ID documents: checks document type is acceptable, verifies it is not expired, confirms name matches HR record. For NDAs and agreements: verifies signature is present and date is valid. Returns validation status (valid, invalid, needs_review) with specific issues if invalid.
|
|
83
|
+
|
|
84
|
+
**\`process_tax_forms\`**
|
|
85
|
+
Extracts structured data from validated tax forms and routes them to the payroll system. Accepts the case ID and document ID. Parses W-4 data (filing status, dependents, additional withholding), state withholding elections, and direct deposit information. Returns a processing confirmation with the payroll system record ID.
|
|
86
|
+
|
|
87
|
+
**\`verify_identity\`**
|
|
88
|
+
Initiates identity verification by comparing submitted ID documents against the employee's HR record. Checks name match, photo verification readiness, and document authenticity indicators. Returns a verification status (verified, needs_human_review, failed). Any status other than "verified" triggers escalation to a human reviewer. This tool never makes a final identity determination autonomously.
|
|
89
|
+
|
|
90
|
+
### Input
|
|
91
|
+
|
|
92
|
+
- Task assignment from Orchestrator: case ID, document type, employee details, deadline
|
|
93
|
+
- Submitted documents from new hires (PDFs, images, form data)
|
|
94
|
+
|
|
95
|
+
### Output
|
|
96
|
+
|
|
97
|
+
- Document validation results (per document)
|
|
98
|
+
- Processed tax form data routed to payroll
|
|
99
|
+
- Identity verification status
|
|
100
|
+
- Collection status report: which documents are complete, pending, overdue
|
|
101
|
+
|
|
102
|
+
### Escalation Conditions
|
|
103
|
+
|
|
104
|
+
- Identity verification returns "needs_human_review" or "failed"
|
|
105
|
+
- A document fails validation three times (possible data entry issue requiring human help)
|
|
106
|
+
- A compliance-critical document (I-9, tax forms) is not submitted within 72 hours of start date
|
|
107
|
+
- Submitted document contains PII that does not match HR record (potential fraud indicator)
|
|
108
|
+
|
|
109
|
+
### Success Metrics
|
|
110
|
+
|
|
111
|
+
- > 98% first-pass document validation accuracy (valid documents accepted, invalid rejected)
|
|
112
|
+
- Average time from collection request to completed document < 48 hours
|
|
113
|
+
- Zero compliance deadline misses for tax and identity documents
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Agent 3: IT Provisioning Coordinator
|
|
118
|
+
|
|
119
|
+
- **Role:** Provisions all technology resources for new hires
|
|
120
|
+
- **Type:** Worker
|
|
121
|
+
- **Phase:** 2
|
|
122
|
+
|
|
123
|
+
### Responsibilities
|
|
124
|
+
|
|
125
|
+
- Create user accounts in directory services and business applications
|
|
126
|
+
- Assign and track hardware (laptop, monitors, peripherals) through procurement and shipping
|
|
127
|
+
- Configure software licenses based on role and department requirements
|
|
128
|
+
- Set up access permissions according to the principle of least privilege
|
|
129
|
+
- Verify Day 1 readiness: all accounts active, hardware delivered, VPN configured
|
|
130
|
+
|
|
131
|
+
### Tools
|
|
132
|
+
|
|
133
|
+
**\`provision_account\`**
|
|
134
|
+
Creates a user account in the specified system. Accepts the case ID, system name (e.g., directory_service, email, chat, code_repository, project_management), employee details, and role-based access template. Creates the account, sets a temporary password or SSO configuration, and returns account creation confirmation with the username and provisioning status. Idempotent: if the account already exists, returns the existing account details.
|
|
135
|
+
|
|
136
|
+
**\`assign_hardware\`**
|
|
137
|
+
Initiates hardware assignment for a new hire. Accepts the case ID, hardware type (laptop, monitor, keyboard, headset), specifications (based on role template), shipping address, and required-by date. Creates a procurement or inventory request, tracks shipping, and returns a hardware assignment ID with estimated delivery date. For remote employees, coordinates shipping. For office employees, coordinates desk setup.
|
|
138
|
+
|
|
139
|
+
**\`configure_access_permissions\`**
|
|
140
|
+
Sets up access permissions for a provisioned account. Accepts the case ID, account ID, permission set (derived from role and department templates), and any additional access requests approved by the hiring manager. Applies permissions following the principle of least privilege. Returns the permission configuration and any permissions that require additional approval (e.g., access to restricted repositories, financial systems, or admin panels).
|
|
141
|
+
|
|
142
|
+
**\`setup_software_licenses\`**
|
|
143
|
+
Assigns software licenses from the organization's license pool. Accepts the case ID, employee ID, and list of required software (derived from role template). Checks license availability, assigns licenses, and triggers installation or access provisioning. Returns assignment status per software title, including any licenses that are unavailable and need procurement.
|
|
144
|
+
|
|
145
|
+
### Input
|
|
146
|
+
|
|
147
|
+
- Task assignment from Orchestrator: case ID, employee details, role, department, start date, office location, remote/hybrid/onsite status
|
|
148
|
+
- Role-based provisioning templates: which systems, hardware, software, and permissions each role requires
|
|
149
|
+
|
|
150
|
+
### Output
|
|
151
|
+
|
|
152
|
+
- Account creation confirmations (per system)
|
|
153
|
+
- Hardware assignment tracking (with delivery status)
|
|
154
|
+
- Permission configuration report
|
|
155
|
+
- Software license assignment status
|
|
156
|
+
- Day 1 readiness checklist (all items green/yellow/red)
|
|
157
|
+
|
|
158
|
+
### Escalation Conditions
|
|
159
|
+
|
|
160
|
+
- Hardware cannot be delivered by start date (stock unavailable, shipping delay)
|
|
161
|
+
- License pool is exhausted for a required software title
|
|
162
|
+
- Access permission request requires security team approval and has been pending > 12 hours
|
|
163
|
+
- Account creation fails due to naming conflict or policy violation
|
|
164
|
+
|
|
165
|
+
### Success Metrics
|
|
166
|
+
|
|
167
|
+
- > 95% of new hires have all accounts, hardware, and software ready on Day 1
|
|
168
|
+
- Average provisioning time from task assignment to completion < 24 hours
|
|
169
|
+
- Zero unauthorized access grants (every permission traces to a role template or approved exception)
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## Agent 4: Training Curriculum Assembler
|
|
174
|
+
|
|
175
|
+
- **Role:** Builds personalized training paths for each new hire
|
|
176
|
+
- **Type:** Worker
|
|
177
|
+
- **Phase:** 2
|
|
178
|
+
|
|
179
|
+
### Responsibilities
|
|
180
|
+
|
|
181
|
+
- Generate a role-specific, department-aware training path for each new hire
|
|
182
|
+
- Include mandatory compliance training (security awareness, anti-harassment, data privacy) with hard deadlines
|
|
183
|
+
- Add role-specific technical training based on the tools and systems the hire will use
|
|
184
|
+
- Include department-specific onboarding content (team norms, processes, key contacts)
|
|
185
|
+
- Assign training modules in the learning management system and track completion
|
|
186
|
+
|
|
187
|
+
### Tools
|
|
188
|
+
|
|
189
|
+
**\`build_training_path\`**
|
|
190
|
+
Generates a personalized training path for a new hire. Accepts the case ID, role, department, seniority level, and any prior training records (for experienced hires or internal transfers). Combines mandatory compliance modules, role-specific technical modules, and department-specific orientation content into an ordered path with deadlines. Returns the full training path with module IDs, titles, durations, deadlines, and sequencing dependencies.
|
|
191
|
+
|
|
192
|
+
**\`assign_modules\`**
|
|
193
|
+
Assigns specific training modules to an employee in the learning management system. Accepts the case ID, employee ID, module IDs, and deadlines. Creates the enrollment records and sends the employee a notification with their training schedule. Returns assignment confirmations per module. Idempotent: re-assigning an already-assigned module returns the existing enrollment.
|
|
194
|
+
|
|
195
|
+
**\`customize_curriculum\`**
|
|
196
|
+
Adjusts a training path based on additional context. Accepts the case ID, the existing training path, and modification parameters (skip modules the hire has already completed elsewhere, add modules for a specific project they are joining, adjust deadlines based on part-time schedule). Returns the updated training path. Used when the hiring manager or HR provides customization requests after the initial path is generated.
|
|
197
|
+
|
|
198
|
+
### Input
|
|
199
|
+
|
|
200
|
+
- Task assignment from Orchestrator: case ID, employee details, role, department, seniority, start date
|
|
201
|
+
- Training catalog: available modules with metadata (category, duration, prerequisites, compliance flag)
|
|
202
|
+
- Department training requirements: team-specific modules and recommended resources
|
|
203
|
+
- Employee prior training records (if available)
|
|
204
|
+
|
|
205
|
+
### Output
|
|
206
|
+
|
|
207
|
+
- Personalized training path with module sequencing and deadlines
|
|
208
|
+
- LMS enrollment confirmations
|
|
209
|
+
- Training completion status (updated as employee progresses)
|
|
210
|
+
|
|
211
|
+
### Escalation Conditions
|
|
212
|
+
|
|
213
|
+
- A required compliance module is not available in the LMS (content needs to be created or updated)
|
|
214
|
+
- An employee has not started mandatory compliance training within 7 days of start date
|
|
215
|
+
- A hiring manager requests training customization that conflicts with compliance requirements
|
|
216
|
+
|
|
217
|
+
### Success Metrics
|
|
218
|
+
|
|
219
|
+
- 100% of new hires have a training path assigned within 24 hours of start date
|
|
220
|
+
- > 85% employee satisfaction score for training relevance (measured at Day 30 survey)
|
|
221
|
+
- 100% compliance training completion within 30 days
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
## Agent 5: Progress Tracker
|
|
226
|
+
|
|
227
|
+
- **Role:** Monitors onboarding progress, identifies risks, and reports status
|
|
228
|
+
- **Type:** Worker
|
|
229
|
+
- **Phase:** 2
|
|
230
|
+
|
|
231
|
+
### Responsibilities
|
|
232
|
+
|
|
233
|
+
- Monitor all onboarding milestones across active cases and flag items that are behind schedule
|
|
234
|
+
- Generate status reports for HR, hiring managers, and leadership
|
|
235
|
+
- Identify at-risk onboardings based on completion velocity, blocker patterns, and deadline proximity
|
|
236
|
+
- Trigger automated reminders to new hires, managers, and approvers for pending actions
|
|
237
|
+
- Calculate and report onboarding metrics (time-to-productive, completion rates, satisfaction scores)
|
|
238
|
+
|
|
239
|
+
### Tools
|
|
240
|
+
|
|
241
|
+
**\`generate_status_report\`**
|
|
242
|
+
Generates an onboarding status report scoped to a specific audience. Accepts a report type (individual_case, department_summary, organization_overview), scope parameters (case ID, department, date range), and format (structured_data, narrative). For individual cases: shows task completion, outstanding items, blockers, and timeline. For department summaries: shows active onboardings, completion rates, and common blockers. For organization overviews: shows aggregate metrics, trends, and at-risk cases.
|
|
243
|
+
|
|
244
|
+
**\`identify_at_risk_onboards\`**
|
|
245
|
+
Scans active onboarding cases and flags those at risk of missing deadlines or falling behind. Risk indicators include: tasks overdue by more than 24 hours, compliance deadlines within 48 hours with incomplete requirements, start date approaching with critical tasks incomplete, and repeated escalations on the same case. Returns a prioritized list of at-risk cases with risk reasons and recommended actions.
|
|
246
|
+
|
|
247
|
+
**\`send_reminder\`**
|
|
248
|
+
Sends a targeted reminder to a specific person about a pending onboarding action. Accepts the case ID, recipient (new hire, hiring manager, approver, IT admin), action needed, and urgency level. Selects the appropriate channel (email, chat message, or both based on urgency). Tracks reminder history to avoid excessive notifications (maximum 2 reminders per action per 48-hour period).
|
|
249
|
+
|
|
250
|
+
**\`calculate_completion_metrics\`**
|
|
251
|
+
Computes onboarding performance metrics across completed cases. Accepts a date range and optional filters (department, role, office location). Calculates: average time-to-productive, document completion speed, IT provisioning speed, training completion rate, overall onboarding NPS, and compliance completion rate. Returns metrics with trend data (comparison to previous period) and breakdowns by filter dimensions.
|
|
252
|
+
|
|
253
|
+
### Input
|
|
254
|
+
|
|
255
|
+
- Read access to all onboarding case records managed by the Orchestrator
|
|
256
|
+
- Milestone completion events from all worker agents
|
|
257
|
+
- Employee survey responses (Day 30 satisfaction survey)
|
|
258
|
+
|
|
259
|
+
### Output
|
|
260
|
+
|
|
261
|
+
- Status reports (per case, per department, organization-wide)
|
|
262
|
+
- At-risk case alerts with recommended actions
|
|
263
|
+
- Reminder notifications to pending action owners
|
|
264
|
+
- Onboarding performance dashboards and trend data
|
|
265
|
+
|
|
266
|
+
### Escalation Conditions
|
|
267
|
+
|
|
268
|
+
- An at-risk case has been flagged for more than 48 hours with no progress
|
|
269
|
+
- Organization-wide metrics drop below threshold (e.g., Day 1 readiness falls below 90%)
|
|
270
|
+
- A pattern of repeated blockers indicates a systemic issue (e.g., a specific integration failing for multiple hires)
|
|
271
|
+
|
|
272
|
+
### Success Metrics
|
|
273
|
+
|
|
274
|
+
- At-risk cases identified at least 48 hours before deadline (early warning accuracy)
|
|
275
|
+
- > 90% of reminders result in action within 24 hours
|
|
276
|
+
- Onboarding metrics reports delivered on schedule with zero data accuracy issues
|
|
277
|
+
`;
|
|
278
|
+
//# sourceMappingURL=agent-specifications.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"agent-specifications.js","sourceRoot":"","sources":["../../../../src/blueprints/employee-onboarding/files/agent-specifications.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoRtB,CAAC"}
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export declare const content = "# Agent Coordination Rules\n\nThese rules govern how the five onboarding agents communicate, retry, and escalate. Every agent must follow them.\n\n## Message Format\n\nAll inter-agent messages use a standard envelope:\n\n```\n{\n \"message_id\": \"unique-uuid\",\n \"timestamp\": \"ISO-8601\",\n \"source_agent\": \"agent-name\",\n \"target_agent\": \"agent-name\",\n \"onboarding_case_id\": \"case-uuid\",\n \"action\": \"string (the requested operation)\",\n \"payload\": { ... },\n \"correlation_id\": \"uuid (links related messages across agents)\",\n \"priority\": \"normal | high | critical\"\n}\n```\n\nEvery message must include `onboarding_case_id` and `correlation_id`. Messages without them are rejected.\n\n## Retry Policy\n\n- Workers retry transient failures (network timeouts, rate limits, temporary service unavailability) up to 3 times with exponential backoff: 5s, 30s, 180s.\n- After 3 failures, the worker reports the failure to the Orchestrator with error details. The worker does not retry further.\n- The Orchestrator decides whether to re-dispatch, escalate to a human, or mark the task as blocked.\n\n## Escalation to Manager\n\nWorkers escalate to the Onboarding Orchestrator when:\n\n- A task fails after exhausting retries.\n- A task requires approval that the worker cannot obtain (e.g., access provisioning for a restricted system).\n- Input data is missing or invalid and the worker cannot resolve it independently.\n- A compliance-critical deadline is at risk (less than 24 hours remaining with incomplete requirements).\n\nEscalation messages must include: the original task, what was attempted, what failed, and a recommended next action.\n\n## State Propagation\n\n- The Orchestrator is the single source of truth for onboarding case state.\n- Workers report task completion or failure back to the Orchestrator. They do not update case state directly.\n- The Orchestrator updates the case record and notifies dependent workers when prerequisites are met.\n- The Progress Tracker reads state from the Orchestrator's case records. It does not maintain a separate state store.\n\n## Idempotency\n\n- Every tool invocation must be idempotent. Calling `provision_account` twice for the same employee and account type must produce the same result, not a duplicate account.\n- Workers must check whether an action has already been completed before executing it. Use `onboarding_case_id` + `action` + `target` as the idempotency key.\n- If a duplicate request is detected, return the existing result without re-executing.\n\n## Parallel Execution\n\n- The Orchestrator dispatches independent tasks in parallel. Document collection, IT provisioning, and training path assembly do not depend on each other and run simultaneously.\n- Dependent tasks wait. For example, access provisioning for a specific application may depend on account creation completing first. The Orchestrator enforces this ordering.\n- Workers must not assume execution order. A worker may receive tasks at any time and must handle them based on the current state of the onboarding case, not assumptions about what other workers have done.\n";
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
export const content = `# Agent Coordination Rules
|
|
2
|
+
|
|
3
|
+
These rules govern how the five onboarding agents communicate, retry, and escalate. Every agent must follow them.
|
|
4
|
+
|
|
5
|
+
## Message Format
|
|
6
|
+
|
|
7
|
+
All inter-agent messages use a standard envelope:
|
|
8
|
+
|
|
9
|
+
\`\`\`
|
|
10
|
+
{
|
|
11
|
+
"message_id": "unique-uuid",
|
|
12
|
+
"timestamp": "ISO-8601",
|
|
13
|
+
"source_agent": "agent-name",
|
|
14
|
+
"target_agent": "agent-name",
|
|
15
|
+
"onboarding_case_id": "case-uuid",
|
|
16
|
+
"action": "string (the requested operation)",
|
|
17
|
+
"payload": { ... },
|
|
18
|
+
"correlation_id": "uuid (links related messages across agents)",
|
|
19
|
+
"priority": "normal | high | critical"
|
|
20
|
+
}
|
|
21
|
+
\`\`\`
|
|
22
|
+
|
|
23
|
+
Every message must include \`onboarding_case_id\` and \`correlation_id\`. Messages without them are rejected.
|
|
24
|
+
|
|
25
|
+
## Retry Policy
|
|
26
|
+
|
|
27
|
+
- Workers retry transient failures (network timeouts, rate limits, temporary service unavailability) up to 3 times with exponential backoff: 5s, 30s, 180s.
|
|
28
|
+
- After 3 failures, the worker reports the failure to the Orchestrator with error details. The worker does not retry further.
|
|
29
|
+
- The Orchestrator decides whether to re-dispatch, escalate to a human, or mark the task as blocked.
|
|
30
|
+
|
|
31
|
+
## Escalation to Manager
|
|
32
|
+
|
|
33
|
+
Workers escalate to the Onboarding Orchestrator when:
|
|
34
|
+
|
|
35
|
+
- A task fails after exhausting retries.
|
|
36
|
+
- A task requires approval that the worker cannot obtain (e.g., access provisioning for a restricted system).
|
|
37
|
+
- Input data is missing or invalid and the worker cannot resolve it independently.
|
|
38
|
+
- A compliance-critical deadline is at risk (less than 24 hours remaining with incomplete requirements).
|
|
39
|
+
|
|
40
|
+
Escalation messages must include: the original task, what was attempted, what failed, and a recommended next action.
|
|
41
|
+
|
|
42
|
+
## State Propagation
|
|
43
|
+
|
|
44
|
+
- The Orchestrator is the single source of truth for onboarding case state.
|
|
45
|
+
- Workers report task completion or failure back to the Orchestrator. They do not update case state directly.
|
|
46
|
+
- The Orchestrator updates the case record and notifies dependent workers when prerequisites are met.
|
|
47
|
+
- The Progress Tracker reads state from the Orchestrator's case records. It does not maintain a separate state store.
|
|
48
|
+
|
|
49
|
+
## Idempotency
|
|
50
|
+
|
|
51
|
+
- Every tool invocation must be idempotent. Calling \`provision_account\` twice for the same employee and account type must produce the same result, not a duplicate account.
|
|
52
|
+
- Workers must check whether an action has already been completed before executing it. Use \`onboarding_case_id\` + \`action\` + \`target\` as the idempotency key.
|
|
53
|
+
- If a duplicate request is detected, return the existing result without re-executing.
|
|
54
|
+
|
|
55
|
+
## Parallel Execution
|
|
56
|
+
|
|
57
|
+
- The Orchestrator dispatches independent tasks in parallel. Document collection, IT provisioning, and training path assembly do not depend on each other and run simultaneously.
|
|
58
|
+
- Dependent tasks wait. For example, access provisioning for a specific application may depend on account creation completing first. The Orchestrator enforces this ordering.
|
|
59
|
+
- Workers must not assume execution order. A worker may receive tasks at any time and must handle them based on the current state of the onboarding case, not assumptions about what other workers have done.
|
|
60
|
+
`;
|
|
61
|
+
//# sourceMappingURL=agents.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"agents.js","sourceRoot":"","sources":["../../../../src/blueprints/employee-onboarding/files/agents.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2DtB,CAAC"}
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export declare const content = "# Architecture Decisions\n\nKey design decisions for the Employee Onboarding Automation system, with rationale for each.\n\n---\n\n## Why Manager-Workers (Not Pipeline)\n\nOnboarding is not a linear process. A pipeline pattern (Agent A finishes, passes to Agent B, passes to Agent C) would be wrong here because:\n\n- **Tasks run in parallel.** Document collection, IT provisioning, and training path assembly are independent. They should start simultaneously when a new hire event arrives, not wait in sequence.\n- **Task dependencies are a graph, not a chain.** Some tasks depend on others (access provisioning depends on account creation), but most are independent. A pipeline forces artificial sequencing.\n- **Different tasks complete at different speeds.** Document collection depends on the new hire responding. IT provisioning depends on hardware stock. Training path generation is near-instant. A pipeline would bottleneck on the slowest step.\n\nManager-Workers is the right pattern because the Orchestrator can dispatch tasks in parallel, manage the dependency graph, and handle the inherent unpredictability of onboarding timelines.\n\n## Why Phased Rollout\n\nBuilding and deploying all five agents simultaneously is high risk with no upside.\n\n- **Phase 1 (Orchestrator + Document Processor) validates the architecture.** If the manager-worker communication pattern, the retry logic, or the integration approach has fundamental problems, you discover them with two agents, not five.\n- **Document processing is the highest-volume pain point.** Every new hire requires 5-10 documents. This is where manual processes fail most visibly. Automating it first delivers measurable value fastest.\n- **Phase 1 is self-contained.** The orchestrator and document processor can run in production while the other three agents are still being built. There is no \"big bang\" cutover.\n- **Phase 2 agents reuse Phase 1 patterns.** The integration approach, message format, retry policy, and escalation flow proven in Phase 1 are directly reused for IT Provisioning, Training Assembly, and Progress Tracking.\n\n## Orchestrator as Single Entry Point\n\nEvery onboarding starts the same way: a new-hire event from the HR system triggers the Onboarding Orchestrator. The Orchestrator is the only agent that receives external events. Workers never receive tasks from outside the system.\n\nThis matters because:\n\n- **Single source of truth.** The Orchestrator owns the onboarding case record. Every task, every status update, every escalation flows through it. There is no ambiguity about what has been done and what has not.\n- **Centralized dependency management.** Only the Orchestrator knows the full task graph. It enforces ordering (account creation before access provisioning) and parallelism (document collection and IT provisioning simultaneously).\n- **Audit trail.** Every action in the system is traceable to an Orchestrator decision. This is critical for compliance.\n\n## Parallel Worker Execution\n\nWorkers operate independently and concurrently. The Orchestrator dispatches tasks to multiple workers at the same time when those tasks have no dependencies on each other.\n\nConcrete example of a typical new-hire event:\n\n1. Orchestrator receives new-hire event, creates onboarding case.\n2. Orchestrator simultaneously dispatches: document collection to Document Processor, account creation to IT Provisioning Coordinator, and training path generation to Training Curriculum Assembler.\n3. Each worker executes independently, reports back to the Orchestrator on completion or failure.\n4. Orchestrator dispatches dependent tasks as prerequisites complete (e.g., access provisioning after account creation).\n5. Progress Tracker monitors all of the above and flags anything falling behind.\n\nThis parallelism is why onboarding time drops significantly. Manual processes serialize these tasks because a single person cannot do them all at once. Agents can.\n\n## Human-in-the-Loop Checkpoints\n\nNot everything should be automated. The system includes deliberate points where a human must review and approve:\n\n- **Identity verification.** The Document Processor flags documents for human review rather than making a final identity determination. This is a legal and compliance requirement.\n- **Access provisioning for restricted systems.** The IT Provisioning Coordinator can provision standard role-based access automatically, but access to restricted systems (financial data, admin panels, customer PII) requires explicit approval from the security team or system owner.\n- **Escalation handling.** When a worker cannot resolve an issue after retries, it escalates to the Orchestrator, which routes it to the appropriate human. The system does not silently fail or make assumptions.\n- **Pilot decision gate.** The Phase 1 exit requires stakeholder sign-off on measured outcomes. This is not automated because the decision to expand the system affects budget, headcount, and organizational change management.\n\nThe goal is not full autonomy. The goal is automating the predictable, repetitive parts so humans can focus on judgment calls and relationship building.\n\n## Event-Driven Architecture\n\nThe system is event-driven rather than polling-based:\n\n- **New-hire event** triggers onboarding case creation.\n- **Document submission event** triggers validation.\n- **Validation completion event** triggers tax form processing or identity verification.\n- **Account creation completion event** triggers access provisioning.\n- **Milestone completion event** triggers the next set of dependent tasks.\n- **Deadline approaching event** triggers reminders.\n\nThis matters for two reasons:\n\n1. **Responsiveness.** Actions happen immediately when their triggers fire, not at the next polling interval. A new hire submitting a document at 3 PM gets it validated at 3 PM, not at the next hourly batch run.\n2. **Efficiency.** No agent wastes cycles checking for changes that have not happened. Each agent is dormant until it receives an event that requires its action.\n\nThe Orchestrator is the event router. It receives events from workers and external systems, updates case state, evaluates the dependency graph, and dispatches new tasks as prerequisites are met.\n";
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
export const content = `# Architecture Decisions
|
|
2
|
+
|
|
3
|
+
Key design decisions for the Employee Onboarding Automation system, with rationale for each.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Why Manager-Workers (Not Pipeline)
|
|
8
|
+
|
|
9
|
+
Onboarding is not a linear process. A pipeline pattern (Agent A finishes, passes to Agent B, passes to Agent C) would be wrong here because:
|
|
10
|
+
|
|
11
|
+
- **Tasks run in parallel.** Document collection, IT provisioning, and training path assembly are independent. They should start simultaneously when a new hire event arrives, not wait in sequence.
|
|
12
|
+
- **Task dependencies are a graph, not a chain.** Some tasks depend on others (access provisioning depends on account creation), but most are independent. A pipeline forces artificial sequencing.
|
|
13
|
+
- **Different tasks complete at different speeds.** Document collection depends on the new hire responding. IT provisioning depends on hardware stock. Training path generation is near-instant. A pipeline would bottleneck on the slowest step.
|
|
14
|
+
|
|
15
|
+
Manager-Workers is the right pattern because the Orchestrator can dispatch tasks in parallel, manage the dependency graph, and handle the inherent unpredictability of onboarding timelines.
|
|
16
|
+
|
|
17
|
+
## Why Phased Rollout
|
|
18
|
+
|
|
19
|
+
Building and deploying all five agents simultaneously is high risk with no upside.
|
|
20
|
+
|
|
21
|
+
- **Phase 1 (Orchestrator + Document Processor) validates the architecture.** If the manager-worker communication pattern, the retry logic, or the integration approach has fundamental problems, you discover them with two agents, not five.
|
|
22
|
+
- **Document processing is the highest-volume pain point.** Every new hire requires 5-10 documents. This is where manual processes fail most visibly. Automating it first delivers measurable value fastest.
|
|
23
|
+
- **Phase 1 is self-contained.** The orchestrator and document processor can run in production while the other three agents are still being built. There is no "big bang" cutover.
|
|
24
|
+
- **Phase 2 agents reuse Phase 1 patterns.** The integration approach, message format, retry policy, and escalation flow proven in Phase 1 are directly reused for IT Provisioning, Training Assembly, and Progress Tracking.
|
|
25
|
+
|
|
26
|
+
## Orchestrator as Single Entry Point
|
|
27
|
+
|
|
28
|
+
Every onboarding starts the same way: a new-hire event from the HR system triggers the Onboarding Orchestrator. The Orchestrator is the only agent that receives external events. Workers never receive tasks from outside the system.
|
|
29
|
+
|
|
30
|
+
This matters because:
|
|
31
|
+
|
|
32
|
+
- **Single source of truth.** The Orchestrator owns the onboarding case record. Every task, every status update, every escalation flows through it. There is no ambiguity about what has been done and what has not.
|
|
33
|
+
- **Centralized dependency management.** Only the Orchestrator knows the full task graph. It enforces ordering (account creation before access provisioning) and parallelism (document collection and IT provisioning simultaneously).
|
|
34
|
+
- **Audit trail.** Every action in the system is traceable to an Orchestrator decision. This is critical for compliance.
|
|
35
|
+
|
|
36
|
+
## Parallel Worker Execution
|
|
37
|
+
|
|
38
|
+
Workers operate independently and concurrently. The Orchestrator dispatches tasks to multiple workers at the same time when those tasks have no dependencies on each other.
|
|
39
|
+
|
|
40
|
+
Concrete example of a typical new-hire event:
|
|
41
|
+
|
|
42
|
+
1. Orchestrator receives new-hire event, creates onboarding case.
|
|
43
|
+
2. Orchestrator simultaneously dispatches: document collection to Document Processor, account creation to IT Provisioning Coordinator, and training path generation to Training Curriculum Assembler.
|
|
44
|
+
3. Each worker executes independently, reports back to the Orchestrator on completion or failure.
|
|
45
|
+
4. Orchestrator dispatches dependent tasks as prerequisites complete (e.g., access provisioning after account creation).
|
|
46
|
+
5. Progress Tracker monitors all of the above and flags anything falling behind.
|
|
47
|
+
|
|
48
|
+
This parallelism is why onboarding time drops significantly. Manual processes serialize these tasks because a single person cannot do them all at once. Agents can.
|
|
49
|
+
|
|
50
|
+
## Human-in-the-Loop Checkpoints
|
|
51
|
+
|
|
52
|
+
Not everything should be automated. The system includes deliberate points where a human must review and approve:
|
|
53
|
+
|
|
54
|
+
- **Identity verification.** The Document Processor flags documents for human review rather than making a final identity determination. This is a legal and compliance requirement.
|
|
55
|
+
- **Access provisioning for restricted systems.** The IT Provisioning Coordinator can provision standard role-based access automatically, but access to restricted systems (financial data, admin panels, customer PII) requires explicit approval from the security team or system owner.
|
|
56
|
+
- **Escalation handling.** When a worker cannot resolve an issue after retries, it escalates to the Orchestrator, which routes it to the appropriate human. The system does not silently fail or make assumptions.
|
|
57
|
+
- **Pilot decision gate.** The Phase 1 exit requires stakeholder sign-off on measured outcomes. This is not automated because the decision to expand the system affects budget, headcount, and organizational change management.
|
|
58
|
+
|
|
59
|
+
The goal is not full autonomy. The goal is automating the predictable, repetitive parts so humans can focus on judgment calls and relationship building.
|
|
60
|
+
|
|
61
|
+
## Event-Driven Architecture
|
|
62
|
+
|
|
63
|
+
The system is event-driven rather than polling-based:
|
|
64
|
+
|
|
65
|
+
- **New-hire event** triggers onboarding case creation.
|
|
66
|
+
- **Document submission event** triggers validation.
|
|
67
|
+
- **Validation completion event** triggers tax form processing or identity verification.
|
|
68
|
+
- **Account creation completion event** triggers access provisioning.
|
|
69
|
+
- **Milestone completion event** triggers the next set of dependent tasks.
|
|
70
|
+
- **Deadline approaching event** triggers reminders.
|
|
71
|
+
|
|
72
|
+
This matters for two reasons:
|
|
73
|
+
|
|
74
|
+
1. **Responsiveness.** Actions happen immediately when their triggers fire, not at the next polling interval. A new hire submitting a document at 3 PM gets it validated at 3 PM, not at the next hourly batch run.
|
|
75
|
+
2. **Efficiency.** No agent wastes cycles checking for changes that have not happened. Each agent is dormant until it receives an event that requires its action.
|
|
76
|
+
|
|
77
|
+
The Orchestrator is the event router. It receives events from workers and external systems, updates case state, evaluates the dependency graph, and dispatches new tasks as prerequisites are met.
|
|
78
|
+
`;
|
|
79
|
+
//# sourceMappingURL=architecture-decisions.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"architecture-decisions.js","sourceRoot":"","sources":["../../../../src/blueprints/employee-onboarding/files/architecture-decisions.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6EtB,CAAC"}
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export declare const content = "# Business Context\n\nThe business problem, current state pain points, and target outcomes for Employee Onboarding Automation.\n\n---\n\n## The Onboarding Challenge\n\nEmployee onboarding sits at the intersection of HR, IT, legal, and operations. It touches more systems and more people than almost any other recurring business process. And it happens every time someone is hired, which for growing companies means constantly.\n\nThe fundamental challenge: onboarding requires coordinating dozens of tasks across multiple departments, each with different systems, different timelines, and different owners. No single person or team has visibility into the full picture. Things fall through the cracks because the process depends on manual handoffs, tribal knowledge, and individual diligence.\n\n**Scale makes it worse, not better.** A company hiring 10 people per quarter can handle onboarding with spreadsheets and personal attention. A company hiring 50 or 100 cannot. The process that worked at 200 employees breaks at 500 and is unmanageable at 2,000.\n\n---\n\n## Current State Pain Points\n\nThese are the problems that exist in most organizations before automation. Not all will apply to every company, but most companies experience at least three of the five.\n\n### Manual Checklists\n\nOnboarding tasks are tracked in spreadsheets, wikis, or email threads. Each new hire gets a copy of the checklist. Someone (HR generalist, hiring manager, or office coordinator) manually checks off items as they are completed. Items get missed. Different people follow different versions of the checklist. There is no real-time visibility into where things stand.\n\n### Tribal Knowledge\n\n\"Ask Sarah in IT to set up the VPN\" and \"Make sure you CC finance on the laptop request.\" Critical process steps live in people's heads, not in systems. When those people are on vacation, busy, or leave the company, steps get skipped. New HR team members take months to learn all the informal procedures.\n\n### Delayed Provisioning\n\nIT provisioning is the most common bottleneck. Account creation requires tickets to multiple teams. Hardware procurement has lead times. Software licenses require budget approval. The result: new hires show up on Day 1 and cannot log in, do not have a laptop, or do not have access to the tools they need. They sit idle while IT catches up. First impressions are terrible.\n\n### Inconsistent Experience\n\nOnboarding quality varies wildly depending on who handles it. Some hiring managers plan structured first weeks with introductions, training, and mentorship. Others hand the new hire a laptop and say \"let me know if you have questions.\" This inconsistency affects retention: employees who have a poor onboarding experience are 2x more likely to look for a new job within the first year.\n\n### Compliance Risk\n\nTax forms, I-9 verification, mandatory training, and policy acknowledgments have legal deadlines. Manual processes miss them because:\n\n- Reminders are sent by people who forget\n- Tracking is in spreadsheets that nobody updates\n- Responsibility is split across HR, legal, and hiring managers with no clear owner\n- The consequences of missing a deadline are invisible until an audit surfaces them\n\n---\n\n## Impact of Poor Onboarding\n\n### Employee Turnover\n\nEmployees who report a negative onboarding experience are 2x more likely to seek a new opportunity within 12 months. At an average replacement cost of 50-200% of annual salary (depending on role seniority), this is the most expensive consequence of bad onboarding.\n\n### Time-to-Productive\n\nThe longer it takes a new hire to get fully set up and trained, the longer the company waits for return on its hiring investment. For technical roles with 3-6 month ramp times, even a 2-week delay in onboarding has measurable productivity impact.\n\n### Compliance Exposure\n\nMissed I-9 deadlines: fines range from $252 to $2,507 per violation for first offenses (US). Missed tax form processing: payroll errors and IRS penalties. Missed mandatory training: liability exposure for harassment, safety, and data privacy incidents.\n\n### Manager and HR Burden\n\nEvery hour a hiring manager spends chasing IT tickets, filling out forms, and sending reminder emails is an hour they are not spending on their actual job. HR generalists managing 20+ concurrent onboardings spend the majority of their time on administrative coordination rather than strategic work.\n\n---\n\n## Industry Benchmarks\n\nThese are representative benchmarks from published HR research. Use them as reference points, not absolute targets.\n\n| Metric | Typical | Good | Best-in-Class |\n|--------|---------|------|---------------|\n| Time to full productivity | 8-12 weeks | 4-8 weeks | 2-4 weeks |\n| Onboarding satisfaction (NPS) | 10-30 | 30-50 | 50-80 |\n| Day 1 IT readiness | 40-60% | 70-85% | 90-99% |\n| Compliance completion within 30 days | 65-80% | 85-95% | 98-100% |\n| First-year voluntary turnover | 20-30% | 12-18% | 5-10% |\n| HR hours per onboarding | 10-20 hours | 5-10 hours | 2-4 hours |\n\nSources vary by industry and company size. Measure your own baseline before comparing to benchmarks.\n\n---\n\n## Target Outcomes\n\nWhat the automated system should achieve, expressed as improvements over the current manual process.\n\n### Primary Outcomes\n\n1. **Reduce time-to-productive by 30% or more.** Parallel execution of provisioning, document collection, and training eliminates the sequential bottlenecks that delay manual onboarding.\n\n2. **Achieve 100% compliance completion within 30 days.** Automated tracking with escalation ensures no compliance item is forgotten or delayed past its deadline.\n\n3. **Deliver Day 1 readiness for 95%+ of new hires.** Automated IT provisioning triggered immediately on hire confirmation means accounts, hardware, and software are ready before the employee arrives.\n\n4. **Eliminate manual tracking overhead.** HR generalists and hiring managers stop spending time on spreadsheets, reminder emails, and status check meetings. The system tracks everything and reports proactively.\n\n### Secondary Outcomes\n\n5. **Consistent experience regardless of location, department, or manager.** Every new hire goes through the same structured, complete onboarding process. Quality does not depend on individual diligence.\n\n6. **Onboarding NPS above 60.** A smooth, fast onboarding experience is one of the strongest signals a new hire receives about the company's competence and culture.\n\n7. **Reusable patterns for offboarding and transfers.** The orchestration pattern, integration infrastructure, and agent architecture built for onboarding directly apply to employee offboarding (reverse provisioning) and internal transfers (delta provisioning).\n";
|