Runtime and events
Understand how Runiq executes tools and streams tool events.
Tool execution is part of the agent runtime.
Runiq sends attached tool schemas to the provider with the agent request. If the model requests a tool call, Runiq executes the typed .NET tool and returns the result to the model for continuation.
Runtime flow
| Step | What happens |
|---|---|
| 1 | The user sends a message to an agent. |
| 2 | Runiq builds the provider request with the agent instructions and attached tool schemas. |
| 3 | The model either answers directly or emits a tool call with JSON arguments. |
| 4 | Runiq deserializes the JSON arguments into the tool input type. |
| 5 | Runiq creates the tool instance through DI and calls ExecuteAsync. |
| 6 | Runiq serializes the typed output to JSON. |
| 7 | The output is returned to the model for continuation. |
| 8 | The agent produces the final assistant response. |
The tool result is not the final answer. It is context for the model to continue.
Stream events
When an agent calls a tool, Runiq can emit stream events:
| Event | Meaning |
|---|---|
tool_call_started | The model requested a tool and produced arguments. |
tool_call_completed | The typed .NET tool completed and returned JSON output. |
tool_call_failed | Tool input or execution failed. |
assistant_delta | The assistant streamed response text. |
completed | The agent run completed. |
failed | The agent run failed. |
The dashboard can show the tool name, call id, arguments JSON, output JSON, error code, and error message. This makes tool behavior inspectable instead of hidden inside a prompt.
Error behavior
Runiq reports tool failures with structured error codes.
| Error code | Typical cause |
|---|---|
ToolNameRequired | The requested tool name was empty. |
ToolNotFound | The tool is not registered or not attached to the agent that tried to call it. |
ToolInputInvalid | The model produced JSON that could not be deserialized into the input type. |
ToolExecutionFailed | The tool implementation threw an exception. |
Validate input early and fail clearly.
Clear failures are better than fake fallback data. The dashboard can show the failure, and the model can continue with accurate information about what went wrong.