Super Agent node

Purpose

The Super Agent node is an agent that plans and delegates. Instead of being handed a fixed list of tools by the builder, it discovers the published workflows in its own project and treats each one as a callable capability. Given a request, it decomposes the work, calls the capabilities it needs in the right order, and writes the final answer from what came back.

This is the difference between a workflow that does one thing well and a front door that routes across everything the project already automates. If your project has a leave-balance lookup, an expense-policy answerer, and a ticket-creation workflow, a Super Agent in front of them can take "I'm travelling next month, how much leave do I have and what's the per-diem?" and handle both halves without you ever authoring the branch.

When to use it

How it works

Capabilities

How a workflow becomes a capability

Every published use case in the project is turned into one tool:

• Tool name: derived from the workflow's slug, prefixed uc_ (for example uc_leave-balance), capped at 60 characters and de-duplicated with a numeric suffix if two slugs collide.
• Description: the workflow's own description, truncated at 1,024 characters. If it has none, the platform falls back to Run the '<name>' workflow.
• Parameters: the Start node's input schema from the pinned published snapshot, exactly as a direct caller would send it.

File and image inputs

A Start field typed file or image is exposed to the model as a string file_id, not as a file upload. The description tells the model to pass a file_id it already holds and never to invent one. When the call is made, the id is validated against the child's real schema with a project-scoped check, and the child resolves the file exactly as it would for a direct submission.

If a document is attached to the conversation, the Super Agent is told its file_id so it can hand the reference onward instead of retyping the content into the capability's arguments. Retyping silently loses content that neither side can detect afterwards.

Which workflows are excluded

A workflow in the project will not appear as a capability if any of these apply:

Every one of these is recorded on the execution, with its reason. See What the debugger shows.

Turning capabilities off

The Capabilities section of the properties panel lists every workflow in the project. Published ones carry a callable badge; click it to switch that workflow off for this Super Agent. Unpublished ones show not published and can't be toggled.

This is a deny list scoped to the node, which has two useful consequences:

• Two Super Agents in the same project can each expose a different subset.
• A newly published workflow is callable immediately, with no reconfiguration. If you don't want that, switch it off explicitly.

What happens on a capability call

Each call is validated and recorded before anything executes:

Budgets

Two limits bound what one run can spend:

• max_capability_calls (default 10) is a run-wide counter across the whole loop. When it's exceeded, the next call returns Capability call limit reached (N). Answer with available information. and the model is expected to conclude. Setting it to 0 disables capabilities entirely: nothing is exposed to the model at all, and the node becomes a plain instructions-driven agent.
• capability_timeout_minutes (default 15) is the ceiling on a single child workflow.

The delegation protocol

Beyond your instructions, the platform appends a fixed set of delegation rules to every Super Agent's prompt. You don't write these, and you can't turn them off. They exist so builders don't have to rediscover them:

• One goal per call. Keep enumeration (listing candidates) separate from interpretation (choosing and reading one).
• Each call is self-contained. The capability cannot see the conversation or the agent's other calls, so every detail it needs must be in the arguments.
• Pass ids forward. When a result includes an id, the exact id goes into follow-up calls instead of a re-description.
• A "not found" is one data point, not a conclusion. The agent must retry with a genuinely different angle (a different field, a wider range, an alternate spelling) before reporting failure.
• Results accumulate, they don't replace. If a retry returns less than an earlier call did, the agent answers from the earlier result and says which one it used.
• Never pretend. If no capability fits part of the request, the agent says so and names the capability that would be needed.

Long-term memory

When Memory is on (the default), the Super Agent remembers things about the signed-in user, scoped to this specific node in this project. It is written only by a post-run pass. The agent never writes memory mid-task.

What is remembered

Guardrails

Memory on a Super Agent is deliberately conservative, because the failure mode is severe: a remembered "fact" read as authoritative data means the agent answers directory and policy questions from a stale note instead of calling the capability.

• Memory is advisory, never evidence. It is fenced in the prompt and explicitly labelled non-authoritative. The agent is instructed to use it for tone, format and preference only, never to answer a factual question from it, and to re-verify with the capability and trust the capability's answer if a note contains a fact it is about to assert.
• Facts require verification. If a run made no successful capability call, it verified nothing, and the store pass is blocked from writing a fact at all. Preferences and corrections come from the user's own words, so they're always allowed.
• Facts age out of the prompt. A fact older than 30 days stops being injected. The row stays for audit; only the prompt is bounded.
• Episodes are an audit trail, not answers. Each line records that a capability ran, never that its answer is still known. The results are not retained anywhere. A run that called nothing is recorded but withheld from future prompts, because "this question was answered with no retrieval" reads as precedent and compounds.
• Caps. Up to 100 entries and 10 episodes per user per node, each entry up to 1,000 characters.

Everything is inspectable in an execution's Debugger → Memory tab.

Choosing which memory a Super Agent uses

A Super Agent can draw on the platform's own memory store, on an external context provider, on both, or on neither.

Leave it unset and MagOneAI infers it from what is configured: memory on with a provider means both, memory on alone means internal, a provider alone means external, and neither means none.

External context providers

A context provider is an external HTTP service a Super Agent may consult for extra context before a turn, and report to afterwards.

The platform deliberately does not know what a provider is for. It knows how to ask a configured endpoint for advisory text before a turn, and how to report what happened after one. Memory is the first thing built on it, but a deployment can implement the same two endpoints for something else entirely, or configure none and see no change.

The contract is two calls:

Configuration:

Attachments and structured data

A Super Agent handles chat attachments the same way an Agent node does:

• Documents are extracted and fenced into the system prompt as attached content.
• Spreadsheets and CSVs register a __query_<dataset> SQL tool backed by DuckDB. The agent is instructed to answer any counting, summing, averaging, grouping, ranking, or lookup question by running SQL and using only the returned rows, never by estimating from prose.
• When a tabular file is attached and you've left max_iterations at its default, the budget is floored at 25 iterations, because a schema peek, a query, a refine and an answer all compete with capability calls.

The Super Agent also gets the __query_blackboard recall tool when the deployment has harness retrieval enabled, so it can pull back the full body of an earlier capability result. See Execution artifacts and the Debugger.

Context compression

The agent loop summarizes its own history when that history grows past a character threshold. For a Super Agent this matters more than for a normal agent, because compression replaces the message list with a short summary rather than trimming it, so capability results gathered before it runs are gone, and the evidence the answer was built from goes with them.

The Advanced → Context compression threshold field controls this:

Inputs and outputs

By default the previous step's output flows in automatically, and the node produces one text field called response. Downstream nodes reference it as:

<node-id>.response

The panel shows the exact reference for your node.

You can replace either default with a declared contract.

Declared inputs

Declaring input fields replaces the automatic chaining from the previous step. Each declared field names where its value comes from, so the node reads exactly what you point it at rather than whatever happened to arrive.

{
  "input_fields": {
    "question": { "source": "input.message" },
    "account_tier": { "source": "lookup-account.tier" }
  }
}

Two rules are enforced when you save, both because getting them wrong is silent:

Declared outputs

Declaring output fields replaces the single response field. Each one becomes its own path downstream, so a Condition node can branch on one value without parsing prose.

One declared field can still be answered as prose, because the loop can return its raw reply under that field's name. Two or more cannot, so a multi-field contract requires structured output.

Configuration reference

Workflow JSON

{
  "id": "support-super-agent",
  "type": "orchestrator",
  "config": {
    "name": "Support Super Agent",
    "instructions": "You help employees with IT and HR questions. Confirm the employee's office location before quoting any location-specific policy.",
    "llm_config_id": null,
    "max_iterations": 20,
    "timeout_minutes": 60,
    "max_capability_calls": 10,
    "capability_timeout_minutes": 15,
    "memory_enabled": true,
    "disabled_capability_ids": [],
    "context_compression_threshold": null
  }
}

Timeouts and nesting

• The loop's timeout is clamped to the parent workflow's own ceiling minus five minutes of headroom, so a configured value larger than the deployment's workflow timeout produces a clean Super Agent timeout rather than an opaque parent failure.
• Capability children are cancelled if the Super Agent is cancelled.
• Nesting is capped at 5 levels across the whole chain, and a use case already in the chain cannot be re-entered.

What the debugger shows

The Super Agent is deliberately not a black box. Its step's input snapshot records:

• capabilities_visible: every tool the model could see this run, with the workflow name and id behind each.
• capabilities_skipped: every other workflow in the project and why it was excluded, using the reasons in the table above.
• memory_entries_injected and episodes_injected: how much remembered context was in the prompt.

Each capability call also produces its own child execution and audit row, so you can open the child run and see exactly what it received and returned. If the deployment captures artifacts, each capability result is also written to the Blackboard as a sub_agent_result, queryable alongside the agent's own tool results.

Best practices

Limitations

• No human tasks inside a capability. A workflow containing a Human Task node can't be a capability, because a capability call runs to completion rather than pausing for input.
• No Super Agent calling a Super Agent. Orchestrator nodes are excluded from discovery.
• Same project only. Discovery never crosses project boundaries.
• A declared contract is re-validated at run time. Declared inputs and outputs are checked against the published version on every execution, so rolling the platform back after you save one turns that node's runs into a configuration error. See Inputs and outputs.
• 50 capabilities per node. Beyond that, workflows are skipped with over capability cap.

Next steps