DEV Community: Ivan Jurina

building enterprise multi-agent workflows in .net with mistral

Ivan Jurina — Wed, 22 Jul 2026 12:54:01 +0000

most people know Mistral for its chat models. the part i find more interesting for enterprise work is the Agents API: persistent agents with instructions and tools, stateful conversations you can resume, built-in connectors (web search, code interpreter, document library), and handoffs so one agent can delegate to another.

the .net story stops short of this. the community sdks (tghamm's is genuinely good) cover chat completions, embeddings and function calling. they don't cover the agentic layer. so if you're a .net shop that wants to build a multi-agent workflow on mistral, you're writing raw http. i didn't want to, so i built Mistral.Agents.Net. here's the design and the one wire-format detail that cost me a debugging session.

agents, not just completions

a chat completion is stateless: you send messages, you get a reply, you manage all the history yourself. an agent is a stored object with instructions and tools, and a conversation is a stateful thread you can continue by id. that difference matters for enterprise workflows, where a "session" spans many turns and you want the platform to hold the state.

var agent = await client.CreateAgentAsync(new CreateAgentRequest
{
    Model = "mistral-medium-latest",
    Name = "Financial Analyst",
    Instructions = "Use the code interpreter for math and web search for current facts.",
    Tools = { AgentTool.CodeInterpreter(), AgentTool.WebSearch() },
});

using var turn = await client.StartConversationAsync(new StartConversationRequest
{
    AgentId = agent.Id,
    Inputs = "what was 15% of last quarter's revenue if it was 12.4M?",
});
Console.WriteLine(turn.OutputText);

the response isn't a single message. it's a list of outputs: tool executions, message chunks, function calls, handoffs. the library gives you OutputText for the common case and Outputs for the raw stream, plus a Root JsonElement escape hatch for anything the typed model doesn't cover yet. same philosophy i used for the serpapi and elevenlabs clients: typed where it helps, raw where you need it.

handoffs: one agent delegating to another

the enterprise-interesting feature is handoffs. you give an agent the ids of other agents it may delegate to, and the platform routes work between them.

var researcher = await client.CreateAgentAsync(new CreateAgentRequest
{
    Model = "mistral-medium-latest",
    Name = "Research Agent",
    Tools = { AgentTool.WebSearch() },
});

var analyst = await client.CreateAgentAsync(new CreateAgentRequest
{
    Model = "mistral-medium-latest",
    Name = "Financial Analyst",
    Handoffs = new List<string> { researcher.Id! }, // delegate research
    Tools = { AgentTool.CodeInterpreter() },
});

ask the analyst a question that needs current market data and it hands off to the researcher, which uses web search, and the answer comes back through the analyst. you orchestrate multiple specialized agents without writing the routing yourself.

your own code as a tool

built-in connectors are great, but enterprise value is in your private data. a function tool exposes your c# to the agent: it decides when to call, you run it, you return the result.

request.Tools.Add(AgentTool.FunctionTool(FunctionDefinition.FromJsonSchema(
    "get_internal_metric", "Returns a private company metric.",
    """{"type":"object","properties":{"name":{"type":"string"}}}""")));

then, when the agent calls it:

foreach (var call in turn.FunctionCalls)
{
    using var args = call.ParseArguments();
    var result = LookUp(call.FunctionName!, args.RootElement);
    using var next = await client.SubmitToolResultAsync(turn.ConversationId!, call.ToolCallId!, result);
}

i tested this end to end: asked "what is 15% of our q3 revenue?", watched the agent call get_internal_metric, feed the private number back, and compute 15% with the code interpreter. the whole loop, from .net.

the detail the docs don't tell you

here's the debugging session. the docs show function-call arguments as a json object. the live api returns them as a json string — a stringified object you have to parse. my first live run threw element has type 'String' the instant the agent called a function, because i was calling GetProperty on what i thought was an object.

this is a common llm-api quirk (openai does the same), but it's exactly the kind of thing you only learn by running against the real service, not by reading the reference. so the library handles it for you:

public JsonDocument ParseArguments()
{
    var v = Arguments;
    return v.ValueKind switch
    {
        JsonValueKind.String => JsonDocument.Parse(string.IsNullOrEmpty(v.GetString()) ? "{}" : v.GetString()!),
        JsonValueKind.Object or JsonValueKind.Array => JsonDocument.Parse(v.GetRawText()),
        _ => JsonDocument.Parse("{}"),
    };
}

ParseArguments() normalizes both forms, so your code never sees the difference. every wrinkle like this that the library absorbs is a wrinkle your users don't hit.

what's real

agents, conversations, connectors, handoffs and function tools are all live-verified against the real api — the revenue demo above actually runs. the library is net8.0, zero dependencies, async-first with cancellation, typed requests with a raw escape hatch, and an offline test suite that replays captured api frames (including the string-arguments case) so ci needs no key or credits.

it's on nuget as Mistral.Agents.Net and the source is on my github. .net is a large enterprise audience for agentic ai and right now it has no official path to mistral's agents platform. if you're at mistral and reading this: happy to help close that gap properly.

originally published at ivanjurina.com

giving a .net app a voice: building on the elevenlabs agents platform

Ivan Jurina — Wed, 22 Jul 2026 08:56:22 +0000

ElevenLabs is best known for text to speech, but the thing i find most interesting is ElevenAgents: you configure an agent with a prompt, a voice and some tools, and it handles the whole voice loop. speech to text, the llm, turn-taking, interruptions, text to speech. you just open a websocket and talk.

they ship sdks for python, typescript, kotlin and swift. nothing for .net. so if you want to build a voice agent from c#, you're hand-rolling the websocket protocol. i didn't want to do that every time, so i built ElevenAgents.Net. here's what the protocol actually looks like and the two design decisions that mattered.

the protocol is a typed event stream

after the handshake, the agent sends a conversation_initiation_metadata event with a conversation id and the negotiated audio formats. then it's a stream of json events, each with a type: user_transcript, agent_response, audio, interruption, vad_score, ping, client_tool_call. you send events back: user_message, user_audio_chunk, client_tool_result, pong.

the naive way to model this is a big enum and a switch. the problem is the event list is long and still growing, and you don't want your library to break the day elevenlabs adds an event type. so: typed classes for the events people actually handle, and a raw JsonElement on the base class for everything else.

await foreach (var evt in conversation.ReceiveEventsAsync())
    using (evt)
        switch (evt)
        {
            case AgentResponseEvent r: Console.WriteLine($"agent: {r.Text}"); break;
            case UserTranscriptEvent t: Console.WriteLine($"you: {t.Transcript}"); break;
            case UnknownEvent u: Log(u.Raw); break; // future event types still usable
        }

UnknownEvent.Raw means a new server event is never a breaking change. you can read it today and i can add a typed wrapper later without anyone's code changing.

two protocol chores the library should just do

two things in the protocol are pure mechanics that no caller should have to think about.

first, ping/pong. the server sends ping events with an id and expects a matching pong for latency measurement. forget it and the connection looks dead. so the library answers pings itself, before the event is even handed to you.

second, client tools. this is the good part. an agent can be configured with "client tools", and mid-conversation it emits a client_tool_call event: run this function with these parameters and give me the result. that's how a voice agent does something real instead of just talking. the library lets you register a handler and wires up the response frame:

conversation.RegisterTool("get_order_status", async (parameters, ct) =>
{
    var id = parameters.GetProperty("orderId").GetString();
    var order = await orders.GetAsync(id, ct);
    return $"Order {id} is {order.Status}.";
});

when the agent calls the tool, your code runs and the result is spoken back. if your handler throws, the library reports it as a tool error instead of dropping the turn. this is stock async-with-cancellation c#, which is the whole point: it should feel like the rest of your codebase, not like a protocol you're fighting.

the payoff: your existing .net code, now with a voice

here's the part i actually built this for. if you already use Semantic Kernel, you have plugins: c# methods decorated as kernel functions. those are exactly what a voice agent's tools want to be. so there's a companion package that maps every kernel function to an elevenlabs client tool in one line:

var kernel = Kernel.CreateBuilder().Build();
kernel.Plugins.AddFromType<OrdersPlugin>("orders");

await using var conversation = await AgentConversation.ConnectAsync(
    new ConversationOptions { AgentId = agentId });

KernelToolBridge.Register(conversation, kernel); // every function is now callable by voice

the agent handles speech, the model and the voice. your business logic runs when the model decides it needs it. the same OrdersPlugin you'd expose to a text chat agent now works over a phone call, and you wrote it once.

what's real and what's next

the realtime client, the event model, ping/pong, client tools and the semantic kernel bridge are all live-verified against a real agent: i asked a voice agent "what's the status of order 1234?" and watched it call my c# method and speak the result back. audio streaming and webrtc are modeled from the docs and next on my list to exercise end to end. the library is net8.0, zero dependencies in the core, async-first with cancellation everywhere, and has an offline test suite that replays captured protocol frames so ci doesn't need network or credits.

one gotcha worth documenting, because it cost me a debugging session: the websocket serves the published version of your agent, not your draft. add a client tool, and until you hit publish, the live conversation still runs the old config with no tools. the agent will even narrate "let me check that" and then do nothing, because it was never told the tool exists. publish, and it works.

it's on nuget as ElevenAgents.Net and ElevenAgents.Net.SemanticKernel, and the source is on my github. .net is a big audience for voice agents, enterprise contact-center teams especially, and right now that audience has no official path onto this platform. if you're at elevenlabs and reading this: happy to help close that gap properly.

originally published at ivanjurina.com

what a 2019 api client teaches you about modern .net

Ivan Jurina — Tue, 21 Jul 2026 13:50:09 +0000

i've been playing with SerpApi lately. nice service. one GET request and you get structured json for google, bing, maps, news, shopping and about a hundred other search surfaces. captchas and layout changes handled for you. their python and ruby stories are strong. their .net story is a time capsule.

the official google-search-results-dotnet package was written around 2019 and it shows. Hashtable parameters. Newtonsoft.Json. a synchronous api that blocks on Task.Result. not a knock on SerpApi, every company has a long tail of sdks. but it makes a great case study. the distance between "working 2019 c#" and "good 2026 c#" is exactly the stuff that bites people in production. so i did two things. sent a set of prs to the official library, and built a modern client from scratch (serpapi-dotnet). here's what changed and why it matters.

1. sync-over-async is a deadlock waiting for a synchronization context

the original core looks like this:

Task<string> queryTask = createQuery(uri, parameter, jsonEnabled);
queryTask.ConfigureAwait(true);   // does nothing here, by the way
return queryTask.Result;

two problems. first, Task.Result wraps any failure in an AggregateException. callers catch (SerpApiSearchException) and miss. second, blocking on a task that resumes on a captured context deadlocks classic asp.net and ui apps. the ConfigureAwait(true) on a task variable (not an await) is a no-op. a hint that the intent was understood but the mechanics weren't.

the fix when you must keep a sync api for compatibility: GetAwaiter().GetResult(), which rethrows the original exception, plus ConfigureAwait(false) on every await inside the library. the real fix: expose GetJsonAsync(CancellationToken) and let callers be async end to end. my pr does both without breaking the existing surface.

2. `catch (Exception ex) => throw new X(ex.ToString())` destroys the stack

the original wraps every failure like this:

catch (Exception ex)
{
    throw new SerpApiSearchException(ex.ToString());
}

stringifying the exception into a message means no InnerException, no type to catch on, and cancellation gets swallowed into a generic error. the modern pattern: let OperationCanceledException flow untouched, wrap transport errors with the original as InnerException, and carry the http status code on your exception type. callers can then tell a 401 from a 429 without parsing strings.

3. `Hashtable` to typed request with an escape hatch

Hashtable is pre-generics .net. the interesting design question is what replaces it, because SerpApi has dozens of engines with different parameters. a rigid typed model can't cover them all. a plain Dictionary<string,string> gives up on discoverability. the answer is both:

var request = new SearchRequest
{
    Engine = SearchEngine.GoogleNews,
    Query = "dotnet 9",
    Location = "Prague, Czechia",
    AdditionalParameters = { ["so"] = "1" },   // anything engine-specific
};

common parameters are typed and documented. everything else passes through. same philosophy on the response side: typed accessors for organic_results and friends, and a raw JsonElement Root for the long tail of answer boxes and knowledge graphs.

4. Newtonsoft to System.Text.Json source generation

dropping Newtonsoft isn't about fashion. with [JsonSerializable] source generation you get reflection-free deserialization that's trim-safe and native-aot-compatible. the library ends up with zero external dependencies. for an sdk, every dependency you don't take is a diamond-dependency conflict your users don't have.

one real-world wrinkle worth showing: SerpApi's local_results is sometimes an array and sometimes an object containing a places array, depending on the engine. that's the kind of thing you only learn by reading actual responses. handle it in the library so your users never see it.

5. `new HttpClient()` per instance, or bring your own

the 2019 client news up its own HttpClient. in 2026 the library should accept one. that's what makes it work with IHttpClientFactory, polly resilience pipelines, and unit tests with a fake HttpMessageHandler. ship a di package with services.AddSerpApi(...) and an ISerpApiClient interface, and testing a search feature no longer requires mocking http at all.

the payoff: a web-grounded agent in 30 lines

the reason i care about search apis in .net at all is ai agents. every llm's knowledge stops at its training cutoff. search grounding fixes that, and everyone does it in python. with a modern client, the c# version is a Semantic Kernel plugin:

public sealed class SerpApiSearchPlugin(ISerpApiClient client)
{
    [KernelFunction("search")]
    [Description("Searches the web and returns the top results.")]
    public async Task<string> SearchAsync(string query, CancellationToken ct = default)
    {
        using var result = await client.SearchAsync(new SearchRequest { Query = query }, ct);
        return string.Join("\n", result.OrganicResults.Select(r => $"{r.Title} - {r.Link}\n{r.Snippet}"));
    }
}

register it, enable automatic function calling, and the model decides when to search. the full sample, a working console agent, is in the repo.

takeaways

if you maintain an api client, the 2026 checklist is short. async-first with CancellationToken. exceptions that preserve their cause. accept an external HttpClient. source-generated System.Text.Json. typed requests with an untyped escape hatch. an interface for testability. none of it is exotic. it's just the accumulated lessons of a decade of .net moving on.

the prs to the official library and the full serpapi-dotnet source are on my github. if you're at SerpApi and reading this: i'd love to help you tell this story to .net developers properly.

originally published at ivanjurina.com

DEV Community: Ivan Jurina

building enterprise multi-agent workflows in .net with mistral

agents, not just completions

handoffs: one agent delegating to another

your own code as a tool

the detail the docs don't tell you

what's real

giving a .net app a voice: building on the elevenlabs agents platform

the protocol is a typed event stream

two protocol chores the library should just do

the payoff: your existing .net code, now with a voice

what's real and what's next

what a 2019 api client teaches you about modern .net

1. sync-over-async is a deadlock waiting for a synchronization context

2. catch (Exception ex) => throw new X(ex.ToString()) destroys the stack

3. Hashtable to typed request with an escape hatch

4. Newtonsoft to System.Text.Json source generation

5. new HttpClient() per instance, or bring your own

the payoff: a web-grounded agent in 30 lines

takeaways

2. `catch (Exception ex) => throw new X(ex.ToString())` destroys the stack

3. `Hashtable` to typed request with an escape hatch

5. `new HttpClient()` per instance, or bring your own