FluidGrids
AI Automation4 illustrations

AI Agents and Conversational Workflows

An agent node with pluggable model, memory, tool and parser ports, driven by chat and traced tool call by tool call.

These images are illustrations of the concept, not screenshots of the actual product.

Overview

AI Agents and Conversational Workflows covers the design for putting a reasoning step inside an ordinary automation graph. Rather than hiding the model behind a black box, the concept draws the agent as a node with visible ports — one for the chat model, one for memory, one for tools, one for the output parser — and lets each port be filled by a separate card on the canvas that anyone can inspect and swap.

The problem is trust. An agent that decides which system to call and what to do next is useful precisely because it is not fully scripted, which is also what makes it hard to operate. Teams need to see which model answered, what it remembered, which tools it was allowed to touch, how its free-form answer was turned back into structured fields, and exactly which calls it made on a given run before they will let it act on real orders or real customers.

The four illustrations follow that arc. First, an agent node on the canvas fans out to adapter cards for the model, a per-session memory store, an HTTP tool, a sub-workflow tool and a structured parser, while a side panel exposes the agent's standing instructions, agent type, model choice, sampling controls, timeout and tags. Second, a retrieval step is wired in front of the agent so answers are grounded in a knowledge collection, with the collection, query binding, result count, similarity metric and score threshold all configurable and a preview of scored matches. Third, a chat panel sits beside a live workflow so a person can talk to the automation and watch the same graph handle escalation through a decision node. Fourth, a run trace expands the agent step into the individual tool calls it made, with durations, iteration and token counters, and a structured record of each call and its observation.

Because the agent is just another node, the rest of FluidGrids applies unchanged: the workflow is versioned and published, credentials come from stored connections, decision nodes and connector nodes handle everything around the reasoning step, and every execution lands in run history.

What this concept shows

  • An agent node drawn with labeled ports for chat model, memory, tool and output parser, each wired to its own adapter card on the canvas
  • Adapter cards for a named chat model, a per-session memory store with a time-to-live, an HTTP tool bound to an API route, a sub-workflow tool and a structured parser that emits typed fields
  • A configuration panel with standing instructions and character counter, agent type, model selector, temperature slider, token cap, timeout and tags
  • A retrieval step in front of the agent with collection, templated query, result count, similarity metric, score threshold, vector store and embedding model settings
  • A preview of scored retrieval matches so the grounding data can be checked before the agent sees it
  • A docked chat panel that drives a live workflow, with message history, timestamps, a typing indicator and a per-session memory indicator
  • A decision node that routes low-confidence or high-priority conversations to a human escalation channel
  • A run trace that nests each tool call under the agent step with durations, plus iteration, token and attached-tool counters and a structured step record

How it works

  1. Drop an agent node onto the canvas between a trigger and whatever should happen next.
  2. Attach adapter cards to the agent's ports: a chat model, a memory store, the tools it may call, and a parser that turns its answer into structured fields.
  3. Set the agent's standing instructions, type, model, sampling controls and timeout in the configuration panel, and tag it for the catalog.
  4. Add a retrieval step ahead of the agent, point it at a knowledge collection, tune result count and score threshold, and check the previewed matches.
  5. Open the chat panel and converse with the workflow, letting a decision node escalate to a human channel when priority or confidence calls for it.
  6. Open the resulting run and expand the agent step to read every tool call, its duration and its observation, then re-run if needed.

Who it's for

  • Support and service operations teams automating triage and first-line answers
  • Automation engineers who need agent behavior to be inspectable rather than opaque
  • Product teams adding a conversational front door to an existing back-office process
  • Platform and AI leads deciding which models, tools and data an agent may reach

Illustrations

4 illustrations of this concept. Select one to view it full size.

Agent Node With Model, Memory, Tool and Parser Ports

The agent node fans out to its model, memory, tool and parser adapters, with settings on the right.

The concept shows a published order-triage workflow on the builder canvas, with undo and redo controls, a zoom readout, a test-run button and a publish action along the top. A chat trigger feeds a large agent node described as a conversational agent that triages orders and decides next steps. Four labeled ports run along the node's lower edge — chat model, memory, tool and output parser — and dashed connectors drop from each to its own card: a named chat model, a per-session memory store with a one-hour time-to-live, an HTTP tool bound to an order lookup route, a sub-workflow tool for cancellation, and a structured parser emitting category, severity and action. The agent's output continues into a decision node with true and false branches. A right-hand panel holds standing instructions with a character counter, agent type, model, temperature, token cap, timeout and tags.

Retrieval Step Configured Ahead of the Agent

A similarity search node grounds the agent, with collection, top-k, metric and threshold settings.

This illustration shows a draft second version of a support answer workflow, with save, test-run and activate actions in the header. A left palette groups nodes into triggers, flow control, AI and databases. On the canvas a chain runs from a chat trigger into a selected vector similarity search node, then a data-shaping step that builds the prompt, then the agent node with its four port labels, and finally a message-posting node; a chat model card hangs below the agent. A small callout explains that, in this design, the vector store joins the chain as an ordinary step rather than plugging into an agent retrieval port. The properties panel sets the collection, binds the query to the incoming message with a template expression, sets the number of results, the similarity metric and a score threshold, selects a vector store and embedding model, and previews three scored sample matches.

Chat Panel Driving a Live Workflow

A conversation on the right drives the trigger, agent and escalation path drawn on the left.

The design pairs a compact canvas with a docked conversation. On the left, an active support assistant workflow runs from a chat trigger, described as firing when a user sends a message, into an agent node that processes the request, then into a decision node checking priority and confidence; its yes branch leads to a node that escalates into a team channel. Share and deploy controls sit in the header, with a minimap, zoom readout and canvas lock below, and a plan usage meter in the left navigation. The right panel shows a sample exchange: a request for a summary of the day's orders with anything above a threshold flagged, and a reply listing sample counts and values as bullets with a flagged line beneath. A typing indicator, a message composer with a send shortcut and a per-session memory note complete the panel.

Run Trace Expanding Every Agent Tool Call

A succeeded chat-triggered run with each agent tool call nested under the agent step.

This illustration shows a single run opened from run history. A header carries the run identifier, a succeeded badge, the workflow version, total duration and the trigger type, with re-run and cancel actions. The left column lists the node timeline: a chat trigger, the agent step highlighted with its own duration, and a final message-posting step, each with a success marker. Nested under the agent are the individual tool calls it made in order — an HTTP order lookup, a database query, a sub-workflow approval and a message post — each with its own elapsed time. The right column is titled agent output and leads with three counters for iterations used against a cap, tokens consumed and tools attached, followed by a structured record listing each step as a tool and observation pair, with a note beneath the panel stating that the tool calls were executed by the workflow engine.

Topics

  • AI agent node
  • conversational workflow
  • chat trigger automation
  • agent tools and memory
  • retrieval augmented workflow
  • vector similarity search node
  • agent run trace
  • structured output parser
  • human escalation routing
  • support triage agent

Related concepts

All FluidGrids concepts
Get started freeBrowse all concepts

We use cookies for essential site functions and, with your consent, for analytics to improve FluidGrids. We don't use advertising or cross-site tracking cookies. See our Cookie Policy.

Preferences