Table of Contents
The conversation usually starts like this:
“We need an AI agent.”
Fine.
Then comes the next question:
“Should we build it or buy one?”
And suddenly the meeting splits into two camps.
Technology says:
“We should build. Our business is unique.”
Procurement says:
“Why build something that already exists?”
Finance says:
“Which is cheaper?”
Operations says:
“I just need it to work.”
The vendor says:
“Our platform can do everything.”
The developers quietly look at each other.
Because everyone in the room is asking the wrong version of the question.
In 2026, the choice is increasingly not:
Build
or:
Buy.
It is:
What should we own?
What should we rent?
What should we customize?
And where does our competitive advantage actually live?
That produces a third answer companies need to become comfortable with:
Blend.
Buy the commodity.
Build the differentiation.
Connect the two around your company’s data, workflow and rules.
For many companies, that will be the most sensible AI architecture.
Build vs. Buy Was Easier Before AI Agents
Traditional enterprise software made the distinction relatively clear.
You need accounting software?
Buy it.
CRM?
Usually buy it.
Something highly specific to your operation?
Perhaps build it.
An agent complicates the decision because an agent isn’t necessarily one application.
It may sit across:
your CRM,
ERP,
email,
documents,
website,
internal databases,
third-party APIs,
messaging,
payments,
and employee workflows.
It may also use:
a model you don’t own,
a platform you don’t own,
company data you do own,
custom business logic you should own,
and integrations somebody needs to maintain.
So what exactly are we building?
And what exactly are we buying?
That’s why Gartner’s 2026 research has moved away from a simple build-versus-buy question and toward a build, buy or blend framework for agentic automation. [1]
That distinction is important.
Most enterprises probably won’t build every layer themselves.
And they probably shouldn’t.
You Probably Shouldn’t Build the Model
Let’s begin at the bottom.
Suppose your company wants an agent that can:
qualify leads,
prepare proposals,
process invoices,
answer employee requests,
or coordinate customer support.
Do you need to build your own foundation model?
Almost certainly not.
The investment required to compete with frontier AI-model providers is enormous.
For most companies, the model will increasingly become an input.
Like:
cloud infrastructure,
databases,
payment infrastructure,
or operating systems.
You consume intelligence from providers.
Then create value on top.
This doesn’t mean model choice is irrelevant.
Different models have different:
performance,
cost,
latency,
security,
deployment options,
context limits,
tool capabilities.
But unless artificial-intelligence research itself is your competitive business, your moat probably does not come from training a general-purpose model from zero.
Microsoft’s 2026 platform strategy reflects exactly this shift: as models become increasingly capable and abundant, it argues that enterprise differentiation moves toward context, proprietary intelligence, business logic and how agents operate inside the organization. [2]
That is where the build/buy conversation becomes interesting.
The Model Is Not the Agent
This is another distinction executives should understand.
An agent might contain several layers.
Think about it this way.
Layer 1 — Intelligence
The model.
OpenAI.
Anthropic.
Google.
Microsoft-hosted models.
Open models.
Others.
Layer 2 — Context
What does the agent know about your business?
Customers.
Products.
Policies.
Contracts.
Transactions.
History.
Relationships.
Knowledge.
Layer 3 — Instructions and Business Logic
How should it behave?
What rules apply?
What should it prioritize?
What decisions can it make?
Layer 4 — Tools
What can it do?
Read CRM.
Create an opportunity.
Send an email.
Generate invoice.
Book meeting.
Issue refund.
Search inventory.
Layer 5 — Workflow
What sequence of actions produces the business outcome?
Layer 6 — Governance
Who can access what?
Which actions are permitted?
What requires approval?
What gets logged?
How is the agent monitored?
Layer 7 — Experience
Where does the agent appear?
Website.
Teams.
WhatsApp.
CRM.
Internal portal.
Or nowhere visible at all.
Your build/buy decision can be different at every layer.
That’s why asking:
“Should we build the agent?”
is too broad.
You Can Buy the Engine and Build the Car
Imagine your company builds custom logistics software.
You don’t manufacture:
processors,
servers,
network cables,
database engines,
and every programming language.
You build using existing components.
AI agents work similarly.
A company might:
buy access to a foundation model,
buy cloud infrastructure,
use an existing agent runtime,
use existing identity/security systems,
then build:
its own business logic,
workflow,
integrations,
knowledge architecture,
and customer experience.
Did you build or buy?
Both.
That’s increasingly normal.
Gartner Calls This “Blend”
And I think the term is useful.
Gartner’s July 2026 research frames enterprise agentic automation around three possibilities:
Build
Buy
Blend
rather than treating every AI requirement as a binary choice. [1]
Blending can mean:
existing enterprise application
commercial AI capabilities
custom integrations
custom workflow logic
your data.
That model often gives companies something they actually need:
speed without giving away all control.
When Should You Buy?
Buying is usually attractive when the work is:
Common.
Standardized.
Non-differentiating.
If thousands of companies need almost exactly the same capability, somebody will probably build a better product than your internal team can justify building alone.
Examples might include:
meeting transcription,
standard HR FAQs,
basic expense workflows,
common coding assistance,
document OCR,
routine scheduling,
generic employee productivity.
Ask:
If our competitor used exactly the same software, would we care?
If the answer is:
“Not really.”
that’s a strong buy signal.
The capability matters.
But it isn’t your competitive advantage.
Don’t Build Payroll Because You’re “Different”
Every company believes it is special.
Sometimes it is.
Sometimes the company says:
“Our payroll process is unique.”
Then you investigate.
It is mostly payroll.
With some unusual approvals.
Do not build a payroll system from zero because three screens need customization.
Configure.
Integrate.
Extend.
Companies have spent decades creating enormous technical debt because they confused:
“Our organization has requirements”
with:
“Our organization needs proprietary software.”
Those are not the same thing.
AI can repeat this mistake at much greater speed.
Buy When Time Matters More Than Uniqueness
Suppose an excellent commercial agent can solve 80% of your requirement in four weeks.
Custom development could solve 95%.
In nine months.
Which is better?
Depends on the business.
If being operational this quarter matters more than the final 15%:
buy.
You can learn from actual use.
You can discover whether the workflow deserves deeper investment.
You can refine requirements based on reality rather than a PowerPoint.
Speed has value.
Especially when the technology itself is changing quickly.
Buy When the Vendor Has an Unfair Structural Advantage
Imagine building an agent deeply embedded inside Microsoft 365.
It needs access to:
Outlook,
Teams,
calendar,
documents,
identity,
permissions.
A platform provider operating inside that ecosystem may have integration advantages that are difficult and expensive to reproduce.
Likewise:
an agent built deeply around Salesforce,
SAP,
Oracle,
ServiceNow,
HubSpot,
or another major enterprise platform.
Sometimes the vendor already possesses:
the data model,
permissions,
APIs,
workflow context,
security architecture.
Rebuilding all of that yourself simply to prove independence may not create much value.
Use the advantage.
But “It Already Exists” Is Not Enough Reason to Buy
Now let’s reverse the argument.
A vendor shows you an impressive demo.
Their sales agent can:
research leads,
write messages,
schedule meetings,
update CRM.
Wonderful.
Your company sells complex industrial systems across the GCC.
Your sales process contains:
technical qualification,
partner relationships,
custom pricing,
country-specific rules,
project history,
engineering constraints,
tender requirements,
commercial approvals.
The agent knows nothing about any of that.
Can you configure it deeply enough?
Can it connect to your systems?
Can it understand your sales methodology?
Can you control its decisions?
Can you inspect what it is doing?
Can you adapt it when the process changes?
If not, you’re not buying an agent.
You’re buying another software limitation employees will work around.
Build When the Workflow Is Part of Your Advantage
This is probably the most important criterion.
Ask:
Does the way we perform this work help us win?
Imagine two companies.
Both sell insurance.
One believes its underwriting process is significantly better because of:
proprietary data,
specialized risk models,
industry expertise,
unique decision logic.
Should it buy a completely generic underwriting agent?
Maybe parts of it.
But the core intelligence deserves stronger ownership.
Another company sees underwriting as largely standardized.
Its competitive advantage is distribution.
Buy becomes more attractive.
Same technology.
Different strategy.
If the Workflow Is Your Secret Sauce, Be Careful Who Owns the Kitchen
Businesses often think competitive advantage lives in:
products,
brand,
technology.
It also lives in processes.
How you:
qualify a customer,
price risk,
select investments,
optimize logistics,
detect fraud,
manage inventory,
serve strategic clients,
develop proposals
can be extremely proprietary.
If the agent becomes the place where those decisions live, then the agent architecture becomes part of your competitive infrastructure.
That does not automatically mean build everything internally.
It does mean:
don’t casually outsource the logic that makes you different.
Build When Your Data Creates Unique Value
Suppose every competitor can access the same model.
But you have:
15 years of customer history,
millions of transactions,
specialized product data,
industry-specific knowledge,
historical project outcomes,
service records,
proprietary research.
Now the competitive value doesn’t come primarily from the LLM.
It comes from how your agent can use your institutional knowledge.
Microsoft’s 2026 Build announcements describe this idea as organizational intelligence becoming a differentiating layer around agents rather than model access alone. [2]
That suggests an important architecture principle:
Rent intelligence when appropriate.
Own context where it matters.
Context May Become More Valuable Than Code
This is a subtle shift.
Companies traditionally protected:
source code.
In agentic systems, some of the most valuable intellectual property may instead become:
instructions,
workflow design,
decision criteria,
semantic models,
organizational knowledge,
exception logic,
evaluation datasets,
agent memory.
Two companies might use identical code and identical models.
But one has much richer context.
That company may produce dramatically better outcomes.
This means “custom AI” should not automatically mean:
we wrote everything ourselves.
It may mean:
the system understands us in a way generic software cannot.
That’s much more strategically relevant.
Build When Integration Is the Product
Remember Article 05?
Your First AI Agent Shouldn’t Be a Chatbot.
The highest-value agent often works across multiple systems.
That means integration isn’t a technical afterthought.
It is often the agent.
Imagine an operations agent that has to coordinate:
ERP,
CRM,
inventory,
email,
logistics API,
finance,
customer portal.
A commercial product might provide intelligence.
But if 70% of the implementation is adapting the workflow to your systems, buying an “off-the-shelf agent” may still involve significant custom work.
This is where Brightery’s approach to automating company operations becomes relevant: automation creates real value when systems, workflows and business rules are connected rather than when another isolated tool is added.
That is effectively a blend architecture.
Build When Your Customer Experience Depends on It
Imagine a luxury hospitality company in Dubai.
Its agent communicates with VIP customers.
Brand language matters.
Service standards matter.
Guest history matters.
Cultural context matters.
Escalation matters.
What counts as “good enough” is not generic.
A generic hotel chatbot may technically answer questions.
A proprietary service layer could understand:
the guest,
property,
preferences,
booking,
past experiences,
service-recovery policies,
and exactly when a human concierge should appear.
The difference is not:
AI vs AI.
It is:
generic capability vs branded operational intelligence.
That may justify custom development.
When Should You Blend?
For many enterprises:
Most of the time.
A blended architecture might look like:
Commercial foundation model.
Commercial agent runtime.
Existing CRM.
Existing identity platform.
Existing communication tools.
Then custom:
knowledge layer,
workflow logic,
integrations,
guardrails,
business rules,
customer experience.
This gives you access to innovation happening across the AI ecosystem without forcing your company to rebuild infrastructure that is becoming increasingly standardized.
At the same time, it protects the layers where your business actually differentiates.
Buy the Commodity. Build the Advantage.
If you remember one sentence from this article, make it this:
Buy the commodity.
Build the advantage.
Do not spend six months building something every competitor can buy for AED 500/month.
And do not outsource the workflow that determines why customers choose you.
Both mistakes are expensive.
There Is Another Option: Apply
Deloitte’s 2026 work on enterprise AI investment uses a similar idea when discussing build, buy or apply decisions: organizations need to prioritize where custom development is justified versus where existing capabilities can simply be configured and applied to a business process. [3]
I like this because many requirements don’t need either a major procurement program or a software-development project.
Sometimes:
the capability already exists.
You need to:
configure it,
ground it,
integrate it,
govern it,
deploy it.
The hardest work isn’t coding.
It is making the capability fit the business.
Stop Treating Custom as Automatically Better
There is a strange prestige attached to:
“We built our own AI.”
Congratulations.
Was that necessary?
Custom systems create obligations.
You own:
development,
maintenance,
testing,
monitoring,
security,
upgrades,
documentation,
knowledge transfer,
bugs.
The impressive prototype built by one brilliant developer becomes much less impressive after that developer leaves.
Custom architecture is not free strategic flexibility.
It is a permanent operational responsibility.
Build only when the control or differentiation justifies that responsibility.
Stop Treating SaaS as Automatically Cheaper
The opposite mistake exists too.
Commercial software looks cheap initially.
AED 100/user/month.
Easy.
Now:
2,000 employees.
Plus AI usage.
Plus agent actions.
Plus premium data features.
Plus integration.
Plus workflow modules.
Plus professional services.
Plus usage-based agent pricing.
Suddenly the “cheap” product is a major operating expense.
Agentic AI is already beginning to change enterprise-software economics.
Gartner estimates that as much as $234 billion of enterprise application SaaS spending could be exposed to what it calls agentic arbitrage by 2030, as agents increasingly perform work across applications and reduce the importance of traditional user-seat economics. [4]
Whether the exact market develops as Gartner projects or not, the direction matters.
How businesses buy software is changing.
Your three-year cost matters more than the introductory subscription.
Calculate Total Cost of Ownership
For buy, calculate:
license,
usage,
agent actions,
premium integrations,
implementation,
customization,
consulting,
data migration,
support,
additional modules,
contract growth,
switching cost.
For build, calculate:
developers,
AI engineering,
architecture,
testing,
cloud,
model usage,
monitoring,
security,
governance,
maintenance,
documentation,
support,
ongoing improvement.
Then calculate both across:
three years.
Not three months.
Build often looks expensive initially.
Buy can become expensive as scale increases.
The curves are different.
Model the Cost at 10× Volume
This is one of the most useful procurement questions.
The agent works beautifully at:
5,000 tasks/month.
Now imagine:
50,000.
What happens?
Does vendor cost increase:
2×?
10×?
20×?
Does infrastructure become expensive?
Does human review increase?
Do API calls explode?
Does the commercial license change tiers?
Don’t only price today’s agent.
Price successful adoption.
Because one of the worst possible outcomes is:
the agent works so well you can no longer afford it.
Watch the Pricing Unit
Traditional SaaS commonly prices:
per user.
Agents create different possibilities:
per agent,
per action,
per task,
per token,
per workflow,
per outcome,
per API request,
capacity-based pricing.
Each creates different incentives.
Imagine a customer-service agent.
If vendor pricing is:
per resolved case,
that’s directly connected to business volume.
Potentially good.
If:
per action,
and each resolution requires 40 actions,
economics change.
Understand the unit.
The pricing architecture can determine whether your business case survives scale.
Vendor Lock-In Is Not Just About the Model
Companies say:
“We don’t want model lock-in.”
Good.
But there are deeper forms.
You can become locked into:
agent memory,
workflow definitions,
proprietary tools,
data representations,
evaluation systems,
vendor-specific APIs,
permissions,
orchestration,
business logic.
Changing the model may be easy.
Moving the operating system around it may not be.
So ask:
What would be painful to move?
That’s your real lock-in.
The Most Dangerous Lock-In Is Institutional Knowledge
Suppose your agent learns:
customer preferences,
exception handling,
workflow improvements,
decision rules,
employee feedback
inside a vendor’s proprietary environment.
After three years, that agent understands your business much better.
Great.
Now try leaving.
Can you export:
the knowledge?
memory?
evaluations?
workflow rules?
decision history?
If not, switching vendors doesn’t just mean changing technology.
You may be abandoning organizational learning.
That deserves executive attention.
Ask the Exit Question Before Signing
Every major AI procurement should include:
“What happens if we leave?”
Can we export:
our data?
agent configurations?
prompts?
workflows?
logs?
evaluation history?
knowledge indexes?
Can we move to another model?
Can another agent call the same systems?
Can we reproduce behavior elsewhere?
What is contractually ours?
You hope never to exercise the exit plan.
But you should know whether one exists.
Model Flexibility Is Valuable
AI models are improving too quickly to assume today’s winner remains tomorrow’s best choice.
An architecture that tightly couples everything to one model may limit future flexibility.
Microsoft’s 2026 Foundry architecture explicitly emphasizes cross-framework and model choice, arguing that enterprises need the ability to build and operate agents without making the entire production system dependent on one framework from day one. [5]
That is sensible.
Where practical, separate:
business logic
from:
model dependency.
Then you can evaluate new models without rebuilding the company.
Open Does Not Mean Free
Another trap.
An open-source framework looks free.
Then you need:
engineers,
infrastructure,
deployment,
security,
monitoring,
support.
The license may cost zero.
Operating it does not.
Open technologies can be excellent for:
control,
flexibility,
portability,
customization.
But finance should compare:
total operational cost,
not:
software license.
Proprietary Does Not Mean Bad
Likewise, vendor dependency is not inherently foolish.
Companies depend on:
Microsoft,
AWS,
Google Cloud,
Salesforce,
SAP
for critical operations.
The question is whether:
benefit,
stability,
support,
economics,
control
justify that dependency.
Architecture is about intentional trade-offs.
Not purity.
The Build Decision Has Five Hidden Requirements
If you’re considering custom agents, ask whether you possess:
1. Product Ownership
Who decides what the agent should become?
A developer isn’t automatically the product owner.
2. Engineering Capability
Who builds it?
Who reviews it?
Who maintains it?
3. AI Evaluation Capability
How will you know performance is improving?
Agents need more than software testing.
Their behavior may vary.
4. Operational Capability
Can you monitor production continuously?
Microsoft describes production operation, evaluation, tracing, identity and governance as some of the hardest parts once an agent leaves prototype stage. [5]
5. Governance Capability
Who controls:
access,
permissions,
actions,
data,
risk?
If the answer to all five is:
“Our one AI developer.”
you may not have an enterprise build strategy yet.
You have a talented employee with an enormous future workload.
Building the Agent Is the Easy Part
This theme keeps appearing across 2026 enterprise research.
Prototype:
easy.
Production:
hard.
The agent itself may take days or weeks.
Then comes:
identity,
authorization,
integration,
observability,
evaluation,
security,
data,
reliability,
deployment,
versioning,
cost controls,
human escalation,
audit.
Microsoft’s Build 2026 guidance makes the comparison to microservices: creating one service was never the biggest problem; operating many reliably became the real infrastructure challenge. [5]
Agents are heading toward that same stage.
So a build estimate that includes only development hours is incomplete.
Buying Doesn’t Eliminate Production Work
Do not hear the previous section and think:
“Fine. We’ll buy.”
A purchased agent still needs:
data,
integration,
configuration,
permissions,
monitoring,
governance,
change management.
IBM makes this point explicitly in its 2026 agentic-control work: enterprises already have agents arriving from many sources—some built internally, some supplied by vendors, others embedded inside business applications—and the problem increasingly becomes operating and governing the whole estate together. [6]
Buying moves some responsibility to the vendor.
It does not eliminate enterprise responsibility.
You Need an Agent Control Plane Eventually
Imagine your company reaches:
5 agents.
Manageable.
Then:
Then:
Some built.
Some purchased.
Some embedded inside SaaS.
Different:
models,
frameworks,
owners,
permissions.
Now someone needs to answer:
Which agents exist?
What are they doing?
Who owns them?
Which systems can they access?
What do they cost?
Which are performing well?
Which violate policy?
IBM’s 2026 Agentic Control Plane announcement is effectively a response to that emerging problem: central visibility, governance, reuse and operation across heterogeneous agents. [6]
This tells us something important about build vs. buy.
Even if you choose different approaches at the agent level, you may still need a common enterprise management layer.
Don’t Let Every Department Make the Decision Alone
Marketing buys one agent.
Finance builds another.
HR adds AI inside its SaaS.
Sales creates agents with a no-code platform.
Developers build custom agents.
Operations contracts a vendor.
Two years later:
nobody knows how many agents exist.
This is agent sprawl.
You do not need to centralize every innovation decision.
But you do need some architecture standards.
For example:
approved models,
identity standards,
logging requirements,
data policies,
integration patterns,
evaluation standards,
human-approval controls.
This gives teams freedom without creating chaos.
The Agent Architecture Question
Before choosing build or buy, draw the system.
For example:
Customer Request
↓
AI Agent
↓
Company Knowledge
↓
Business Rules
↓
CRM ←→ ERP ←→ Payments
↓
Human Approval (when required)
↓
Customer
Now ask at each layer:
Should we own this?
Maybe:
Model → buy.
Agent platform → buy.
Company knowledge → own.
Business rules → own.
CRM → buy.
ERP → buy.
Integration → customize.
Customer experience → own.
That is a far more useful discussion than:
Build vs Buy?
What Should Almost Every Company Own?
I would strongly consider ownership over:
Business Definitions
What is a qualified lead?
What is a high-risk customer?
What is a priority case?
Decision Rules
When is escalation required?
What financial threshold applies?
Company Knowledge
Policies.
Products.
Customers.
History.
Workflow Intent
What outcome are we trying to produce?
Evaluation Standards
What does “good” mean?
Agent Authority
What may it actually do?
These are not merely technical configurations.
They encode how your company operates.
Treat them accordingly.
What Can Usually Be Rented?
Depending on the business:
foundation models,
cloud runtime,
commodity APIs,
standard productivity capabilities,
generic search,
standard software functions,
certain monitoring/security capabilities.
The provider can often invest more heavily than one company reasonably should.
Again:
buy the commodity.
Build the advantage.
The Competitive-Advantage Test
Ask these five questions.
1.
Would a competitor benefit equally from exactly the same agent?
Yes?
Leaning buy.
2.
Does the workflow encode proprietary knowledge or decision-making?
Yes?
Leaning build/blend.
3.
Does customer experience depend on this capability?
Yes?
Stronger customization may be justified.
4.
Would vendor constraints prevent us from changing the workflow as our business evolves?
Yes?
Leaning build/blend.
5.
Would owning this capability create long-term strategic leverage?
Yes?
Invest more heavily.
The Speed Test
Ask:
How quickly does this capability need to exist?
Need it in 30 days?
Buy/apply becomes attractive.
Need a strategic capability over three years?
Custom investment becomes more reasonable.
Still don’t know whether it creates value?
Do not build the final architecture.
Test cheaply.
This connects directly to Article 03:
Your AI Pilot Worked. Your Transformation Didn’t.
Use pilots to learn.
Not as excuses to build permanent systems prematurely.
The Complexity Test
Commercial products are attractive when your workflow resembles the market.
They become less attractive as complexity increases.
Score:
number of systems,
number of decision types,
data sources,
exceptions,
country requirements,
customer variations,
approval structures.
At some level, forcing commercial software to support your operation can become more expensive than customizing the architecture.
Customization cost grows.
But so does configuration complexity.
Compare honestly.
The Data Test
Ask:
Where must sensitive data go?
A purchased agent may require sending data into external infrastructure.
Can it support:
UAE requirements,
industry requirements,
customer contracts,
data residency,
privacy obligations,
internal security?
Different companies will reach different answers.
An architecture suitable for a marketing content agent may not be suitable for:
health records,
financial decisions,
government data.
Do not apply one AI procurement rule across every workflow.
The UAE Adds Another Architecture Question
For businesses operating in the UAE and GCC, the system may need to handle:
Arabic,
English,
multiple regulatory environments,
cross-border data,
local customer expectations,
WhatsApp-heavy workflows,
regional payment/service systems.
A global agent product may solve 80%.
The last 20% can be the entire business.
That makes blend especially relevant.
Use mature global technology.
Customize it around local operating reality.
Udjat Already Uses This Logic in Marketing Automation
Udjat’s own Marketing Automation in Dubai proposition makes a useful point:
the objective is not to select a CRM or automation platform first.
The workflow should begin with:
customer journey,
ownership,
lead routing,
handoffs,
and the business outcome.
Then technology is connected around it.
The same philosophy applies to AI agents.
Do not begin with:
“Which agent platform should we buy?”
Begin with:
“What outcome are we redesigning?”
Then choose architecture.
Udjat’s AI Marketing Automation UAE insight applies the same principle to marketing: value comes from connecting automation, customer data, segmentation, qualification and sales execution rather than adding AI as another isolated feature.
That is essentially the difference between buying technology and designing an operating system.
Brightery Makes the Case for the Custom Layer
Where an organization needs:
custom workflow,
deep system integration,
proprietary business logic,
or software built around how the company specifically operates,
custom development becomes more defensible.
Brightery’s AI-Empowered Software approach focuses on tailored intelligent systems rather than one-size-fits-all solutions.
And its AI Transformation work emphasizes the combination of strategy, integration and execution rather than tool deployment alone.
That is exactly the category where:
blend
can outperform both extremes.
You don’t build artificial intelligence from zero.
You build your business around intelligent components.
Example: Lead Qualification Agent
Imagine a UAE B2B company.
Should it buy?
Existing platforms can handle:
lead capture,
basic enrichment,
CRM,
email sequencing.
Buy those.
But perhaps qualification depends on:
company size,
country,
sector,
historical relationship,
website behavior,
specific service interest,
margin,
sales capacity,
strategic account lists.
That logic is proprietary.
Build/configure it.
Now the agent:
uses purchased CRM,
purchased enrichment,
purchased foundation model,
custom qualification logic,
custom integration.
Build or buy?
Blend.
Exactly.
Example: HR Employee Support Agent
The company needs:
policy answers,
leave questions,
basic employee requests,
document retrieval.
These are fairly standard.
Buy/configure may win.
But suppose the company has:
complex regional employment policies,
custom onboarding,
proprietary learning programs,
multiple HR systems.
Then extend.
Do not rebuild HR software.
Build the missing intelligence around it.
Example: Investment Decision Agent
Now imagine a family office.
The agent supports:
investment research,
portfolio monitoring,
deal assessment.
The firm’s investment philosophy itself is valuable.
Its:
criteria,
risk tolerance,
historical decisions,
portfolio context,
proprietary research
may form strategic IP.
Buying a generic investment agent and making it the center of the decision system could be a mistake.
Buy:
models,
market feeds,
infrastructure.
Own:
decision framework,
knowledge,
evaluation,
workflow.
Blend again.
Example: Real-Estate Agent
Generic capability:
answer property questions.
Commercial product may be enough.
Strategic capability:
understand thousands of listings,
match buyer intent,
identify investment preferences,
qualify financing,
coordinate broker availability,
schedule viewing,
update CRM,
follow up across WhatsApp,
respect developer-specific commercial rules.
Now customization becomes more valuable.
The customer sees one conversational interface.
Underneath sits an operating system.
The Build/Buy Decision Changes Over Time
Another important point.
Your answer today does not need to be your answer forever.
Year 1
Buy.
Learn the workflow.
Prove value.
Year 2
Customize.
Integrate more deeply.
Year 3
Build proprietary layers around the highest-value capabilities.
Or the opposite.
Year 1
Build a custom prototype because the market lacks a solution.
Year 2
Commercial products catch up.
Migration may become cheaper than maintaining custom infrastructure.
Good architecture should preserve the option to change.
Do not treat build/buy as a marriage vow.
Avoid the Sunk-Cost Trap
The company spent:
AED 2 million building an agent.
A year later, a platform offers something better for:
AED 200,000.
Leadership says:
“But we’ve already invested AED 2 million.”
Irrelevant.
That money is gone.
The question is:
Which architecture produces the best future economics?
The same applies to software you bought.
Do not continue paying for an inferior platform because migration would make the original procurement decision look bad.
Technology changes.
Architecture decisions need periodic review.
The 3-Year Build vs. Buy Model
Do not compare only Year 1.
Create a model.
| Cost | Build | Buy | Blend |
|---|---|---|---|
| Initial implementation | High | Low/Medium | Medium |
| Speed to market | Slower | Fast | Medium/Fast |
| Customization | Very high | Limited/Medium | High |
| Internal control | High | Lower | Medium/High |
| Maintenance burden | High | Lower | Medium |
| Vendor dependency | Lower* | High | Medium |
| Integration flexibility | High | Product-dependent | High |
| Differentiation | Potentially high | Lower | High |
| Scaling economics | Depends | Depends on pricing | Depends |
| Talent requirement | High | Lower | Medium |
*Custom builds still depend on cloud, models, frameworks and other vendors.
No architecture is truly independent.
Don’t Ignore Opportunity Cost
Suppose your engineering team spends:
six months building an internal HR agent.
What didn’t they build?
A customer product?
Revenue feature?
Critical integration?
Opportunity cost belongs inside the build decision.
A system can be technically worth building and strategically still be the wrong use of scarce engineering capacity.
Executives should ask:
“Is this the best thing our technical team can build?”
Not merely:
“Can they build it?”
Scarce Engineering Talent Should Work on Differentiation
This is a principle I’d apply strongly.
Do not use your best AI engineers recreating generic software unless there is a compelling reason.
Use them where:
your data,
workflow,
IP,
customer proposition,
or operating model
makes custom capability economically meaningful.
Let vendors commoditize commodities.
You concentrate talent where owning technology changes your position.
Buying Also Consumes People
A vendor proposal sometimes creates the illusion:
Sign contract.
Agent works.
No.
Someone still needs to:
define requirements,
integrate systems,
configure access,
clean data,
test,
train users,
govern,
manage vendor,
evaluate results.
A bought system can be cheaper.
It is almost never organizationally free.
Include internal workload in the business case.
The Build vs. Buy Decision Framework
I would score ten dimensions.
Each from:
1 → strongly buy
to:
5 → strongly build/customize
1. Strategic Differentiation
Is the capability part of why we win?
2. Process Uniqueness
How different is our workflow from the market?
3. Proprietary Data Advantage
Does our information materially improve the agent?
4. Integration Complexity
How deeply must it connect across our systems?
5. Control Requirements
How important is owning behavior, permissions and release decisions?
6. Security / Regulatory Requirements
Do we have unusual deployment constraints?
7. Speed
How quickly must the capability launch?
High urgency pushes buy/blend.
8. Internal Capability
Can we actually operate what we build?
9. Scale Economics
What happens to costs at expected volume?
10. Market Maturity
Does a good commercial solution already exist?
If yes, don’t pretend it doesn’t.
Interpreting the Score
10–20
Strong BUY/APPLY candidate.
Commodity capability.
Move quickly.
21–35
Strong BLEND territory.
Probably the largest category.
Use platforms/components and customize important layers.
36–50
Potential BUILD/CUSTOM candidate.
Especially if strategic differentiation, proprietary data and control are high.
This is not mathematics.
It is structured management thinking.
One Question Can Simplify Everything
Ask:
If we execute this capability exceptionally well, will customers choose us because of it?
No?
Probably don’t overbuild.
Yes?
Ownership becomes much more interesting.
Another Question: Does Owning It Improve Our Economics?
Customization can create advantage even when the customer never notices.
Perhaps a proprietary operational agent enables:
lower cost,
faster execution,
higher capacity,
better pricing.
That can still justify building.
Competitive advantage does not need to be customer-visible.
Another Question: Can We Maintain It?
This is where CEO ambition meets operational reality.
A custom system without maintenance becomes:
legacy software remarkably quickly.
Who updates the agent when:
models change?
APIs change?
systems change?
policies change?
employees change?
regulations change?
the business changes?
Building is a commitment to an operating lifecycle.
Not a one-time project.
Every Custom Agent Needs a Product Owner
Who owns:
roadmap?
performance?
business outcome?
permissions?
improvement?
Not just IT.
If the agent materially operates part of finance, someone in finance should own the result.
If sales:
sales.
If customer service:
service leadership.
This connects back to Article 03.
A major reason AI pilots fail to scale is that technology ownership exists without business ownership.
Do not repeat that problem at architecture scale.
Every Bought Agent Needs an Owner Too
Vendor does not equal owner.
The vendor may own:
software.
Your company owns:
what it does to your customers and business.
So even purchased agents need internal ownership of:
results,
configuration,
quality,
risk.
You cannot outsource accountability.
Procurement Needs New Questions
When evaluating an agent vendor, don’t only ask for features.
Ask:
Data
What data do you store?
Where?
For how long?
Models
Which models are used?
Can we choose?
Can they change without notice?
Training
Is our data used to improve vendor models?
Integration
Which systems can the agent act inside?
Identity
Does every agent have a distinct identity?
Permissions
Can we restrict actions granularly?
Audit
Can we see exactly what happened?
Evaluation
How do we measure agent quality?
Portability
What can we export?
Economics
What happens to cost at 10× volume?
Exit
How do we leave?
These questions are considerably more valuable than:
“Does it support GPT-5?”
Vendor Maturity Matters More Now
Gartner’s 2026 work on enterprise AI coding agents makes an important point that applies beyond coding: as enterprise agent markets mature, buyers need to evaluate not only technical performance but also:
governance,
support,
pricing clarity,
enterprise readiness,
commercial maturity,
and vendor durability. [7]
A brilliant startup demo is exciting.
Will the company exist in three years?
Can it support enterprise security?
Will pricing remain sensible?
Can it operate at your scale?
Those are architecture questions too.
Don’t Choose the Best Demo
Choose the best operating model.
Demo:
Agent writes an incredible sales email.
Impressive.
Operating question:
Can it:
use our CRM?
respect permissions?
remember customer history?
route correctly?
work in Arabic and English?
escalate?
avoid sending something inappropriate?
report ROI?
operate reliably at 100,000 interactions?
That’s what matters.
Enterprise AI will increasingly be won after the demo.
Agent Architecture Is Business Architecture
This is the deeper argument.
Your agent architecture determines:
where your knowledge lives,
who controls decisions,
how workflows operate,
which vendors become critical,
how costs scale,
how quickly you can change.
Those are not minor IT details.
They influence:
margin,
speed,
risk,
competitive advantage.
Which means build vs. buy should not be left entirely to:
IT,
procurement,
or an AI committee.
Business strategy belongs in the room.
A Better Leadership Conversation
Instead of:
“Should we build or buy an AI agent?”
Ask:
Business
What outcome does this agent own?
Strategy
Is the workflow differentiating?
Process
How unique is our way of doing it?
Data
Which proprietary context matters?
Technology
Which layers already exist as mature products?
Integration
What must connect?
Control
What do we need to own?
Economics
What does each architecture cost at scale?
Risk
What happens if vendor/system fails?
Talent
Can we operate the custom layer?
Exit
How difficult is it to change later?
Now the answer usually becomes much clearer.
The Architecture I Expect to Win Most Often
For many established businesses:
Model
Buy/access.
Infrastructure
Buy/cloud.
Commodity tools
Buy.
Agent platform
Often buy/use existing platform.
Company context
Own.
Business rules
Own.
Strategic workflow logic
Own/customize.
Integrations
Build/configure as required.
Customer experience
Own where strategically important.
Governance
Enterprise-wide control.
This is not universal.
But it is a powerful default.
The Future May Be Less “Software We Use”
And more:
“Capabilities We Assemble.”
Historically, you buy CRM software.
Employees live inside its interface.
Agentic AI may change this.
An agent can potentially operate across:
CRM,
ERP,
email,
documents,
payments
without employees manually opening every application.
Gartner’s 2026 analysis argues that this could weaken the traditional relationship between software value and user-seat growth, with agents increasingly consuming application capabilities on behalf of people. [4]
That has a huge implication.
Companies may begin caring less about:
Which software screen is best?
And more about:
Which capability can our agent access?
That is another reason architecture flexibility matters.
Agents Could Make Some Software Invisible
Imagine the employee says:
“Prepare the renewal proposal for Emirates Logistics.”
The agent:
retrieves CRM data,
checks usage,
retrieves pricing,
reviews contract,
generates proposal,
routes approval,
updates CRM.
The employee may never open four of the applications involved.
The software still exists.
But it becomes infrastructure.
This changes the strategic value of interfaces.
And may change which tools companies choose to own.
Build vs. Buy Will Become Continuous
The old model:
Choose ERP.
Use for ten years.
Agentic AI will move faster.
Architecture needs regular reassessment.
Every 6–12 months, ask:
Which custom capabilities are now commoditized?
Which vendor capabilities became strategically important?
Which costs changed?
Which models improved?
Which integrations became standard?
Which agent should we retire?
This is not instability.
It is modern technology management.
The Build/Buy Mistake I Fear Most
Not choosing the wrong platform.
Something deeper.
Companies may outsource understanding of their own operations.
A vendor implements agent.
Consultant writes prompts.
Integrator creates workflow.
Nobody internally understands:
why decisions happen,
how agent works,
where knowledge lives.
Then leadership says:
“The AI runs it.”
Dangerous.
Even when you buy the technology, retain organizational understanding.
Own:
why,
rules,
decision rights,
metrics.
Technology can be outsourced.
Responsibility cannot.
The Company After AI Must Know What It Owns
When everything was physical, ownership was easy.
Factory.
Inventory.
Buildings.
Then digital companies learned to think about:
software,
data,
IP.
The agentic company needs another inventory.
What do we own?
Models?
Probably not all.
Agents?
Some.
Workflows?
Yes.
Knowledge?
Absolutely.
Decision systems?
Potentially.
Evaluation data?
Should.
Customer context?
Definitely.
The most valuable assets of the company after AI may not look like traditional assets.
But they deserve strategic protection.
The Decision in One Page
If your leadership team needs the short version:
BUY when:
The workflow is common.
A mature solution exists.
Speed matters.
Differentiation is low.
Vendor integration advantage is high.
You lack internal technical capability.
BUILD when:
The workflow creates strategic advantage.
Your proprietary data matters deeply.
The process is highly unique.
Control is strategically important.
Commercial solutions cannot support the operation.
You possess the capability to maintain it.
BLEND when:
You need commercial speed
but
custom:
context,
integration,
rules,
workflow,
or experience.
Which means:
blend will probably be the answer more often than leadership initially expects.
Don’t Build Your AI Company Like a Collection of AI Projects
Article 03 argued that companies are becoming trapped in pilots.
There is a similar risk here.
Agent 1 uses one framework.
Agent 2 another.
Agent 3 belongs to CRM vendor.
Agent 4 is custom Python.
Agent 5 is built inside Microsoft.
Agent 6 comes from marketing SaaS.
Soon:
30 agents.
No architecture.
The answer is not necessarily one vendor.
The answer is:
coherent standards.
Identity.
Access.
Governance.
Observability.
Knowledge.
Economics.
Ownership.
Interoperability.
IBM’s 2026 work around agent control planes reflects how quickly this problem is becoming real as enterprises begin operating agents built across different teams, vendors and frameworks. [6]
Plan for plurality.
Don’t plan for chaos.
Your Competitive Advantage Is Probably Not “We Have AI”
Every competitor can have AI.
Every competitor can access strong models.
Every competitor can buy agent platforms.
So ask:
What do we know?
How do we operate?
What data do we possess?
How quickly can we redesign?
How effectively can our systems work together?
What customer context can we activate?
How intelligently can we allocate humans and agents?
That’s where differentiation moves.
Not:
artificial intelligence.
But:
organizational intelligence.
And that is exactly why build versus buy cannot be answered by the technology department alone.
So: Build or Buy?
Neither question is sufficient.
The better answer is:
Own what makes you different.
Buy what makes you functional.
Blend what makes the two work together.
If a vendor can provide excellent infrastructure:
use it.
If a foundation model can provide world-class intelligence:
use it.
If a commercial agent solves a commodity process:
use it.
But if your:
workflow,
knowledge,
customer experience,
or decision system
creates competitive advantage—
don’t give it away casually.
Build the layer that deserves to belong to you.
Because in the company after AI, one of the most important strategic questions will not be:
“Which AI do we use?”
It will be:
“Which part of our intelligence do we own?”
And companies that answer that question well will have something much more valuable than a collection of impressive agents.
They will have an operating system competitors cannot simply subscribe to.
What’s Next in The Company After AI
10 — Your AI Is Only as Good as the Data It Can Reach
You bought the model.
Built the agent.
Connected the interface.
Then someone asks:
“Why doesn’t it understand our business?”
Because your company’s most valuable knowledge is scattered across:
CRM,
ERP,
email,
documents,
SharePoint,
Google Drive,
spreadsheets,
WhatsApp,
databases,
and people’s heads.
The next article explores one of the biggest constraints on enterprise AI:
the AI can think—but it cannot see the company.
We’ll examine:
data readiness,
structured vs. unstructured knowledge,
RAG,
enterprise search,
permissions,
data quality,
institutional memory,
and why the AI race may ultimately become a race to organize what the company already knows.
Related Udjat Insights
For organizations connecting AI architecture to customer journeys, CRM and business operations:
Series Internal Links
As permanent Udjat URLs become available, connect this article contextually to:
01 — Your Company Doesn’t Need an AI Strategy
02 — Stop Asking “Where Can We Use AI?”
03 — Your AI Pilot Worked. Your Transformation Didn’t.
04 — Don’t Automate a Bad Process
05 — Your First AI Agent Shouldn’t Be a Chatbot
06 — What Should Humans Do, and What Should AI Do?
07 — AI Saved 10 Hours. Where Did the Money Go?
08 — Should You Hire Another Employee—or Deploy an Agent?
The strongest internal links should be:
Article 03 for production architecture and ownership.
Article 05 for agent selection and workflow design.
Article 07 for total-cost and ROI analysis.
Related Brightery Insights
For businesses where the answer involves custom systems, integrations or workflow development:
Sources
[1] Gartner — “Agentic Automation: Decide When to Build, Buy or Blend,” July 8, 2026. Gartner frames agentic automation as a build, buy or blend decision rather than a simple binary choice, noting that enterprises increasingly combine purchased solutions, existing automation platforms and internally developed capabilities.
[2] Microsoft — Build 2026, “Be Yourself at Work,” June 2, 2026. Microsoft argues that as access to capable AI models expands, enterprise differentiation increasingly comes from ownership of organizational context, institutional knowledge, business logic and the way agents operate using company-specific intelligence.
[3] Deloitte — Enterprise AI Navigator, February 26, 2026. Deloitte describes enterprise AI portfolio decisions across operational, workforce, regulatory and technology dimensions and explicitly includes smarter “build, buy, or apply” choices as companies design agentic solutions.
[4] Gartner — “$234 Billion in Enterprise Application Software Spend Is at Risk From Agentic AI,” July 1, 2026. Gartner estimates that up to $234 billion of enterprise application SaaS spending may be exposed to agentic arbitrage by 2030 as agents perform work across multiple systems, potentially weakening traditional per-user software economics.
[5] Microsoft Foundry — “Build and Run Agents at Scale With Microsoft Foundry at Build 2026,” June 2, 2026. Microsoft describes how production agent development extends far beyond prototyping into integration, enterprise knowledge grounding, runtime, identity, observability, evaluation and governance. It also emphasizes framework and interoperability flexibility to reduce unnecessary architectural lock-in.
[6] IBM — Agentic Control Plane / watsonx Orchestrate, May–July 2026. IBM says enterprises increasingly operate heterogeneous agent estates containing internally built agents, vendor agents and agents embedded in applications, creating a need for centralized visibility, governance, reuse and operational control across frameworks.
[7] Gartner — Enterprise AI Coding Agent Market, May 20, 2026. Gartner argues that enterprise agent selection needs to consider not only model performance and developer experience but governance, support, pricing, workflows, commercial maturity and vendor durability for medium- and long-term commitments.
[8] Gartner — “The New Application Strategic Framework for Build vs. Buy With AI,” July 20, 2026. Gartner argues that agentic AI is changing traditional enterprise application strategy and recommends evaluating business capabilities before determining where applications and AI capabilities should be bought, built or composed.
