# AI agents: agents you can put in production

Tool-using agents on EU-resident models. The firewall protects personal data in every tool call, models stay in the region you chose, and every step is traced.

## Agents you can put in production.

Build tool-using agents on EU-resident models with full function-calling. The Firewall protects personal data in arguments and results, threads keep conversation state, and Observability traces the cost and latency of each step.

tools · inspected · traced

Every step is scanned, and every step is a span in the trace.

## An agent multiplies everything that can go wrong.

Every tool call is a new way to inject instructions, leak personal data, or run up cost in a loop you did not intend. A demo agent ignores all of it. A production agent needs each step inspected, personal data protected, state kept, and a trace of where the time and credits went, or you are shipping a liability that talks back.

## Tool-using, and checked at every step.

The difference between an agent demo and an agent in production is what happens on the steps nobody watched.

### Full function-calling

Define tools, let the model call them, and steer with tool_choice, the same surface you already build against, now on EU-resident models.

### Protected at every hop

The firewall pseudonymizes personal data in arguments and results before anything leaves, and the router keeps each step on a model you approved.

### Stateful and observable

Threads keep conversation state server-side without resending it, and every step is traced, so you can see which tool or model spent the time and the credits.

## The tool result full of customer data.

Your agent reads a support ticket. The ticket carries a name, an email address and a card number. The firewall replaces them before the model reads the result, and puts them back in the answer.

1. Tool output passes the firewall too: Anything a tool returns is treated like a prompt. The web page, the ticket body, the PDF a customer uploaded: all of it, every turn.

2. The model works on placeholders: The model reasons over a token and calls its tools with it. The real values go back into the response, so the agent still answers the customer by name.

3. The trace shows the whole step: Observability records which tool ran, what it cost and where the time went, so a slow or failing agent is something you can actually debug.

## The agent loop, end to end.

Each part of a production agent maps onto a service behind the same endpoint, and each one is metered on its own.

- Inference API: Function-calling and structured output on EU-resident models.

- MCP Server: Memory and tools for agents, over the Model Context Protocol.

- Recall: Facts and documents keep agent state grounded.

- Observability: A span per step, so you see cost and latency.

- Firewall: Protects personal data in arguments and results.

- Model Router: Routes per step with a fail-closed egress guard.

## Questions people ask about agents.

### Is tool output checked, or only the prompt?

Both. Anything a tool returns is scanned like a prompt, every turn: the web page, the ticket body, the PDF a customer uploaded.

### What happens when an injection is caught?

The turn stops with a typed 422 your code can branch on. The tool the model was being steered towards is never reached.

### Do we have to resend the conversation each step?

No. Threads keep conversation state server-side, so you are not paying to resend the same context on every turn.

### How do we find out where an agent spent its time?

Observability records a span per step with its latency and cost, so a slow or expensive loop is visible rather than inferred.

### Is personal data in tool arguments protected?

Yes. The firewall pseudonymizes personal data in arguments and results before anything leaves the platform.

## Put an agent in production.

Create a key, define your tools, and run an agent that is inspected, protected and traced at every step.