Conversation Node

What Conversation is and why it exists

Conversation is the node where model inference happens. It is used for classification, extraction, synthesis, summarization, and multi-step reasoning. In NodeFox, Conversation is intentionally embedded in deterministic orchestration so model flexibility can be used without losing control over branch behavior.

Conversation is not a replacement for policy routing. It produces output; Decision and activation edges determine whether sensitive actions are allowed to proceed.

Execution behavior

Conversation consumes slot inputs and configuration context, calls the selected model/provider, and emits outputs to downstream slots. The node can work with free-text output or schema-constrained output. For production reliability, schema-constrained output is preferred when downstream branches depend on explicit fields.

When tools are enabled, Conversation may invoke workspace functions or MCP tools as part of completion. Tool usage should be bounded and observable so costs and side effects remain predictable.

Typical output semantics:

output slot 1: primary generated response
output slot 2: attachments/artifacts (when available)
output slot 3: full message history/context envelope

Provider and variant posture

Variant	Typical role	Notes
`Gemini`	fast general reasoning and extraction	Often used for cost-sensitive, high-throughput branches.
`ChatGPT`	broad general-purpose reasoning	Strong default for mixed-generation tasks.
`Claude`	analysis and long-form synthesis	Common for deeper reasoning and policy interpretation drafts.
`Grok`	search-connected model workflows	Useful where external freshness matters.
`Mistral`	multilingual and regional strategy paths	Useful for provider-diversity and localization.

Model/provider choice should be explicit per branch. Different branches can optimize differently for latency, cost, and quality.

Configuration areas and what they mean

Field	What it controls	Practical guidance
`Model`	Provider/model target	Keep model choice explicit per branch when latency, quality, or cost profiles differ.
`Instructions`	Behavioral system guidance	Keep instructions narrow, versioned, and domain-specific.
`Messages`	Prompt and context content (supports `$N`)	Build prompts from deterministic slots rather than ad-hoc concatenation.
`Max Tokens`	Output length and cost envelope	Use limits proactively to avoid runaway verbose outputs.
`Thinking`	Extended reasoning mode where available	Reserve for branches that benefit from deeper reasoning; monitor cost impact.
`Web Search` / `URL Context`	External retrieval behavior in supported models	Enable only where freshness is required and policy allows outbound retrieval.
`Tools`	Workspace function surfaces exposed to the model	Expose only optional tools for least-privilege operation.
`MCPs`	MCP servers and tool surfaces available at runtime	Scope MCP access by branch and risk profile.
`Tool Limit`	Maximum tool calls per interaction	Always set in production paths to cap cost and execution fan-out.
`Schema`	Typed structured output contract	Use whenever downstream logic depends on specific fields.

How schema changes runtime quality

Without schema constraints, Conversation output can be useful but harder to route safely. With schema, downstream nodes can evaluate explicit fields through Data and Decision patterns, which improves deterministic branching and reduces ambiguous parsing logic.

Schema does not eliminate model error, but it reduces ambiguity and improves recoverability when outputs are partially malformed.

Transform mode in schema-driven flows

Transform mode can project selected schema properties to sequential output slots. This lets teams run Conversation -> Decision/Data pipelines without manual response parsing.

Use Transform when:

only a subset of schema fields should drive routing
downstream branches need fixed slot contracts
you want to reduce post-processing in Code/Data nodes

Tool and MCP usage patterns

A robust pattern is to keep tool usage inside bounded branches and evaluate tool-derived outputs before external writes. For example, Conversation(with tools) -> Decision(confidence/policy) -> Writer(Activated) prevents tool calls from becoming implicit authorization for side effects.

If your workflow relies on multiple tools, define a clear fallback route for tool failure, timeout, or malformed response. Production incidents are often caused by missing fallback design rather than by model quality.

Operational checklist

Before promoting a Conversation-heavy workflow:

define schema contracts for decision-critical outputs
set Tool Limit and max token bounds per branch
separate low-risk generation from high-risk decision/act branches
enforce activation-gated Writer release for sensitive actions
monitor parse-failure rate, fallback-to-human rate, and per-run token variance

Common mistakes to avoid

A frequent mistake is overloading one Conversation node with too many responsibilities: classification, summarization, policy interpretation, and response generation all in one step. Splitting those concerns across multiple nodes usually improves explainability and testability.

Another common issue is unbounded tool usage with weak branch controls. Keep tool surfaces minimal, enforce limits, and route uncertainty through review paths.