frankxai Automation Tool Router
Use this first when the work is about automation architecture or tool choice. Return a concrete owner, not a vague stack.
Routing Order
- Use the native connector when one exists for the target system.
- Use Codex automation for recurring reasoning, review, repo, inbox, or briefing work.
- Use MCP when an agent needs a typed, bounded tool or resource.
- Use Make.com for fast SaaS glue, forms, CRM updates, and simple approval chains.
- Use n8n for branchy technical workflows, private data flows, reusable templates, and self-hostable automation.
- Use a Starlight queue for cross-repo, multi-agent, eval-heavy, or handoff-heavy work.
Safety Gates
- Require human approval before send, post, spend, delete, publish, invite, production deploy, or account-permission changes.
- Dry-run first for migrations, workflow activation, bulk edits, and storage cleanup.
- Fail closed on auth, schema, transport, webhook, or confidence errors.
- Never print or commit secrets, live webhook URLs, customer data, inbox content, or private memory.
- Public exports must use mock payloads and pass a sensitive-marker scan.
Decision Output
Return:
- tool owner
- why this tool wins
- fallback tool
- trigger/input
- output contract
- approval gate
- validation step
- where durable state belongs
Reference Routing
- For Make.com scenario design, use
make-com-operations. - For n8n workflow design or exported workflow review, use
n8n-operations. - For MCP scopes, tool schemas, and server boundaries, use
mcp-governance. - For recurring scheduled work in Codex, use
codex-automation-operator. - For multi-agent queues and handoffs, use
starlight-queen-queue.
Verification
For public artifacts, run scripts/scan_public_safety.py from the source repo
when available. For installable bundles, run scripts/validate_skill_bundle.py.