Use Orq.ai as the model control layer for Azure AI Agents. Route LLM calls through one OpenAI‑compatible endpoint, capture traces, monitor cost, and manage fallback behavior without rebuilding your Azure agent logic or Foundry projects.
What is Azure AI?
Azure AI Agent Service (part of Azure AI Foundry) is Microsoft’s enterprise‑grade platform for building, hosting, and monitoring AI agents, with features like hosted agents, Memory Service, toolbox/MCP tools, and integrated observability via Azure Monitor and Application Insights. It helps teams focus on agent behavior and workflows instead of wiring every monitoring, routing, and deployment component from scratch.
Why use Orq with Azure AI
Trace agent behavior end to end
Trace Azure AI Agents runs end to end, including prompts, retrieval steps, tool calls, model responses, and errors in one place. You get clearer visibility into agent behavior without stitching together custom traces across Foundry, Azure Monitor, and downstream services.
Model flexibility without rewiring agents
Test new models, add external providers, or assign different model tiers to different Azure agent workflows from Orq.ai, while keeping your Azure AI Agents definitions and Foundry/Fabric integration stable.
Evaluate real production runs
Use real Azure agent conversations and traces to build datasets, compare prompt or model changes, and move from subjective tuning to measurable quality checks. You can turn failed or slow agent runs into eval inputs for future experiments across providers.
Control spend and access centrally
Track token usage and spend per agent, team, and workflow so you can see which Azure routes drive cost. Add budgets, rate limits, and approved‑model lists at the Orq platform layer instead of enforcing governance separately inside each agent or Foundry project.
How the integration works
Step 1
Point Azure AI Agents at Orq.ai’s router
Configure the model calls your Azure agents make (for example via the Azure OpenAI endpoint in Foundry) to use Orq.ai’s OpenAI‑compatible base URL instead of calling every LLM provider directly. This gives Orq the context it needs to apply routing rules, capture usage, and enforce fallback behavior.
Step 2
Enable tracing from Azure to Orq
Route Azure AI Agents’ LLM calls through Orq.ai’s AI Gateway / Router while keeping Azure’s own observability (Application Insights + Azure Monitor) enabled. Azure continues to emit metrics, traces, and evaluation results for agent operations, and Orq logs the LLM interactions and cost metrics for those requests.
Step 3
Define routes, fallbacks, and policies in Orq
Create routes for key Azure agent workflows and assign them model tiers, fallback chains, and region/data policies. The Azure agent sends the LLM request to the configured Orq route, and Orq applies the routing rules you define before invoking Azure OpenAI or other providers.
Step 4
Monitor, evaluate, and tune
Once connected, use Orq’s dashboards to watch latency, errors, and cost for Azure agents, and run evals or experiments on their traces. You can then adjust routes, models, or prompt configurations centrally where supported, without changing Azure AI Agents’ orchestration or Foundry deployment setup.
Use Cases
Multi‑agent products with real observability
Trace which Azure agent, step, tool call, and model contributed to a failed workflow or unexpected outcome, combining Foundry’s agent monitoring views with Orq’s router‑level traces.
Cost‑aware internal tools
Route routine steps to lower‑cost models while keeping complex reasoning or data‑sensitive flows on stronger routes configured in Orq, all still running through Azure AI Agents and Foundry.
Eval‑driven agent improvements
Reuse failed conversations and Azure agent traces as eval inputs before shipping prompt, tool, or model changes, turning production telemetry into a continuous improvement loop.
Safer experimentation across providers
Test a new model or provider on a small share of Azure agent traffic, then promote or roll back based on traces and evals, instead of editing each agent definition or Foundry integration by hand.
FAQ
Do I have to change my Azure AI code to use Orq.ai?
In many cases, you can repoint the LLM calls that Azure AI Agents make (for example by updating the Azure OpenAI endpoint and key to Orq’s OpenAI‑compatible router) and keep Azure’s observability setup as‑is, adding only minimal configuration instead of rewriting your agents. The agent definitions, tools, Memory Service, and Foundry orchestration stay in Azure.
Does Orq.ai replace Azure AI’s own runtime or framework?
No. Azure AI Agent Service and Foundry remain your agent runtime and primary observability source. Orq.ai sits alongside them as the control plane for models, multi‑provider routing, cost tracking, and additional evaluation. You still design and run agents in Azure AI Agents and Foundry, but you use Orq to see what they cost, which models they should call, and how LLM behavior compares across providers under the same agent workflow.
Can I keep using my existing LLM providers with Azure AI if I move to Orq.ai?
Yes. You can import your Azure OpenAI deployments into Orq.ai and route Azure agent traffic through them, alongside any additional providers you add later. That way you centralize access, routing, and tracking without losing the Azure models you already rely on. Bring production controls to Azure agents
