Should You Build Your Own AI Brain or Buy One?

The pitch sounds compelling: stitch together Stack AI for agent orchestration, Merge for API unification, Browser Use for web actions, and layer RAG on top. You’ve got your own company brain. Except you probably don’t.

Jay Hack, Head of AI at ClickUp — the $4B work management platform whose customers include marketing firms, construction companies, and legal services firms — spent years watching companies attempt exactly this approach. First at Codegen, the coding agent company he founded and sold to ClickUp, and now leading AI for a platform with roughly 200 engineers focused on the problem full-time.

The Stitching-Together Fallacy

The DIY approach has a specific failure mode. It looks functional in demos but breaks in production. The gap between “agent has access to all the tools” and “agent reliably produces useful output” is wider than most engineering teams expect.

“There is a very large difference between essentially just having Merge API or access to many different MCPs and sort of letting the agent stitch together information at runtime versus having the preassembled, all the important insights precomputed, native access for the agent to the right nodes in that knowledge graph,” Jay explains.

The problem isn’t connecting to APIs. It’s that runtime context assembly — where the agent queries Slack, pulls from Notion, searches email, and synthesizes on the fly — produces inconsistent results. Pre-computed summaries and a native knowledge graph outperform ad hoc retrieval, but building that layer is a different order of engineering effort.

The 200-Engineer Reality Check

Jay frames the build-vs-buy decision the way any company should evaluate software acquisition: “It’s taken Rippling, was it 10 years in order to build a good functioning, some would say good functioning, payroll platform. There’s obviously maintenance associated with that.”

At ClickUp, approximately 200 engineers work on AI infrastructure as their primary focus. That includes the context graph, permissions model, memory architecture, evaluation framework, and the agent surfaces across tasks, chat, documents, and whiteboards.

“If you have 200 engineers that you’re willing to send on the side quest to go do something that’s going to be, you know, not even as good as one of the things that are on the market today, you could do that,” he says. “I do not think it is a savvy business strategy if you’re a construction company to be going off and building your own internal AI.”

Who Should Actually Build

Jay acknowledges exceptions. Ramp, a former Codegen customer, built their own internal coding agent and open-sourced it. He credits them as pioneers. But he limits the viable pool to maybe ten companies with the engineering depth to pull it off — and even then, it’s about going from 98% to 100% efficacy on specific tasks.

The deciding factor isn’t ambition. It’s obsolescence velocity. Whatever internal AI infrastructure you built six months ago is already outdated. The maintenance burden compounds faster than in traditional software because foundation models, best practices, and tooling shift every quarter.

“Considering the fact also that if you started building this, whatever we’re talking about here, whatever the best version of that is six months ago is now completely obsolete. So it’s just not a good play for them.”

The Permissions Problem Nobody Talks About

Beyond raw engineering effort, there’s a subtler challenge that catches DIY builders off guard: permissions. When your AI brain operates across an organization, it inherits every access control question your company has, plus new ones that nobody has solved yet.

“If I talk with you, but also my agent in a shared channel, and then I’m talking to somebody else who maybe is not at the same level — should that agent leak information from our conversation to this other person?” Jay describes this as a problem where “there is no converged upon correct answer in industry today.”

Claude, OpenAI, and Gemini haven’t had to solve multiplayer permissions because their products are single-player. Building a company-wide AI brain means inventing that permissions layer from scratch.

FAQ

What’s the difference between connecting APIs and building a true company AI brain?

Connecting APIs gives an agent access to data sources. A true company brain pre-computes summaries, builds a native knowledge graph, handles permissions across teams, and maintains context over time. Jay Hack describes the gap as “having preassembled insights precomputed” versus “letting the agent stitch together information at runtime.” The former is far more reliable.

How many engineers does it take to build enterprise AI agent infrastructure?

ClickUp dedicates approximately 200 engineers to AI infrastructure as their primary focus. This covers the context graph, memory architecture, permissions model, evaluation framework, and agent surfaces. Jay says even with that investment, what you build is “not even as good as” mature market solutions for some tasks.

When should a company build their own AI agent infrastructure?

Only if you have deep engineering resources, a highly specific use case where 98-to-100% accuracy matters, and willingness to rebuild every four to six months as models and best practices change. Jay estimates maybe ten companies meet this bar. Ramp is the example he cites — they built and open-sourced their own coding agent.

What is the biggest hidden cost of building an AI brain in-house?

Obsolescence. Foundation models, tooling, and best practices shift every quarter. Internal infrastructure built six months ago may already be outdated. Unlike traditional software where maintenance is incremental, AI infrastructure requires periodic wholesale rebuilds to stay current with new model capabilities.

How does ClickUp handle AI data permissions across teams?

ClickUp treats AI memory objects like any other workspace object — permissioned to users who had access to the original information. If an agent learns something from a private channel, that knowledge is gated to channel members. Jay describes this as “fundamental science” that cloud providers haven’t solved because their AI products are single-player.

What are the risks of using multiple point solutions instead of a unified AI platform?

Information silos. If your legal AI is separate from your project management tool, transferring context between them requires manual work or brittle integrations. Jay points out that a question asked in one platform can’t draw on context from another without native integration — the agent appears “stupid” when the real problem is API restrictions.

Can a non-technical company successfully vibe-code their own AI agent system?

Jay says no. ClickUp’s primary customers are non-technical — marketing, legal, construction, accounting firms. Asking them to vibe-code a knowledge management and agentic orchestration platform is impractical in 2026. The engineering complexity extends well beyond generating code to permissions, evaluation, scalability, and ongoing maintenance.

How fast is AI infrastructure becoming obsolete?

Jay describes needing to “burn down your entire tech stack every four months” to stay current. New models, new capabilities, and new best practices emerge continuously. He notes it has “never been more possible to rewrite code” with current AI tools, but that speed only helps if you have the team to execute the rewrites.

What should a company evaluate when choosing between AI agent platforms?

Depth of context access (does the agent see your full workspace or just API endpoints), permission handling for multi-user environments, pre-computed knowledge versus runtime retrieval, and the vendor’s ability to integrate new models as they release. Jay emphasizes that the “batteries included” approach — agents ready to go without installing MCPs — delivers value faster.