Overview
How might we design agent marketplace so people can trust and act on AI output?
When this pattern fits
- Perfect for agent platforms, automation tools, and ecosystems where providing pre-built agents accelerates adoption and reduces development time.
When to skip or lighten it
- Internal tools with only one sanctioned agent.
- Highly regulated orgs that forbid third-party agent installs.
- Products that are not agent platforms at all.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Listings that hide required permissions until after install.
No uninstall or revoke from the same surface.
Fake social proof with no verifiable publisher.
Agents that request broad scopes for a narrow job.
How products use it
| Product | Implementation |
|---|---|
| Zapier | Template and agent-style automation catalogs. |
| Make | Scenario templates users can install and tweak. |
| n8n | Workflow templates and community nodes. |
| Microsoft Power Automate | Template gallery for automated flows. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Agent Marketplace" AI interface design pattern.
Pattern Definition:Frequently asked questions
What should an agent listing show?
What it does, who published it, required permissions, data access, ratings, and a try-before-install path when possible.
How does this relate to agent identity?
Marketplace cards are how identity is discovered. After install, the same name and scopes should appear in runtime UI.
Should marketplaces allow custom agents?
Yes for power users, but keep a review or permission gate before org-wide publish.
What is the uninstall expectation?
One-click remove that revokes tokens and stops schedules. Leftover silent jobs are a trust failure.