All documentation

Builder & Admin Guide

Exactly how an agent goes from idea to live, paying product on MNKI AgentOS — and how the MNKI team reviews and operates it.

Covers both the Builder journey and the Admin (MNKI team) workflow.

The lifecycle at a glance

Every agent moves through the same pipeline. Builders drive the first step; MNKI admins drive review and operations.

StageWhoWhat happens
draftBuilderFill out the submission form (or paste a manifest).
pendingBuilder → AdminSubmission enters the review queue.
in_reviewAdminMNKI reviews quality, safety, and accuracy.
approved → liveAdminA live agent is published; a Stripe product/price is created.
suspendedAdminTemporarily removed from the marketplace if needed.

Becoming a builder

There is no separate sign-up. The first time you submit an agent, a builder profile is created for your account automatically. To get verified status (the “✓ Verified builder” badge and higher revenue tiers), the MNKI team reviews your account during your first approval.

  1. 1
    Sign in (passwordless email OTP). Visit For Builders and click Become a builder.
  2. 2
    Complete the guided submission form. Use Load example to see a fully-filled agent.
  3. 3
    Submit for review. Track status in your builder dashboard.
  4. 4
    To receive payouts, complete Stripe Connect onboarding from the builder dashboard.

The submission form

The form is organized into seven steps. Steps 1–3 are the required core (they become your agent.manifest.yaml); steps 4–7 are your marketplace listing — optional, but they are what render on your agent’s detail page across the four tabs buyers browse.

StepSectionFeeds
1The basics — name, tagline, description, icon, accent, categoryManifest + listing header
2How it runs — runtime, trigger, model, price, SLAManifest
3Tools, inputs & outputsManifest
4Listing — Overview (what / outcomes / who for / use cases)Overview tab
5Listing — How it works (pipeline / triggers / example output)How it works tab
6Listing — Setup (connect tools / configure / schedule / first run)Setup tab
7Listing — Specs & FAQSpecs & Pricing tab
Prefer YAML? Toggle Advanced: paste raw YAML/JSON to submit a complete manifest by hand, including a top-level listing: block. Both paths produce the same result.

The agent manifest

The manifest is the contract between your agent and the platform. The guided form builds it for you; here is the shape it produces.

{
  "name": "SEO Blog Publisher",
  "version": "1.0.0",
  "category": "marketing",
  "runtime": "langraph",                // langraph | crewai | n8n | custom
  "llm_requirements": { "primary": "claude-sonnet-4-6" },
  "tools_required": ["wordpress", "google_search"],
  "trigger_type": "scheduled",          // scheduled | event | realtime | ondemand
  "pricing": { "model": "subscription", "base_price": 9900 },  // cents
  "inputs":  [{ "name": "target_keywords", "type": "string[]", "required": true }],
  "outputs": [{ "name": "published_posts", "type": "url[]" }],
  "sla": { "uptime": 99.5 },
  "tagline": "Researches, writes, and publishes SEO posts weekly.",
  "icon": "✍️",
  "accent_color": "#8B92B8",
  "description": "An always-on content team that …",
  "listing": {                          // OPTIONAL — your rich detail page
    "overview":   { "what": "…", "outcomes": [], "whoFor": [], "useCases": [] },
    "howItWorks": { "steps": [], "triggers": "", "eachRun": "", "exampleOutput": "" },
    "setup":      { "connectTools": [], "configure": [], "schedule": "", "firstRun": "", "requirements": [] },
    "specs":      { "sla": "", "faq": [] }
  }
}

Required fields

  • name, version, category (one of marketing, sales, operations, finance, hr, support, ecommerce, security).
  • runtime, trigger_type, and llm_requirements.primary.
  • tools_required (array, may be empty), inputs, and outputs (arrays).
  • pricing.base_price in cents (e.g. 9900 = $99/mo).

Is agent.manifest.yaml enough?

For listing and publishing: yes. A valid manifest is all that is strictly required to submit, pass review, and have a live, subscribable, richly-documented agent page. The optional listing block is what makes the detail page comprehensive — without it, the platform generates a sensible page from your base fields, but authored listing content converts far better.

For execution: it depends on the runtime. The manifest declares what the agent is and what it needs; how it actually runs depends on the runtime you choose:

RuntimeWhat you provide beyond the manifestNotes
custom / langraph / crewaiA deployable runtime endpoint (e.g. on Railway) that accepts a run request and posts results back to the platform callback.Wired with the MNKI team during review.
n8nAn n8n workflow (webhook-triggered) that performs the work.Connected via your n8n instance + API key.
house agentsConfig-driven definition (system prompt + tool keys + step graph) run on MNKI’s Claude executor.Used for MNKI’s own agents; no separate code.

So the manifest is necessary and sufficient to list an agent, plus it’s the single source of truth the runtime reads. The execution behavior for third-party runtimes is supplied separately (an endpoint or workflow) and finalized during review — the manifest tells the platform how to reach and trigger it.

Beyond the manifest, you may also need

  • Tool access: the integrations in tools_required must exist as supported connectors. OAuth-backed tools (Google, Slack, etc.) require the buyer to connect their own account; credentials are encrypted and injected at runtime — your code never sees raw tokens.
  • Stripe Connect onboarding to receive payouts (one-time, from the builder dashboard).
  • Accurate claims: your listing must match what the agent actually does — this is checked in review and enforced by the Builder Terms.

Pricing & payouts

You set the monthly price. MNKI retains a platform commission (currently 30%) and remits the rest to you via Stripe Connect, net of refunds, chargebacks, taxes, and fees. Higher revenue tiers improve the split as you scale. See the revenue share details and the Builder Terms.

Admin

How the MNKI team reviews submissions and operates the marketplace. Admin access is restricted to the configured allowlist (ADMIN_EMAILS) and gated on every request.

Reviewing submissions

  1. 1
    Open Admin → Review. The queue shows all pending / in_review submissions with the builder and full manifest.
  2. 2
    Inspect the manifest and listing: do the claims match the runtime? Are the tool scopes minimal? Is pricing sane? Is the content safe and policy-compliant?
  3. 3
    Approve to publish, or Reject with notes the builder will see.

What approval does

  • Creates a live row in agents with status live, copying the manifest (including the listing block) so the detail page renders rich content immediately.
  • Carries over the builder’s tagline, icon, and accent_color if provided.
  • Generates a Stripe product and price so the agent is immediately subscribable.
  • Marks the submission approved and links it to the new agent.

Managing live agents

  • From Admin → Agents, admins can fully edit an agent — name, tagline, description, category, badge, price — and suspend or relist it.
  • Suspending removes an agent from the marketplace (status no longer live) without deleting its data; relisting restores it.
  • Edits take effect immediately on the public listing.

Operations: data, CRM & payouts

  • The overview shows platform metrics and charts; every metric card and table row drills down (e.g. an organization → its users, subscriptions, deployments) and exports to CSV.
  • CRM & campaigns captures contacts and waitlist leads and sends email via Amazon SES.
  • Run builder payouts from the overview triggers Stripe Connect transfers to builders for their share of collected revenue.

Ready to publish your first agent?

Submit an agent