What Microsoft Agent Framework Looks Like on a Real Line-of-Business Stack

The Microsoft Agent Framework makes it possible to define agents that can call tools, follow a sequence of steps, and hand work to other agents. The framework documentation shows how to wire those pieces together. What it does not show is how the same pattern behaves when the tools touch systems that already have owners, approval rules, and audit requirements.

We have used the framework for three kinds of internal work: content approval routing, security finding triage, and scheduled reporting. In each case the useful part was not the agent's ability to decide on its own. It was the ability to package a known procedure, limit the tools the agent could call, and record every step so that a person could reconstruct what happened.

Agents are given procedures, not open goals

An agent that is told to "approve content when it looks ready" will eventually approve something it should not. We write the procedure as a skill that lists the checks, the order they run in, and the conditions that require a person. The agent executes that skill. It does not improvise additional checks or skip ones that fail.

For content approval, the skill confirms that the draft has a source document, that required metadata is present, and that a designated reviewer has already marked the factual sections as accepted. Only then does the agent call the tool that moves the item to the next state. If any check fails, the agent stops and posts the failure reason to the review queue. It does not attempt to fix the content itself.

Security triage follows the same shape. The agent receives a finding, retrieves the related code or configuration through a read-only tool, and produces a structured summary that includes the file, the line range, and a suggested severity based on rules the security team wrote. A person still assigns the final severity and the owner. The agent's output is the input to that decision, not the decision.

Tool permissions are narrower than the agent's instructions

Every tool the agent can call is registered with an explicit permission. Read tools can retrieve pages, tickets, or scan results. Write tools are limited to specific operations, such as adding a comment or changing a status field, and they require that the skill has already passed its checks. No agent is given a tool that can publish content, modify security groups, or run arbitrary queries.

The framework's tool-calling mechanism makes it straightforward to enforce this boundary in code. The harder part is keeping the skill text and the tool list in agreement. We store both in the same repository and review changes to either one together. A skill that describes a step the agent cannot actually perform is updated or the tool is added under the same review.

Every run produces a record that can be examined later

Each agent execution writes a trace that includes the skill version, the tools that were called, the inputs those tools received, and the outputs they returned. The trace also records whether the run completed, stopped for human review, or failed. These records are kept according to the same retention rules as other application logs.

When a content owner asks why an item moved to the next state, or a security lead asks why a finding was summarized a certain way, the trace is the answer. It is also the artifact we use when we sample runs for quality review. A sample of traces is scored against the expected procedure, not against whether the final text sounded reasonable.

Handoffs between agents stay explicit

Some workflows involve more than one agent. A reporting agent may call a data-retrieval agent to gather figures, then format the result. We do not let the first agent decide on its own to invoke the second. The skill lists the handoff, the expected input shape, and the condition under which the handoff occurs. The receiving agent has its own skill and its own tool list. The trace shows both executions and the data that passed between them.

This explicit handoff is slower to set up than a single agent that tries to do everything. It is also easier to change when one part of the workflow needs a different data source or a different review step. The reporting agent can be updated without touching the retrieval agent, and the retrieval agent can be given a new read-only tool without changing how reports are formatted.

What we learned about operating them

The agents that continued to run after the initial project shared two traits. Their procedures were already documented before the agent was built, so the skill was a translation of an existing process rather than a new invention. And the people who received the agent's output had a way to reject it and send it back without needing a developer to intervene.

Agents that were given broader goals and broader tools required more supervision, not less. The framework makes the supervision possible by giving you a place to put the procedure, a place to limit the tools, and a place to read the trace. Those three controls are what turn an agent demonstration into something that can sit next to the other systems the organization already trusts.