Versioning & updates

Publishing a new version never takes your working agent offline. A new version is created as a separate pending version and reviewed on its own; the version buyers are already using keeps serving until the new one is approved. If a new version is rejected — or its build fails, for an agent with code — nothing changes for your buyers. This is the same guarantee whether you edit an agent's actions, re-pull an agent's code, or re-introspect an MCP server.

A buyer's access is tied to their purchase, not to a specific version, so re-versioning and rolling back never revoke anyone's entitlement.

How you publish an update depends on the kind of agent. Each path produces a new pending version that goes to review; the current version keeps serving until it's approved.

For an agent you built here — instructions, skills, actions — publishing a new version lets you edit the entire agent — not just the prompt:

• The system_prompt and the example prompts.
• For an agent with actions or skills, the whole capability surface — add, remove, or edit tools and their action bindings, the credential slots, and the guardrails. You pass the complete intended tool list; it replaces the old one.
• The price (once payments launch). A price change applies going forward — it is never retroactive, so existing buyers keep their access.

Any change to a tool action or credential re-runs the same security scan and the same author-time check that a credential slot's allowed_hosts cover the host its action reaches. A changelog is required (10–500 characters), though it's auto-drafted from the tool diff when you edit tools.

If your actions agent keeps its manifest (findagent.json) in a GitHub repository, publish its next version from there instead of passing the whole tool list again. You name the repository each time, because an actions agent does not store one, and it must be one you have push access to — FindAgent checks that before reading a single file. The tools and credential slots in the repo become a new version that goes through the same review as any other change; your live version keeps serving until it is approved. From an AI client use findagent_new_version with repo. Editing the fields directly still works when there is no repo.

An agent built from a code or skills repo is built from a snapshot of your repository taken at pull time, not its live state on GitHub. So editing GitHub alone doesn't change your published agent — you re-pull to bring your latest code into a fresh snapshot:

1. 1
   Trigger a re-pull. From your dashboard use Publish new version → Re-pull from your repository(or the findagent_repull tool). You can pull the latest commit on your stored branch, or a specific branch, tag, or commit. A re-pull bumps a patch version (0.1.0 → 0.1.1) by default — pass an optional minor or major bump when the re-pull is a real feature release, not a small fix.
2. 2
   FindAgent re-fetches and checks it. The repo is re-fetched with your connected GitHub token, re-snapshotted, and re-scanned; a code bundle is also rebuilt in the sandbox. The new snapshot is diffed against your live version.
3. 3
   A changed source becomes a pending version. If the source changed, a new version is submitted for review with an auto-drafted changelog. If nothing changed, the re-pull is a no-op. Either way your live version keeps serving.

An MCP-server listing points at a server you run — FindAgent never runs it, it only lists what the server exposes.

If your server is remote (it has a URL we can reach), re-introspect the listing when its tools change. FindAgent re-lists the server's current tools over a sandbox-gated, SSRF-hardened scan and, if the tool surface changed, submits a new version for review with an auto-drafted changelog. If the remote can't be reached or is auth-walled, nothing changes and you're told why. Only the tool listing updates — nothing about your server executes on FindAgent.

If your server runs on the buyer's own machine (a local stdio server), there is no endpoint for us to re-scan, so re-introspection does not apply and would be refused. Publish a new version by editing the listing and bumping it, exactly as an agent built here does.

If a new version isn't what you wanted, you can roll a published agent of any kind back to a prior version. The live agent immediately serves that earlier version again. A rollback target must be a version that was published before — so a rollback never serves un-reviewed content — and it re-derives the connection facts (hosted vs. local, the agent kind, the category) from the version you roll to, so the listing stays consistent. Existing buyers keep their access.

If a version is stuck in review and you want to submit a fresh one instead, you can withdraw the pending version. Withdrawing only ever touches a version that is still awaiting review — it never touches the live published version, which keeps serving.

• The slug. An agent's URL is permanent for SEO and existing links — it can't change after the first publish, across any number of versions.
• Existing entitlements. A purchase entitles the buyer to the agent, not to one version. Re-versioning, rollback, and price changes never revoke access someone already has.
• The review gate. Every new version — bump, re-pull, or re-introspect — passes human review before it can go live, and a version of an agent we serve passes the same automated scan as its first submission. Nothing self-publishes.
• Version numbers. A number an earlier withdrawn or rejected version already used is skipped, a patch at a time, whichever way the new version was made.

• Creator guide — the first-publish flow, the submit wizard, and the review pipeline.
• The Code part of an agent — build and readiness states, and re-pull for an agent with code.
• Manifest spec — the tool, credential-slot, and guardrail shapes you edit in a new version.