Agent Presets
Two distinct things called "preset" — compile-time preset templates surfaced as connector actions, and tenant-owned versioned agent presets referenced by chat sessions and workflow steps.
"Agent preset" means two different things in Ductor, and conflating them causes confusion. This page keeps them apart.
Two different presets
Preset templates are compile-time, built-in agents surfaced as one-click connector actions in the workflow editor. Tenant agent presets are runtime, tenant-owned, versioned agent configurations managed through an API. The first ships with the binary; the second is data your tenants create.
1. Preset templates (connector actions)
A preset template is a compile-time agent baked into the binary and registered as
a connector action under the agent provider (displayed as "AI Agents") so it
appears one-click in the workflow editor palette alongside every other action. The
provider is registered AuthNone and read-only — preset agents consume no per-tenant
credentials; the inference proxy handles upstream LLM
authentication.
Each template is a thin authoring wrapper: a model, a baked-in system prompt, and sensible generation defaults. The built-ins:
| Slug | Model | Provider | Does |
|---|---|---|---|
support_triage | gpt-4o-mini | openai | Classifies and routes inbound support cases by severity and topic. |
deal_summarizer | gpt-4o | openai | Summarizes deal context, owners, history, and risk into a brief. |
reply_drafter | claude-3-5-sonnet | anthropic | Drafts an empathetic customer reply for human review. |
The action key is the provider key plus the slug — e.g. agent.support_triage.
Overriding a template per step
A step author supplies the input and can override the baked defaults:
| Arg | Required | Effect |
|---|---|---|
user_prompt | yes | The input passed to the agent. CEL expressions over prior step output are allowed. |
instructions | no | Extra system-prompt text, appended to the preset's baked instructions. |
model | no | Override the default model. |
temperature | no | Override sampling temperature (0.0–2.0). |
max_tokens | no | Cap completion tokens. |
The action output is a structured object:
{
"preset": "support_triage",
"model": "gpt-4o-mini",
"provider": "openai",
"content": "…the model's answer…",
"latency_ms": 812,
"usage": { "prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0 }
}Because a preset template is just a connector action, it runs anywhere a connector action runs — most commonly as a step in a workflow run. See workflow AI steps for how it slots into a DAG.
2. Tenant agent presets (versioned config)
A tenant agent preset is a reusable, tenant-owned agent configuration stored per
tenant and versioned. It captures the full agent runtime configuration — model,
provider, instructions, the tool set, per-tool approval requirements, output type, and
generation parameters (max tokens, temperature, top-p, and the loop bounds
max_tool_calls / max_requests) — so that a session or a workflow step can reference
a preset by id instead of inlining all of that. A chat session
records the preset it runs against via agent_preset_id; an ai_agent
workflow step resolves a preset (optionally pinned to a
version) at execution.
Every save mints a new version, so a PresetRef can pin an exact version — or use
version 0 to mean "resolve the latest."
The presets are managed through the AgentPresetService:
| Operation | Purpose |
|---|---|
CreateAgentPreset / UpdateAgentPreset | Author a preset; each write creates a new version. |
GetAgentPreset / ListAgentPresets | Read presets (latest version). |
DeleteAgentPreset | Soft-delete a preset. |
ListAgentPresetVersions / GetAgentPresetVersion | Walk the version history and fetch a specific version. |
A tenant preset requires a name, a model, and at least one tool; tool names must be unique within the preset.
Related
Inference Proxy
Ductor's provider-neutral inference vertical — unary and internal streaming paths, routing, circuit breakers, tenant budgets, usage, and provider credentials.
Agent Work Steps
The worker-side AI step types — ai_action for a single inference and ai_agent for an execution-bound agentic loop — that run inside a DAG workflow run.