Microsoft has several agent-related products. A code development framework, a managed agent service and a workplace application provide different parts of a solution. Identify the component you need before comparing names.
This guide focuses on Microsoft Agent Framework. It is an orientation guide, not a tutorial for configuring other Microsoft products.
What the framework provides
Agent Framework supplies agent abstractions, explicit workflows, provider integrations, sessions and supporting execution components. Microsoft’s documentation identifies it as the successor to Semantic Kernel and AutoGen. Capabilities and release status vary by language; the current overview marks Go as preview. Microsoft Agent Framework overview.
A framework is code used to build an application. It does not automatically decide where your application is hosted or grant access to your business systems.
Separate framework, service and application
When assessing a Microsoft-based design, label each component by its responsibility: development library, model endpoint, hosting, business data, identity and user interface.
Do not assume that selecting a Microsoft library requires every component to come from the same vendor. Equally, do not assume every integration shares the same data handling or permissions.
Ask the implementation team to show the actual deployment and credential path. A broad product diagram can omit the service identity that performs a write.
Work through a support process
In an illustrative design, ordinary code verifies the case ID. An agent investigates delivery status with narrow tools. A workflow then routes the draft to the responsible person and records the outcome.
Keep the send action separate from investigation. If a case needs more information, return a defined unresolved result rather than bypassing the verification step.
Use the framework only where it solves execution requirements. A deterministic lookup may remain a function. A model-directed investigation needs a bounded decision cycle.
Assess integration and state
Check how the chosen model connection, tool adapter and session store behave together. Record which component persists progress and what happens when the process restarts.
A provider integration does not prove that all features have equivalent support across models. Verify the specific API and language you intend to deploy.
For a write, identify the backend authorization check and duplicate prevention. An approval in the workflow should be tied to the actual record and proposed change.
Keep operating responsibilities visible
Your team needs to own updates, telemetry, usage costs, incidents and recovery. Determine which responsibilities are supplied by hosting and which remain in application code.
Record the assessed package and model versions. Documentation can describe newer behavior than the release installed in your application.
Avoid adopting additional orchestration merely because the framework supports it. Measure whether it improves your chosen task and whether maintainers can understand the resulting failures.
Prototype checklist
- Identify the exact development library and installed version.
- Separate it from hosting, model endpoints and workplace products.
- Draw the fixed workflow and model-directed steps.
- Verify language-specific capabilities.
- Test access denial, interruption and duplicate writes.
- Assign service and evaluation owners.
The architecture guide can help you map those responsibilities before choosing a full implementation stack.
The parts of an agent architecture ↗
Follow a task through context, model decisions, tools, permission checks, state and recovery.
Prepared with AI assistance and checked against the linked documentation. Examples and numerical limits are illustrative unless stated otherwise. These guides do not report independent product testing. Check current documentation before choosing a tool.