The demonstration finishes early. A supplier's agent has read an order, found the right customer record and prepared a reply. Your own team has a prototype that can do much the same. One option comes with a subscription; the other comes with a development estimate. At first glance, the decision looks financial.
Then someone asks who will deal with an order that changes twice, a model update that alters the answer, or a customer who disputes what was sent. The two proposals suddenly look incomplete. This is an illustrative situation, but it is a useful place to begin: compare the work each option leaves your organisation to do.
This guide is for the person responsible for one consequential business workflow. You will find a comparison of buying, building and combining components, a way to expose ongoing costs, and a responsibility worksheet you can use with your team. You may discover that your internal team already has enough evidence to decide.
First, decide whether the workflow needs an agent
An AI agent uses a model to choose steps and tools while pursuing a task. That flexibility is useful when the next step cannot be fully specified in advance. It also gives you more behaviour to test and supervise.
Start by describing the job without naming a product. For example: “Prepare a response to a supplier's delivery exception using the current order, approved terms and a named person's approval before sending.” You can now ask which steps are fixed, where judgement is needed and whether the system needs permission to act.
If the task follows a stable sequence, a conventional workflow with a bounded AI step may be sufficient. Anthropic's engineering guidance distinguishes predefined workflows from agents that choose their own steps and recommends starting with the simplest adequate design. That is useful design guidance, not a reason to choose a particular model supplier.
Write down the start, the accepted outcome and the point at which a human must take over. A broad ambition such as “automate operations” is too large to support a sensible build-or-buy decision.
There are three realistic routes
Buying means adopting a product or managed service whose behaviour and operating boundary are largely set by its supplier. Building means taking responsibility for your own application and workflow design, usually on top of external models and infrastructure. Combining means using a purchased foundation while retaining selected workflow components and controls.
On a small screen, scroll the table sideways to compare all three routes.
| Question | Buy | Build | Combine |
|---|---|---|---|
| When is it worth considering? | The product fits the actual process, including its exceptions. | The workflow needs behaviour or control you cannot obtain from a suitable product. | A standard foundation fits, but a few important steps need your own design. |
| What remains yours? | Business ownership, access decisions, acceptance criteria and work outside the supplier's scope. | Application maintenance, testing and support arrangements, as well as business ownership. | The custom layer and the handoffs between it and the supplier's components. |
| What evidence matters? | Performance on your cases, control options, usable records and a defined support boundary. | Maintainable design, realistic team capacity, a test set and a credible recovery plan. | A tested end-to-end workflow and a named owner for each interface. |
| What could rule it out? | A critical exception or approval requirement cannot be supported. | There is nobody with capacity to maintain the application after delivery. | Failures move between teams without anyone owning the whole outcome. |
| What should you test before committing? | A difficult real-world case and a change or outage scenario. | A handover to someone other than the original developer. | A failure that crosses the supplier/custom boundary. |
This is an architectural comparison, not a ranking of products. Buying can be a sound choice for a critical workflow when the evidence and boundaries fit. Building can be reasonable when your organisation can sustain it. A combined approach still needs a clear owner for the full service.
Ask who will do the work after launch
“The vendor supports it” is a starting point for a conversation. Ask what support covers, how an issue is recognised and what your team must do while it is being resolved. An infrastructure service can be healthy while the workflow produces the wrong business outcome.
Microsoft's guidance on agent operating models treats ownership, decision rights, lifecycle management and monitoring as explicit organisational responsibilities. For one workflow, you can make those responsibilities concrete without creating a new department.
Use the worksheet below in a working session. Replace role labels with actual people or teams. For each buying, building or combined option, complete the last column separately.
| Responsibility | Ask for this evidence | Record for each option |
|---|---|---|
| Business outcome | A definition of an acceptable completed case and who accepts it. | Accountable owner; acceptance measure. |
| Data and access | Which records the agent can read or change, and a demonstrated way to revoke access. | Approver; operator; remaining access gaps. |
| Exceptions and human review | A queue, coverage arrangement and escalation for cases the agent cannot resolve. | Review team; available capacity; fallback. |
| Behaviour changes | A record of model, prompt or tool changes and tests required before release. | Change owner; reviewer; notification boundary. |
| Monitoring and recovery | An alert tied to a business failure, plus a rehearsed pause and restart. | Responder; recovery authority; coverage. |
| Supplier exit | What records, configuration and test cases can be exported and in what usable form. | Migration owner; unportable elements; cost assumptions. |
A named owner without time, access or authority is an unresolved dependency. Record it as such. If an external team owns a task, distinguish what is documented in its service from what a demonstration or sales conversation merely suggested. Procurement and legal specialists should review contractual commitments.
For a deeper look at permissions, use the AI agent identity and authority guide. For the signals a live workflow needs, see the agent monitoring guide.
Compare the full cost of an accepted outcome
Put the same volume, quality threshold and observation period against each route. Otherwise, a product subscription may be compared with a development project that includes work the subscription leaves to your staff.
Separate one-off spending from recurring spending. Include setup, data preparation and acceptance testing in the first category. In the second, include model and platform usage, human review, exception handling, maintenance, monitoring and the support your organisation actually needs. List exit work separately so it is visible.
Cost per accepted case = attributable operating cost for the period ÷ cases that met the agreed acceptance criteria.
Specify whether your comparison includes allocated setup costs. Do not count both an internal maintenance estimate and an external managed-service fee for the same work. Keep capacity reservations visible even when a quiet month produces few incidents.
The strongest test of the business case is often the review burden. How many cases need a person, how long does that take, and does the queue grow at peak volume? Measure this on representative cases. A claimed saving is still an assumption until the changed process and its costs have been observed. The workload-router guide explains the narrower question of model usage and cost per accepted result.
Run one difficult case through every option
Return to the delivery-exception example. Suppose an order has changed, an attachment contains old information and the proposed response would promise a new delivery date. This is a test scenario, not a report of client work.
Give each route the same permitted information and the same acceptance conditions. The system should establish which record is current, recognise the unresolved date and route the commitment to the authorised person. The exact implementation can differ. The business boundary should remain consistent.
- Check the result and the evidence behind it. A fluent reply is insufficient if it relies on the wrong version.
- Inspect the proposed action. Could the system send a commitment without the required approval?
- Withdraw a dependency or deny a permission in a safe test environment. Find out how the workflow stops and who receives the case.
- Make a controlled change, repeat the case and examine how a regression would be detected.
Use a representative set that also includes ordinary cases. Difficult cases reveal boundaries; routine cases reveal the cost and review workload you may face every day. Agree the test set before comparing proposals so each option faces the same standard.
A buying decision can still need your own architecture
A purchased tool does not define every handoff around it. In an Austrian business, a standard product might process the document well while a locally agreed approval rule, a German-language exception or a dependency on an existing system requires additional design.
Describe the missing capability precisely before deciding to customise. Can the product be configured within a supported boundary? Would a small controlled workflow around it be enough? Would the proposed custom layer make future updates or fault diagnosis harder?
Keep cross-border data and service arrangements explicit. A hosting-region label alone does not describe every support, logging or subprocessor path. Ask for the relevant documentation and involve your privacy and security specialists where needed. This guide provides architecture questions, not a determination of legal compliance.
Use four weeks to make the uncertainty smaller
The following is a suggested internal decision sequence. Adjust it to access and team availability; it is not a promise of implementation or a delivery schedule for the Architecture Mandate.
- Week 1: bound the workflow, name the decision owner and collect current volumes, exceptions and acceptance criteria.
- Week 2: complete the three-route comparison and responsibility worksheet. Ask suppliers and internal teams for missing evidence.
- Week 3: test representative cases and one recovery scenario. Replace important cost assumptions with observations where possible.
- Week 4: review the evidence with the sponsor. Select a route with explicit conditions, redesign the scope or defer the commitment.
Before accepting a recommendation, check five things: a bounded job, an accountable operating owner, demonstrated authority limits, an honest cost model and a usable fallback. A serious gap in any one of these needs a decision. Do not average it away with strengths elsewhere.
When an Architecture Mandate is useful
If your team can answer these questions and the decision is small enough to manage internally, use the worksheet and proceed through your own controls. External advice is useful when the choice has material consequences and the evidence spans teams that cannot yet agree on the operating design.
The Architecture Mandate examines one priority AI workflow and provides a documented decision, including business-case assumptions and a build, buy or integrate recommendation. The standard scope is €22,000 excluding VAT, with a planned 15–20 business days after mobilisation conditions are met. It is an advisory engagement; implementation, procurement, managed operation and legal opinions are outside the standard scope.
Bring a non-confidential description of the workflow, the choice facing you and the person responsible for it. The first conversation checks fit, evidence access, timing and budget. A proposal follows qualification.
Review the Architecture Mandate for your AI decision
If the route is already clear and the remaining question is release readiness, continue with the pilot-to-production decision framework.
Questions before you choose
Is buying an AI agent usually cheaper than building one?
There is no reliable answer without a defined workflow and operating assumptions. Compare setup, recurring charges, human review, maintenance and exit work over the same period and against the same acceptance criteria.
Does building mean training our own model?
No. You can build the workflow and application around externally supplied models. Document which parts you control and which model, platform and service dependencies remain external.
Who is responsible when a purchased agent makes a mistake?
Operational ownership and contractual liability are different questions. Name who detects, pauses, reviews and recovers the workflow; have the relevant specialists assess contractual and legal responsibility.
When does a combined approach make sense?
Consider it when a standard foundation fits but specific steps need your own controls or behaviour. Test the handoffs and assign an owner for failures that cross the boundary.
What if no option has enough evidence?
Reduce the scope, keep a human-led process or defer the commitment. Record the missing evidence and its owner rather than treating uncertainty as approval.
Editorial method: the comparison and worksheets are the author's architectural analysis. The example is illustrative. Linked supplier guidance supplies technical context, not endorsements or evidence of client outcomes. Sources reviewed on 20 September 2026.
Continue Reading
