feat: Marketing Swarm v2 — templates, SDK, CLI, MCP, and docs

[tonyoconnell]

Summary

Major feature release adding complete marketing swarm infrastructure:

Templates (packages/templates)

• swarm-starter: Full commerce stack (payments, pricing, tiers, revenue tracking, cross-holdings)
• consumer-commerce: Multi-token payments (FET + USDC), invoicing, fiat onramp
• people.ts: Org chart → agent swarm generator (startup/smb/enterprise presets)
• 16 presets: 5 C-suite + 7 marketing + 4 consumer commerce roles

SDK (packages/sdk)

• payments.ts: Multi-token transfers (FET, USDC on BSC)
• delegation.ts: ERC-20 spending limits (approve/transferFrom)
• invoices: CRUD operations in agent storage
• 26 total exports (verified by smoke tests)

CLI (packages/cli)

• npx agentlaunch marketing — Deploy 7-agent Marketing Team (960 FET)
• npx agentlaunch alliance — Deploy 27-agent ASI Alliance (3,240 FET)
• npx agentlaunch wallet balances/send/delegate
• npx agentlaunch pay <address> <amount> --token USDC
• npx agentlaunch org-template --size smb
• npx agentlaunch swarm-from-org people.yaml

MCP (packages/mcp)

• 7 new payment tools: multi_token_payment, check_spending_limit, create_delegation, get_fiat_link, create_invoice, list_invoices, get_multi_token_balances
• 28 total tools (all verified working)

Examples

• 7 marketing team agents with real API integrations (ASI1-mini, Twitter, Telegram, Resend)
• 3 org chart YAML templates (startup, smb, enterprise)
• Telegram bot example with Cloudflare relay

Rules & Skills

• marketing-swarm.md, consumer-payments.md, workflow.md
• /alliance, /welcome skills
• Phase 3 optimization enforcement in all deploy flows

Test plan

• npm run build — All packages compile
• npm run test:publish — 5/5 smoke tests pass
• CLI, MCP, SDK, Templates all verified
• 9 templates, 16 presets registered

🤖 Generated with Claude Code

[sentry]

Bug: The toAtestfet function incorrectly truncates any price less than 0.01 FET to zero due to using Math.floor on the multiplied value before converting to BigInt.
_{Severity: CRITICAL}

Suggested Fix

Modify the toAtestfet function to handle floating-point numbers without premature truncation. The calculation should be performed using BigInt to preserve precision. A potential fix is to multiply the fet value directly by the full FET unit representation (10^18) before converting to BigInt, for example: BigInt(Math.floor(fet * Number(FET))).

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: packages/templates/src/people.ts#L110-L117

Potential issue: The `toAtestfet` function, defined as `Number(BigInt(Math.floor(fet *
100)) * (FET / 100n))`, incorrectly handles prices smaller than 0.01 FET. For example, a
price of `0.005` FET becomes `Math.floor(0.5)`, which evaluates to `0`. This results in
agents intended to have micropayments (e.g., `DEFAULT_PRICING.team = 0.005`) having
their services priced at zero. This is a silent failure that leads to unintended free
services and revenue loss for deployed agents.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: The transferToken function creates a duplicate ABI entry for the transfer function by spreading ERC20_ABI and then re-declaring it, which will cause a runtime error.
_{Severity: CRITICAL}

Suggested Fix

Remove the redundant transfer function signature from the abi array definition within the transferToken function. The spread ...ERC20_ABI already includes the necessary signature, so the manual addition is not needed.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: packages/sdk/src/payments.ts#L187-L191

Potential issue: In the `transferToken` function, a new ABI is constructed by spreading
the existing `ERC20_ABI` and then manually adding a `transfer` function signature.
However, `ERC20_ABI` already contains this exact signature. This duplication will cause
the `ethers.js` v6 library to throw a runtime error when `new Contract(...)` is called,
as it does not permit duplicate ABI entries. This breaks any functionality that relies
on token transfers, such as the `agentlaunch pay` command and the `multi_token_payment`
tool.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[Hovessian]

Code Review: Changes Requested

Critical — Must Fix Before Merge

1. No spending limits or confirmation on MCP payment tools
packages/mcp/src/tools/payments.ts — The multi_token_payment tool can drain a wallet without any authorization gate. Any MCP client can call it. At minimum, add a per-call spending cap or require confirmation for amounts above a threshold.

2. wallet send and pay commands have no confirmation prompt
packages/cli/src/commands/wallet.ts, packages/cli/src/commands/pay.ts — Unlike marketing and alliance which prompt before deploying, these commands transfer tokens immediately. An accidental agentlaunch wallet send USDC 0x... 10000 is irreversible.

3. wallet balances requires WALLET_PRIVATE_KEY for a read-only operation
packages/cli/src/commands/wallet.ts — Should accept --address as an alternative to avoid loading the private key unnecessarily for balance queries.

High Priority

4. Address validation inconsistent across payment flows
packages/sdk/src/payments.ts, packages/sdk/src/delegation.ts, packages/cli/src/commands/wallet.ts, packages/cli/src/commands/pay.ts — handoff.ts has validateEthAddress() but none of the new payment code uses it. All functions accepting Ethereum addresses should validate format.

5. formatEther hardcoded instead of formatUnits(balance, decimals)
packages/sdk/src/payments.ts — Multiple places assume 18 decimals. The PaymentToken type already carries a decimals field — use ethers.formatUnits(balance, token.decimals) and ethers.parseUnits(amount, token.decimals) so adding USDT (6 decimals) doesn't silently break balances.

6. Generated Python template doesn't validate addresses before URL construction
packages/templates/src/templates/swarm-starter.ts — generate_buy_link() and generate_sell_link() in HoldingsManager concatenate token_address directly into URLs. Unlike the TypeScript SDK, no validation prevents URL injection via characters like ? or #.

Medium Priority

7. Parallel deployment waves aren't actually parallel
packages/cli/src/commands/marketing.ts, packages/cli/src/commands/alliance.ts — Waves marked parallel: true still iterate with for...of. Should use Promise.all() for parallel waves.

8. scaffoldSwarm() duplicated verbatim between marketing.ts and alliance.ts
Extract to a shared utility to avoid DRY violation and divergent bug fixes.

9. delegationKey() doesn't include spender
packages/sdk/src/delegation.ts — Multiple delegations from the same owner for the same token symbol silently overwrite each other. Include spender in the compound key.

10. MCP server has no access control distinction
packages/mcp/src/index.ts — All 28 tools are callable by any MCP client with no concept of "dangerous" vs "safe" tools. Consider at least categorizing tools and documenting the risk.

Low Priority (non-blocking)

• No pagination on listInvoices() / listDelegations()
• CLI version hardcoded as "1.6.0" instead of reading from package.json
• Invoice status filter accepts any string cast to InvoiceStatus without validation
• .env parser doesn't handle quoted values

---

The feature scope is solid and well-structured. Addressing the critical and high items (especially around payment security) will make this production-ready.

🤖 Generated with Claude Code