A useful enterprise AI proposal is not a collection of demonstration prompts. It is a hypothesis about a business process: what work will change, which decisions remain human, what evidence proves the change is beneficial, and what operational obligations the new system creates. In Microsoft AB-100, planning an agentic business solution includes adoption strategy, total cost of ownership, return on investment, build-versus-buy choices, small language models, and intelligent model routing. Those decisions belong in one business case because architecture determines cost and risk just as surely as license price does.
Consider a distributor that receives hundreds of supplier change requests each day. A proposed agent might read messages, find the matching purchase order, identify delivery changes, draft a response, and present exceptions to a buyer. An impressive prototype can still have negative business value if users must recheck every extracted date, the organization cannot establish who approved a change, or processing errors require expensive manual recovery. The business case needs a baseline for the existing process and a definition of success that includes erroneous actions, not just minutes saved.
Define the outcome before buying a model
A transformation objective such as “use generative AI in purchasing” is not measurable. Separate the business event from the agent’s intermediate activity. For example, define a successful cycle as a vendor change request classified, matched to the correct open purchase order, reviewed by an authorized buyer, and recorded without introducing a duplicate update. Measure how often that complete event occurs, not only whether the classifier returns an answer. This distinction stops high response accuracy from concealing workflow failures.
Build the baseline with real process data: median and tail completion time, manual touches, escalation rate, rework, exception types, seasonal volume, and the proportion of requests that require judgment. Segment the work. A routine delivery confirmation may be automatable, whereas a contract amendment that changes payment terms may require legal approval. If the project removes ten low-value clicks but adds a twenty-minute exception review for every tenth transaction, the net benefit may be much smaller than a vendor slide suggests.
Use the Cloud Adoption Framework without turning it into ceremony
Microsoft’s AB-100 blueprint specifically calls for applying the AI adoption process within the Cloud Adoption Framework for Azure. For an agentic application, translate adoption into decisions: which sponsor owns the business result, who is accountable for data stewardship, how safety is assessed, which platform team operates the agent, and what skills change for the users. An architecture can be technically sound yet fail because the organization has no process owner empowered to change its workflow.
Start with a bounded service and define an adoption path. A procurement pilot can run in observation mode, comparing agent recommendations with purchasing-team decisions before gaining permission to send messages or alter orders. Its go/no-go gates should measure extraction accuracy, operator trust, avoided rework, and the reliability of audit records. A center-of-excellence function is most useful when it publishes reusable control patterns, reference architectures and measurement methods rather than requiring identical agent designs for every department.
Calculate benefits using accepted outcomes
Estimate benefit per completed task, not per generated answer. The basic model is straightforward: accepted cases multiplied by verified time or cost saved, adjusted for any new review, infrastructure and operational burden. Where staff time is not actually eliminated, describe capacity released for more valuable work rather than booking fictional headcount savings. Quality improvements may also carry a real benefit, but they need their own evidence: fewer erroneous order changes, shorter customer wait times or better compliance with response obligations.
Build separate scenarios for optimistic, expected and stressed operation. Include a lower-than-expected adoption rate, a spike in tool failures, more human escalations, and a rise in vendor API cost. If the return becomes negative whenever approval rates drop slightly, the proposal needs a smaller scope or a different design. In a regulated workflow, the avoided cost of a severe error may be important, but it should not be invented as a precise dollar figure when the organization has no defensible historical basis.
Price the full workflow, including recovery
Total cost of ownership includes model input and output usage, embedding or retrieval, storage, connector and tool calls, infrastructure, licensing, security review, observability, evaluations, incident response, and human oversight. A model that is cheaper per token may produce longer prompts, require more retries or make more expensive tool calls. Compare cost per accepted business outcome, and keep latency and safety thresholds fixed during the experiment. A cost comparison that allows one candidate to fail more often is not comparing equivalent services.
A useful cost trace identifies the requested task, routing choice, model versions, actual tokens, retrieval count, tool requests, retries, elapsed time, human review and accepted result. The observability of multi-agent workflows provides the evidence needed to reconcile operational cost with outcome quality. Avoid storing raw confidential prompts solely for accounting: aggregate metrics where possible and apply retention limits to sensitive traces.
Decide when to buy, configure, extend or build
Begin with the process boundary. If an existing Microsoft 365 Copilot or Dynamics 365 capability performs the task inside approved permissions and provides adequate ownership and audit, adopting it may reduce implementation and maintenance cost. If the missing capability is narrow, extending an existing agent with grounded information or a carefully scoped action can be preferable to creating another runtime. A custom Copilot Studio agent fits when the business needs controlled conversational actions and low-code integration. A Microsoft Foundry-based implementation is more suitable when the organization needs specialized model or orchestration control that the managed business experience does not supply.
Document the rejected options as well as the chosen one. A finance application cannot become safe merely because a model is capable of drafting journal entries. If the existing system has authoritative validation and approval processes, the agent should propose inputs to those mechanisms rather than replace them. This architecture decision also limits vendor lock-in: separate policy and transaction commits from probabilistic language understanding. For the model and agent runtime boundary, the existing Microsoft Foundry agent architecture supplies the complementary implementation view.
Route models according to risk and task difficulty
The current AB-100 planning blueprint names model routing. Routing can reduce cost when straightforward classification uses an appropriately capable, efficient model and more complex reconciliation uses a stronger model. But a router must preserve task semantics, data boundary, safety policy and response contract. A classifier should not be allowed to downgrade a high-risk case simply because its initial confidence appears high. Use explicit workload classes and an independent policy to prohibit unapproved model choices or processing locations.
Microsoft documents a model router in Foundry, but availability, routing modes and supported regions change. Validate the currently offered service in the intended subscription, region and deployment class instead of treating a model comparison table as permanent. In a controlled evaluation, log both the router choice and the serving model, measure quality and latency per task class, and test how fallback behaves when a chosen model is unavailable. Automatic fallback is a recovery mechanism, not permission to violate contractual data residency.
Test small models rather than assuming smaller is cheaper
A small language model can work well for constrained classification, narrowly defined entity extraction or a repetitive domain vocabulary. It is less attractive if the task requires long multi-document reasoning, unusual languages or broad synthesis. Compare an SLM with a larger model on the exact business dataset, using the same schema and acceptance thresholds. Include refusal behavior and missing-field cases. The right answer may be a deterministic rule for common cases, an SLM for moderate ambiguity and a stronger model for a small number of exceptions.
Model specialization creates lifecycle obligations. A custom-tuned model needs source-data provenance, versioning, evaluation, drift checks, secure deployment and rollback. The improvement must outweigh the cost of collecting and maintaining representative data. If the data changes every day, a better grounding and retrieval strategy may be more appropriate than retuning a model to memorize volatile policy details. Measure reliability over time rather than treating a single benchmark run as a procurement decision.
Turn the business case into an operating contract
A final architecture decision record should state the process and owner, alternative designs, constraints, success metrics, expected costs, controls, release stages and stop conditions. Include who can grant new tool permissions and who reviews incidents. When the system is exposed to untrusted customer or supplier text, the approved agent governance boundaries are not optional features to add after launch. They determine whether the claimed savings are achievable within the organization’s risk tolerance.
Review the decision after real usage begins. Track accepted-result rate, exception causes, operator corrections, time saved, model and tool spend, and the cost of incidents. A decline in model spend is not an improvement if customer complaints or manual work increase. Microsoft AB-100 is therefore asking for architectural judgment: translate an AI idea into a measurable business investment, choose the least complex solution that satisfies its hard constraints, and keep enough evidence to revise or retire the design when conditions change.