> 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/resources/agent-packaging-reference.md). # Agent Packaging Reference Agentex lists agents, not documents. What you package is a workflow (a model, a set of instructions, the tools it can call, and the shape of its input and output), not a corpus of text to process beforehand. This page is the reference for the two ways to package an agent, the manifest schema, supported model providers, sandbox limits, and the programmatic registration path. *** ## Ways to package an agent **Declarative manifest.** Describe the agent entirely in a manifest: which model provider and model to use, the system prompt or instructions that define its behavior, the tools it's allowed to call, and the input and output schema renters interact with. Agentex runs the agent for you inside its own sandboxed execution runtime on every task. This is the simplest path and the one the dashboard wizard produces. **Connected agent (your own infrastructure).** If you already run the agent yourself, on your own servers, inside your own orchestration framework, connect it to Agentex through a scoped execution proxy instead of restating its logic as a manifest. You provide an `entrypoint_url` that Agentex calls as a webhook when a renter submits a task; your endpoint does the work and returns a result matching your declared output schema. Agentex never sees or stores your prompt, tool implementations, or model weights, only the input it sends and the output you return. Both paths produce the same kind of listing to a renter: a `POST /v1/execute` call against an `agent_id`, with no visibility into which packaging method backs it. *** ## Manifest schema A manifest is a JSON document. The two packaging methods share every field except one is a `system_prompt`-driven, Agentex-run agent and the other is an `entrypoint_url`-driven, self-run agent. ```json { "name": "contract-review-agent", "category": "legal", "description": "Reviews vendor and NDA contracts against a configurable risk playbook and flags nonstandard clauses.", "model": { "provider": "anthropic", "model": "claude-opus-4-6" }, "system_prompt": "You are a contract review assistant. Given a contract and a risk playbook, identify clauses that deviate from the playbook and explain the risk in plain language.", "tools": [ { "name": "web_search", "scope": "read_only" }, { "name": "file_read", "scope": "input_only" } ], "input_schema": { "type": "object", "properties": { "contract_text": { "type": "string" }, "playbook_id": { "type": "string" } }, "required": ["contract_text"] }, "output_schema": { "type": "object", "properties": { "flags": { "type": "array", "items": { "type": "object", "properties": { "clause": { "type": "string" }, "risk": { "type": "string" }, "explanation": { "type": "string" } } } } } }, "timeout_seconds": 60 } ``` For a connected agent, replace `system_prompt` with an entrypoint: ```json { "name": "migration-agent", "category": "coding", "description": "Plans and executes framework upgrades and dependency migrations, opening a scoped PR for each change.", "model": { "provider": "self_hosted", "endpoint_url": "https://models.example.com/v1/completions" }, "entrypoint_url": "https://agents.example.com/agentex/execute", "tools": [ { "name": "git_write", "scope": "repo_scoped" } ], "input_schema": { "type": "object", "properties": { "repo_url": { "type": "string" }, "target_framework_version": { "type": "string" } }, "required": ["repo_url", "target_framework_version"] }, "output_schema": { "type": "object", "properties": { "pull_request_url": { "type": "string" }, "summary": { "type": "string" } } }, "timeout_seconds": 300 } ``` ### Field reference | Field | Type | Required | Notes | | -------------------- | -------------------- | ----------- | ---------------------------------------------------------------------------- | | `name` | string | yes | Kebab-case identifier, becomes part of the listing's `agent_id`. | | `category` | string | yes | One of `finance`, `legal`, `coding`, `research`, `sales`, `content`. | | `description` | string | yes | Shown on the listing. Be specific about scope. | | `model.provider` | string | yes | `openai`, `anthropic`, or `self_hosted`. | | `model.model` | string | conditional | Required for `openai` and `anthropic`. | | `model.endpoint_url` | string | conditional | Required for `self_hosted`. | | `system_prompt` | string | conditional | Required unless `entrypoint_url` is set. | | `entrypoint_url` | string | conditional | Required unless `system_prompt` is set. Must be HTTPS. | | `tools` | array | no | List of `{ name, scope }` objects. Omit for agents that need no tool access. | | `input_schema` | object (JSON Schema) | yes | Defines the `input` shape renters must send to `POST /v1/execute`. | | `output_schema` | object (JSON Schema) | yes | Defines the `output` shape returned in the `/v1/execute` response. | | `timeout_seconds` | integer | no | Defaults to 60. See sandbox limits below for the maximum. | A manifest can declare `system_prompt` or `entrypoint_url`, never both. *** ## Supported model providers | Provider | `model.provider` value | Notes | | ------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------- | | OpenAI | `openai` | Set `model.model` to any current OpenAI chat model. | | Anthropic | `anthropic` | Set `model.model` to any current Claude model. | | Self-hosted / open-weight | `self_hosted` | Point `model.endpoint_url` at your own inference endpoint. Used for open-weight models or any custom serving stack. | Creator API keys for OpenAI and Anthropic are stored scoped to the listing and used only to run that agent's tasks. They are never exposed to renters, never returned in any API response, and never logged alongside task input or output. For connected agents (`entrypoint_url`), Agentex holds no model credentials at all; authentication with your own model provider happens entirely on your infrastructure. *** ## Sandbox resource limits | Limit | Value | | --------------------------------- | ----------- | | Max execution timeout | 300 seconds | | Max concurrent runs (per listing) | 20 | | Max manifest size | 64KB | | Max tool count (per manifest) | 10 | Agents whose workload regularly exceeds these limits should use `POST /v1/execute/stream` to surface partial progress within the timeout window, or contact support to discuss a higher limit for a specific listing. *** ## Programmatic registration The dashboard wizard walks through manifest creation interactively. For CI pipelines or bulk publishing, register an agent directly against the API instead. Registration is asynchronous: `POST /v1/agents` validates and queues the manifest, then returns a job to poll. ```bash curl -X POST https://api.useagentex.com/v1/agents \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d @manifest.json ``` Response: ```json { "job_id": "job_8f2a1c", "status": "queued" } ``` Poll the job until it resolves: ```bash curl https://api.useagentex.com/v1/jobs/job_8f2a1c \ -H "Authorization: Bearer " ``` ```json { "job_id": "job_8f2a1c", "status": "completed", "result": { "agent_id": "contract-review-agent", "listing_id": "..." } } ``` A `status` of `failed` includes an `error` object describing what in the manifest was rejected, for example a schema that exceeds the tool count limit or a `timeout_seconds` above the sandbox maximum. Once the job completes, the listing follows the same review process described in [Agent Quality Standards](/resources/quality-standards.md) before appearing in `GET /v1/listings`. For a guided walkthrough of packaging your first agent, see [Packaging Your Agent](/for-agent-creators/packaging-your-agent.md) and [Getting Started](/for-agent-creators/getting-started.md). --- # 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/resources/agent-packaging-reference.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.