#352 Guidance: Built-in Tools vs Marketplace Apps

## Overview Define clear guidelines for when functionality should be a built-in tool vs a marketplace app. ## Built-in Tools Criteria Tools should be built-in when they are: 1. **Fundamental primitives** - Basic building blocks (shell, HTTP, email) 2. **No business logic variation** - Standard interface, no customization needed 3. **Security-sensitive** - Need tight platform integration (secrets, code execution) 4. **Workflow control** - Core engine features (wait, parallel, approval) ## Marketplace Apps Criteria Apps should be in marketplace when they: 1. **Have business logic** - Domain-specific behavior (payment processing, CRM) 2. **Vendor-specific** - Tied to specific service (Stripe, Salesforce, AWS) 3. **Complex configuration** - Need extensive setup per tenant 4. **Evolve independently** - Frequent updates separate from engine ## Current Classification ### Built-in Tools (keep as-is): - tools.shell.* - Fundamental primitive - tools.http.request - Fundamental primitive - tools.email.send - Fundamental communication - tools.llm.call - AI primitive - tools.approval.request - Workflow control - tools.secrets.* - Security - tools.docker.* - Infrastructure primitive - tools.workflow.* - Engine feature - tools.code.exec - Security-sensitive ### Should Add as Built-in: - tools.sms.send - Fundamental communication (like email) - tools.webhook.register - Workflow control ### Should be Apps (marketplace): - Payment gateways (Stripe, PayPal) - Cloud providers (AWS, GCP, Azure) - CRM systems (Salesforce, HubSpot) - Document services (DocuSign, PDF generation) - IoT platforms (AWS IoT, Azure IoT) - Video processing (cloud transcoding services) - Identity verification (Onfido, Jumio) ## Implementation Notes - Built-in tools: Part of engine, tenant-agnostic - Apps: Installed per-tenant, own versioning, own secrets