Skip to content

Agents

In Flow, agents are governed AI personas for chat and automation. You configure each one in Admin → Agents with its own model, tools, skills, and Knowledge Graph boundaries. Every tool call is audited; every agent runs inside the permissions you set.

Agent definitions follow the open AGENTS.md pattern. You can edit each agent as a structured form or as one raw document; both views produce the same portable definition your team can version, review, and adapt for production.

Fontana ships ready-to-use agents you can tailor for your organisation:

  • Fontana agent (fontana-agent) - top-level default chat agent for unmapped routes and general routing.
  • Page agents - one primary agent per major Flow surface (for example workflow-agent on /workflow, kg-agent on Knowledge Graph, skills-agent on Skills, plus placeholders for dashboard, files, admin routes, and more). New threads start as the agent for the page you are on.
  • Canvas agent - specialist for building and editing workflow graphs (nodes, edges, ports, and canvas config). It remains a sub-agent of workflow-agent, typically invoked by delegation.

When you send a message from a different page than the thread’s current owner, Flow switches the thread to that page’s agent automatically. Intentional non-page transfers still use handoff (chat_handoffThread) to allowlisted agents. Chat history is per-user across pages (not siloed by workflow).

On Skills, skills-agent can manage namespaces, packages, and files with the same RBAC as the Skills UI. Page selection (namespace, folder, file) is sent as structured chat context. When you ask to open a named skill, Fontana agent and dashboard agent resolve it via the skill catalog and navigate to that skill’s SKILL.md (not only the Skills home page).

You can clone these defaults, adjust prompts and tool allowlists, and assign additional Skills as your operating model requires.

In Admin → Agents, you control how each persona behaves in production:

SettingWhat you control
Id and display nameStable identity and the label users see in chat
Description and system promptShort summary plus Markdown instructions that define tone, scope, and operating rules
Language modelApproved model override; leave empty to use the deployment default
ToolsAllowlisted entries from the audited catalog; see Tools and MCP
ScopesWhere the agent may run (for example Flow chat vs internal programmatic calls)
Sub-agentsDelegation targets that run work in child threads
Handoff agentsSame-thread transfer targets when the conversation needs a different specialist; see Agent Interop
SkillsAssigned agentskills.io packages (SKILL.md folders); catalog + on-demand activation; see Skills
Knowledge Graph namespacesWhich governed corpora the agent may search and retrieve
Vector sourceKeywords that help route and discover this agent and related workflow templates
Call settingsOptional JSON for temperature, topP, maxOutputTokens, and related LLM parameters
Reasoning effortAgent default; per-thread chat controls can override
Context window slotsHow much recent transcript the agent keeps in context; per-thread overrides available
KB injection score thresholdMinimum similarity score for automatic Knowledge Graph injection on each turn; per-thread overrides available

Agents receive Knowledge Graph context in two ways, described fully on Knowledge Graph:

  • Automatic pre-turn injection - fast vector search over assigned namespaces before each message, so likely-relevant approved documents are already in context.
  • Agentic search - during the work, agents can search again, explore ranked matches, and pull full text only for documents that support the current step.

You assign namespaces per agent so regulated corpora stay segregated and retrieval stays least-privilege.

Agents can search community workflow templates by semantic similarity and, with user consent, read workflow configuration from the canvas. That lets assistants help you design and refine pipelines with awareness of graph structure, node types, and connections.

Runtime execution data is queried separately from canvas configuration, so design assistance and live run results stay strictly separated.

Complex work can span multiple agents without losing governance:

  • Sub-agents run delegated tasks in child threads while the parent conversation continues under audit.
  • Handoff transfers the same thread to another in-app agent when the task surface changes (for example from planning to canvas editing).

Peer-agent federation with external platforms uses separate interop protocols. See Agent Interop for A2A, ACP, and related patterns.