Building agents

Versioning & updates

Once an agent is published you keep it current by publishing new versions. Every new version goes through the same scan and review as a first submission — and your live version keeps serving the whole time. Rolling back is instant. The exact update path depends on the agent kind.

The one rule: your live version never goes down

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 a code agent — nothing changes for your buyers. This is the same guarantee whether you edit a doer's tools, re-pull a code agent, or re-introspect an MCP-server listing.

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.

Which update path is yours

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.

Agent kind	How you update it	What FindAgent re-runs
Doer / prompt recipe	Publish a new version — edit the system prompt, example prompts, and (for a doer) the whole tool surface, credential slots, and guardrails.	The security scan + the author-time credential-to-host binding check on any capability change.
Code agent · skills bundle	Re-pull from your connected GitHub repo (a “Publish new version → Re-pull from your repository” action, or the re-pull tool).	A fresh snapshot of your repo, the static scan, and — for a code agent — a rebuild in the sandbox.
MCP-server listing	Re-introspect the remote server so its listed tools match what your endpoint actually exposes now.	A sandbox-gated, SSRF-hardened re-listing of the remote server’s current tools.

Doer & recipe agents — publish a new version

For a declarative doer or a prompt recipe you own, publishing a new version lets you edit the entire agent — not just the prompt:

The system_prompt and the example prompts.
For a doer, 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.

Two ways to bump a doer

You can publish a new version from your dashboard, or straight from your AI client with the platform MCP (the findagent_bump_version tool). Both go through the same review; see MCP & API.

Code & skills agents — re-pull from GitHub

A code agent or a skills bundle 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:

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.
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.
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.

“Update available” tells you when to re-pull

FindAgent checks the head of your source branch and flags Update available on your dashboard when your repo has moved ahead of the commit your published version was built from. Re-pulling that lands the new commit clears the flag. This is a signal only — nothing publishes automatically.

A failed build won’t fix itself by re-running

The build compiles the snapshot, so if a build failed and you've since fixed the repo, re-running the same build recompiles the same code. Re-pull to pull your fix into a new snapshot and rebuild from it. A build that still fails is held back — a broken bundle never serves. See Code agents for the build and readiness states.

MCP-server listings — re-introspect

An MCP-server listing points at a remote server you run — FindAgent never runs it, it only lists what the server exposes. When your server's tools change, re-introspect the listing so the catalogue reflects them. FindAgent re-lists the remote 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.

Rolling back

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.

Withdrawing a pending version

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.

What never changes across versions

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 the same automated scan and human review before it can go live. Nothing self-publishes.

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