待翻譯：The Wrong Defaults is why enterprise AI agents fail at adoption

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

Aug 12, 2026 Do you see the similarities across AI agent interfaces that these companies give you? There are chat sessions, there are model selections, there are tone settings, then there are MCP connections, there are skills, there are memories. They are setting up the “industry standards” and now whoever is building a new AI agent for themselves or for their companies, they follow the same standard. And whether you realize it or not, these standards suck, and I’m gonna tell you why. Configurations are often just a polite way to ship uncertainty You see, when engineers build a CLI with different flags or a product with different settings, they usually don’t know what the user wants, so they give them a choice, a setting. And with that, they nicely shift the “decision maker” role to you. So every time using the current standard AI chat interfaces, many questions raise inside your head: Where did I discuss X? Should I compact this conversation now since the context is almost full, or open a new conversation? What other model should I use? What connectors should I connect to? And you have to make decision for each of them. This is you speaking engineering language. One of the best first impressions with iOS (comparing with vs Android) is that iPhones are always ready-to-use. Sure, you have limited choices, you’re “locked in”, but the truth is for the majority of users, you don’t need that much customization for it to work. You just pick up the phone and use it, it just works, what could be more convenient? Now, to be fair, both exist because there are people who want the freedom of choices, they want more configurations, making the world as beautiful as it is now. But, if you’re an enterprise trying to get hundreds or thousands of employees to adopt AI better, you must build the iPhone version. Because obviously it’s optimized for mass adoption. You don’t want to sacrifice the majority of users for the luxury of a few power users. And that is what I want to talk about today: You need to break The Wrong Defaults. Do the right things I have been taught since I was little: if you believe you’re doing the right thing, even though everyone else says the other way, then trust your gut and do it. So here is my take. If you look at the enterprise AI landscape right now – it’s all over the news by the way – you can tell that companies large and small are desperate for AI adoption as they’re afraid of being left behind. They buy licenses from the AI companies, then they build their own AI agents using the industry standards, also from those AI companies. They’re encouraging people to try the new AI tools. It’s a never-ending cycle. The only winners are those AI companies. And the end-users are the ones who suffer. But who cares if your company asks you to use or build such tools? I do. One conversation is enough for the AI agent The same way that you talk with your friends or your coworker: you have one long chat for each of them. You open the chat, and you start typing. That’s how it should work. That’s how it should be. Don’t be brainwashed by the standard and build a multi-session chat interface. If you are an AI agent builder and you cannot solve the context budget, or AI hallucination problem, that’s on you. Don’t put that on the users and expect them to “adopt” your tool. Spoiler alert, you can do that by simply observing how human memory work, because our brain has a similar “context budget”, just much larger. We’re forgetting things too. Apply that judgement to your AI, you’ll find your own solutions. Embed your AI agents right into your chat platform Whether you’re using Slack or Teams or any other application at work, copying and pasting chats between the AI agents and those chat platforms is ridiculous. It’s an absolutely absurd standard. Your chat platform already holds context - conversations with coworkers, decisions made in group chats, files shared, links exchanged. Why would you force the user to leave that context, open another tool, paste their question there, get a response, then copy/paste it back? Now just imagine a world where your AI agent lives right there in the same chat. You talk to it the same way you talk to your coworker. Your coworker can see what the agent said. The agent can see what your coworker said. No context lost. No copy-paste. No switching tabs. Yeah, it’s sci-fi stuff - except it’s not. One AI agent is enough The AI industry wants you to build as many AI agents as possible. That’s how they make money. So they (highly recommend you read this very slowly) build platforms for your company to build platforms for its employees to build their specialized, personal assistant AI agents. And you play right into their hands. You burn tokens to build agents, then burn tokens to use agents. Double charge, ouch. And if your company pays for two AI vendors? Quadruple charge, double ouch. The question is, why do you want to build so many agents? They say specialized agents are smarter, less hallucination, more reliable. But is it? What if you build only one general-purpose agent that could be customized for every single user, depending on their personalities and their roles? What if you build an empty vessel, that can load different skills depending on what is asked? Isn’t that better than individually built, customized agents? It not only optimizes the cost of building and operating the agent. It is also so much easier to apply governance and security to the agent’s infrastructure. And each employee has their own personal assistant instantly. One stone, three+ birds. Give the AI agent generic tools So you want your agents to be smarter, so you hook it up to additional APIs and systems. OK, that’s fair. It sounds simple and straightforward, and it is. But here is a subtle fact. If you, say, connect to Jira via jira-cli, connect to Confluence via confluence-cli, connect to Google via google-cli, the list goes on. How many CLIs are you going to support? Every new integration would require an engineer to get involved. Again, don’t even think about mentioning CLI setup to the end-user - you’re speaking alien language. The answer is much simpler than you thought. How do you think those CLIs work with the APIs? By TCP/HTTP calls, of course. The common theme of all of those CLIs is a generic tool to transfer data via HTTP. And Linux has a very powerful program for that: curl. With curl, your AI agent can naturally reach every API. All the agent needs to know is where to connect, how to authenticate, and what you want to do with it, which you can describe in a very simple text instruction. By the way, LLM models know a lot about public well-known API documents (like Atlassian, MS Graph API, etc), so you don’t even need to repeat such details in the skill instruction. I know all AI code assistant editors out there have the MCP or Connectors configurations, but they are completely different products with completely different goals and audiences. Remember, your goal is AI adoption, so one less click is ten more potential users. Knowledge-base is overrated From a company’s perspective, it makes sense for the LLM models to have the company’s knowledge. One common recommendation is building a knowledge-base layer that the LLM can reliably pull data from with exact citations and quotes. I suppose the only way you can experiment and feel the pain is to implement this yourself and test the results. What you will experience is that building and maintaining this KB is non-trivial. It’s a huge never-ending component that requires constant monitoring, data ingestion, conflict-free, up-to-date, best ranking, etc. And the retrieval methods vary depending on the data you have as well. There are many papers about RAG that will easily overwhelm you. In contrast, models are getting better and better at self-reasoning. So instead of relying on those complicated RAG pipelines, you can give the models messy data from different sources, a clear instruction, then you can count on their reasoning process. I found the responses are surprisingly accurate most of the time, with the huge upside of removing a massive engineering component. Think about the trade-off between complexity, optimization, and user experience. Only you can balance all of those. Fine-tuning is also overrated Another way of incorporating a company’s knowledge into LLM models is fine-tuning. But continuous learning is hard. It’s hard to keep adding more knowledge into the models while making sure they get better. For some reason, the newly added data doesn’t have as much impact on the core memory as we expected. And don’t forget it costs companies a fortune to do all of this experimentation and cross their fingers for it to work. One possible approach, while we’re waiting for fine-tuning to get better, is to rely on live data from API calls via skills or tools or any connectors you could plug into your agents. Yes, the same question from two users would trigger the same API calls - wasteful and repeated. But accuracy beats optimized and wrong. Building users’ trust is non-negotiable. The industry profits from the complexity. They won’t fix this for you. So either you break the defaults yourself and build with confidence, or follow the crowd and hope people find your tool useful and stick with it. Your choice.