Prototype, Trace, Evaluate, Red-Team: An AI Agent Workflow in Microsoft Foundry

Coaxing a few good replies out of an AI agent takes minutes. Deciding that it is fit to release takes much longer, because a team first has to learn whether the chosen model justifies what it costs, whether the agent draws on the right data, which tools it invoked, how its replies score and how it holds up against someone actively trying to break it.

Microsoft Foundry gathers a large part of that loop into a single browser workspace covering model comparison, instructions, tools and knowledge, tracing, evaluation, generated test data and automated red teaming. Its real value isn't that code can be postponed indefinitely. It lets costly design choices get settled while the project is still cheap to change, before production code sets hard around them.

What follows tracks one agent from a blank project to a prototype that is grounded in data, traced, scored and attacked, and then marks the point where work moves from the portal into the SDK. The setting is the Microsoft Build retail-agent environment inside the new Foundry experience, hosted in the Sweden Central region. The portal serves as the quick-iteration surface, and the route to production stays inside the very same Foundry project, so nothing is rebuilt from scratch.

Begin with something that runs

A fresh Foundry project is a workspace holding agents, models, tools, knowledge, evaluation and observability. Exact provisioning steps, default settings and which features exist differ by region and shift over time, so the portal itself should be treated as the final word on what a project can do.

After an agent has been created, the playground is where the productive work begins. The model and instructions are set there, tools or knowledge are attached, and the outcome gets tried in the chat pane. This is also where a prototype first reveals how weak it is. Put a broad product question to a barely configured agent and the reply is typically bland. It may sound confident while knowing nothing of the catalog, the policies or the business setting. Keep that reply as the baseline, since every later change should be judged against it.

Picking a model on evidence

A strong default model isn't necessarily the correct one for production. Certain tasks demand deep reasoning, while others value speed or a low price, so the selection should come out of an evaluation and not a hunch. Foundry gives several tools for trimming the catalog:

• A leaderboard that ranks models on the quality, safety, performance and cost-related measures on offer.
• Trade-off charts that put two dimensions on one plot, such as quality against price.
• A side-by-side view that shrinks a shortlist to models suited to the workload.
• A model router that assigns each request to a suitable model according to a cost-versus-quality policy, so a single model needn't answer everything.

Benchmark scores alone are weak evidence. Running the identical workload through each candidate is stronger. The router earns its keep when requests differ widely in difficulty. It currently offers Balanced, Cost and Quality modes, and current versions switch automatically to another eligible model if the routed one goes down.

The next move is to send the same representative prompts to every candidate setup and compare answer quality, latency and spend. Benchmarks reduce the field, and your own workload chooses the winner. Microsoft Learn describes both the benchmark workflow and the router in its Foundry documentation.

Instructions are the cheapest lever

Changing models is not always the right first step. Vague instructions can reduce an expensive model to a generic chatbot. The Prompt Optimizer in Foundry rewrites and restructures instructions, explains the reasons for edits to particular sections and allows several passes before anything is applied. That way the instructions turn into a versioned input to engineering, in place of a loose paragraph rewritten until a reply seems nicer.

A pretty rewrite proves little. The better check runs one evaluation dataset against both the old and new versions. Any persona, response layout, fallback behavior or limit on off-topic requests that the agent is supposed to follow belongs both in its instructions and in the evaluators that grade its output.

Tie answers to approved data

Instructions govern how the agent behaves, whereas knowledge governs what it is able to answer. In small cases, attaching files and exposing them through retrieval tools lets replies cite source material.

Bigger enterprise setups can use Foundry IQ, a shared knowledge layer over many sources. A knowledge base may link Azure Blob Storage, SharePoint, OneLake, existing search indexes and public web content, and agentic retrieval plans the queries, chooses sources, searches them and returns cited, grounded results.

One warning applies to access control. Permissions at document level are honored only for sources and setups that support them, so nobody should describe a knowledge base as permission-aware before the source permissions and identity flow are really configured.

To see the effect, ask one question twice, before and after grounding. The first reply exposes the model's general knowledge, and the second should show the difference your data makes.

Switch tracing on early

Observability helps most while the agent still fails. Foundry's tracing follows OpenTelemetry conventions and plugs into Azure Monitor Application Insights, recording the path of an agent or application so that model calls, tool use, inputs, outputs and timings can be examined afterward.

Three layers draw on that shared operational picture, each answering its own question:

• Tracing tells you what took place in one particular run.
• Evaluation tells you whether the behavior met the bar.
• Monitoring tells you how runs trend over time.

Remember that Application Insights telemetry carries a price tied to data volume and retention. Budget for observability as part of the production architecture and not as a free debugging bonus.

Measure behavior, not hunches

Hands-on testing works for exploring, though it can't settle whether a change made the agent better. Foundry includes ready-made evaluators across several behavior dimensions: quality, risk and safety, and agent-specific measures namely whether the task was followed, whether it was finished, whether intent was understood and how well tools were called.

Custom evaluators tend to take one of two shapes. Rubric or prompt-driven ones use a model as the judge for criteria that are subjective or depend on context. Deterministic ones are plain functions for criteria you can compute directly. How friendly a reply is may call for a rubric, while a cap on length never does. Evaluation adds cost and noise of its own, so when a function can make the call reliably, another model invocation is wasted money.

Datasets make iteration rigorous

A single prompt shows that a feature works, but a dataset reveals patterns. Foundry can score a JSONL or CSV file you prepared, traces you already have, or synthetic test data. Synthetic data is handy before launch and when live traffic is too light to cover the edge cases of interest.

The result is a loop you can repeat:

1. Fix a representative test set so it stays constant.
2. Run the present agent version on it.
3. Alter exactly one variable, whether model, instructions, tool setup or grounding.
4. Evaluate again on the same set.
5. Compare the scores, response times and spend.
6. Accept or discard the change.

Here the work stops resembling prompt tinkering and starts resembling regression testing for software.

Red teaming catches what normal scoring misses

Ordinary quality checks ask whether the agent does its assigned job well. Red teaming asks what the system does when someone feeds it hostile input on purpose. The AI Red Teaming Agent inside Foundry combines the open-source PyRIT project with Foundry's risk and safety evaluation. It tests supported models and agents with attack methods built to get around standard safeguards, and it reports an Attack Success Rate (ASR).

The supported methods include transformations like Flip and Tense, as well as jailbreaks and other adversarial tricks, and the present risk scenarios take in harmful content, leakage of sensitive data, prohibited actions and indirect prompt injection. The exercise pays off when its scorecard drives yet another round of engineering, and not when it ends as a single screenshot for compliance. Treat it as a cycle:

1. Run a scan somewhere that isn't production.
2. Study which risk category and attack method got through.
3. Repair the cause, whether that's an instruction, a tool boundary, a content control or a permission.
4. Scan once more.
5. Watch whether the Attack Success Rate trends downward.

Watch the whole fleet

After agents are live, the question stops being whether one prompt worked and becomes how the system behaves across weeks. The monitoring and Operate views show signals for the whole workload, such as call counts, token usage, failures and cost-oriented metrics, with drill-down to single agents and models where that's supported.

Thinking in microservices is useful here, within limits. An agent can be handled as a unit of behavior with its own version, made of instructions, tools, knowledge, a model policy and outputs you can observe. Every agent needn't become a separately deployed service. The point is to draw boundaries so one agent can be edited, scored and promoted without rewriting everything near it.

The loop beneath the portal

In practice the cycle runs build, measure, optimize, govern, and back to the start whenever evidence shows the agent isn't ready. Advance because traces and scores clear a bar set beforehand, and never because a demo looked good. Product screens change, but the routine lasts: prototype, trace, evaluate, harden, monitor and repeat.

One caveat as of now: Microsoft plans to retire Foundry Workflows on December 1, 2026 and points new workflow work toward Microsoft Agent Framework. A new design shouldn't be built on the surface that is going away.

From browser prototype to production code

The portal ought to shorten the road to code and not stand in for it. Needs such as custom orchestration, CI/CD, deeper integration or hosted agent code call for the Foundry SDK and its tools, currently available for Python, C#, JavaScript and Java. Architecturally, the project's assets and endpoint remain central. The portal, SDK and tooling are simply different doors into one Foundry project and its resources, so picture one project with a unified endpoint and no separate prototype platform and production platform. The SDK quickstart on Microsoft Learn is where that transition begins.

Next experiments

Two subjects come next. One is multi-agent orchestration, in which independently testable agents, each with a clear contract and evaluation baseline, are combined through a modern orchestration framework and not packed into one giant prompt. The other is model customization, which is worth assessing only after prompting, grounding, routing and tool design have all fallen short. Each belongs after the evaluation discipline described here.

Closing thought

An agent's first working answer starts the process and doesn't finish it. A release candidate needs proof on several fronts: a model choice that held up in a workload comparison, grounding that visibly changes answers, tool calls you can see, repeatable evaluation, and a red-team risk number that shrinks over time. The portal supplies the quick loop, and the project and SDK carry the work into real production engineering. Build fast, add instrumentation early, test each change on the same workload, probe your own system before outsiders do, and switch to code once the browser has answered what it answers well.