The frontier AI labs run on a simple model: metered intelligence. The more tokens you burn, the more they make. So it is no surprise they push a seductive vision—once you have a powerful LLM, anyone can build their own agents, workflows, and apps.
Up to a point, they are right. For a one-off task, a personal workflow, or a tool for a small team, you can absolutely build your own agent today. But this pattern breaks when you are building a real business application. This is based on my own experience in building Maya, our AI-Native Growth Orchestration System.
If your team says “we can just build this ourselves,” here’s what they are likely underestimating:
- Providing Context (about the business, the task, the dependencies): An LLM may be the most intelligent thing we have ever built, but it’s stateless — it doesn’t accumulate knowledge. Everything proprietary has to be supplied at query time. You obviously can’t dump your entire enterprise database into a prompt, so context engineering — giving the model the right data and the right semantics for the task — becomes a core skill. A concrete example: Maya has an Analytics agent that reviews ad performance. One day it flagged that a campaign’s interest audiences were stacked as “A OR B OR C” and recommended changing them to “A AND B AND C.” But when I checked Meta Ads’ UI, they were already AND. The agent got it wrong because Meta’s API returns these interests in a flexible_spec array — and the raw array gives no indication of whether the interests are AND-ed or OR-ed. The semantics simply aren’t in the data. So we taught our context engine to describe the API’s semantics explicitly. That’s context engineering — and no LLM does it for you.
- Building it Right (Quality & Evals): A meaningful AI agent is non-deterministic by definition and that changes how you would develop, test and iterate on it. Traditional coding patterns don’t directly work. You need to learn how to measure relevance, helpfulness, and accuracy. You need to learn how to set up evals, how to improve metrics and iterate. Even within software engineering, this is more of a niche skillset—something you saw in Google Search and Ads development and not necessarily in standard SaaS product development.
- Running it (Multi-agent Orchestration, Hosting and Maintenance): If your application needs multiple agents, you will need a way to orchestrate them properly with correct handoffs. There are frameworks for this but they still need substantial work to make it work for a real-world use case. For most AI agents, you will need to figure out where to host it and its dependencies (like custom tools or databases). So you will need to use one of the cloud providers. Version 1 is just a start, you need to maintain it, fix bugs and add features and there are ongoing resources needed for that. Maintenance is especially tricky for integrations which are fragile by nature: rate-limiting, schema changes and sometimes low availability.
- Enterprise Fit (Governance, human-in-the-loop): Enterprises have a large number of people with different roles and responsibilities, naturally an AI agent needs to respect that. It also needs to provide knobs for governance. Very few business use cases can be fully automated. Most critical ones can be semi-automated with humans being pulled in at the right time for judgment and decision making. This means you need interrupts, approval workflows and resume execution post human decision making.
- Economics (Cost, Model Routing): We are already seeing LLM costs for frontier models becoming a hot topic. You want to route to the right model based on the use case. Some queries need to go to the frontier model like Fable, others can be served perfectly fine with an open source model. So you want your app to be LLM agnostic. Such routers are not easy, a small change here will impact your quality and reliability.
Once you look at the above factors, it becomes clearer how designing a solid Agentic AI system is akin to designing a real software application—before LLMs came along. Agentic coding has reduced development time, so yes, it would take less time for the “core coding” but it barely touches the hard parts—context, testing, reliability, hosting, and maintenance.
For an enterprise, in certain cases “build” will be the right decision—when the system is a core competitive differentiator or when you are at a scale where owning it is cheaper than buying. In other cases “buy” will be the right decision. When I joined Google in 2016, it had its internal tool for employee performance management, everyone loved it. But at some point Google decided to migrate to Workday, that was a “buy” decision. It is not that Google can’t build an HR software, it is more like does it need to build and maintain one for internal use?
Here is my appeal:
If you are an Enterprise CTO/CMO/Head of DemandGen/Head of Performance Marketing, looking to build your own AI orchestration system for managing paid and owned media—totally fine, let’s connect. Happy to swap notes; I have been deep in this and can probably save you some pain.
If you are that same persona but on the buy side — you would rather let experts build the software while your team focuses on marketing — let’s also connect. We are still signing design partners, and I would love to show you Maya, our AI-Native Growth Orchestration System (yes, a mouthful).
