← Back to Blog

I Built an Agent-First Marketplace in 14 Days

· 6 min read · 1,345 words
aiwebdevstartupjavascript

Here's something nobody tells you about the AI agent gold rush: agents can't buy things.

They can write code, analyze data, draft emails, and orchestrate workflows. But when Agent A needs a capability that Agent B already built — say, a Slack integration workflow or a code review skill — there's no commerce layer. No npm install for agent capabilities. No marketplace where agents are the customers.

So I built one. In 14 days.

This is the build log for PackDrop — an agent-first marketplace for capability packs. Not a pitch. Just what shipped, what didn't, and what I learned.

The Problem: Agents Need a Commerce Layer

AI agents are getting good at executing tasks. But they're terrible at acquiring new capabilities. Right now, if you want your agent to handle email automation, you either:

  1. Build it from scratch (expensive, slow)
  2. Copy-paste from GitHub (no versioning, no trust, no payments)
  3. Hope someone wrote a blog post about it (lol)

What's missing is a structured way for agents to discover, install, and pay for capability bundles — skills, workflows, tools, knowledge bases — through a programmatic interface.

Not a web UI designed for humans clicking buttons. A CLI and API designed for agents making decisions.

Why CLI-First

This was the first real design decision. Most marketplaces start with a pretty website. I started with a terminal.

The reasoning: agents are the primary consumers. An agent doesn't open Chrome and browse a catalog. It runs commands:

bash
# Search for what you need
packdrop search "email automation" --category automation --json

# View details
packdrop view email-automation-workflow --json

# Install it
packdrop install email-automation-workflow

# Or buy it
packdrop buy email-automation-workflow

The --json flag on every command was non-negotiable. Humans get colored terminal output. Agents get structured JSON they can parse and act on. Same command, two audiences.

Authentication works the same way — PACKDROP_TOKEN environment variable. No config files, no interactive prompts. Works in CI, works in agent runtimes, works everywhere.

Building with AI agents? Get weekly insights on agentic tooling.
You're in ✓

What Shipped in 14 Days

18 CLI Commands

The CLI ships in three phases that mirror how users actually engage with a marketplace:

Browse & Install (Phase 1): login, logout, whoami, search, view, install, library

Sell & Publish (Phase 2A): seller init, seller status, pack create, pack publish, pack version, pack update-price

Commerce & Management (Phase 2B): revenue, api-key create, api-key list, api-key revoke, buy

The single dependency is commander.js. That's it. Node 18+ native fetch handles HTTP. No axios, no node-fetch, no bloat.

The Pack Manifest

Every pack has a structured manifest:

json
{
  "name": "Email Automation Workflow",
  "slug": "email-automation-workflow",
  "type": "workflow",
  "version": "1.0.0",
  "category": "automation",
  "price": 29.99,
  "tags": ["email", "automation", "workflow"],
  "description": "Automated email response workflow with templates",
  "manifest": {
    "entry": "main.js",
    "capabilities": ["email.read", "email.send", "template.render"],
    "requirements": ["gmail_oauth"]
  }
}

Pack types: skill, workflow, tool, knowledge, system. Categories span 10 domains — automation, development, data & analytics, communication, security, and more.

Scoped API Keys with Spend Limits

This was probably the most important feature for agent safety. When an agent gets an API key, the key is scoped:

bash
# Create a key with limited permissions
packdrop api-key create --name "CI Pipeline" --scopes browse,install --json

# Returns:
# { "key": "pk_live_a1b2c3...", "scopes": ["browse", "install"], "spend_limit_cents": 10000 }

Six available scopes: browse, claim_free, purchase, install, publish, manage_packs. Spend limits are enforced server-side — an agent can't accidentally blow through your budget.

Keys are stored as SHA-256 hashes in the database. The plaintext key is returned exactly once at creation time. Rate limited at 100 requests/minute.

Stripe Payments

Paid packs ($4.99–$29.99) go through Stripe checkout. The flow:

  1. Agent calls packdrop buy (or POST /api/checkout/:packId)
  2. Gets a Stripe payment URL
  3. Payment completes → purchase verified with fraud scoring
  4. Pack auto-installs to the buyer's library

Fraud detection checks: time window validation (30-minute expiry), verification attempt limits, session validation. Not enterprise-grade, but enough to ship.

39 REST API Endpoints

The full API covers everything the CLI does, plus more:

Full docs at packdrop.polsia.app/docs with all 18 CLI commands and every API endpoint documented.

Stack Decisions

Express + Postgres (Not Next.js)

I know. In 2026 it feels like committing a crime to not use Next.js. Here's why I didn't:

Express because:

PostgreSQL because:

The total dependency footprint for the backend: express, pg, bcryptjs, uuid, and openai (for AI-powered features). Five production dependencies.

Full-Text Search Over Elasticsearch

PostgreSQL's tsvector gave me 90% of what Elasticsearch would, with zero additional infrastructure:

sql
-- Weighted search: name matters more than description
SELECT * FROM packs
WHERE search_vector @@ plainto_tsquery('english', $1)
ORDER BY ts_rank(search_vector, plainto_tsquery('english', $1)) DESC;

Trigger-based index updates mean search stays in sync automatically. For a marketplace with hundreds of packs, this is more than enough. If it ever isn't, migration to a dedicated search service is straightforward.

Current State: Complete Product, Zero Users

I'm going to be honest about this because build logs that pretend everything is going great are useless.

What's live:

What's real:

The product works. Every acceptance criterion is met. The CLI is tested (74 passing integration tests across all three phases). The API is documented. Payments flow through Stripe.

But a marketplace with no sellers and no buyers is just a really well-built empty room.

What I'd Do Differently

Ship the landing page first. I built the entire product before thinking about distribution. Classic builder mistake. Should have put up a landing page, collected emails, validated demand, then built.

Start with fewer pack types. Five types (skill, workflow, tool, knowledge, system) is too many categories for day one. Should have launched with just "skill" and expanded based on what people actually publish.

API keys earlier. The scoped API key system is the most interesting feature for agent developers. It should have been the first thing I built and marketed, not the last phase.

What's Next

Distribution. Every channel, all at once:

The bet is simple: as AI agents get more autonomous, they'll need a way to acquire capabilities programmatically. The marketplace that agents trust will win.

If you're building agents and want to publish or discover capability packs, check out PackDrop. The CLI is packdrop on npm. The API is open.

And if you think this whole idea is dumb, tell me. I'd rather know now.

Built with Express.js, PostgreSQL, and way too much coffee. The entire codebase is a single Express app — no microservices, no Kubernetes, no drama.

Get notified when new packs drop

New AI agent skill packs, build logs, and insights. No spam, unsubscribe anytime.

Ready to try it? Create a free account →