Agent Parameters¶

Every agent in Tryll is created by a single wire frame: CreateAgentRequest. This page documents every field on that request, grouped by what it controls:

The graph the agent will run.
The fallback model every Generate node uses by default.
Diagnostics.

The authoritative source for every shape below is the wire protocol.

Changing parameters after creation

Many node parameters can be updated after the agent is created and while it is idle. See Change Agent Parameters at Runtime for the full list and API examples.

Overview¶

Field	Type	Required	Default	Description
`request_id`	uint64	Yes	—	Client-assigned correlation id. Echoed on `CreateAgentResponse` and on any `ErrorResponse` replacing it.
`graph`	`GraphDescription`	Yes	—	The workflow graph. See Graph.
`default_model_name`	string	No	`""`	Fallback model name for Generate nodes that do not set their own `model_name` param. Empty = no default; every Generate node must supply its own.
`enable_diagnostics`	bool	No	`false`	When `true`, the server serialises per-node execution data into `TurnComplete.debug_info`.

A CreateAgentRequest is rejected with error 3003 GraphCompilationFailed if any validation rule below fails.

Graph¶

GraphDescription carries the full topology of the agent's workflow.

Field	Type	Description
`nodes`	`[NodeDescription]`	List of every node in the graph. At least one.
`start_node`	string	Name of the node where execution begins. Must match a node in `nodes`.

Wiring between nodes is encoded in each node's typed params object, not in a separate list. Each declared exit has a corresponding <exit_name>_exit field (e.g. default_exit, triggered_exit). An empty string routes the turn to END. A non-empty string must name another node in nodes — the server rejects graphs where an exit field names a missing node with error 3008 InvalidExitTarget.

`NodeDescription`¶

Field	Type	Description
`name`	string	Node instance name. Unique within the graph. Also the default `source` label on Retrieve.
`params_type`	union tag	Selects the typed params table variant (`GenerateParams`, `HumanMessageGuardrailParams`, etc.).
`params`	typed table	The typed params table for this node type. Contains configuration fields (model name, prompts, …) and exit fields (`default_exit`, `triggered_exit`, …). Each node's reference page lists all available params and exit fields.
`tools`	`[ToolDefinition]`	Tool schemas. Used only by `ToolCall` nodes; ignored by all others.

`ToolDefinition`¶

Field	Type	Description
`name`	string	Tool name exposed to the model.
`description`	string	Short description shown to the model as part of the tool prompt.
`parameters`	`[ToolParamDefinition]`	Parameter schema for the tool.

`ToolParamDefinition`¶

Field	Type	Description
`name`	string	Parameter name.
`type`	string	Type hint as a string (e.g. `"string"`, `"integer"`). Model-facing only; the server does not validate arguments.
`description`	string	Short description of the parameter.

See Tool Call node and the tool-calling concept page for how the server uses these definitions.

Default model¶

default_model_name is a fallback used by Generate nodes that omit their own model_name param. Leaving it empty is legal — every Generate node must then supply model_name itself; at least one node missing both results in a compilation failure.

Naming resolves against the model catalog (models.json). The server loads the model on demand if it is not already resident; see model management.

Diagnostics¶

When enable_diagnostics = true, every TurnComplete that ends successfully carries a JSON string in debug_info with:

Per-node entry / exit events, in execution order.
The exit route taken at each branching node.
The prompt passed to each Generate node (on servers where this is enabled).

When the server-side include_interaction_in_diagnostics flag (in server-config.json) is also set, debug_info additionally carries the interaction's knowledge components, each as a flat JSON object with a "_type" discriminator.

The default is false — no diagnostics, zero overhead. Flip it on for debug sessions only; payloads grow linearly with graph size and knowledge component count.

See How to define and handle tool calls for a worked example that turns diagnostics on to inspect the tool-call detection path.

Minimum working example¶

PythonC++Unreal

# Minimal agent with no Retrieve nodes
from tryll_client.graph import GraphDescription, GenerateParams

graph = (
    GraphDescription()
    .add_node("answer", GenerateParams())
    .set_start_node("answer")
    .set_default_model_name("My Local Model")
)

agent = client.create_agent(graph)

using namespace Tryll::Client;
using namespace Tryll::NodeParams;

GenerateParamsT gp;
// default_exit defaults to "" (END)

GraphDescription graph;
graph.AddGenerate("answer", std::move(gp))
     .SetStartNode("answer")
     .SetDefaultModelName("My Local Model");

auto agent = client.CreateAgent(graph);

UTryllGenerateParams* P = UTryllNodeParamsFactory::MakeGenerateParams(this);
// DefaultExit defaults to TEXT("") (END)

FTryllGraphDescription Graph = FTryllGraphBuilder()
    .AddNode(TEXT("answer"), P)
    .SetStartNode(TEXT("answer"))
    .SetDefaultModelName(TEXT("My Local Model"))
    .Build();

Or author the equivalent inside a UTryllWorkflowAsset and assign it to the UTryllAgentComponent.

For an agent with Retrieve + Mustache template, see How to create a simple RAG assistant and How to use Mustache templates.

Client bindings¶

C++: Tryll::TryllClient::CreateAgent + Tryll::Client::GraphDescription — TryllClient.h, GraphDescription.h
Python: tryll_client.TryllClient.create_agent + tryll_client.GraphDescription — client.py, graph.py
Unreal: UTryllAgentComponent::CreateAgent / FTryllGraphDescription / UTryllWorkflowAsset — TryllGraphDescription.h