Microsoft Agentic AI Developer

An agent that plans and acts in one step cannot be steered. You require a structured plan before any change, review and approve it, and keep artifacts that let a person see what the agent intends and what it did.

• Why planning comes before acting
• Writing a plan format an agent can follow
• Reviewing and approving a plan
• Inspectable artifacts: plans, diffs and logs
• Detecting when the work departs from the plan

You build A plan-then-act workflow where an agent proposes a plan that a person approves before any change.

How much freedom an agent has should be a decision, not an accident. You set autonomy levels for different tasks, make the agent’s activity observable, and build the controls that let a person pause or stop it.

• Levels of autonomy for different tasks
• What to log so work can be reconstructed
• Dashboards and notifications for running agents
• Pause, stop and take-over controls
• Choosing autonomy by the cost of a mistake

You build An autonomy policy that gives each type of agent task a level, with the logs and controls it needs.

Tools are how an agent touches the world, and each one is a risk. You choose and configure tools and MCP servers, grant the narrowest permissions that work, and handle credentials without exposing them to the model.

• What tools and MCP servers give an agent
• Choosing a tool set for a task
• Configuring an MCP server
• Narrow permissions and allowlists
• Credentials and secrets for agents
• Reviewing a tool before approving it

You build An agent configured with three tools and an MCP server, each with its narrowest workable permissions.

An agent should work in a space you drew for it. You limit agents to named repositories and branches, give them safe environments to run code, and connect their work to the checks that every change must pass.

• Scoping an agent to a repository and branch
• Branch protection and required reviews for agent changes
• Sandboxed environments for running code
• Connecting agent work to CI checks
• Tokens and identities for agents

You build A repository setup in which an agent can open pull requests but cannot merge or reach other repositories.

Agents fail in ways that code does not, quietly and plausibly. You design retries that do not repeat damage, rollbacks that restore a known state, and escalation that brings in a person at the right moment.

• Failure modes of tool-using agents
• Retries and idempotent actions
• Rollbacks with version control
• Detecting a stuck or looping agent
• Escalating to a person with the right context

You build An error-handling design with retry, rollback and escalation paths, tested on a deliberately failing task.

An agent’s results depend on what it remembers and what it sees. You choose between short-term and long-term memory, save progress in durable artifacts, and detect and correct drift when the context goes stale.

• Short-term and long-term memory compared
• Repository instructions and project context
• Persisting progress in files and issues
• Detecting context drift
• Correcting drift without restarting the task
• What an agent must never remember

You build A memory design for a long-running agent task, with the artifacts that carry its progress between sessions.

A change to an agent is only an improvement if you can show it. You define success signals, build test tasks, and trace failures through logs to their cause, whether that is instructions, tools, context or the model.

• Defining success signals for agent work
• Building a set of evaluation tasks
• Reading logs and traces
• Root-cause analysis: instructions, tools, context or model
• Distinguishing a bad run from a bad design

You build An evaluation set and a root-cause report for an agent that fails on a subset of its tasks.

Evaluation tells you what is wrong, and tuning is how you fix it. You change instructions, memory and tool definitions one at a time, re-run your tests, and keep a record so that a fix does not undo an earlier one.

• Tightening instructions without overfitting
• Reshaping tools for clearer use
• Adjusting memory and context
• Changing one thing at a time
• Regression checks before adopting a change

You build A before-and-after tuning record showing evaluation results for each change to an agent.

More agents mean more ways to collide. You assign roles, isolate parallel work, resolve conflicting changes, and manage agents from creation to retirement, with patterns for recovering when one goes wrong.

• Roles and handoffs between agents
• Isolating parallel work in branches
• Resolving conflicting changes
• Coordinating through shared artifacts
• Agent life cycle: start, supervise and retire
• Recovery patterns when one agent fails

You build A multi-agent workflow in which three agents work in parallel branches and a reviewer merges their output.

People remain answerable for what agents do. You classify actions by risk, set autonomy by class, apply least privilege, and require explicit human approval for anything irreversible.

• Classifying agent actions by risk
• Autonomy levels for each risk class
• Least privilege for agent identities
• Approval gates for irreversible actions
• Audit trails and who is accountable
• Reviewing guardrails after an incident

You build A risk classification and approval policy for an organization’s agent actions.

One repository brings every control together. You define the tasks, plan and scope the agents, give them tools and memory, evaluate and tune them, and add the guardrails that keep people in charge.

• Choosing tasks and success criteria
• Designing planning, tools and scope
• Adding memory, evaluation and tuning
• Setting guardrails and approvals
• Reviewing the workflow with a skeptical team

You build A working, supervised agent workflow on a sample repository, with its evaluation results and guardrail policy.