Three Ways LLMs Actually Get Used (Only Two Get Attention)
Co-thinkers, assistants, and the integration layer nobody talks about.
Watching AI adoption across different companies, organizations and industries, it’s becoming increasingly clear there’s really only three ways LLMs are used. They vary dramatically in the required LLM complexity and infrastructure required to do the work. No option is an LLM alone; all have infrastructure. They vary equally in how much attention is paid to them, and the one with the least attention may be the most important one.
My work, like most of the work in the industry, has been focused on the first two use cases. My goal with this post is to show the existence of the third and argue that its business impact may very well be equal or greater than the other two.
Each use case also has a bad version, the misuse case, if you will. I don’t intend to cover those in this post, but I feel it’s right that I draw attention to that fact.
The co-thinker.
Only frontier models can handle this, more or less. That gap is closing compared to open source models, but there is still a gap.
The co-thinker seems to be the promise of LLMs, the idea of an assistant and expert for everyone is the draw of the chatbot, and why the novelty of the first ChatGPT release turned into such fervor.
Vibe coders are the stereotypical people associated with this type of use case. At their worst: “please code me an app like Facebook but better. make no mistakes.” But when an iterative approach is used, human ideas honed, researched and executed by AI with a human providing feedback, this use case can speed up the process of building something great.
The assistant.
The assistant doesn’t need the imagination and flexibility of the co-thinker. It needs a good, stable prompt and tools at its disposal to execute.
These are models used for a defined set of tasks. Amazingly small models can excel at this if well prompted, especially if tuned to the domain or company.
The main example I’ve seen of this is an LLM app that takes documents, summarizes them, or finds information using RAG and cites the document and location where the information was found. You absolutely do not need a frontier model for this.
While security is paramount for all of these functions of an LLM, this is likely the one that goes deepest into a company’s crown jewels. You must absolutely trust the LLM provider 100%. Unfortunately, that’s not the case with a frontier model.
The universal API exchange.
A carpenter probably doesn’t need an Azure subscription with multiple services to run the business. Around 50% of skilled contractors use paper and pencil. But of those who don’t, as they grow their business, their tech stack grows too. Each new app requires different integrations. There are upwards of 500k independent skilled tradespeople in the US. Some build desks for people like Warren Buffett; they probably can’t write a Python program to integrate two apps that don’t have connectors.
An LLM can easily connect itself to an API and figure out how to be the middleman between any number of apps. No programming required. A connector, a skill and an app that can be accessed anywhere and, almost (LLM uptime isn’t the most consistent), any time.
And it’s not just contractors. M&A. Mergers and acquisitions are messy; all of the payroll, HR, every system must be made to cooperate. This IT integration is a large part of the integration budget.
And an LLM can just do a large portion of the work.
Please note, all of these build off each other. In order for a co-thinker to be effective, it must have access to tools in a more flexible manner than an assistant. The assistant’s tools and access are effectively the same as the API aggregator’s.
Think of a research assistant app. If it just finds the details and documents, perhaps summarizes them, it’s clearly an assistant. If it goes on to provide a synthesis, it’s a co-thinker. All of this is built on tool calls, mostly API searches. It’s additional work on top of an API aggregator.
