Buy a Platform, Build an Agent, or Commission a Managed AI Workforce?

Compare buying, building and managing AI workforce roles with responsibility maps, a worked cost model, exit checks and a practical decision worksheet.

Executive summary

This paper uses three operating model categories as a decision framework for AI workforce planning. These categories represent common patterns; your actual options may differ depending on vendor market conditions, your sector and your specific job requirements.

The three reference categories are: buying a platform (licensing software configured to run AI roles), building a custom agent (your engineering team designs and maintains a bespoke implementation), and commissioning a managed AI workforce (a delivery partner designs, integrates and operates the roles under agreed terms).

None of these is universally cheaper, faster or safer. The right choice depends on what your team can configure and operate independently, how specific your business processes are, what risk you accept if the AI role fails or behaves incorrectly, and how you exit if the choice turns out to be wrong.

This paper uses a senior operating-model lens rather than a technical architecture lens. It does not compare foundation models, infrastructure configurations or machine learning approaches. Those topics are covered in the AI agent architecture production whitepaper. This paper addresses the decision that precedes those technical choices: who is responsible for what, at what cost structure, and under what exit conditions.

The illustrative cost model in section 9 uses explicit input assumptions and worked arithmetic. Do not treat the outputs as market pricing, savings guarantees or budget estimates for your specific situation. Your actual costs depend on your job scope, data complexity, integration effort, operating load and team capabilities.

1. Definitions and scope

This paper does not address AI copilots (model-assisted tools used directly by individuals), robotic process automation (rule-based workflow scripts), or broad enterprise AI platform selections at the infrastructure level. Those are related but distinct decisions.

2. Problem analysis: what the decision actually involves

The platform versus build versus managed decision is rarely a technology decision. It is an operating model decision that determines:

Who configures the role. Someone has to translate your business process into a working AI implementation. That person needs to understand your process, your data sources, your acceptance criteria and your exception paths. In the self-operated reference platform model below, your team configures the role. In the internal-build reference, your engineering team implements it. In the managed reference, a delivery partner is contracted to implement it. Real arrangements can combine these responsibilities.

Who operates the role. After launch, the role needs monitoring, correction when it drifts, updates when sources change, and recovery when integrations fail. Assign this work explicitly. A platform subscription can include services, an internal build can use external operations, and a managed agreement can exclude particular integrations. A label does not identify the person who will respond to an incident.

Who is responsible for role failures. In all three models, your organisation is responsible for business decisions made on the basis of the role's output and for ensuring appropriate review before consequential outputs are acted on. How responsibility is allocated for the role's configuration, integration quality and operating stability differs across models and depends on your specific contracts. This paper does not address legal liability allocation, which varies by jurisdiction and contract.

What you own when the engagement ends. Check continued runtime access, export formats, licences, repositories and handover obligations separately. A platform may offer export; a contractor may retain background intellectual property; a managed service may use licensed components. Payment for implementation is not, by itself, proof of ownership or portability.

3. Platform model: responsibility, cost and risk

A platform gives you access to a configured environment where you can set up AI roles without writing custom code. For the reference arrangement here, the vendor supplies the platform runtime and your team configures and operates the role. Actual hosting, provider access, service commitments and available professional services must be checked against the selected product and contract.

What a platform provides

• A pre-built user interface for defining roles, triggers and outputs.
• Managed connections to a defined set of business systems.
• Model access without requiring your own provider agreement (or with your own agreement depending on the platform's model).
• Monitoring and alerting within the platform's capability.
• Updates and new features from the vendor.

Work to assign beyond a basic software licence

• Business-specific process knowledge. The platform does not know how your delivery briefing process works.
• Unsupported-system integration: verify custom connectors, APIs and professional-services options rather than assuming none are available.
• Acceptance testing against your specific quality standard.
• An exception owner. The platform routes errors to your team.
• Role-level operational support: distinguish included software support from separately contracted workflow monitoring and business-process maintenance.

Proposed reference responsibility map

The following table is a proposed reference map for the platform model. Actual responsibility depends on your specific platform and contract terms.

Platform risk factors

A platform can also be the fastest way to test whether the job is worth automating. Anthropic's workflow and agent guidance distinguishes fixed workflows from model-directed agents and recommends starting with the simplest useful solution. That is an architecture choice, not an argument for one commercial delivery model.

Configuration capability gap. If your job is more complex than the platform's configuration interface supports, you will either simplify the job (reducing value) or add custom code outside the platform (adding maintenance burden). Evaluate the platform against your specific job specification, not the vendor's reference scenarios.

Vendor dependency. Platform features, pricing and supported integrations change. A role that works well today may require reconfiguration after a platform update. Vendor pricing changes affect your operating cost without a corresponding change in what the role does.

Operational burden underestimation. Platform marketing often presents a low-code or no-code configuration experience. The configuration may be low-code. Ease of setup does not demonstrate how much monitoring, exception handling, source maintenance or quality review remains. Measure that work in a trial.

Data sovereignty. Understand where your data is processed and retained by the platform. This affects your obligations under applicable data protection requirements and your ability to comply with data subject access requests and deletion requirements.

4. Custom build model: responsibility, cost and risk

A custom build means your engineering team (or a contractor) designs and implements the AI role from your specific business requirements. The team controls the technology stack, the integration design, the evaluation framework and the operational architecture.

What a custom build provides

• Design control within provider APIs, third-party licences, available engineering capacity and the approved permission boundary.
• Custom integrations where the source system permits the required access and automation.
• Access to a maintainable codebase, with ownership and modification rights checked in the relevant licences and agreements.
• The option to avoid a separate agent-platform licence, while retaining infrastructure, model, connector, dependency and support costs.

What a custom build requires

Engineering capacity to design, build and maintain:

• The role definition and prompt management.
• Integration with each business source.
• An evaluation framework and acceptance test suite.
• Monitoring, alerting and operational runbooks.
• Exception handling and escalation paths.
• Updates when underlying models, APIs or business processes change.

The AI agent development playbook covers this engineering work in detail. The relevant question for this decision is whether your team has the capacity to do that work sustainably alongside your other engineering commitments.

Proposed reference responsibility map

The following table is a proposed reference map for the custom build model. Actual responsibility depends on your team structure and engagement terms.

In this internal-build reference, your organisation assigns implementation and operations internally. External contractors and managed components can change that allocation. The upside is control. The downside is that AI roles require ongoing attention: model providers change their APIs, source systems update their data structures, business processes evolve, and evaluation datasets drift. Without a dedicated team member responsible for AI role operations, source or provider changes can leave failures undetected unless someone owns monitoring and regression evaluation.

Custom build risk factors

Opportunity cost. Engineering time on AI role maintenance is time not spent on product features or platform work. For organisations where engineering capacity is constrained, this is often the critical constraint on the custom build model.

Evaluation discipline. A specific risk is shipping a role that performs well on development examples but poorly on inputs outside that sample. Maintaining a versioned evaluation set and running it on every change requires process discipline that is often deprioritised under delivery pressure.

Dependency management. A custom build that integrates with five business systems has five sets of API dependencies. When any of those systems changes its authentication, schema or rate limits, the role needs updating. The frequency of these changes tends to be underestimated.

5. Managed AI workforce model: responsibility, cost and risk

In a managed model, the delivery partner takes on the business-specific design, integration, configuration, and ongoing operational responsibility under agreed terms. Ampity's preferred engagement starts with customer-controlled provider accounts and authorised operating access; component rights and handover deliverables are agreed explicitly. The customer retains the business decisions: what the role does, what output is acceptable, and which permissions the role holds.

What the managed model provides

• A delivery partner who understands both the business process and the technical implementation.
• Custom integration with your specific business systems.
• An agreed acceptance test framework based on your actual examples.
• Operational monitoring, maintenance and exception handling under defined support terms.
• A handover path: documentation, workflows and custom code that you can take over if the engagement ends.

What the managed model requires from you

• A clear job specification (see Prepare your company for an AI workforce).
• Named data owners and access to the required systems.
• An exception owner available during the testing and operation phases.
• An agreed support scope with defined boundaries for what changes are included.

Proposed reference responsibility map

The following table is a proposed reference map for the managed model. Actual responsibility depends on the specific engagement terms agreed with your delivery partner.

Managed model risk factors

Scope definition. One risk to address is scope creep: the engagement expands beyond what was agreed without a corresponding change in commercial terms. The mitigation is a clear initial scope, agreed change procedures and explicit exclusions.

Vendor dependency on implementation knowledge. A delivery partner who built a role has operational knowledge that is not fully captured in documentation. Transitions are possible but require investment. Plan for transition from the start by requiring handover-ready documentation and a tested rollback procedure.

Delivery quality. A managed agreement assigns defined operational duties to a partner. It does not automatically transfer legal liability, remove customer oversight or guarantee business outcomes. Verify the delivery partner's acceptance evidence, not just their stated methodology. Ask for specific examples of how they have handled integration failures, model drift and business process changes in previous roles.

Illustrative assignments, not provider capability limits. Actual responsibilities depend on the agreement. A managed operator does not take over the customer's business decision authority.

6. Customer-owned infrastructure choices

Regardless of which operating model you choose, you have choices about who owns the underlying infrastructure: provider accounts, data stores, credentials and custom components.

Customer-owned accounts. In this configuration, you hold the accounts with your AI model provider (Anthropic, OpenAI, AWS Bedrock, Google Cloud or others), your vector database, your data stores and your integration credentials. The delivery partner or platform vendor is granted authorised access to those accounts. When the engagement ends, you retain the accounts and can revoke access.

Confirm that the provider agreement permits the intended API or automation use. A paid consumer chat subscription is not evidence that shared logins or unattended business automation are licensed. Use the appropriate provider access path and keep personal account credentials out of the integration. Customer account control also does not settle whether a provider retains submitted data, uses it for training or processes it in a particular region. Check the selected product, settings and contractual terms for those questions.

Vendor-owned accounts. Some platforms and managed services run everything through vendor-controlled accounts. You get a tenanted environment. When you leave the vendor, you need to reconstruct your data, prompts and workflows in a different environment.

The customer-owned account model is preferable for:

• Organisations with data residency or sovereignty requirements.
• Organisations that want to switch delivery partners or platforms without losing access to their operating data.
• Organisations with compliance requirements that extend to their AI provider accounts.

The vendor-owned model may be acceptable when:

• The workflows are sufficiently simple to reconstruct.
• The vendor offers export of all configuration data in a portable format.
• The total switching cost (reconstruction plus migration) is acceptable given the expected engagement duration.

AWS's shared responsibility model explains that customer security duties vary with the services selected. Holding an AWS account does not establish compliant data handling, remove application duties or make every dependency portable.

For Ampity engagements, the preferred model is customer-owned provider accounts with authorised Ampity access. The engagement documents which data travels to which provider, under what terms, and how access is revoked at the end of the engagement.

7. Support model comparison

Support scope matters most when something fails. Define the boundary between what the delivery partner covers and what requires your involvement before the engagement starts, not when an exception occurs.

8. Exit and export assessment

Switching models or vendors is possible from all three options. The cost and difficulty varies.

From a platform. Export your role configuration, workflow definitions and any training data or evaluation sets the platform stores. Test that the export is complete and that the data is in a format that is usable without the platform. Some platforms export configuration in proprietary formats that require conversion. If you use the platform's hosted integrations, you will need to rebuild those integrations when you switch.

From a custom build. Establish repository access and modification rights rather than assuming ownership. The switching cost is the cost of redeploying or adapting the code to a different environment. If the custom build uses a specific model provider through a direct API, switching to a different provider requires adapting the integration. If it uses an abstraction layer, switching may be simpler.

From a managed service. Use the handover record from the onboarding playbook as a starting point, then test whether a replacement operator can actually run the role. In practice, the operational knowledge gap (the difference between what is documented and what the delivery partner knows from running the role) is the primary switching cost. Reduce this by requiring regular handover-ready documentation updates throughout the engagement, not only at the end.

Plan your exit before you start. Define what you expect to receive as a handover, in what format, and what your team would need to be able to do with it. Include this in the engagement terms.

9. Compare cost on the same accepted-work boundary

A cheap attempted run is not necessarily a cheap useful result. Specify the period, workload, acceptance rule, response requirement and customer review obligation before comparing options. Include failed attempts, retries and corrections in the numerator. Count each accepted business result once in the denominator. A queued job, an API success response or a duplicate draft is not automatically an accepted result.

The comparison below is deliberately synthetic. CU means currency units in one consistent currency, not a price quote. The numbers are chosen to make the arithmetic inspectable, not to represent market rates, Ampity pricing or measured customer performance. The platform option wins the base example. Changing assumptions can reverse the order.

A common workload and service level

Assume a 12-month planning horizon, 100 accepted internal delivery briefs per month, and 120 attempted runs per month across all three options. Each brief uses the same three authorised systems and must satisfy the same quality and delivery-time checks. Customer review and correction total six hours a month in each option. The same review requirement prevents a managed-service comparison from hiding customer effort.

Provider and hosting spend is 100 CU per month per option, including the 20 attempts that do not become additional accepted results. This combined input is a placeholder for actual metered charges, not a per-token estimate. If platforms bundle provider usage, allocate that bundled price once instead of adding a second model charge.

Inputs to replace with your own evidence

Zero means zero for this fictional scenario, not an assertion that build or managed options never require licences. The managed fee is assumed to cover the listed technical operating work only. It does not replace the customer's six review hours or add unlimited changes. Connector subscriptions, storage and platform usage tiers belong in the relevant line when they apply.

The exit allowance is a reserve for comparison, not an invoice already paid. Keep it separate in the cash plan. Setup is paid upfront in this example; spreading it over 12 months makes options comparable but does not change the initial cash required. Tax, financing, discount rates and exchange-rate movements are excluded. A finance owner should adapt the model before using it for a budget.

Worked arithmetic

For each option, whole-horizon planning cost equals one-time setup plus 12 times monthly recurring cost plus the exit allowance. The cost per accepted result is that total divided by 1,200.

The platform is least expensive under these assumptions. A managed role can still be the preferred operating arrangement if a named external operator, custom integrations or internal capacity constraints matter enough to justify its additional cost. That is a business decision, not proof that the higher-cost option produces better results.

There is no employee-replacement saving in this table. Reducing effort on briefs does not prove that salary disappears, that staff can be redeployed productively, or that a role replaces a whole job. Any claim of saved capacity needs a separately measured human baseline and an explanation of which work actually stops.

Test whether the choice survives changed assumptions

Keep the customer reviewer rate at 50 CU/hour, but increase the technical operator rate from 50 to 150 CU/hour. Assume, only for this sensitivity, that the managed technical fee remains 600 CU. The platform's monthly equivalent becomes 1,350 CU: 100 provider + 300 review + 200 licence + 600 technical labour + 100 setup allocation + 50 exit reserve. The build becomes 1,700 CU: 100 + 300 + 900 technical labour + 300 setup allocation + 100 exit reserve. The managed option remains 1,200 CU.

Managed is least expensive in this second scenario, but only because the operating-rate assumption changed while its fee did not. Obtain an actual scope and fee before relying on that result. If the managed fee changes with complexity, update it too. Do not present the second scenario as a market benchmark.

These sensitivity figures still use whole-horizon planning cost divided by 12. The expanded component calculation makes setup allocation and the exit reserve visible; it does not turn either item into a monthly supplier charge.

Now keep the base-case total costs but reduce accepted results to 60 a month, or 720 over the horizon. Costs per accepted result become 15.83 CU for the platform, 18.33 CU for the build and 20.00 CU for managed. That calculation holds spending constant to isolate the denominator effect. In a real system, lower acceptance can also increase retries, review and incident cost, so remeasure those inputs.

If accepted results are zero, the unit cost is undefined. Report the period's spend and failure condition instead of displaying zero cost per result or an invented return on investment. Pending outputs should remain pending until acceptance or a documented final rejection closes their status.

Put the model to work

Use the existing AI accepted-result cost calculator for a detailed workload scenario and downloadable report. Keep the comparison assumptions beside the result: horizon, attempted volume, accepted volume, review effort, fee inclusions and exclusions. The calculator is a planning aid, not a substitute for a provider invoice or an acceptance record.

For an actual procurement comparison, request itemised quotes for the same role pack. Ask every supplier to identify included provider usage, connector charges, operating hours, support windows, change allowances and exit assistance. Record the date of each quote. Compare cost ranges when an input is uncertain rather than turning a guessed point estimate into a precise payback promise.

Compare the same workload and service level. Include each cost once and divide by accepted results, not attempted runs. In the worked example, failed-attempt usage is included in provider spend and correction time is included in customer review. Do not add those amounts again. Setup allocation and exit reserves are planning assumptions, not vendor prices.

10. Operating-model consequences

Ask for an operating demonstration, not only a successful run

A useful trial demonstrates both routine delivery and a controlled failure. For example, remove access to a permitted test source, supply conflicting record owners, and simulate a timeout after a test action was submitted. Use isolated fixtures and safe sinks, not customer communications or live commercial records. The operator should show how the role stops or escalates, how an ambiguous result is reconciled, and how a restart avoids repeating a completed action.

OWASP's excessive-agency guidance identifies risks from granting more functionality, permission or autonomy than a task requires. For this procurement exercise, translate that into a concrete test: can the selected arrangement prevent an out-of-scope action even when the input asks for it? A prompt saying “do not do this” is not a demonstration of an enforced permission boundary.

Require evidence at the connected-system boundary. In Slack, check the actual message-posting scopes and identity behaviour. In Teams, check the intended resource-specific consent rather than assuming installation supplies every permission. In Zoho CRM, check the selected module and operation scopes together with the associated user's access. These examples establish questions to test, not a universal permission recipe.

The business owner should be able to inspect an execution receipt without needing a transcript of the model's private reasoning. A useful receipt identifies the job, approved sources, attempted actions, resulting record or message identifiers, acceptance status and exception owner. Store only what the operating and audit purpose requires, with access and retention rules. A detailed log that exposes unrelated customer information creates its own problem.

Routine permitted work can run independently once its authority and acceptance evidence are agreed. Protected actions, such as approving commercial terms, should take a separate route. A design that requires someone to approve every harmless internal step may fail its business objective; a design that grants every permission to avoid that inconvenience fails the control objective.

Beyond cost, three operational consequences influence the choice:

Rate of business process change. If your delivery briefing process changes frequently (new clients, new output format, new systems), the role needs corresponding updates. In a platform model, your team applies those updates. In a custom build, your engineers apply them. In a managed model, your delivery partner applies them within the agreed maintenance scope, with substantial changes scoped separately. If your process is stable, this is less important. If it changes frequently, the cost of updates and the time lag between a process change and a role update affect the role's value.

Exception volume. A well-scoped role handles most inputs and surfaces the rest to the exception owner. If the exception volume is high, the exception owner's time is a significant operating cost regardless of which model you choose. Investigate high exception volume rather than assigning a cause in advance. Missing data, access limits, unclear acceptance rules, model behaviour and unusually difficult work can all contribute. Separate intentional abstentions from preventable failures before deciding whether to expand permissions or change the implementation.

Risk of quality failure. If the role produces an incorrect output and it is used without correction, what happens? For a delivery brief, a wrong owner on a commitment causes a missed follow-up. For a sales proposal, an incorrect scope causes a commercial dispute. The consequence of quality failure determines how much review is appropriate and how quickly the exception owner needs to respond. In a managed arrangement, name the partner's technical correction duties and the customer's business review duties explicitly. Neither an SLA nor an automated quality score removes the need to investigate a consequential error.

11. A decision worksheet your team can complete

Keep this record alongside the role pack and quotes. Use one row per decision, attach the evidence and name who can resolve missing information. An unanswered field is an investigation task, not a reason to choose the option with the most confident sales presentation.

A missing technical operator is not automatically evidence for managed service. It can instead mean that the job should remain manual, that a smaller fixed workflow is sufficient, or that a platform plus limited external support is a better fit. Likewise, having engineers does not mean their best use is maintaining this role.

Apply the worksheet to one illustrative decision

Consider a company preparing an internal weekly delivery brief from project records, Zoho CRM and a Teams channel. This is a hypothetical decision exercise, not a customer case study. The role reads selected records, identifies unresolved commitments, posts an accepted internal summary and asks the delivery lead about conflicting owners. It must not alter contract terms or send customer commitments without approval.

A platform trial could be enough if it can enforce the required record boundary, preserve evidence links and expose failed runs to the designated owner. The buyer should test the actual permission boundary rather than accept a connector logo as proof. A connector existing does not establish that the right fields, regional endpoints or write restrictions are supported.

An internal build could be appropriate if the company already operates the necessary integration and release infrastructure, can maintain it alongside other commitments, and needs behaviour the platform trial could not provide. The decision record should include the cost of that maintenance and a named backup operator. A successful prototype without that operator is not an operating plan.

A managed role could fit if the job needs business-specific integration and the company wants implementation and defined technical operation supplied together. The customer still assigns the delivery lead, approves the accepted-output rule and authorises connected-system access. The agreement should specify which API changes are covered and what happens if a source becomes unavailable.

The next action is a bounded comparison against the same sample and authority boundary. Select an arrangement after inspecting its results, costs and support responsibilities. Do not let one option demonstrate a simplified read-only job while another is priced for production writes, incident cover and continuing maintenance.

12. Limitations and cases where this framework does not apply

This framework applies to recurring, bounded business jobs with inspectable outputs and a human owner for exceptions and consequential decisions. It draws a limited recommendation from NIST's Generative AI Profile: examine risks throughout use, not only at model selection. The particular worksheet and synthetic costing here are Ampity's proposed decision aids, not a NIST-prescribed procurement method. It does not apply to:

• Open-ended assistant deployments. An AI assistant available to all staff for arbitrary questions is a different operating model. The job is not bounded, the output quality is not consistently measurable, and the exception path is less defined.
• Regulated decisions. If the role touches outputs that require regulatory approval (financial advice, clinical decisions, legal conclusions), additional compliance and governance requirements apply that are outside this framework.
• Multi-agent coordination. When multiple AI roles hand work to each other, the responsibility model becomes more complex. Each handoff introduces additional failure modes and each role needs its own specification. Test individual role boundaries and then test handoff failures, shared state and end-to-end acceptance. This paper does not price or certify that additional coordination.
• Experimental or exploratory AI work. If you are still learning what AI can do for your business, a platform experiment may be appropriate regardless of the framework analysis. The framework assumes you have a defined job. If you do not, use the AI readiness and feasibility assessment first.

13. Review checklist

Job specification

Is the role's job defined precisely enough to evaluate against a platform's capability, an engineering team's capacity, or a managed service's scope?

Internal capacity

Is there an honest assessment of your team's ability to configure, operate and maintain each option, based on current capacity, not projected future hiring?

Cost structure

Does the cost model include implementation, operations, quality failure correction, and switching? Are all inputs from your actual situation, not market averages?

Risk allocation

Is the consequence of quality failure defined, and is the chosen model's accountability structure appropriate for that consequence level?

Exit conditions

Is the exit plan documented before the engagement starts, including what you own, in what format, and what your team would need to operate it independently?

Infrastructure ownership

Is the preferred account and data ownership model agreed and documented in the engagement terms?

Support scope

Is the boundary between what the delivery partner or vendor covers and what requires your team's involvement explicit, agreed and tested before launch?

14. Practical next steps

If you have identified a recurring job and completed the preparation described in Prepare your company for an AI workforce, you are ready to evaluate the three models against your specific situation.

Start by completing the decision worksheet in section 11 with your actual inputs. Be honest about your team's current capacity, not your planned capacity. An operating model that depends on a capability you do not yet have is a risk, not a plan.

If you conclude that a managed AI workforce is the appropriate model, bring the completed role pack from the onboarding playbook to your first conversation with a delivery partner. A role pack gives the conversation specificity: instead of "we want to automate our delivery reporting," you present a defined trigger, source map, example set, exception path and authority boundary. That specificity makes the engagement scope more accurate and the delivery evidence more verifiable.

If you conclude that a platform or custom build is appropriate, the same preparation materials are useful. A job specification, source map and example set are necessary regardless of which delivery model you choose.

Primary references and limits

Checked 16 October 2026. These sources support the mechanisms identified below, not the synthetic costs, vendor rankings or any claim of Ampity customer results.

• NIST AI 600-1: Generative Artificial Intelligence Profile: lifecycle risk management, relevant to the limits and review questions in section 12.
• Anthropic: Building effective agents: workflow and agent distinctions, relevant to choosing a simpler implementation in section 3. This is architecture guidance, not evidence that one sourcing model is cheaper.
• AWS: Shared Responsibility Model: service-dependent customer duties, relevant to account-control decisions in section 6.
• OWASP: Excessive Agency: risks from excessive permissions, functionality and autonomy, relevant to the operating checks below.
• Slack: chat.postMessage: concrete token, scope and message-identity behaviour that a collaboration integration must verify.
• Microsoft Teams: Resource-specific consent: resource-scoped permissions and consent, relevant to integration-fit testing.
• Zoho CRM API v8: Scopes: module and operation scope choices, relevant to the CRM boundary in the illustrative decision.