Most businesses need a licensed platform, a custom integration, or both.
The choice is rarely a pure build or buy decision. Products such as Microsoft Copilot, ChatGPT Enterprise, Google Gemini for Workspace, and Salesforce Agentforce give staff a capable assistant inside tools they already use. A custom AI agent is software built for a specific task in your operation, connected to your systems and governed by your rules. Many businesses end up using each where it fits.
The practical question is where the work lives. If the task happens inside email, documents, meetings, and a mainstream CRM, a licensed product may cover it with little configuration. If the task depends on an ERP with custom fields, a practice system, an internal application, or an older database, the product will need help reaching it, and that help is custom work.
A useful way to frame the decision is to separate the conversation from the actions. Licensed products are strong at conversation, drafting, and summarizing. The actions that change records in your systems are where business rules, permissions, and approvals matter most, and those are often better built once in an integration layer that any assistant the business chooses can call.
Off-the-shelf products handle everyday knowledge work and mainstream systems well.
Licensed assistants are good at the work that looks similar across companies: summarizing a meeting, drafting a reply, searching documents the user can already open, and answering questions about files in a shared drive. They arrive with identity, administration, and data handling terms already defined, which saves the effort of designing those from scratch for common tasks.
They also come with connectors to widely used systems. A CRM vendor’s agent product understands that vendor’s records, and a workplace assistant understands the vendor’s email and document tools. When the task sits entirely inside those systems and the product’s actions match what you need, configuration usually beats construction. Check the connector list against the systems the task really uses before assuming it covers them.
The product’s roadmap is also someone else’s responsibility. New models, new features, and security updates arrive without a project on your side. For tasks that are common, low risk, and not a source of competitive difference, that is a real advantage. The cost is per-seat licensing and accepting the product’s idea of how the task should work.
Products reach their limits at internal systems and business-specific rules.
The limits show up when the work leaves the vendor’s systems. An ERP customized over many releases, a practice management system with a narrow API, a warehouse database with no API at all, or an internal application built in-house will not appear in a product’s connector list. The assistant can talk about the work but cannot see or change the records that matter.
Business rules are the second limit. A product can be told that returns over a threshold need approval, but that instruction is advice to a model. If the rule matters, it has to be enforced where the action runs. Products vary in how much of that they allow you to configure, and the rules specific to your business are often the ones they handle least well.
The third limit is visibility. When an action goes wrong, you need to know who asked, what the agent called, what the system returned, and what changed. Check whether the product gives you that record in a form your team can search and keep, and whether it covers actions taken in systems the vendor does not make.
The common answer is a licensed product plus a custom integration layer.
In many businesses the best arrangement keeps the licensed assistant as the place staff talk to, and adds a custom integration layer that gives it approved actions in internal systems. The layer is a small API or an MCP server that exposes actions such as look up an order or create a service ticket, with permissions, limits, approvals, and logging enforced in code.
This arrangement protects the investment on both sides. The business keeps the product it already pays for, and the integration layer does not depend on one vendor. If the company changes assistants later, or runs more than one, the same approved actions can be offered to the new tool without rebuilding the connections to the ERP or CRM.
A fully custom agent makes sense when the task is central to how the business operates, when it runs without a person starting a conversation, such as overnight triage of incoming requests, or when the product’s data handling terms do not fit the records involved. Even then, the integration layer is usually the larger part of the work.
Decide with one real task, not a feature comparison.
Pick one task that matters and test the licensed product against it with real records. Can it reach every system the task needs? Can it take the actions required, or only read? Are the approval rules enforced or merely suggested? Can you see a complete record of what it did? A short structured trial answers these questions better than a vendor’s feature matrix.
Where the product falls short, ask what would close the gap. Sometimes it is configuration or a connector the vendor already offers. Sometimes it is an integration layer that gives the product approved actions in one internal system. Only when the task itself is specific to the business, and runs on a schedule rather than in a conversation, does a fully custom agent usually earn its cost.
Write the decision down with the reasons, so it can be revisited as products improve. Baybloom builds custom agents and the integration layers that connect licensed products to internal systems, and the first conversation is usually about which of the two a given task needs. The answer depends on the task, the systems, and the rules, not on a preference for building.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project