The temptation with agent projects is to start with the technology. Pick a model, pick a framework, wire up some APIs, see what happens. That is how you end up with a demo that impresses nobody who actually has to use it.
Start with the pain instead. In go-to-market the pain is that prospects fall into a static page and the system has no idea who they are. In operations the pain is that account managers do not have a single place to manage their daily work — they are reactive instead of proactive, systems are inconsistently updated, and managers have no visibility into what is actually happening across the book of business. Those are the problems worth attacking. Not "we should use agents." Not "AI strategy." Specific, expensive, daily pain.
The agent does not replace HubSpot. It does not replace Metabase. It does not replace the landing page CMS. It sits on top of all of them and becomes the interface the team — and the prospect — actually interacts with. HubSpot becomes the data layer. Metabase becomes the analytics layer. The agent becomes the operating layer. The thing that turns data into action and action back into data.
This is what I mean when I talk about agents as software, not prompts. A prompt can summarize your CRM data. Software can run your daily operations. The difference is not sophistication. It is reliability, inspectability, and the ability to evolve the system as the business logic changes.
Find the pain. Build the smallest agent that touches it. Let the team complain. Make the agent better. Skip the platform-selection theater. The pain is the brief.
— Ry
Sources
Related Essays
Agents in Production: GTM Mesh and the Death of the ERP
The same mesh-of-agents pattern that closes the gap between ad click and revenue is the one that retires the ERP dashboard. Two examples, one architecture.
The Mirror Problem
95% of enterprise AI projects fail not because the models are weak. They fail because the company cannot describe its own processes well enough for an agent to act.
The Demo Is Not the Deployment
A French CTO with twelve Claude Max seats can ship from his laptop and watch his product team file tickets and wait. That gap is the real problem.
Key takeaways
- Pick a model, pick a framework, wire up some APIs, see what happens — that is how you build a demo nobody adopts.
- Start with the actual pain. In GTM the pain is static pages that ignore who showed up. In operations the pain is six tools and no daily work plan.
- The agent does not replace the systems of record. It sits on top of them and becomes the interface humans actually use.
- Agents as software, not prompts — that is the line between something that runs your operations and something that summarizes your CRM data.
FAQ
What is the most common mistake?
Starting with the platform. Picking the model, the framework, the vector database, the orchestration layer — and then looking for a problem to apply them to. The result is always a demo that impresses the people who built it and confuses the people who would have to use it.
How do you find the right pain?
Watch the team for an afternoon. Find the moment they are most reactive, the place where they toggle between four tools to make one decision, the workflow they complain about every Monday. That is the pain. The agent attacks that, not whatever is interesting to the engineers building it.