Build, Buy, or Extend AI Solutions for AB-100

AB-100 Agentic AI Business Solutions Architect is an architecture exam, which means a technically possible AI solution is not automatically the right solution. A business architect has to decide whether an organization should use a prebuilt Microsoft capability, extend an existing Copilot or Dynamics experience, build a custom agent in Copilot Studio, build a code-first solution with Microsoft Foundry, combine several platforms, or avoid AI entirely when the business case is weak. Those choices require evidence about business value, total cost, integration, governance, data readiness, operating ownership, and risk.

Microsoft has published an updated AB-100 skills blueprint that takes effect on October 14, 2026. As of October 4, 2026, that update is announced but not yet effective, so candidates should verify which blueprint applies on their exam day. The published update explicitly emphasizes ROI/TCO, build-buy-extend analysis, model routing, multi-agent platforms, security, monitoring, ALM, and agentic-first business processes. The underlying architecture decisions are useful regardless of the exam transition.

Start with the business process, not the model

AI architecture begins by identifying the business outcome and the friction in the current process. Is the goal to reduce handling time, improve data discovery, automate repetitive decisions, increase self-service, assist employees, or create a new product capability? Define baseline cost, volume, quality, cycle time, and failure rate before proposing AI. Otherwise ROI becomes a story written after the technology has already been selected.

Determine which steps require judgment, which are deterministic, which involve regulated decisions, and which already have reliable automation. An LLM should not replace a simple rules engine merely because it can. A useful agent architecture combines deterministic services and AI only where each is strongest.

“Buy” means adopting packaged capability with its operating model

Prebuilt Copilot and Dynamics capabilities can deliver value faster because Microsoft supplies much of the application integration, UX, security integration, lifecycle, and product support. The trade-off is control. The organization adapts to the product’s capabilities, licensing, release cadence, data model, and extension points.

Buy when the use case is common, differentiation is low, requirements fit the product, and faster time-to-value is more important than custom behavior. Include licensing, administration, training, governance, and process change in the TCO, not only the license price.

A packaged solution can still need significant data cleanup and identity governance. Buying software does not buy organizational readiness.

“Extend” is often the highest-leverage middle path

Extension preserves an existing user experience while adding knowledge, actions, connectors, prompts, or agents. Extending Microsoft 365 Copilot, Dynamics 365, or Copilot Studio can avoid building a new application shell and identity model. It also keeps users in tools they already understand.

Choose extension when the core product solves most of the workflow but needs organization-specific data, actions, or reasoning. Watch for extension limits: connector behavior, data residency, custom UX, model choice, orchestration control, latency, and platform quotas may matter.

Extension is not automatically cheaper. A heavily customized packaged platform can become harder to operate than a smaller purpose-built application. Compare the steady-state operating model, not only the prototype effort.

“Build” is justified when the requirement truly needs control

A custom solution makes sense when the business needs a distinctive experience, complex integration, specialized orchestration, custom models, strict network boundaries, unusual performance requirements, or control that packaged products do not expose. Microsoft Foundry, Azure services, APIs, and custom front ends can provide that control.

Building transfers more responsibility to the organization: architecture, security, prompt/model management, tool validation, observability, evaluation, scaling, incident response, and ongoing model/platform changes. The team must budget for that lifecycle. The first version is often the cheapest phase.

Model-selection trade-offs are only one part of build decisions. Application ownership is often the larger long-term cost.

Use ROI and TCO to compare architectures, not to justify a favorite

ROI should include measurable benefits and the cost of achieving them. Benefits may include labor hours saved, faster revenue recognition, reduced error/rework, increased conversion, improved case deflection, or better employee throughput. Avoid counting every “time saved” minute as cash unless the operating model actually converts it into productive capacity or reduced cost.

TCO should include licenses, model/token consumption, storage/search, network, integration, development, testing, governance, security, monitoring, support, training, data preparation, and change management. Include expected growth. An architecture that is inexpensive at pilot scale may become expensive at enterprise volume.

AB-100 business-case and model-economics scenarios train the sourcing judgment the exam expects rather than assuming custom AI is always the best path.

Two questions help. First: can a packaged or extended Microsoft capability meet the requirement safely and reliably? Second: if several approaches can meet it, does custom ownership create meaningful competitive value?

A customer-service summary feature may be commodity capability that should be bought or extended. A proprietary decision engine built on unique internal data may justify custom architecture. Building commodity features can consume scarce engineering capacity without creating business advantage.

Strategic differentiation can also change over time. A feature that required custom development last year may become a standard Copilot capability. Revisit build decisions as Microsoft platforms evolve.

Model routing can make “build” less binary

The October 14 blueprint explicitly includes model-router decisions. A model router can choose among models based on task complexity, cost, latency, safety, or capability instead of forcing every request through one deployment. This lets an architecture reserve expensive high-capability models for cases that need them and use smaller or faster models for routine work.

Routing adds its own complexity: evaluation by route, fallback behavior, consistent safety controls, telemetry, and debugging. The savings are real only if classification is reliable and the additional architecture remains operable.

Data and grounding readiness can disqualify an otherwise good idea

An agent that depends on inaccurate, stale, inaccessible, or poorly permissioned data will not become trustworthy through prompt engineering. Assess data accuracy, relevance, timeliness, cleanliness, availability, and access controls before committing to the solution.

If the organization must spend months fixing data foundations, include that work in the business case. Sometimes the right recommendation is to improve the data platform first and defer AI automation.

Security and compliance can change the sourcing decision

Compare where prompts, data, model inputs, outputs, telemetry, and tuning data flow. Review identity, residency, retention, audit, private networking, model security, and access to grounding data. A packaged solution may provide stronger built-in governance; a custom solution may provide more control. Either can be the safer choice depending on the requirement.

For autonomous or action-taking agents, evaluate the authority surface. A prebuilt agent with constrained actions may be lower risk than a custom general-purpose tool layer. Conversely, a custom application may be necessary to enforce specialized approval or separation-of-duties rules.

Operating ownership is the decision many business cases miss

Who reviews failed conversations? Who updates prompts? Who owns a connector when an API changes? Who monitors cost? Who investigates unsafe output? Who approves new tools? Who retests after a model version changes? A solution with no answer to those questions is not production-ready, regardless of prototype quality.

Map ownership across business, application engineering, platform, security, data, compliance, and support. If the operating team does not have the skills or capacity for a custom build, that is a valid sourcing constraint.

The strongest AB-100 answer is usually evidence-based, not technology-first

A mature architecture decision can explain why one path was selected and what would cause the decision to change. Use a decision record with business outcome, candidate approaches, ROI/TCO, data readiness, integration fit, security, lifecycle, ownership, and key risks. Pilot the uncertain assumptions and update the case with measured evidence.

Build, buy, and extend are not permanent identities. Organizations can start with a packaged capability, extend it as needs grow, and build specialized components later. They can also retire custom code when the platform catches up. AB-100 architecture is about choosing the least complex solution that can meet the business outcome safely and sustainably—and being able to defend that choice with evidence.

The sourcing decision should also consider interoperability and exit cost. A deeply integrated packaged agent may be easy to adopt but difficult to move if the organization later needs another model, data platform, or channel. A custom solution can preserve abstraction layers but adds engineering work. Evaluate portability where the business expects rapid AI platform change.

Prototype design should target the uncertain parts of the decision. If the biggest risk is whether grounding data produces accurate answers, prototype retrieval and evaluation rather than building a polished UI. If the risk is whether Copilot Studio can execute the required transactions safely, prototype tool integration and approvals. A proof of concept should retire architecture risk, not merely impress stakeholders.

Use decision criteria with weights when alternatives are close. Business fit, time to value, TCO, security, compliance, extensibility, user experience, performance, data readiness, operational skills, vendor dependency, and strategic differentiation can be scored with evidence. The score is not mathematically objective, but it forces trade-offs into the open.

Model routing should be governed by measurable policy rather than intuition. Define which tasks qualify for a high-capability model, which can use a smaller model, what happens when the preferred deployment is unavailable, and how routing decisions are logged. Evaluate each route independently so cost optimization does not silently send hard cases to an inadequate model.

Build-versus-buy also changes ALM. Packaged features may update on a Microsoft release cadence, while custom components move on the organization’s cadence. Extensions and connectors sit between the two. The architecture should include regression testing for both planned internal releases and vendor-driven changes.

Finally, revisit the decision after production telemetry exists. Adoption, task completion, cost per successful outcome, escalation rate, user feedback, and incident data can prove or disprove the original business case. Architecture is stronger when the organization is willing to reduce, replace, or retire an AI component that does not deliver measured value.

Evaluation effort should be proportional to irreversibility. A small internal assistant can be piloted with limited users and adjusted quickly. An agent embedded in a revenue process or regulated decision path deserves stronger preproduction evidence, security review, and rollback. This affects build-versus-buy economics because packaged capabilities may reduce some assurance burden while custom code can provide tighter control where required.

Integration topology is another cost driver. Count systems of record, connectors, custom APIs, event sources, identity providers, and channels. A “simple agent” that needs eight brittle integrations is not simple. Sometimes extending the application where the data already lives is cheaper and safer than building a central agent that reaches into every system.

User adoption should be modeled explicitly. An AI feature can have excellent technical ROI on paper but produce little benefit if users do not trust it or if it interrupts their established workflow. Compare embedded experiences with separate applications, training effort, feedback mechanisms, and the cost of changing business process.

Vendor roadmap risk cuts both ways. Building custom functionality that Microsoft is likely to commoditize may create avoidable maintenance. Waiting indefinitely for a roadmap feature can delay a strategic capability. Record assumptions about platform evolution and define when the organization will revisit them.

A build/buy/extend review should include a “do nothing for now” option. If data quality is poor, process ownership is unclear, expected volume is tiny, or benefits are speculative, delaying the AI component can be the most responsible architecture choice. AB-100 reasoning rewards alignment to business outcomes, not maximum AI adoption.

Decision records should survive the project team. Capture the option selected, alternatives rejected, assumptions, expected unit economics, data dependencies, review date, and trigger conditions for reconsideration. When model prices, licensing, or platform capabilities change, future architects can revisit the choice without reconstructing the original debate from memory.

For AB-100 scenarios, this record helps separate architecture from preference. The best answer is the one that satisfies business and governance constraints with justified complexity, even when another technology would be more interesting to build.

A useful final check is reversibility. If the organization discovers after six months that adoption is low or economics are poor, how difficult is it to unwind the choice, export data, replace the model, or move the workflow? Exit cost belongs in TCO because AI platforms and licensing models are changing quickly.