Microsoft presents a practical, four-session path for building an artificial intelligence agent in C# using Microsoft Agent Framework, starting with a simple call around the IChatClient interface and ending with an agent that can be monitored, evaluated, governed, and deployed in Microsoft Foundry. The example uses a personal finance education assistant to show the differences between reading data, modifying files, and executing an action with an effect, such as a mock trading transaction.
What Is an Agent Harness?
A language model can generate text, but it does not by itself provide the operational loop required by an agent. This loop calls tools, examines their results, updates the plan, maintains memory, manages the context window, requests user approval for sensitive actions, and then continues working until the task is completed. The source calls this surrounding layer a harness, while the concept of “claw” refers to a command-line-tools-style agent built on top of this layer.
In the example, a configuration containing instructions and tools is enough to start an agent capable of automatically invoking functions, saving the transcript after model calls, creating task lists, compacting context, using file memory, and running web searches when the model service supports them, in addition to requesting tool approvals and sending telemetry through OpenTelemetry. These capabilities remain replaceable, disableable, or extensible through custom providers.
Four Stages for Building the Agent
The first session begins by transforming a chat client connected to a model in Microsoft Foundry into an agent equipped with a custom C# tool for obtaining an illustrative stock price. When the agent is asked about the price of MSFT, the model selects the tool, the harness invokes it, and then returns the result to the model to produce the answer. When given a broader task, such as reviewing a watchlist and suggesting what should be researched next, the agent can create a plan and task list without requiring the developer to build a separate planning engine for the demonstration.
The second session focuses on working with user data safely. The agent reads a CSV portfolio file only from an approved working directory, while the defined boundaries prevent it from accessing arbitrary paths in the file system. The mock trading transaction is also wrapped in a tool that requires approval, so the model can request the action but cannot execute it directly. By contrast, read-only operations can be passed through automatically to avoid overwhelming the user with unnecessary confirmation requests.
The source also presents an approval policy with a time limit: five seconds for each attempt and a maximum of five attempts, with retries when input is missing or invalid, immediate approval when y is entered and rejection when n is entered, followed by automatic rejection after the final attempt. It also discusses the difference between local JSON memory owned by the application and Microsoft Foundry Memory, emphasizing that the model saying “I saved that” does not prove that the data was actually written or that it was saved within the correct scope.
In the third session, skills are added that package specialized knowledge in files that are not loaded in full into the core instructions unless needed, along with restricted shell access, CodeAct execution for running code in a controlled environment, and background agents that can perform independent research tasks in parallel. The source explicitly notes that approval and policies do not replace isolation when commands or code are executed.
What Changes in Practice in a Production Environment?
The fourth session is dedicated to monitoring, governance, evaluation, and deployment. Monitoring includes OpenTelemetry traces, tool and model calls, and token consumption, while governance is connected to Microsoft Purview policies. Repeated evaluations are also used to turn an impression of demonstration quality into a measurable signal, and the option is presented to deploy the agent hosted in Foundry while sharing a single definition among a console application, a hosted endpoint, and an evaluation environment.
The most important message here is that the composability of capabilities does not mean that all of them must be moved into production. A development agent may need files or shell access, but a shared hosted container should not inherit broad local access merely because those permissions were useful during development. Determining what it may read, write, execute, remember, or track remains a design decision owned by the developing organization.
Why Does This Approach Matter?
The harness layer reduces the need to rebuild the tool, planning, memory, and approval loop for every project, but it does not eliminate the responsibility of defining boundaries. The series’ practical value lies in connecting advanced capabilities to their corresponding controls: files to an approved directory, sensitive actions to approval, memory to a verifiable storage result, code execution to isolation and policies, and deployment to monitoring and evaluation. The financial examples remain educational; the prices and transactions used are mock and illustrative, not financial advice.