Overview

Runiq Tools let agents call your .NET application code safely and intentionally.

This is where Runiq becomes very practical for .NET developers. Real AI features usually need real application behavior: query a database, check a policy, calculate a price, create a ticket, search an internal service, or fetch account state. Without a tool system, teams often end up building ad hoc HTTP endpoints, moving logic to another runtime, or hiding business behavior inside prompts.

Runiq keeps that capability native to your ASP.NET Core application. A tool is a strongly typed C# class with an input model, output model, metadata, and ExecuteAsync method. Runiq turns that contract into model-facing schema, executes the tool through dependency injection, captures the result, streams tool events, and shows the whole call in Studio.

The result is a clean boundary: the model can ask for an approved capability, but your .NET code still owns what actually happens.

From application code to agent capability

The important part is not that you can "define a tool." The important part is that a tool can wrap code your organization already trusts.

In Runiq.ExpenseDesk, the ExpenseSearchTool does not ask the model to guess employee spending. It uses the application's in-memory SQLite database service through normal ASP.NET Core dependency injection, applies typed filters such as year, department, employee, and category, and returns structured rows plus totals. The agent can then summarize those results, but the source of truth remains the .NET data layer.

In Runiq.WorkflowTravelPlanner, tools expose deterministic travel capabilities: weather guidance, curated places, meal areas, and budget estimates. Each agent receives only the tools it should use. The Weather Agent can call weather logic, the Places Agent can call place search, and the Planner Agent synthesizes the final plan from earlier workflow output.

That is the leverage: AI gets access to real application behavior without moving business rules into prompts or another runtime.

Why .NET tools matter

Most real applications need AI to do more than write text. They need AI to use application-owned behavior without giving up type safety, DI, validation, or observability.

Need	What a Runiq tool gives you
Query app data	Use your repositories, services, database clients, or APIs from normal C# code.
Run business rules	Keep pricing, validation, eligibility, and policy logic in your application layer.
Produce structured results	Return typed output models instead of unstructured text blobs.
Use DI	Constructor-inject services that already exist in your ASP.NET Core host.
Stay observable	Inspect tool names, arguments, output, failures, and attached agents in the dashboard.
Keep boundaries explicit	Attach only the tools an agent is allowed to use.

The point is not to let the model run arbitrary code. The point is to give the model a controlled list of typed capabilities that your application owns, and to make every call inspectable.

Good tool fits

Tools are a good fit when the operation is deterministic, application-specific, or needs real data.

Tool idea	Why it fits
Weather lookup	The model should not invent weather. A tool returns current or demo weather data.
Place search	The application owns curated place data or route constraints.
Meal suggestions	A deterministic demo service can return city-specific meal areas.
Budget estimate	Business rules can calculate an approximate cost from structured input.
Inventory lookup	The agent can check actual stock before answering.
Customer subscription lookup	The agent can answer from account state instead of guessing.
Create support ticket	The application can perform a real write operation with validation.
Calendar availability	The tool can query the user's real schedule.
Policy check	The tool can evaluate a policy rule and return a structured result.
Report generation step	The tool can fetch or compute data used by the agent's final explanation.

Tools are usually not a good fit for broad reasoning or final answer writing. Use an agent for interpretation, planning, synthesis, and natural language. Use a workflow when the execution order must be fixed.

Example: business data as a tool

public sealed class ExpenseSearchTool : IRuniqTool<ExpenseSearchInput, ExpenseSearchOutput>
{
    private readonly ExpenseDeskDatabase database;

    public ExpenseSearchTool(ExpenseDeskDatabase database)
    {
        this.database = database;
    }

    public Task<ExpenseSearchOutput> ExecuteAsync(
        ExpenseSearchInput input,
        CancellationToken cancellationToken = default)
    {
        // Query application-owned data and return structured rows.
    }
}

This is the normal .NET shape: constructor injection, typed input, typed output, and application-owned data access. The model sees a safe capability named expense_search; the application still owns SQL, filtering, validation, and the returned contract.

Tool boundaries

Concept	Responsibility
Tool	Executes one typed .NET capability.
Agent	Decides, calls tools, and synthesizes the final response.
Workflow	Controls a fixed execution order.
Context Space	Provides source-backed knowledge from documents or files.

The tool result is not the final answer. It is returned to the model so the agent can continue with grounded information.