What AI Adoption Leaves You: Continuous Improvement by Design

Many conversations about AI adoption begin with two questions: Which model should we use, and how should we connect it to our systems? Microsoft’s recent launch of Frontier Company suggests that the more important question may be what the organization retains after the model is deployed. Once the model is in place, what lasting capabilities and assets remain within the organization? Start the design there, and the picture changes.

What Microsoft launched — a “new operating business”

On July 2, 2026, Microsoft announced Microsoft Frontier Company. The company describes it as “a new operating business” for delivering AI-driven transformation to customers. Microsoft says it is investing $2.5 billion in the initiative and embedding roughly 6,000 industry and engineering experts with customers.

According to Microsoft, the distinguishing feature is that Frontier Company builds on Forward Deployed Engineering (FDE) and extends it, combining deep industry knowledge, change management, continuous-improvement experience, and enterprise-grade AI engineering. Microsoft describes the approach as embedding experts into the customer’s organization and teams to co-design, deploy, and continuously improve systems together.

Microsoft also addresses how it treats customer data, IP, and competitive advantage. By its own account, it will not use them to train models in ways that commoditize what differentiates the customer. That said, this is a stated policy in the announcement; the specific terms of data use vary by product, contract, and configuration, and should be confirmed each time.

As one example of the continuous-improvement loop, Microsoft points to its work with LSEG (London Stock Exchange Group). By Microsoft’s account, its engineers and industry experts worked with LSEG to embed AI-powered search into LSEG Workspace, letting finance professionals query structured and unstructured content and get quick answers. The underlying solution, Microsoft says, is refined iteratively through client feedback and real-time user testing, steadily improving model quality and scope. This is Microsoft’s account of its own case, not a general guarantee that any deployment will succeed—but it does show where the emphasis sits: not “build it and walk away,” but “keep improving it while it’s in use.”

The value of AI adoption isn’t decided by the model alone

The broader point is that Microsoft does not frame the model itself as the sole source of value.

That aligns with our view. Successful AI adoption depends less on raw model performance than on the broader business system built around it: how the model is integrated into workflows, how its actions are governed, how performance is evaluated, and how the system improves over time. For many organizations, the foundation model is an externally sourced component that may be replaced as capabilities, costs, and business requirements change. So rather than “pick the highest-performing model,” the longer-term assets are a workflow that keeps running when the model changes, and a structure that can turn into reusable value the longer you operate it.

Put another way, the foundation model is a procured component, and it may be replaced. What can endure are the workflows, controls, data structures, evaluation criteria, and operational records built around the model. Next, we look at how to design that.

Improvement data: designing the asset that stays with you

In this article, we use the term operational improvement data—shortened below to improvement data—for records that connect AI inputs, outputs, actions, human interventions, and business outcomes in a form that supports evaluation and continuous improvement. This is not an official Microsoft term; it is our own framing for this article.

Improvement data connects the operational record of an AI-assisted workflow. It may include the user’s request, the information the system referenced, the AI’s response or classification, the tools it invoked, the results of those actions, human approvals or edits, and the final business outcome.

The important point is not merely to store each item. The organization must be able to reconstruct the sequence: what was requested, what information was used, what action was proposed or taken, where a person intervened, and what ultimately happened. This is not about storing the AI’s internal reasoning. It is about keeping the observable inputs, actions, results, and human interventions so they can be used later for evaluation and improvement.

“Improvement” here does not mean only retraining a model. The records you gather can feed revisions to business rules, adjustments to permissions, UI improvements, changes to procedures, and reconsideration of which model to use. Often, those operational adjustments matter more than retraining.

A common misconception is that “building it yourself means the data accumulates in-house.” Accumulation itself is not the goal. What matters is being able to decide—on your own terms—what you store, the identifiers that link it, who can access it, how long you retain it, and which evaluation or improvement process it supports. It also includes whether you have the right to use those records, whether you can export them in a usable form, and whether they are portable if you change vendors. “Staying with you” is not only about where data is stored; it includes these usage rights and portability. You can create an improvement-data pipeline even on an off-the-shelf product, if you design it to write records back to your own platform—and even a fully custom build, without this design, leaves scattered logs rather than an asset. The dividing line is not “build or buy,” but whether there is a design that keeps records in a form usable for improvement.

More data is not always better. Organizations should define a specific purpose, retain only the data needed for that purpose, restrict access, set retention periods, and delete the data when those periods expire. Personal and confidential information should be masked or removed where appropriate. Without these controls, the same data can create privacy, security, compliance, and operational-cost risks. Designing what to retain must therefore go hand in hand with designing what not to collect—or when to delete it.

Think in three implementation patterns

AI adoption is often framed as a binary of off-the-shelf versus custom-built, but in practice there is a range in between. A more useful approach is to distinguish among three implementation patterns. These are not a maturity ladder you climb from bottom to top. Nor is it a single choice for the whole company—you can mix and combine them per workflow.

1. Use an off-the-shelf product with minimal customization. This is usually the fastest option and requires the least initial development effort.
2. Build on an existing platform by adding connections to internal data, custom tools, organization-specific permissions, and logging or governance controls.
3. Build for your business down to the UI, data, authorization, and execution layers, tailoring the screens, stored data, permission controls, and actions performed in external systems to your work. This does not mean writing everything from scratch; it means your organization—or an implementation partner—designs the parts specific to you.

Within the same company, first-line inquiries might fit pattern 1, internal knowledge search pattern 2, and a routine process that updates or acts on a system of record pattern 3. Choosing different patterns per workflow is natural.

What custom development enables—and what it requires

A custom implementation can give the organization greater control over how the system operates. It can support organization-specific permission rules, deeper integration with existing systems, custom evaluation criteria, purpose-built data collection, and optimization for cost and latency. It can also help the organization retain operational knowledge that develops through day-to-day use.

These benefits are not automatic. For example, changing models safely requires an abstraction layer and an evaluation framework that can determine whether a new model performs adequately on the organization’s own workflows.

The trade-off is greater operational responsibility. For the layers that are customized, the organization and its implementation partners must clearly assign responsibility for development, monitoring, security, incident response, maintenance, and quality evaluation. Outsourcing the implementation does not eliminate the organization’s responsibility for business rules, authority boundaries, or risk acceptance. Ignore this—assuming that custom development provides unlimited freedom—and the operational load becomes the bottleneck. Greater control comes with greater responsibility.

Which pattern to choose — decide per workflow

That is why the choice is best made per workflow, not per company. Useful criteria include the following. The table below is a starting draft to adapt to your own situation; it is not a set of correct settings. Decide the actual values and weightings for your own work, organization, and risk tolerance.

Criterion	What to look at	Rough guide (one example)
Uniqueness of the work	Are your own judgments and know-how a source of competitive advantage?	Greater uniqueness may justify Pattern 2 or 3
Enforcing controls	Can required approvals, caps, stops, and audits be enforced by the product’s standard features?	Consider Pattern 2 or 3 if standard controls are insufficient
Depth of integration	How far must it connect to existing systems?	Deeper integration generally favors Pattern 2 or 3
Data	Do you want to design what to keep and how to use it for evaluation and improvement?	Depends on requirements; even Pattern 1 can write records to your own platform
Scale and frequency	Do volume, speed, and cost start to matter?	Larger scale offers more room to optimize; Pattern 1 may still suffice
Security and compliance	Can the option meet requirements for data location, access control, auditability, retention, and deletion?	Eliminate any pattern that cannot meet mandatory requirements
In-house operating capacity	Do you have the capacity for development, monitoring, incident response, and evaluation?	If internal capacity is limited, start with Pattern 1 or 2

Although these criteria appear in a single table, the decisions span multiple layers. Authorization and execution controls may be enforced in connected systems; retention and permitted uses may be governed by internal policy; and performance must be evaluated against the organization’s own criteria. List several important workflows, assess each one against these criteria, and decide which pattern provides the best starting point. This usually makes the trade-offs much more concrete.

Conclusion: decide what stays, alongside the model

Microsoft’s announcement illustrates a broader point: the company is investing not merely in delivering AI models, but in building systems that are deployed, evaluated, and improved within customer environments over time. The value of AI adoption therefore does not depend on model selection alone.

If you are weighing this for your own organization, decide “what stays in this workflow” at least at the same time as choosing the model—not after. Decide which requests, source information, AI outputs, tool actions, human edits, and business outcomes should be linked. Define the identifiers that connect them, who may access or control them, how long they should be retained, and which evaluation or improvement process they will support.

Map these requirements early. Whether you begin with an off-the-shelf product or a custom implementation, the resulting records and operating practices can become reusable organizational assets—provided that the organization maintains the data-capture, evaluation, and improvement processes over time. Models may change; a well-designed operating model can endure.

Sources and date of review

This article was prepared as of July 2026, drawing primarily on Microsoft’s official blog post “Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence” (July 2, 2026) and the official Microsoft Frontier Company business page. The organization’s scale and structure, its stated approach to data and IP, and the details of the example may change, and specific data-use terms differ by product, contract, and configuration. When adopting or using these services, please confirm the details in each product’s official information and contract terms.