How Do Agents Work

An agent rests on three things: what it can read, what it can call, and what it may change. Getting the third one right makes the first two safe to grant.

A signup profiler on Microsoft Foundry turns a bare trial registration into a lead profile before staff open it: profession, company, a recommendation, a confidence score and the source links behind each finding, with tracing and token usage per run. A document pipeline takes intake by sidebar drop, phone photo or shared mailbox over Microsoft Graph, archiving each original.

Model Context Protocol turns an existing REST API into typed tools staff call in their own words. The model drafts; an interactive form performs the only write.

What Makes a Run Operable

The gap between a demo and an operable run is durable state. Microsoft Agent Framework 1.0, released April 2026 in .NET and Python, supplies the shared ledger that keeps every member current on what is done and what is still open.

Microsoft Foundry Hosted Agents run with scale-to-zero and per-session VM isolation, so a long run holds no infrastructure warm between steps. The Agent Harness adds automatic context compaction and OpenTelemetry tracing to Application Insights, keeping every stage auditable.

The failure modes that matter appear by running, not by reading documentation. Each is written into the harness the first time it is diagnosed, so the cost is paid once rather than on every build.

Multi-Agent & Autonomous

Some work is too big for a single agent. The Microsoft Agent Framework splits it: a researcher gathers material, a writing team drafts and reviews, and a shared ledger keeps every member current on what is done and what remains.

That pipeline runs in production today. An operator describes an article, the request streams to a team hosted on Microsoft Foundry, and the result arrives complete: the article with frontmatter, a LinkedIn post, an SEO file, a publish manifest and a second-language variant.

Autonomy has a floor. Magentic teams fail against the Microsoft Foundry Responses API with a manager ledger error, and the working configuration is the Chat Completions client. That finding is written down once and never re-litigated.

7
schedule tools answering office questions in the chat client
0
records saved before a person approves the proposal
10×
faster reply drafting after a model change, at a quarter of the cost
3 weeks
from empty repository to a production application

From a Weekly Chore to a Run Someone Can Audit

Envision & Plan 2 steps
01

Start With the Chores That Actually Eat the Week

The candidate list comes from the people doing the work, not from a technology inventory. A one-week survey records where senior time actually goes, a scoring grid rates every task for AI suitability against effort and repetition, and a 90-minute workshop picks the top five to build. Tasks that look automatable but need real judgement on each instance get named and excluded at this point. Finding that out in a workshop costs an hour. Finding it out in a build costs a phase.
02

Map Every Selected Task to a Delivery Path and a Baseline

Each selected task is mapped to the delivery path that fits it and to the baseline that will measure it. Some tasks need an agent that reads and recommends, some need one that calls live systems, and some involve several agents coordinating on work too large for one. Data residency, identity and audit requirements are settled here rather than discovered in a review later. Baseline figures get recorded before anything is built, so the comparison afterwards runs against a measured number rather than an impression.
Implement 4 steps
03

Put the Agent Where the Question Is Already Being Asked

Staff do not open an application to ask a question they could type. One delivered build exposes seven schedule tools over a live planning database through Model Context Protocol, written in the office's own German vocabulary and resolving fuzzy employee and building names, connected to Claude as a custom connector. Access runs on API-key authentication with OAuth protected-resource metadata, and the connector is pointed at the staging slot before it ever reaches production data.
04

Connect the Documents Before Connecting the Model

An agent is worth exactly what it can read. One shipped ingestion pipeline accepts three intake paths into a single review queue: a file dropped in the sidebar, a photo taken on a phone, and a shared mailbox read over Microsoft Graph. Extraction turns each document into a draft record, the original document is archived in blob storage, and the record carries a review flag until a person confirms it. Nothing reaches the books unseen.
05

Let the Model Draft and Let a Person Write

The pattern that makes a write-capable agent acceptable is that the model never holds the write path. In the delivered implementation the model produces a draft and returns an interactive form rendered inside the chat client, and that form calls the single save tool behind it. A model that cannot write directly cannot write something wrong. That is usually the difference between an integration the owner of a system of record approves and one they refuse.
06

Run It Against Real Data With Nothing Saved Until Reviewed

A monthly planning run shows the shape. The office drops its Excel worklist on the planning page, the model reads it, matches the buildings, and proposes a full month of technician routes grouped by location with real driving times from Google Maps. Not one record is written until a person reviews the proposal. The run executes server-side with visible progress and keeps a history entry, so a schedule can still be explained weeks after it was accepted.
Operate 3 steps
07

Keep Model Choice and Spend an Administrative Decision

Which model runs a use case belongs in a setting, not in a deployment. Every AI feature ships with a model registry: an administrator picks the model per use case in an admin screen, grants AI credits per user, and keeps token cost attributable to the feature that spent it. That control pays for itself quickly. On one drafting feature a model change made suggestions roughly ten times faster and four times cheaper, with no change to the feature itself.
08

Make Every Run Inspectable Stage by Stage

Problems should reach a log before they reach a user. One resolution pipeline fans a single barcode scan out to four public sources, merges the candidates with a language model, and falls back to vision when no barcode is readable. Each stage writes one JSON line carrying a correlation ID and its token cost, and the same trace streams to the screen as a running stage list with a live cost readout. Per-run spend and failure paths stay inspectable afterwards.
09

Let the Customer's Own Email Become the Backlog

Change requests do not need a ticket system. On 4 August 2026 a plain email from a customer's office became a batch of changes: read inside the working session, turned into a documented work item, implemented, and returned as a preview address running the new build against its own isolated test data. The customer reviewed a working URL and the batch was promoted after that review. Onboarding material hands the same loop to the staff who will run it.

Frequently Asked Questions

What is an agentic business process?
It is a process where the agent does the reading, the matching and the drafting, and a person owns the approval. One delivered example takes the monthly Excel worklist the office already produces, matches the buildings, and proposes a full month of technician routes grouped by location with real driving times from Google Maps. Not one record is saved until someone reviews the proposal, and every run keeps a history entry that explains the result later.
What makes an agentic process operable rather than a demo?
An agentic process in production needs three things a demo typically skips: a shared ledger that keeps state when a run outlasts a session, a cost record per stage so spend stays attributable, and a written-down failure mode for every platform behaviour that contradicts its own documentation. The Microsoft Agent Framework 1.0 supplies the ledger. Microsoft Foundry Hosted Agents supply per-session isolation and scale-to-zero so long runs do not hold infrastructure warm. The Agent Harness carries automatic context compaction and OpenTelemetry tracing to Application Insights, so the failure path that surfaces on the third run does not recur on the fourth.
How do agents reach business data without rebuilding the system?
Through Model Context Protocol on top of the API that already exists. One planning platform exposes seven schedule tools over its live database, with tool descriptions written in the office's own German vocabulary so fuzzy employee and building names resolve correctly, connected to Claude as a custom connector. Staff ask who has an appointment on a given date instead of opening the planner. The connector runs against the staging slot before it is pointed at production.
What stops an agent from writing something wrong into a system of record?
The model is not given the write path. In the delivered pattern it produces a draft and returns an interactive form rendered inside the chat client, and that form calls the single save tool behind it. Document intake works the same way: an extracted record carries a review flag and the source document stays archived in blob storage until a person confirms it. Approval is a step in the system, not a habit people are asked to keep.
Who decides which model runs, and what does a run cost?
An administrator does, in a model registry with a default per use case and AI credits granted per user. The effect is measurable: on one drafting feature a model change made suggestions roughly ten times faster and four times cheaper without touching the feature. Cost stays visible at the run level too, because each pipeline stage writes one JSON line with its token cost, and the same trace streams to the screen as a live readout.
What happens when the platform does not behave the way the documentation says?
It gets diagnosed once and recorded. Magentic teams on Microsoft Foundry fail against the Responses API with a manager ledger error, and the working configuration is the Chat Completions client. That finding now lives in the harness that travels with the codebase, alongside the deployment run-book and the conventions. Knowing the failure modes of a platform is a large part of what makes a second project on it faster than the first.