AI Agent Marketplace

The AI Agent Marketplace explores how enterprise teams could discover reusable agents with clear ownership and governance context.

AI Agent Marketplace is a centralized, web-based platform for discovering, launching, and governing an organization's fleet of AI/automation agents (e.g., CRM Agent, MinutesAI, Project Planner Agent etc) from a single, unified dashboard. The portal solves a common enterprise problem: as organizations adopt more internal AI agents, users lose track of what exists, where it lives, and whether it's working. The system is containerized via docker-compose.yml for one-command local deployment and is architected so new agents can be onboarded via configuration/API rather than code changes, with health monitoring, usage analytics, favorites, and audit logging built in as first-class citizens.

AI experiments can become difficult to discover, evaluate, and reuse when capabilities remain isolated across teams.

• —Fragmentation: each agent lived at its own URL/port with no common entry point, forcing users to memorize or bookmark disparate links.
• —No discoverability: employees couldn't tell what agents existed, what they did, or whether they were currently operational.
• —Hard-coded onboarding cost: adding a new agent typically meant redesigning UI/navigation rather than a simple registration step.
• —No operational visibility: no way to know if an agent backend was up, degraded, or down before a user tried (and failed) to use it.
• —No usage insight or governance: no audit trail of who launched what, and no groundwork for role-based access as the agent catalog grew.

Make approved agent capabilities discoverable without separating adoption from ownership, policy, and evaluation.

The vision is to build a "single pane of glass" for enterprise AI agents — decoupling the portal UI entirely from individual agent implementations so that:

• —Agents remain independent Python/web services, integrated via pluggable launch mechanisms (URL redirect, API call, subprocess trigger, embedded iframe).
• —The catalog is config/database-driven, not hardcoded — captured in the Agent data model (agent_id, name, launch_type, health_check_url, permissions, sort_order, etc.).
• —The platform evolves toward a true "agent marketplace" experience — with discovery (search/filter), personalization (favorites/recents), operational trust (health badges), governance (RBAC, audit logs), and eventually orchestration/versioning.

Research was translated directly into a structured, phased engineering plan, reflecting analysis of comparable internal developer/tool portals and enterprise app-launcher patterns. Key research-driven decisions:

• —Config-first bootstrap, DB-second maturity: Phase 1 used a flat agents.yaml registry to validate the UX quickly, before investing in a database layer — a deliberate MVP-first sequencing (Phase 2 migrates YAML → PostgreSQL/SQLite via Alembic).
• —Separation of concerns: Distinct api/, services/, models/, healthchecks/ layers in the backend mirror common FastAPI service architecture best practices for testability and modular growth.
• —Health-check-first reliability model: Research into agent reliability failure modes led to an async, non-blocking scheduler (APScheduler) that periodically probes each agent's health_check_url rather than relying on user-reported failures.
• —Audit-log-driven governance groundwork: Rather than bolting on RBAC first, the team recognized that auth/session handling differs per agent, so audit logging and usage stats were built early to support both compliance and future analytics without blocking on SSO integration.
• —Extensible launch-type abstraction: Research into heterogeneous agent runtimes (some are simple URLs, others long-running Python processes) produced the launch_type enum (url, api, process, iframe) baked into the data model from day one , even though only url is implemented in the current prototype — deliberately future-proofing the schema.

• —Meet Priya, a sales operations lead who needs to update a lead in the CRM before her next call.She opens the AI Agent Marketplace homepage and is greeted by a clean grid of agent cards — CRM, Jira, HR, Data — each with an icon, a short description, and a colored status dot. She types "CRM" into the search bar; the grid instantly narrows to the CRM Agent card, its badge glowing green for "Online," confirming it's ready before she even clicks. She hits Launch, and the agent opens in a new tab in under three seconds — no bookmarks to dig through, no guessing whether the service is up.
• —Later that week, Priya needs the Jira Agent to triage a backlog. She skips search entirely — it's already sitting in her Recently Used row from a previous session, one click away. When a teammate in Engineering complains the Jira Agent seems slow, Priya glances at the dashboard: the badge has flipped to amber (Degraded), confirming it's a known issue rather than something she broke — the portal caught it automatically, before anyone had to file a ticket.
• —Behind the scenes, the platform administrator has a different but equally simple experience. When the team stands up a new Data Agent, she doesn't file an engineering request or wait for a redeploy — she opens the Admin panel, fills in a short form (name, description, category, launch URL), and saves. Seconds later, the Data Agent card appears on every user's dashboard, searchable and launchable immediately. She can also see, at a glance, which agents get used the most and which quietly went idle — data she uses to decide what to invest in next.
• —What Priya and the admin never see, but always benefit from: every launch and every admin change is quietly logged, every agent's health is re-checked every 60 seconds without anyone asking, and the underlying catalog is built so today's four agents can become forty without the experience changing at all.

• —Reduced onboarding friction: adding a new agent is a single POST /api/agents call or an admin-UI form submission — no frontend redeploy — directly hitting the PRD's "<30 minutes" onboarding target.
• —Operational trust and reduced support load: live health badges and 60-second automated polling let users self-diagnose "is it down?" before filing a support ticket, and give platform teams real-time fleet visibility.
• —Governance-ready audit trail: every launch and every admin mutation (with before/after state) is logged, giving compliance and security teams a foundation for change management and usage reviews without any extra engineering lift.
• —Data-driven prioritization: the /api/agents/stats endpoint gives product owners objective usage data (total and 7-day launches) to prioritize which agents to invest in or deprecate.
• —Scalable, low-maintenance architecture: the config/DB-driven registry, soft-delete pattern, and modular router/service structure mean the platform can grow from 4 to 100+ agents (per PRD scalability target) without architectural rework.
• —Faster enterprise AI adoption: by giving employees one branded, searchable "marketplace" instead of scattered tools, it lowers the discovery barrier that typically slows internal AI adoption — directly supporting the "marketplace" positioning.

• —Schema future-proofing paid off: designing the launch_type enum (url/api/process/iframe) and permissions list into the data model from Phase 1 meant Phase 4/5 features (RBAC, subprocess launches) can be added without a schema migration — validating the "design for extension, implement incrementally" approach.
• —Sequencing YAML before DB reduced early risk: shipping a static agents.yaml registry first (Phase 1) let the team validate dashboard UX before committing to a database schema, avoiding premature over-engineering.
• —Health checks needed graceful degradation: the _check_one helper explicitly distinguishes TimeoutException (→ degraded) from other errors (→ offline) — an early lesson that naive up/down checks produce misleading status for slow-but-alive agents.
• —Audit logging is cheaper to build early than retrofit: embedding _audit() calls directly into every CRUD mutation from the start avoided the common pitfall of bolting on compliance logging after the fact.
• —A phased roadmap prevented scope creep: explicitly deferring auth, async job orchestration, and analytics dashboards to later phases kept the initial prototype shippable and demoable while preserving a clear, dependency-ordered path to enterprise readiness.