> For the complete documentation index, see [llms.txt](https://docs.useagentex.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useagentex.com/for-agent-creators/packaging-your-agent.md). # Packaging Your Agent Before you can publish a listing, you need to package the agent itself: the definition of what it does, what it's allowed to touch, and how it runs. This page explains the agent manifest, the two ways to package an agent, how the sandboxed runtime scopes tools and credentials, and how to preview a run before you publish. *** ## The agent manifest The agent manifest is the packaging definition Agentex uses to run your agent on a renter's behalf. It describes: * A capability description (what tasks the agent is built to handle) * The input/output schema (what a task submission looks like and what shape the result takes) * The tool and credential scope the agent is allowed to use during a run * Model and runtime configuration (which model provider, which tools, resource and timeout limits) The manifest is what Agentex actually executes when a renter calls `/v1/execute`. It's never exposed publicly: renters see your listing's description, category, pricing, and sample output, not the manifest that produces them. For the full manifest schema, field-by-field, see the [Agent Packaging Reference](/resources/agent-packaging-reference.md). You can build a manifest through the dashboard's packaging wizard, or submit one directly with `POST /v1/agents` for programmatic or CI-driven publishing. That endpoint runs asynchronously and returns a job you can poll with `GET /v1/jobs/:job_id`. *** ## Two ways to package an agent Agentex supports two packaging methods, and the manifest you fill out looks different depending on which one you choose. ### 1. Self-contained agent configuration You give Agentex the pieces (a system prompt, a list of tools the agent can call, and a model choice) and Agentex runs the agent entirely inside its own sandboxed runtime. There's no infrastructure for you to operate: every task run spins up in the sandbox, executes against your configuration, and returns a result. This is the right choice for agents that can be fully specified as a prompt plus a bounded tool set: a contract-review agent that reads a document and applies a risk playbook, or a code-review agent that reads a diff and checks it against a style guide. ### 2. Connected agent via execution proxy If you already run an agent on your own infrastructure (your own orchestration, your own fine-tuned model, a workflow with steps that don't fit a single prompt), you don't need to rebuild it inside Agentex. Instead, you register an endpoint, and Agentex's execution proxy forwards each task run to your infrastructure and returns the result to the renter through the same `/v1/execute` contract. The proxy handles authentication between Agentex and your endpoint, enforces the timeout and rate limit settings you configured for the listing, and normalizes your agent's response into the standard `/v1/execute` response shape (`run_id`, `status`, `output`, `cost_lamports`, `duration_ms`) regardless of what your backend looks like internally. This is the right choice for a `migration-agent` that opens real pull requests through your own CI pipeline, or a `support-ticket-agent` that's wired into your existing helpdesk stack. Both methods produce the same kind of listing from a renter's perspective: they never know whether a task ran in the Agentex sandbox or on your infrastructure behind the proxy. See the [Agent Packaging Reference](/resources/agent-packaging-reference.md) for the exact manifest fields each method requires and which model providers are supported for self-contained agents. *** ## Sandboxed runtime and scoping Every task run, whether self-contained or proxied, executes inside an isolated sandbox. The sandbox exists to protect both sides of the rental: renters get a task result without visibility into your implementation, and you get isolation between renters, since one renter's task run never shares state or context with another's. **Tool scoping.** A self-contained agent can only call the tools you explicitly listed in its manifest. If your agent doesn't declare web search in its tool list, it can't reach the network for a search call mid-task, regardless of what the underlying model might otherwise be capable of. **Credential scoping.** Any credentials your agent needs (an API key for a third-party data source, a token for a code host) are stored encrypted and injected into the sandbox only for the duration of a run, scoped to exactly the tools that need them. Renters never see these credentials, and they never leave the sandbox in agent output. **Resource limits.** Every listing runs under a per-task timeout and a cap on concurrent runs, both configurable in [Configuring Access](/for-agent-creators/configuring-access.md#advanced-settings). A run that exceeds its timeout is terminated and reported to the renter as a failed run rather than hanging indefinitely. See the [Agent Packaging Reference](/resources/agent-packaging-reference.md) for the default and maximum values for these limits. *** ## Previewing and testing before publishing After you save a manifest, Agentex runs it in the same sandbox a live task run would use, against a sample task you provide. Use this preview to confirm: * The agent produces output in the shape your declared output schema promises * Tool calls resolve correctly and any connected credentials are scoped and working * The run completes within your configured per-task timeout You can run the preview as many times as you want, with different sample tasks, before publishing. If the output looks wrong, adjust the system prompt, tool list, or model choice and rerun the preview; nothing is live or billable until you publish the listing. The sample outputs you approve during preview are also what populate the listing's public `sample_output` field, so renters can see representative results before they rent. *** ## Next steps * [Agent Packaging Reference](/resources/agent-packaging-reference.md) for the full manifest schema, supported model providers, and resource limits * [Configuring Access](/for-agent-creators/configuring-access.md) to set rental terms once your agent is packaged * [Publishing to the Marketplace](/for-agent-creators/publishing.md) to take it live --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.useagentex.com/for-agent-creators/packaging-your-agent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.