update_workflow

Update an existing workflow. Recommended flow for agent-driven edits For editing an existing workflow step-by-step, prefer the per-step tools — they catch errors incrementally and avoid the bulk-JSON vocabulary traps (ai / integration / knowledge_graph_query, silently-stripped root fields like prompt / listKey / appId): - update_step({ workflowId, stepId, updates }) — change one step (prompt, inputs, next, etc.). Safest and most common. - add_step({ workflowId, step, insertAfter? }) — append or insert a new step. - remove_step({ workflowId, stepId }) — delete a step and re-wire its neighbors. - After a series of edits: validate_workflow → (if live) promote_draft / discard_draft. The bulk updates param below is supported for imports, templated rewrites, and programmatic round-trips (export → edit JSON → re-import). Agents editing interactively should not use it for step changes — use update_step instead. Trigger type guidance Prefer schedule (polling) for email intake, document processing, and any workflow where exact-millisecond latency is not required — it is idempotent, supports backfill, and needs no webhook infrastructure. Use app_event or webhook only when the user explicitly says "as soon as", "within X seconds", or "real-time". When in doubt, schedule wins. Draft routing (live workflows) If the workflow is live, config edits (steps, context, name, etc.) are automatically routed to a draft snapshot instead of modifying the live pipeline. The response will include editingDraft: true. Use get_draft to view the draft, promote_draft to make it live, or discard_draft to throw away the changes. Non-live workflows are updated directly with an automatic pre-edit snapshot for rollback. Bulk updates param (imports / round-trips only) ⚠️ Avoid sending a full steps array for large workflows — use update_step instead. Sending more than ~20 steps risks silent truncation at the MCP transport layer. Full steps array replacement is only safe when doing a complete pipeline replacement from a known-good JSON source (import, template, export round-trip). For editing individual steps, always use update_step. context merge semantics (read before patching) Root level: updates.context is shallow-merged with the stored workflow’s context ({ ...existingContext, ...patchContext }). Sibling keys at the root (inputPages, outputPages, executionInputConfig, etc.) do not clobber each other: omitting a key preserves the stored value; only keys present in the patch are overwritten. To clear a collection explicitly, send an empty value (e.g. inputPages: []). Silent deletion-by-omission no longer applies at the root — same spirit as update_step’s deep-merge for nested step fields. One level down: Each value under context is still replaced wholesale when the patch includes that key. For example, context: { executionInputConfig: { someKey: "x" } } replaces the entire executionInputConfig object — any sibling fields under it (e.g. defaults, fields, internal) that are not in the payload are dropped. To partial-patch a nested object, get_workflow first, merge the current value with your changes client-side, then send the full merged object for that key in update_workflow. Surgical alternative (preferred for context/metadata): update_workflow_context is the workflow-level analog of update_step — it accepts the same three explicit verbs (updates / replace / unset) on workflow-relative paths under context.<anything> (both page schemas like context.inputPages AND user-saved page values like context.outreachProfile) and metadata. Returns diff + warnings. Use it instead of bulk update_workflow for any context or metadata edit, including pre-filling configuration input pages programmatically (e.g. updates: { context: { outreachProfile: { name: "Alberto", signature: "..." } } }). To flip a single nested key like executionInputConfig.internal, fetch with get_workflow first, merge locally, then updates: { context: { executionInputConfig: {...full merged...} } }, replace: ["context.executionInputConfig"] — the same merge-order trap as update_step applies (deep-merge runs before replace[], so replace at the parent level). Internal-only workflows Set context.executionInputConfig.internal: true to mark a workflow as a child / sub-workflow that runs only via agentled.call-workflow. The UI hides the Run button and replaces the manual run form with a banner; orchestrators still pass inputs via executionInputData (UI guard, not runtime restriction). Use for child workflows that end in a return step. To toggle on an existing workflow, fetch the current value with get_workflow, then call update_workflow_context with the explicit ops shape replacing at the parent level: updates: { context: { executionInputConfig: {...merged...} } }, replace: ["context.executionInputConfig"].. It is categorised as a Write tool in the Agentled MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

Register the Agentled MCP server in PolicyLayer and add a rule for update_workflow: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Agentled. Nothing to install.

update_workflow is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Yes. Add a rate_limit block to the update_workflow rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for update_workflow. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

update_workflow is provided by the Agentled MCP server (@agentled/mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.