The Code part of an agent

An agent is one package of up to four parts: Instructions, Skills, Actions and Code. Instructions, Skills and Actions run no code of their own; only the Code part does. The other three parts reach buyers through the same two doors as Code: Connect (the hosted gateway) and Install (a plugin from the catalog). See the docs home for the whole model.

A code agent declares one runtime. Node 22/24 and Python 3.13 are equal choices: the agent runs the same way, and only the build step differs.

The Code part is the repository you already have — FindAgent runs it 1:1, unchanged. You don't rewrite it for the platform and you never write a findagent.json by hand: the submit flow reads the repo and generates the manifest from what's already there.

FindAgent reads the artifacts your repo already carries — an Anthropic DXT manifest.json, an MCP server config, your .env.example, package.json, and README — and auto-detects:

• Tools — the capabilities your code exposes, surfaced as the agent's skills.
• Credentials — the secrets your code needs, read from your DXT env and .env.example keys (never the values), each captured as a host-bound credential slot.
• Hosts — the external hosts your code talks to, derived into the default-deny egress allowlist.

You confirm or edit what was detected and submit. That's the 1:1 promise: the repo you bring is the agent that runs.

Not sure where to start? FindAgent/agent-template is a code agent template in Node and Python, and FindAgent/agent-creators holds playbooks that work with any AI assistant.

Code needs a GitHub repo for now. The Code part comes in through the GitHub-connected submit flow — your own repo, gated by an OAuth token you authorize. The other three parts also come in through Upload or the Editor; see What are you adding?.

1. 1
   Connect GitHub. Authorize the FindAgent GitHub App so the platform can read the repo you choose. Only repos your connected token can read are reachable.
2. 2
   Pick the repo. Choose the repository to publish. FindAgent snapshots it and generates the manifest from the code — tools, credential slots, and the egress allowlist are detected for you.
3. 3
   Review & submit. Confirm the detected fields and submit. The bundle is statically scanned and human-reviewed before it can publish; a manifest the sandbox can't accept fails closed rather than being waved through.

When an agent with code is approved, FindAgent builds it for the hosted runtime. The build installs dependencies and runs in the sandbox with a real node_modules — your code runs the way it does locally, not as a single flattened file.

• Native dependencies are supported. Packages with native add-ons — the better-sqlite3 / playwright / onnxruntime class — build and run, because the runtime keeps a full node_modules rather than bundling everything into one module.
• Prebuilds are fetched during the build. The build step reaches the package registries and prebuilt-binary hosts a native dependency needs, through an admin-managed build-egress allowlist.
• The build fails closed. If a native dependency can't fetch or compile its binary, the build is marked failed and the agent does not serve — a broken bundle is never shipped.

A hosted agent with code runs in FindAgent's sandbox, so you use it by connecting your client to its gateway URL — nothing runs on your machine and there's nothing to keep running. The CTA on a hosted agent with code reads Get, never “Install”.

Add its remote MCP server URL — in the form https://mcp.findagent.cloud/agents/<slug> — as a connector in Claude, ChatGPT, Gemini, or any MCP-capable client, and sign in once. The full walkthrough is on the Connect page.

A creator can also offer an agent with code you run on your own machine instead of — or in addition to — the hosted option. A local agent with code is downloaded and run by you via the FindAgent CLI, so it can reach your localhost and local tools. FindAgent never runs it: it runs on your computer, with your own access, like an npm package or a local MCP server.

• Hosted, local, or both. An agent with code declares how it can serve. Hosted is the default; a creator may add a local option, or offer a local-only agent. A local-only agent has no hosted gateway URL — it is never run by FindAgent.
• Buyer-run, buyer-consented. When you run a local agent it executes with your user's access — it can read your files, use your local tools, and make network requests, just like any program you run. There is no FindAgent-enforced egress allowlist on a local run — your machine is the boundary.
• Review the source first. A local agent still passes the same automated scan and human review as any listing, but that is not a guarantee it is safe to run on your machine. Review the source before you run it — and if the source is private, only run it if you trust the publisher.
• Your credentials stay local. A local agent uses your own keys, set through the CLI; they stay on your machine and are never sent to FindAgent.

The listing's Setup section shows the exact run command and client-config snippet when a local option is offered. The security model explains the hosted-vs-local trust boundary in full.

An agent with code moves through build and readiness states after it's approved. The gateway only serves a ready agent:

Publishing a new version of an already-published agent with code creates a fresh pending version and builds it separately — the live version keeps serving until the new one is approved, so an in-progress build never takes a working agent down.

Calls to an agent with code over the hosted gateway are the metered surface — usage is recorded per call on the gateway path. This is what makes hosted agents with code the primary, billable way to run real code on FindAgent. A local agent with code runs offline on the buyer's own machine, so — like any offline local run — it is inherently unmeterable and isn't counted.

The security keystone is unchanged. Instructions, Skills and Actions run no code of their own; only the Code part does. The Code part is scanned statically and human-reviewed before it publishes. Where it runs depends on how it's served:

• Hosted — the code runs only inside the isolated, ephemeral sandbox FindAgent provisions, walled off from FindAgent's own app and data and from your machine, with default-deny egress, host-bound credentials, and platform-enforced guardrails.
• Local — the code runs on your machine with your own access; FindAgent never runs it and there is no platform-enforced sandbox or egress allowlist. The scan and review still ran, but they are not a guarantee it is safe to run — review the source first (like an npm package or a local MCP server).

See the security model for the full reasoning.

• Manifest spec — the code-bundle manifest shape (entrypoint, runtime, allowed hosts, MCP exposure).
• Connect — add a hosted agent's gateway URL as a remote connector in your client.
• Creator guide — the submit wizard, pricing, and the review & scan pipeline.