What Glean and Claude Cowork get wrong about building AI agents for work

I'm Matt, I'm one of the product engineers at Adapt. My work here consists of building the tools and infrastructure that allows the Adapt AI agent to make sense of our customers' company knowledge. Before this, I cofounded a company building developer tools for MCP servers.

Adapt is the AI agent that connects across all your apps and unifies your data. It is your company's brain.

When I first approached Adapt, I was a skeptic. The space is crowded and hyper-competitive, every company is shipping their own flavor of AI Agent, the term slowly losing its meaning. Differentiation in this space was going to be an uphill battle.

What won me over was the team's approach to building the agent harness for Adapt. The tooling, context, and infrastructure that enables Adapt to be more than a naive chatbot. The harness we've built makes Adapt more creative than other agents, more context-efficient, and self-improving through its memory layer. I've never used a work agent that feels this organically intelligent.

In this article, I will go through some of our techniques and why I believe we've built the best agent harness for knowledge work.

Tool calling: API is superior to MCP

We've noticed a lot of agents out there such as Glean's agent and Claude co-work both use MCP tools calling for integrations. I can't blame them, MCP is the easier solution to work with.

Our team has experimented with both approaches, using MCP servers and our current approach of calling API endpoints directly via cURL commands or code execution. We've settled on calling API's directly via curl commands, or running scripts in Adapt's sandbox to perform advanced queries and analysis.

We've noticed that the API approach preserves the context window and allows the Adapt agent to be much more creative. This has given our customers higher quality insights than agents that use the MCP approach. In many cases, our API approach has achieved insights that are literally not possible when calling MCP.

Context window preservation

Loading MCP tool schemas upfront burns context. Calling APIs directly (or via code execution) doesn't. Here's the math and here's why we chose code execution.

Each tool will cost roughly between 500 to 1500 tokens, adding up fast. Github's MCP server alone consumes 18,000 tokens. Connect three MCP servers. You're looking at a quarter of Sonnet's context window being used for just loading MCP servers. Our customers are connecting to more than just three integrations. Even Anthropic acknowledges this problem and has experimented with hacky workarounds for this problem.

Code execution on API flips the structure. Because we're not loading tools upfront, there is no context window consumption on load. When Adapt needs to call an API endpoint, the agent already knows how to use the integration through the skills that it has. This is the optimal strategy to preserve context windows while still giving agents enough to call tools.

We often see that the LLM already knows how to call underlying API endpoints and doesn't even need to load a skill, saving even more context. This is because the API documentation has been on the internet and stable long enough for it to be picked up in the training data and injected into the model. Agents inherently know the API structure for popular endpoints.

MCP strains creativity. Code execution is boundless.

MCP servers are typically built on top of API endpoints, but the tools exposed represent only a fraction of the available API. The Asana MCP server has 42 tools sitting on top of 247 API endpoints. That's 17% coverage. The other 83% of what Asana can do is invisible to an agent calling through MCP.

I've seen these constraints show up in real production environments. One of the biggest gaps is in the HubSpot integration, where HubSpot's MCP has only 10% of the capabilities compared to its API:

User asks “Which marketing campaigns drove the most deals we closed last quarter”

The HubSpot MCP can search contacts, companies, and deals, but it can't query marketing email opens, attribution data, or campaign performance. These endpoints are not exposed as tools. Campaign performance is not accessible at all via MCP.

When you use API calls via code execution, we saw the agent get creative. It wrote a short script to hit the deals API endpoint with the date filter, marketing events endpoint, and the attributions endpoint. It then wrote a Python script to do data analysis just as a full-time data analyst would. The results were insightful:

“The Q1 webinar series drove $190K in closed revenue across 12 deals. Campaign X generated $1.2M in pipeline but only $80K closed. Worth investigating…”

MCP is not mature

Part of why MCP is so constrained is because of its lack of maturity. MCP is a very new framework, only a little over a year old. We've seen security vulnerabilities that have come out, it feels like a vibe coded spec with the risk vector of exposing your company data. You want your proprietary knowledge running through a secure infrastructure, not experiments.

APIs have been around for decades and are just way more reliable. Uptimes are a lot higher. Companies have had APIs around much longer, bolstering their security profile. You still get authorization and scoped permissioning when using the API, by scoping the API key.

Lastly, many services have API services but do not have an MCP server today. We've helped teams integrate with their own internal API systems and apps that don't have MCP. API is the mature system to do serious knowledge work today.

Adapt's memory layer

I've played around with other agents, but Adapt is the only agent I've seen that gives the entire company a shared memory layer. Glean and Cowork scope memory to the individual user. That's fine for a chat assistant. It's the wrong default for a work agent, because work is rarely a solo activity.

How we've engineered memory

We've engineered our memory layer through a combination of skills and knowledge. We view skills as a set of instructions guiding the Adapt agent on how to use different tools and run different workflows. For example, we have a front end design skill guiding Adapt on how to build the UI for an Adapt app (yes Adapt can write code for you). Skills are retrieved through embeddings.

We've built knowledge as a separate entity, representing company-specific information. Things like employee roles and customer profiles. Think of it as a cache of company information. Knowledge is retrieved through embeddings and progressive discovery. The Adapt agent is designed to save knowledge on your behalf when appropriate, passively getting smarter the more you use it.

Memory makes everyone in the org smarter

Our customers onboard new hires faster because Adapt has already answered most of the questions they're about to ask. When the fifth new engineer joins and asks “how do we handle staging deployments?”, Adapt doesn't make them dig through Notion. It answers from the four times it's been asked before, refined by the corrections and follow-ups from each of those conversations.

Het, our Forward Deployed Engineer, researches every customer in Adapt before hopping on a call. That research doesn't sit in his account. It becomes part of the company's shared knowledge, so when sales follow up, they all start from what Het already learned instead of starting over from scratch.

Every interaction with Adapt makes the agent smarter for the whole team.

Choose what works for you

I hope through this article, you found our approach to harness engineering insightful. Building agents is ultimately an art, not a science. It's impossible to objectively prove which agent performs better than another due to the non-deterministic nature of LLMs. Even evals are flawed.

The ultimate evaluator is you, and whether or not you can get these agents to work for your use case. Try out different tools and see which ones stick for you, no solution is perfect.

I've used many flavors of agents and can confidently say that we've engineered one that really works. We're power users of our own product and our customers are happy with the insights Adapt can provide.

I'm proud of what we've built and hope that you consider giving it a try. Feel free to email me at matthew@adapt.com for any questions, happy to help.