Product guide · Browse & search
Configure an agent
A field-by-field guide to the agent editor, with what each setting changes and where to manage it.
Use the agent editor to describe the work, select its model, and choose what it can use. Save edits as a draft, then publish a new version when you want new runs to use them. The current agent editor requires an owner or administrator to save and publish changes.
Overview: purpose, instructions, and limits
| Setting | What it changes | How to choose |
|---|---|---|
| Name | The label used in lists and runs. | Choose a task-oriented name people can recognize. |
| Objective | The outcome the agent should achieve. | State what a useful result contains and where its responsibility ends. |
| Instructions | Guidance on approach, tone, and constraints. | Include what to do when information is missing; keep independent rules separate. |
| Acceptance criteria | Requirements assessed before a successful result. | Keep the required output-schema check and add meaningful self-assessments. |
| Steps | A ceiling on runtime steps. | Use it to bound the overall amount of work. |
| Model turns | A ceiling on model interactions. | Allow enough turns for the task and its tool results. |
| Tool calls | A ceiling on tool invocations. | This is separate from the number of tool definitions loaded in context. |
| Timeout (seconds) | The run's wall-clock ceiling. | A run request can ask for less time, never more than the agent allows. |
Leave a run-limit field empty to omit that agent-level cap. A run that reaches a configured limit fails; the limit is not a suggestion to the model. Environment policy and provider limits continue to apply. See Plans and acceptance for criteria and progress.
Model: choose the execution profile
Select a model profile registered in Connections. Model details shows the exact model, reasoning settings, generation limits, and the connection. A profile's setup status can explain why you can edit the agent but cannot yet publish or run it.
Provider credentials, endpoint, reasoning, token limits, and declared capabilities are managed with the profile, rather than as free text in the agent's instructions. Retry and fallback routes are configured through the SDK or definition API. See Models and connections.
Input and output: define the contract
| Control | Choices and behavior |
|---|---|
| Input | A message, A form, or Custom (JSON). A form creates named inputs for the run launcher. |
| Output | A written answer, Structured data, or Custom (JSON). Use structured data when another step or application consumes the answer. |
| Form fields | Name, type, required status, choices where applicable, and text-length limits. Types include short text, long text, number, yes/no, choice, and list of text. |
| Character limit | Optional limits on a message or written answer. A too-long input is refused; output is subject to the result checks. |
| Run form preview | Shows the form implied by the input schema. It does not run the model. |
| Show the answer as it is generated | Streams provisional text. Requires a written answer and a profile that declares streaming support. |
| Keep a plan | Lets the agent maintain a visible list of steps. Requires a model that supports tools. |
| Let people change the plan while it runs | Lets people with run-control access update remaining work. Completed and required work is preserved. |
Use Custom (JSON) for a schema the simple controls cannot express. Keep the schema valid and follow the validation messages. Switching to a simpler input or output shape can start a new shape; inspect the result before saving.
Capabilities: what the agent can use
| Area | What you manage | Learn more |
|---|---|---|
| Platform tools | Browse built-in file, planning, waiting, and knowledge actions; inspect availability and loading preferences. | Tools, skills, and subagents |
| Discovery settings | Search bindings only, or bindings plus other authorized tools and skills; set the active-tool limit. | Discovery |
| Tools | Attach registered tool versions and choose loading preferences. | Tools |
| Skills | Attach reusable procedures and load them when needed or from the start. | Skills |
| Team | Attach other published agents as specialists. | Subagents |
| Knowledge | Attach collections; optionally permit finding or creating collections. | Knowledge and files |
| Workspace files | Enable a file workspace for the run. | Workspace files |
The model needs tool support for capabilities it invokes as tools. Loading a capability does not grant authorization to use it. Some platform tools also need setup on the definition or run before they become usable.
Access, versions, triggers, and client apps
Access checks whether a published version would run for you. A manager can also check another principal or an API key. It checks dependencies as well as the target itself and links to places where problems can be fixed.
Versions shows the saved draft and immutable published versions. Save the draft before publishing. During publication, confirm the model, bind knowledge slots to collections, and optionally choose a queue.
Triggers shows the automation attached to the agent's versions. Schedules and events target a published version; publishing another does not silently move them.
Client apps gives the agent a name your application can call. The name resolves to its latest published version; app and user authorization still apply. Client-app access and your own console access are distinct. See Access and client apps.
The Queue control on a published version manages its concurrency assignment. Retirement stops new work on the retired target while preserving its history. Follow Publishing and versions before changing an agent that other systems use.
Advanced definition settings
The console does not expose every definition field. Advanced settings include model retry/fallback routes, detailed plan policy, declared milestones, wait bindings, and evidence or citation policy. Configure these through the supported SDK or definition API and use the developer reference for the available operations. Do not assume a matching editor tab exists.
Use this split intentionally: the console handles the common setup and operational controls; the developer interfaces handle advanced authored definitions and application integration.