Skip to content

Agent workflows

A model per step, one policy over all.

A useful agent retrieves, queries, calls other systems and decides. mAIstro composes those steps with the model, guardrails and run record attached to each.

Talk to an engineerBrowse the connectors

The node

A maintained primitive, not a plugin.

One step: retrieve, call a model, query a system, transform, branch, loop. Each node in the function library ships with the platform and is supported as part of it, so it behaves the same in every deployment. Read this one top to bottom.

console › maistro › agent editor
The mAIstro agent editor showing a support-ticket triage agent: a Text input, then a row of Protect, Profanity Filter and Remove PII nodes ending in a Set a Variable; a Condition row that writes a blocked notice and stops; two Send To LLM rows for category and urgency; a Seek row; a Condition row calling a child mAIstro agent; a Condition row drafting a reply; and a final Text node.
The agent editor: a support-ticket triage agent. Nodes stack top to bottom and chain left to right; the Text node at the foot assembles the triage record from everything the run set.

How it composes

Three levels, and they nest.

The same primitive at every level, which is what lets a workflow built for one team become one step of another team's.

  • The node

    One step, with its own settings: which model, which source, which threshold. Written in the editor or as a line of template language — the same object either way.

  • The agent

    Nodes stacked into a flow or chained sideways, with conditions on results, loops where they are needed, and independent steps running in parallel so the run takes as long as its slowest node.

  • The multi-agent

    Agents calling agents — in the same variable space, or sandboxed to return only their output — and a registry from which an orchestrator selects the right agent, or an ordered plan of them, for the task.

Runs you can replay

Every run is a record.

Each execution is logged. The inspector drills into every step — what was set, when, and how it was processed — and Governance shows invocations, median and tail latency, guardrail activations and the tree of child agents each run called.

Every step, inspected

console › governance › agent details
The Agent Details view under Governance for one agent: invocation and latency tiles across the top, and beneath them the invocation tree showing which child agents each run called.
Agent Details under Governance: latency percentiles per agent, and the invocation tree beneath.

After a run

Inspect it, map it, read it as code, schedule it.

The editor is one tab. The others show what a run did, how agents call each other, the same agent as text, and when it runs itself.

  • console › maistro › inspector
    The mAIstro Inspector with steps expanded: a model step listing step time, prompt, cache, token counts, LLM time and its output, followed by uppercase, variable and condition steps with theirs.
  • console › maistro › inspector
    The Inspector's Timeline tab: the PII step selected, its variables and output above, and the run's steps laid out on a time axis with parallel spans for a sandboxed child call, a Seek and the model calls.
  • console › maistro › visualizer
    The Visualizer tab: a graph of support agents — intake and digest agents feeding an orchestrator, a triage agent fanning out to sentiment, knowledge-gap, review, translation and escalation agents, then ticket and alert drafts — with a legend in the corner.
  • console › maistro › ntl
    The NTL tab: the support-ticket agent as lines of NeuralSeek Template Language with syntax highlighting, the function library on the left and an empty Agent Output panel below.
  • console › maistro › scheduler
    The Scheduler tab: a table of schedules with agent, last run, next run in UTC, description and an Enabled switch per row, and a Select or Create a Schedule panel beneath.

Slide 1 of 5

01 / 05

Inspector: step by stepThe mAIstro Inspector drills into each step of a run — what was set, when, and how it was processed. A model step shows its prompt, cache setting, token counts, model time and output; a value masked by Remove PII appears masked here too.

What you control

Composition is the easy half. These properties decide whether a working prototype is allowed near production data.

  • A model per step

    Model choice exists at three levels: the functions each configured model serves, a per-node override inside the flow, and the model id you pass on an API call. A fast model classifies; a stronger one synthesises.

  • Unattended where you say so

    An agent runs when called from the API, or on a schedule you set by minute, hour, day or month. Which agents run themselves and which wait for a request is a setting, not a convention.

  • The same guardrails, mid-flow

    Prompt-injection protection, PII removal and the profanity filter are nodes you place inside a workflow, not just a perimeter around it. A retrieved document or a tool result is screened the same way a question is.

  • Models compared, not guessed at

    Select models, enter a question, and compare their results side by side, with token cost and generation speed recorded alongside — under Seek governance and under mAIstro governance alike.

  • Adversarial testing per agent

    Point Red Team Testing at a specific agent and run it on demand. It reviews the agent's security posture, the risks it found, the test evidence and recommended mitigations — repeatable after every change.

Three questions before you build the first one.

Each is a reason teams abandon an agent framework six months in, so they are worth answering up front.

  1. Is this a visual builder, or real code?

    Both, over the same object. A flow built in the editor reads as template language and back, and the language is a deliberate abstraction: what would be glue code elsewhere is one node a reviewer can read.

  2. Do we start from an empty canvas?

    Only if you want to. Describe the agent in plain language and the auto-builder drafts it, or open a marketplace template and point it at your data. Every node stays visible and editable; change one and it is your agent.

  3. What happens when we have hundreds of these?

    That is when governance stops being optional, so the run record is a platform feature, not something each team wires up. Every run is logged, latency is broken down per agent and child call, and tokens and cost are tracked.

See it running inside your own boundary.

Talk to a NeuralSeek expert about how it fits your stack, where your data has to live, and the governance your auditors already expect.

Request a demo