Business Concept: Commerce Agent

Summary

A personal commerce agent that automates payments and bill management using stablecoins. Pankaj controls it. It tells regulated providers (banks, crypto wallets) what to do. The agent is an automation layer — it never holds funds, never custodies assets, never transmits money itself. It is a tool, not a counterparty.

The system starts as a personal tool ($100 cap, one user, one provider: ClawBank). Architecture is designed so provider plugins are swappable and the system can scale to SaaS without architectural surgery.

Problem

Paying bills and managing money is a manual process built for human attention spans: log in, check balance, click "Pay," verify, record in books. This doesn't map to an agentic world where an AI should be able to handle routine payments autonomously — subject to clear authorization boundaries.

Existing solutions (Mint, YNAB, bank bill-pay) are read-only or limited to specific institutions. None expose a programmable interface for an agent to act on. Stablecoins offer instant settlement and programmability, but the user experience is still manual — copy-pasting addresses, managing keys, worrying about gas.

Specific pain point: Pankaj has a ClawBank account with USDC. He wants to automate small recurring payments and log them properly in double-entry books. He wants to do this from a CLI, not a web dashboard. He wants the system to be his — not a service he subscribes to (initially).

The Agentic Commerce Shift

Traditional commerce: Human → clicks "Pay" → Payment Rail → Settlement

Agentic commerce adds two new actor patterns:

| Pattern | Example | |---------|---------| | Human → Agent | Pankaj tells his agent: "Pay the $20 internet bill from USDC." Agent executes via provider API, logs to GNUCash. | | Agent → Provider | Agent talks to ClawBank's API (or any provider) to check balance, send payment, verify settlement. | | Agent ←→ Agent | Future: Pankaj's agent discovers another agent, negotiates payment, settles. Not in MVP. |

The architecture must treat providers as pluggable — ClawBank is Plugin #1, not the center of the system. The provider interface is a stable abstraction with implementations behind it.

Business Model

Two tiers, identical code:

1. Open Source (free)

Self-hosted, single instance
Full features, community docs
No support, no warranty
Builds trust, adoption, and contribution

2. SaaS (paid subscription)

One-click hosted version
Single-instance-per-user architecture (Docker containers, not multi-tenant)
Subscription fee (~$20-30/month). No per-transaction fees.
Revenue covers VPS costs + Pankaj's time
SaaS is not a regulated financial activity — the system sells software access, not financial services. The regulated providers handle the money.

Why no transaction fees: Per-transaction fees create a regulatory surface (money transmission, payment processing). Flat SaaS subscription does not. It also aligns incentives — the system is not motivated to maximize transactions, only to be useful enough to justify the subscription.

Architecture (Conceptual — 10,000 ft)

Pankaj → CLI / Web UI → Commerce Agent → Provider Plugin → Provider API
                              ↓
                         System of Record (GNUCash)

Five components:

Provider abstraction — stable interface for any payment provider
Authorization engine — rules about what the agent can do autonomously
Payment executor — expresses intent as API calls
System of record — GNUCash via piecash (double-entry, SQLite)
Audit trail — immutable log of every action, decision, state change

Deployment: Single Docker container per user. SQLite for app state. GNUCash .gnucash file (also SQLite) for the ledger. One directory on the host, bind-mounted. Backup = tar the directory.

Web stack (SaaS version): HTMX + Alpine.js + SQLite. No JavaScript framework, no async workers, no message queues. The system is synchronous by design — payments are API calls that complete in milliseconds (stablecoins). Complex state management is not needed.

Inversion Analysis (Munger)

What would make this fail?

Regulatory reinterpretation: A regulator decides that transmitting payment instructions = money transmission, even if funds never touch our infrastructure. The "we're just software" defense fails. Mitigation: stay below the radar (personal tool, small user base), incorporate in a favorable jurisdiction before scaling, and never touch funds.
Provider lock-in: ClawBank becomes the only provider. If they change their API, raise fees, or shut down, the system dies. Mitigation: the provider interface is a first-class abstraction. Add Bridge, OpenNode, or a local Lightning node as Plugin #2 before scaling.
Zero market demand: Agentic commerce is a solution looking for a problem. Nobody actually wants an LLM managing their payments. Mitigation: dogfood first. If Pankaj won't use it daily, nobody will.
Security breach: An API key leaks. Real money moves without authorization. Mitigation: the authorization engine is the single most hardened component. Caps, confirmations, audit trails. Never store keys in plaintext. $100 absolute cap during development.
Complexity collapse: The system tries to do too much — multi-user, agent-to-agent, invoice parsing, recurring schedules, budget alerts — before the core loop works. Mitigation: MVP is five components. Nothing else ships until those five are solid.

Upside / Downside

Upside: If agentic commerce becomes real, this is early infrastructure in a new category. The system is provider-agnostic, open-source, and privacy-respecting. These are moats in a world where fintech is extractive and opaque. The SaaS model is capital-efficient — no need for VC, no need for scale before profitability.

Downside: The market may not exist. Agentic commerce may be a category error — people may never want AI touching their money, regardless of authorization boundaries. The system remains a personal tool for Pankaj, which is still useful but not a business.

Decision

Build. The MVP is small (five components, ~500-1000 lines of Python). The downside is an afternoon's work that produces a useful personal tool. The upside is early positioning in a category that may or may not emerge but is worth being ready for.

Dogfood first. Pankaj uses it for his own ClawBank transactions for 30 days before we consider a SaaS version. If he stops using it, the idea dies here. If he depends on it, we have something.

Project Name

commerce-agent (working title). Renamable.

Next Steps

Phase I: Incubation — map to systems principles, build conceptual/logical/ physical architecture. Output: design doc in sw_design/design.md.