Most teams ask the AI agent question too early: should we build it or buy it?
That sounds responsible. It is also too blunt to produce a good architecture decision.
An agent is not one thing. It may include a model, user interface, workflow logic, connectors, identity, approval rules, memory, monitoring, and support. Buying a platform does not remove the integration work. Building a custom agent does not mean you should train a model or recreate commodity infrastructure.
The better decision is component by component: what should we buy, what should we configure, what must we integrate, and what is worth owning?
Start with the workflow. The workflow tells you where the business value sits, where mistakes become expensive, and where a generic product stops fitting.
First, split the agent into parts
A polished demo hides architecture. It makes the agent look like one product doing one job. Production is messier.
The model interprets requests and produces output. The workflow layer decides what happens next. Connectors move information between the agent and systems such as your CRM, ERP, ticketing platform, document store, or phone system. Identity and permissions control what the agent can see and change. Approval rules keep selected actions with a person. Logs, evaluation, and support tell you whether the system worked and who fixes it when it did not.
Your company does not need to own every layer. It does need to know who owns each one.
The NIST Generative AI Profile recommends inventorying generative AI systems and defining any inventory exemptions for AI embedded in application software. Suggested inventory details include data provenance, known issues, human oversight roles, underlying models, model versions, and access modes. NIST also recommends updating procurement reviews for AI vendors, APIs, embedded tools, and open-source components.
This record becomes useful when a vendor changes the model, a connector fails, or an employee questions an action. The team can identify which layer produced the result and who can correct it.
Buy the parts that are already commodities
Buy when the requirement is common, the product fits the workflow without heavy distortion, and the vendor can meet your control and service requirements.
User authentication, model access, basic orchestration, administrative interfaces, standard connectors, and routine monitoring may not create any competitive value for your company. Rebuilding them can create a larger maintenance burden without making the business outcome better.
A packaged agent can also make sense when one application already contains the people, data, and actions needed for the workflow. If the job starts and ends inside a mature CRM or service platform, its embedded automation may be easier to deploy and support than a separate custom system.
But "available in our current platform" is not the same as "ready for our workflow." Test permissions, data use, exception handling, export options, usage charges, support boundaries, and the exact actions the agent can take. Ask what changes when the vendor swaps an underlying model or retires a connector.
Buy the commodity capability. Do not outsource the decision about how work should run.
Integrate when the value lives between systems
Many useful AI workflows cross application boundaries. A lead-intake agent might capture a request, check account context, route it, create a CRM record, draft a response, and ask a person to approve the next action. No single system owns that entire job.
This is where integration usually matters more than model selection.
You may buy the model and orchestration platform, use existing systems of record, and build the workflow logic and connectors that make them work together. The custom value sits in the operating path that reflects your rules, data, handoffs, and customer commitments.
Integration earns its keep when it removes rekeying, reduces lost handoffs, enforces an approval, or gives the business one traceable result across several tools. It becomes expensive glue when the team keeps connecting a poorly defined process to more software.
If the workflow is still changing every week, stop. Use the seven-point workflow readiness test before adding more architecture. AI does not settle an argument about who owns the work.
Build only where ownership matters
A custom build deserves consideration when the workflow creates meaningful differentiation, packaged products cannot support a necessary control, or the economics at your expected volume clearly favor ownership.
There are other reasonable triggers. Your team may need a specialized data boundary, a unique approval model, portability across model providers, or control over the interface customers use. A packaged tool may force employees into a process that conflicts with how the business operates.
Custom does not mean starting from zero. A sensible build may still use a commercial model API, an identity provider, managed databases, and proven monitoring tools. Own the workflow behavior that matters. Rent the plumbing when renting it is cheaper and safe.
Be honest about the operating commitment. Someone must maintain prompts and rules, test model changes, repair connectors, review failures, manage access, watch costs, and support users. If the project budget pays for a launch but nobody owns month six, you did not choose to build. You chose to accumulate an unsupported system.
Score the workflow before scoring vendors
Use these questions to choose the ownership boundary:
How unique is the workflow? If your competitors run nearly the same process, a packaged product may be enough. If the workflow carries your pricing logic, customer experience, or operating advantage, own more of its behavior.
Where does the source of truth live? A workflow contained in one platform favors buying. A workflow that depends on several systems usually requires deliberate integration.
How costly is a wrong action? High-consequence work may require custom approval gates, narrower permissions, stronger logs, or a design that keeps final authority with a person.
How much change should you expect? Frequent policy, data, or system changes raise maintenance costs. Decide whether a vendor or your team is better positioned to absorb them.
What must remain portable? Identify the workflow definitions, prompts, evaluations, data mappings, logs, and records you need if a model or platform changes.
Can you operate what you build? Name the owner, support path, monitoring process, change test, and shutdown authority. If those names and processes do not exist, reduce the custom scope.
What does a successful case cost? Compare full cost per correctly completed business outcome. Include licenses, model usage, integration, testing, review, exceptions, monitoring, and support. The site's AI ROI framework can help you build the broader cost model.
Watch the hidden cost in every option
Buying hides implementation work. A license does not clean data, settle permissions, redesign approvals, or train the team.
Integrating hides dependency risk. Every API, webhook, credential, and field mapping can fail or change. The design needs retry rules, duplicate protection, alerting, and a manual path.
Building hides operating work. The first release is only the start. Models, policies, source systems, and user behavior all change.
Ask vendors and implementation partners for one cost model that covers setup and steady-state operation. Require assumptions for transaction volume, model usage, connector fees, environments, monitoring, support, and internal labor. Then model a normal month, a growth month, and a bad month with extra exceptions.
A low subscription price can still support an expensive workflow. A larger implementation can still be the better choice if it removes enough manual work and remains supportable. Architecture should follow the business case, not the other way around.
Protect the exit before signing
The ownership decision is incomplete until you can explain how the company changes direction.
Ask which parts can be exported in a usable format. Confirm who owns workflow configurations, prompts, logs, evaluation data, and custom code. Document API rate limits, connector dependencies, model substitutions, data retention, deletion, and post-termination access. Put support responsibilities and service expectations in writing.
NIST's GenAI Profile recommends well-defined contracts and service-level agreements for areas including ownership, usage rights, quality, and security. It also calls for supplier risk assessment and ongoing monitoring of third-party AI risk. Those questions apply whether you buy a complete product or assemble several services behind a custom interface.
Some vendor dependence is normal. Make it intentional, price it, and keep a workable exit.
Pilot the ownership boundary, not only the agent
A pilot should prove more than output quality. It should test whether your chosen split between vendor, integrator, and internal team works under real conditions.
Run normal cases and ugly ones. Use missing data. Revoke a credential. Make an API unavailable. Send an out-of-scope request. Trigger an action that requires approval. Confirm that the system stops correctly, preserves context, and tells the right owner what happened.
Measure the business outcome, correction work, exceptions, reliability, control performance, and full cost. Use the production scorecard to keep the decision tied to the workflow.
Then make the call. Buy more if the product handles the requirement cleanly. Build the narrow piece the business needs to control. Integrate only where the handoff creates measurable value. Stop if the workflow or economics do not hold up.
Own the decisions that shape the workflow. Rent or buy the rest when the controls and economics hold up.