Skip to content

Configure Agent Behavior

Use managed configuration when the same server binary should host multiple agent profiles, switch models, tune prompts, adjust permissions, or change plugin behavior without rebuilding Rust code.

Configuration is for behavior that should change after the runtime capability already exists in code. This is better than rebuilding for every prompt, tool filter, or permission tweak because operators can validate, preview, save, and restore behavior without changing the executable boundary.

This page is UI first. The Admin Console is the safest way to make one change, validate it, preview behavior, and save the next runtime snapshot. Use API references when you need to automate the same workflow.

  • Runtime capabilities already exist in code: tools, providers, stores, and plugins are registered by the server.
  • The Admin Console can connect to the server and shows Connected in the topbar.
  • At least one provider and model are configured if you want live model calls.

Start here if needed: Use the Admin Console.

Open Agents, then create a new agent or open an existing one.

Editor areaTune hereUse when
BasicsModel, max rounds, reasoning effort, system promptYou want to change personality, instruction style, model, or run bounds.
ToolsAllowed tools, excluded tools, source filtersYou want to expose or hide capabilities without changing code.
PluginsPlugin enablement and plugin-backed sectionsYou want permission, reminder, generative UI, deferred tools, or other plugin behavior.
DelegatesAgent handoff targetsThis agent should be able to pass control to other registered agents.
AdvancedRaw JSON previewYou need to review the exact spec before saving.
HistoryPrior revisions and restore actionsYou need to compare or roll back a saved change.
Agent editor with model selection, system prompt, tools, plugins, delegates, history, save controls, and preview chat.
The agent editor is the main tuning surface: edit one tab, validate, preview, then save.
  1. Change one behavior dimension at a time.
  2. Click Validate. Fix validation errors before previewing.
  3. Use the right-side preview chat with a representative prompt.
  4. Save only after the preview behaves as expected.
  5. Run a real task or eval fixture.
  6. If behavior regresses, use History → Restore and save a known-good version.

Edits apply to new runs after saving. Existing running work keeps the spec it already resolved.

Use Basics:

  1. Pick the target model id.
  2. Edit the system prompt.
  3. Adjust max rounds or reasoning effort if the model needs different bounds.
  4. Validate, preview, then save.

Pair with Hot-Tune Prompts when the prompt is the main thing you are changing.

Use Tools:

  1. Choose All tools for broad access or Custom selection for explicit control.
  2. Use source filters to find built-in, plugin, or MCP tools.
  3. Add sensitive tools to the excluded list, or pair them with permission rules.
  4. Validate and preview a task that should and should not call the tool.

Use Plugins and the permission editor:

  1. Enable the permission plugin for the agent.
  2. Add Ask/Allow/Deny rules for sensitive tool names and arguments.
  3. Validate, save, then run a scenario that should suspend for review.

See Enable Tool Permission HITL.

Use Plugins:

  • Reminder rules inject context after matching tool calls.
  • Deferred-tool policy keeps large tool schemas out of the prompt until they are likely to be needed.

Change one plugin section at a time, then preview with a scenario that exercises that plugin.

Use Delegates:

  1. Select the agents this one is allowed to hand off to.
  2. Make sure each delegate has its own model/tools configured.
  3. Preview a scenario where handoff should happen.

See Use Agent Handoff and Multi-Agent Patterns.

Use Basics and stop-policy settings where available:

  • Lower max rounds to prevent unbounded loops.
  • Configure explicit stop policies for token, elapsed time, error frequency, or round count.
  • Pair with evals to ensure the bounds do not cut off valid work.

See Configure Stop Policies.

Use /v1/config/* directly when the change is generated by CI, deployment automation, migration scripts, or internal tooling. Keep the same workflow: validate the draft, write it, then run/evaluate behavior.

Related references:

Safe changes for new runs:

  • Prompt text and tool descriptions.
  • Model id, reasoning effort, max rounds, and stop policies.
  • Allowed/excluded tools and delegates.
  • Plugin config sections such as permission, reminder, generative UI, and deferred-tool policy.

Be careful with:

  • Removing tools or plugins that active workflows expect.
  • Renaming ids used by clients, delegates, eval datasets, or saved examples.
  • Changing provider credentials without testing the provider first.