starred/windmill
1
0
Fork 0
mirror of https://github.com/windmill-labs/windmill.git synced 2026-09-21 00:02:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

refactor: tag enabled_tools and drop the memory step input

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
hugocasa
2026-09-11 21:26:21 +02:00
co-authored by Claude Opus 5
parent 76e70d6a8f
commit 38e80bbb26
20 changed files with 179 additions and 247 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reusable-ai-agents.md
+7 -10
View File
@@ -2,7 +2,7 @@
An AI agent flow step can be saved as a **reusable agent** — a resource of the built-in
`ai_agent` resource type that bundles the agent's brain (provider/model, system prompt,
temperature, output schema…) and its tool set. Other flows can link to the same
temperature, output schema, memory…) and its tool set. Other flows can link to the same
agent, and edits to the agent propagate to every linked step.
The `ai_agent` resource type is defined in the hub (windmill-integrations) and synced into
@@ -16,14 +16,11 @@ every workspace via the standard cached-resource-type sync, like other built-in
- The brain config and tools are resolved at runtime from the resource
(`windmill-worker/src/ai_executor.rs`): the brain is interpolated, so a nested provider `$res:`
credential resolves automatically.
- The step keeps only the flow-local inputs (`user_message`, `user_attachments`, `memory`,
`enabled_tools`) in its own `input_transforms`; the brain and tools stay in the resource
(read-only in the step). `memory` is one of them because a conversation belongs to the flow
having it, not to an agent reused across flows: it is identified by a `memory_id` minted per
step on flow save, so two flows linking one agent cannot answer from each other's history.
`enabled_tools` names the tools of the roster this step may call, narrowing one use of a shared
agent without touching the agent. An agent saved before `memory` moved still carries one, which
the worker honours while the step sets none; unlinking such an agent copies it onto the step.
- The step keeps only the flow-local inputs (`user_message`, `user_attachments`, `enabled_tools`)
in its own `input_transforms`; the brain and tools stay in the resource (read-only in the step).
`enabled_tools` says which of the roster this step may call, narrowing one use of a shared agent
without touching the agent: `{kind: 'all'}` as an absent field does, `{kind: 'only', tools: [...]}`
for a list, tagged like `memory` so the form reads it the same way.
- The agent carries its tools' default input bindings verbatim as authored (static, AI-filled,
or flow expressions), so saving round-trips losslessly. Each host flow overrides what it
needs: `tool_inputs` stores per-tool overrides (a diff from the resource tool's own
@@ -51,7 +48,7 @@ A flow does not wait for that deploy to see the draft:
- Testing the flow, or a single linked step, runs the draft. `runFlowPreview` and `ModuleTest`
substitute each linked step for the standalone step the draft would run as
(`linkedAgentDrafts.ts`): `agent` cleared, the draft's brain as static input transforms, the
draft's tools on the step, and the step's own `user_message`/`user_attachments` kept on top —
draft's tools on the step, and the step's own flow-local inputs kept on top —
the same overlay order `ai_executor.rs` applies to a linked step. `tool_inputs` is untouched,
since the worker overlays it in both branches.
- The step's linked card and the graph's tool nodes show the draft, with a *Draft* badge, so the