The Setup (You need this)
A few months ago, I was invited to a meeting with the managing director of a CRM consultancy, which I’ll call CRM-CO, along with a friend and former colleague. The MD had an idea he wanted to float: an AI agent that could integrate with, or sit alongside, a CRM system to guide salespeople in their daily work.
At a conceptual level, the idea made sense. Salespeople often benefit from structured guidance, not just in managing data and workflows, but also in developing interpersonal skills and sales strategies, handling objections, and maintaining momentum with leads. An AI agent could, in theory, deliver timely prompts and suggestions, tuned to the nuances of different lines of business, technical environments, company strategies, and pricing structures.
It was also not an entirely new idea, though those who had come before weren’t likely to make as much information available as would have been ideal. The CRM market already contains a variety of approaches. Some AI agents ship natively with systems like Salesforce, Zoho, or HubSpot. Others exist as standalone companions, added on for an additional fee. In every case, they are purpose-built: designed with a defined scope, a clear value proposition, and a pricing model that reflects the modules or capabilities offered in its applicable environment.
That context matters, because any new entrant in this space would need to compete seriously. Success would depend not just on building an agent, but on clarifying what it did differently, what value it added, and how it could stand up in a crowded market. At the time, though, clarity was hard to come by, not only in this meeting, but across the whole AI services industry. The market was still young, ideas were numerous, and the direction of travel was uncertain. Lack of definition might fairly have described the entire industry, a reflection of the moment.
The discussion that followed gave us some useful pointers: potential use cases for the application, and a sense that the agent should be able to offer guidance on product, pricing, and sales technique. But the vision as a whole was still loosely framed. That was hardly surprising, I suspect few people at that time had a fully worked-through idea of what an AI sales agent should look like and those who did have a well worked through idea had managed that by having the resources with which to do the investigations and evaluations.
The request to me was framed simply: “Just go to agent.ai, set up an agent, and train it.” I agreed to explore it to understand what would be involved in building an AI agent for sales, either as a companion to CRM or as an integrated feature.
What follows are the key things I learned through that process.
The Initial Product Concept
The idea itself was strong: an AI agent to sit alongside a CRM system and provide guidance to salespeople. The vision was intentionally broad, a system that could help with deal progression, interpersonal advice, or workflow nudges, depending on the context.
For me, the challenge was in what wasn’t specified. Every business operates with its own products, pricing structures, rules, and processes. Those differences directly shape how salespeople work. To be effective, an AI agent would need to reflect those realities. A sales strategy that works in fast-moving consumer goods, with rigid pricing and volume-driven margins, is almost entirely different from one in enterprise ICT, where success depends on complex solution design, negotiation, and relationship management.
The detail, though, hadn’t been defined. That left me facing a dilemma that is familiar in product development: how far do you move forward when the boundaries are unclear? My recent experience with a telesales agency had shown how customised workflows had to be to drive results. Every campaign was adapted to the client’s products, the audience, and the positioning. An AI agent would be no different.
Without that clarity, the risk was that the product might be seen as simplistic or shallow. I could imagine a sales team joking about clumsy advice, or a stakeholder questioning the budget: why spend money here when the same investment could go into something proven and potentially, into something more productive?
The concept remained appealing, but it was already clear that the viability of the product depended heavily on detail and resultant execution. And that lack of detail, not the idea itself, became the first challenge I had to work through as part of this exercise.
The Work Process
As I began working on the exercise, two main strands emerged. The first was around product definition, understanding what already existed, how those agents were positioned, and what it would take to compete. The second was technical exploration: how such an agent could be built, and what platforms and tools would be required.
1. Product definition
To get a sense of the landscape, I looked at how established CRM providers were already deploying AI. Companies like Zoho, Salesforce, and HubSpot had significant advantages: They had long deployed teams of highly capable, well equipped and well supported people to work on the problem. They also already had vast stores of customer and sales data, much of it captured and structured within their own platforms. Their challenge was not where to find training data, but how to clean and structure what they already had. For a new, standalone agent, or indeed market entrant the problem was the opposite, how to get meaningful training data in the first place.
There was also the question of positioning. Salesforce, for example, could use its own AI assistant as a “ticket to the game” feature, bundled into the platform to drive sales of the core product. For them, the agent didn’t even need to be the best in the market; it simply had to add enough perceived value to make Salesforce itself harder to walk away from, either in the form of a new purchase or an existing implementation. By contrast, a consultancy-branded AI agent would be competing against products backed by the weight of Salesforce, Zoho, or HubSpot, some with hundreds of thousands of customers and millions of users. Whatever was built would need not only to differentiate, but to justify itself against “free” or “included” alternatives.
2. Technical exploration
On the technical side, I started with agent.ai. It was an impressive low-code platform designed to help start-ups build AI agents quickly. It had the kinds of features you’d expect in middleware, orchestration, workflow tools, connectors, and it solved an important problem: most small companies don’t have the developer resources to build everything from scratch. The business model was clear enough too: the entry-level tier was accessible, but the features a start-up would need to launch were in the paid plans.
A critical point here was that agent.ai also handled the operational side. Choosing that route meant the provider would manage not only the platform itself, but also the scaling of hardware resources, the underlying infrastructure (containers, virtualisation, networking, operating systems), and essential services like security. In effect, the complexity of technical operations was absorbed by the platform. That level of service is what can make such platforms feel expensive. The reality is that providers, competitors, enjoy the benefit of scale: they run these layers once, at industrial efficiency, and spread the cost across many customers. A “do it yourself” alternative would need to compete against those advantages, and there would inevitably be a tipping point where the hosted or native service remained more cost-effective than an independently built and “in-house” maintained offering. It was clear that to compete in the existing market then it would be very difficult to compete on price, so the product had to compete on value delivered.
Of course, agent.ai didn’t provide the AI itself. Instead, it allowed you to connect to different large language models via API, ChatGPT, Gemini, Copilot, and others. The choice of backend model would depend on the intended use case. A sales support agent, for example, could be well served by ChatGPT, while Claude, which is stronger in code generation, would add little. None of these services were free, and their pricing varied: consumer-facing ChatGPT was very different to API-level business access. What at first seemed expensive in the context of a start-up began to look more reasonable when compared to the cost and complexity of building an entire AI stack internally.
ChatGPT, specifically, does make both Committed Usage-based Enterprise agreements and reseller agreements available and does support Context Stuffing and Retrieval-Augmented Generation (RAG) and are able to differentiate between data sets so that any data given to the LLM relevant or proprietary to customer one is entirely inaccessible to customer two, protecting proprietary information. Costs are usage based and can be calculated in “per one million tokens” blocks, costs can grow quite quickly, and some risks can be handed down to the customer while others can’t.
The narrative in the media at the time was that this had all become easy. The release of DeepSeek, for instance, was hailed as having “revolutionised the market” and made LLMs accessible to the common man. To an extent that was true: the barriers to entry had dropped dramatically. But it had not dropped so far that any laptop could suddenly become the foundation of a commercial AI product. There were still serious technical and financial considerations to work through.
Key Learnings
The most important learning was that product definition must come first. It is tempting to focus on the technical problem and then try to shape a product around whatever solution emerges. In practice, that rarely works. It often leaves vital features unaddressed simply because they weren’t part of the technical hurdle. A simple analogy from the ISP world makes the point: if the goal is “build a network that can deliver customer services,” then customer traffic graphing isn’t strictly necessary. But if the goal is “compete with other ISPs in the market,” then traffic graphing becomes essential, because it is a core part of the customer-facing product. The same logic applied here: without clear product scope, the technical work risks being misaligned with what the market needs.
1. Product learnings
Looking across the market, I found it useful to think of AI sales agents in categories.
- Customer-facing agents
These are the agents that act as the first point of contact, speaking directly to the end customer. Their sales pitch is usually built around promises of higher conversion through increased engagement or better qualification. To me, these looked like “fast build for fast sale” businesses. They work well for small online shops or sole proprietors, often tied into WordPress or WooCommerce. But they don’t scale naturally into the enterprise world, they aren’t suited for complex B2B sales, relationship management, or pre-sales solution design. They also tend to be general-purpose message takers with scripts, not genuine pre-sales or account-support tools. For a consultancy looking to scale into larger corporates, I didn’t see these as the right model to learn from. - CRM-integrated (and ERP-integrated) agents
A more serious category was the agents embedded in CRM, or even ERP, platforms. CRM-only agents can add sales-specific functionality, but they risk being too narrow. ERP-wide agents, though, potentially serve the entire business: the same product data that supports sales also supports debtors, implementation teams, and project managers. An ERP-wide agent could even help unify business language and processes across departments, which is in and of itself, a source of value.
The implications here were significant. Training an agent for a single department versus the entire enterprise might involve a similar workload, but the scope of benefit was radically different. Without specifying which path the product should take, it was impossible to know what the data sourcing strategy should be. A mis-trained or under-trained model could do real harm, for instance, by suggesting unrealistically cheap deals, and the liability could land not only with the client company, but also with the provider.
- Platform-modular agents:
Salesforce had taken a modular approach, which was entirely in keeping with how Salesforce itself works. Sales order management, CPQ, and other functions each had their own AI agents, reflecting the modular sales of the underlying platform. This created an interesting learning for me: a start-up trying to compete in this space might be best served by choosing a specific platform and tailoring its agent to that ecosystem. What worked for Salesforce would not be the same as what worked for Zoho One, Oracle NetSuite, Microsoft Dynamics 365, SAP, or Odoo. Each platform had its own product structure, customer base, and pricing logic, and an agent would need to match that.
Pricing strategy, too, had to fit. Per-user licensing, usage-based pricing, or value-relative models (e.g. a quotation module being priced higher than an invoice-checker) all made sense in different contexts. The key was alignment with the platform and its customers, not just generic functionality.
2. Technical learnings
On the technical side, the limitations of my own test hardware were an important reality check. I managed to get a small demo running, a web interface with a chat agent backed by a local model. Using Mistral in Ollama on what was once a high-spec gaming PC (an ageing GTX 1070 with 8GB VRAM), the system worked, but painfully slowly. Responses crawled out at around 4 tokens per second, like listening to someone speak one word per second. Even a more modern mini-PC with a Ryzen 9 and an integrated 780M GPU with 64GB RAM wasn’t enough to make it usable for a demo.
This was only inference, running a relatively small and already-trained model. Training itself requires vastly more resources. The equipment I was using was the software equivalent of a development board in circuit of electronics design. Notwithstanding that without a clear strategy for sustained data acquisition (since a start-up would begin with a user base of zero), even attempting training would have been impractical. And if the data problem could somehow be solved, the hardware I had available would still not have been remotely adequate. Training would have taken an impossibly long time, if it was achievable at all.
It was a sobering reminder: while local experimentation was useful, it wasn’t a viable path to a commercial product. The entry point for something remotely credible was at the level of a flagship gaming rig, ideally with multiple GPUs. Even then, those machines lacked the enterprise-grade features required for a production environment: rack-mount design, redundant power, proper cooling, hardware RAID. In short, Consumer-PC scale hardware could not deliver a commercial-grade service.
This linked back to the earlier product exploration. If the product definition required enterprise-level credibility, then the technical solution had to be aligned, either through serious infrastructure investment, or by leveraging a platform provider who already handled the operations and scaling. It reinforced the earlier theme: the technical path could not be chosen in isolation; it had to flow from the product goals.
What we gained from the exercise
Looking back, the most valuable outcome of this exercise was not the agent I managed to get running, but the lessons about how product and technical work fit together.
The central theme was clear: product definition must come first. Without it, technical exploration risks heading in directions that don’t serve the market. The categories of agents I studied, from customer-facing message takers to deeply embedded ERP assistants, showed just how diverse the space already is, and how important it is to define scope, positioning, and value proposition up front. Only then does it make sense to decide on the technical path, the data strategy, or the infrastructure model.
The second theme was about scale. Established CRM providers like Salesforce and Zoho enjoy natural advantages: large user bases, vast data pools, and the ability to use AI features as a lever to strengthen their core product. A standalone agent has a much harder road. It must differentiate clearly and justify its value against “free” or bundled competitors. That means being realistic about what problem it is solving, who it is solving it for, and how it will be priced.
On the technical side, the experiments highlighted both the opportunities and the constraints. Platforms like agent.ai show how quickly a functional product can be built, especially when operational overheads, hardware, scaling, infrastructure, security, are handled by the provider. What looks expensive at first often represents good value once the true cost of “do it yourself” is considered. Conversely, local experiments showed the limits of available hardware: while inference was possible, it was slow, and training was completely out of reach. For anything beyond personal learning, enterprise-grade infrastructure or hosted platforms were unavoidable.
Taken together, the exercise gave me a clear sense of how much depends on alignment. A strong product vision defines what kind of agent is worth building. That in turn drives the technical choices, the data strategy, and the commercial model. Trying to invert that sequence, solving technical problems first and hoping a product emerges, risks creating something that functions, but doesn’t compete.
For me, that was the lasting lesson: the technology is important, but the product definition is what makes the difference between an interesting experiment and a viable business.