
There are new AI tools released constantly, and LinkedIn infographics about each just as frequently. It can get confusing. Ultimately, having a framework to understand the concepts behind these tools is a much more powerful way of understanding what they do and how they can be useful to you. After which you can more clearly compare tools to figure out what would best serve your needs.
I would like to share a simple rubric to help you contextualize any tool you come across; a teach someone how to fish kind of thing. I’ll outline what the most important dimensions are, and I’ll use the example of planning a trip to Japan to illustrate how variance in these aspects would impact your workflow and the result you get.
Autonomy: One-Shot vs. Agentic
One-shot flows are the most familiar to most people. They’re chatbot applications like ChatGPT or Claude Chat — you type a prompt, get a response, and follow up with another prompt. For example, I could ask “What are well-reviewed hotels in Tokyo?”
If you’re planning a trip you’ll likely have many such prompts about food, transportation, entertainment..etc. You’d probably copy and paste every result you get somewhere and create your itnierary. An alternative to this potentially tedious flow is agentic AI; if one-shot is the smart junior assistant, the agent is the more experienced project manager to whom you can give a broad goal and they’ll help you get it done. You can ask the agent to “plan my trip to Japan,” and at some point it will realize that one of the sub-tasks is “What are well-reviewed hotels in Tokyo” but you don’t need to provide that upfront.
A good analogy here is driving to a destination. One-shot prompting is like turn-by-turn directions, whereas agentic prompting is describing an end destination and letting it figure out the path.

Now, as you might imagine, there are many subjective decision points for a travel itinerary (e.g., do you prefer museums or nightlife? What kind of budget are you planning with?). In addition to subjective variance, since the scope is broad there are many permutations of possible itineraries; so if you let the AI create a monolithic plan in one go, you might not like what you get. Finally, as you’re overloading the prompt with a wide goal, more things can break or go wrong along the way. These are just inherent characteristics of broad reasoning in general, not a limitation unique to AI.
There are a handful of ways to improve the experience here, but one key concept is the idea of a human-in-the-loop. An example of this is what Claude Cowork sometimes does, which is: after your prompt, it might surface a questions module that tries to clarify your requirements and goals. So after you ask the agent to plan your Japan trip, it’ll ask you about various preferences before charging ahead. This is one way in which you can “steer” the AI.
There are many agentic AI products that I can name, but let’s go over a few. Cursor or Claude Code, for example, are agentic products focused on coding; you’re still mostly working directly with code but with the help of an agent that can coordinate and execute multiple steps. In comparison, tools like Lovable or Replit are agentic app-building products with a more visual-forward approach, not unlike the “what you see is what you get” web development products of the past. And in moving to another non-coding vertical, you have examples such as the aforementioned Claude Cowork, which is really Claude Code under the hood, but is designed to be your productivity and knowledge work partner. And so on.
Finally, it’s worth mentioning orchestrators. These are tools like n8n or Zapier where you can connect multiple agents or steps together, these are your quarterbacks or conductors stitching everything together for a super workflow. To continue with the Japan trip as an example, you might use this to combine the output of multiple agents and take real actions on the results. For instance, you can create an automation that uses the Google Flights API to return flights, another step that books the cheapest one, and a final step that generates calendar events from all your activities.
Hosting
This section requires a bit more technical context than the others, but it’s worth it as you’ll gain a simplified but helpful understanding of how AI works under the hood, which will makes the hosting distinction click.

AI is enabled by models. There is a training stage and an inference stage. Training is when models are fed large amounts of general or domain-specific data and tuned to be performant and accurate in prediction and output. Companies quote “number of parameters” as one indication of model capability. The reality is more nuanced than “more parameters = better”, it’s certainly more expensive, but there are generally diminishing returns. Data quality and uniqueness, as well as other variables of model performance, all play a big role in the end output quality and user experience, which is what actually matters. Furthermore, there’s a whole dimension of general vs. specialized models; the latter possibly being much smaller in parameters but more effective due to their specific tuning and training data.
The trained model file itself is not as large as you might think. The dataset it was trained on can be absurdly large, but the model itself is usually a reasonable size. This is because you can think of the model as a file with a big grid of numbers. These numbers are the result of the training and they represent “weights.” AI is essentially a statistical pattern matcher, and the distribution of those weights is what determines the output.

A key concept you might come across at this stage is the term “evals,” short for evaluations. During model training, there’s a lot of opaque black-box processing that occurs between input and output. Since you can’t see exactly how the model produces its results, the way you tune it is by comparing outputs against evaluation benchmarks, noting the discrepancy, and adjusting model weights iteratively to minimize that gap.
Once a model is trained, this is where inference comes in. When you type something into ChatGPT, every prompt triggers a new inference; your input is run through the model to generate a response. If you’re someone designing or building AI products, there’s a key idea worth internalizing here, which is that traditional software, even when complex, has a finite and fixed number of possible paths for the user. That isn’t the case with AI software, which is probabilistic by nature. The same exact prompt can yield different results. So as a product builder, how do you account for this variance? How do you ensure continued user trust, clarity of expectations, and a baseline level of consistency in the utility you provide? That’s a discussion for another time.
The reason this explanation of how AI works is in the hosting section is to distinguish where inference happens. For the most common consumer applications such as ChatGPT, Claude and Gemini, inference happens in the cloud, which means your data is running through the company’s servers. The alternative is that a model runs fully locally using a tool like Ollama, residing on your computer and doing the inference 100% locally with none of your data leaving your premises.
There are also some examples of hybrid inference models emerging. Apple Intelligence, for instance, is designed to do some tasks on-device and route harder ones to the cloud. An important tradeoff to consider when it comes to local (edge) vs. cloud inference is not just data privacy but also performance. Cloud infrastructure is much more computationally powerful than end devices, so there is a limitation on what kind of inference you can reasonably run on edge.
There’s one more key reason AI might need to run on the edge besides privacy: latency. Imagine the self-driving car taking you from the airport in Tokyo to your hotel. Along the route it’s making thousands of calculations and decisions, many of which are extremely time-sensitive and have to happen in sub-seconds. In those conditions, inference has to happen locally within the car’s hardware as you can’t afford the latency of a round trip to the cloud, or worse, losing network access entirely.
Ultimately, the choice between cloud and edge is a tradeoff between raw power, latency, and privacy.
Scope of Access and Context
The final variable across which you can differentiate AI software is the scope of access, meaning, does this tool have access to your personal content or not. This content can be files on your hard drive, or information in other software you use like Google Calendar.

Putting privacy concerns aside, generally most AI products will be compoundingly more useful to you the more context they have about you. For instance, continuing with the Japan trip example, if an AI can infer your preferences based on travel history from emails, archived itineraries, and combine that with what it knows about your calendar and free time, it can make the planning hyper-personalized to you and more readily closer to a final output that needs much less tweaking, compared to not knowing that information or requiring you to manually define it.
A slightly different but related extension of this construct is in-product context. Just as there is information about you that lives outside the AI product that can be ingested, there is information about you that already lives inside the AI (like your Claude chat history). This is where memory comes in, whether the product works on a stateless per-session basis or one that is persistent across sessions. In the case of Claude for example, this is something you can toggle on and off, which is super nice.
The tradeoff, of course, is privacy concerns, as well as the idea that sometimes you don’t want the inference to be influenced by your personal preferences and would rather get a generic result.
Some Other Concepts to Know
The above three variables — autonomy, hosting, and scope of access — are the big ones differentiating the core of AI products. There are many others that come into play, but once you understand the first three it becomes easier to distinguish these smaller variations in flavor, and they’ll become very obvious to you without needing much of a walkthrough. Here are a few such flavors of distinction:
- Access interface — Text? Voice? Embedded API?
- Modalities — Supported input and output types (text? images? video?)
- Pricing model — Free? Subscription? Pay per token?
One example of an AI product I want to call out separately is something like OpenClaw (it keeps getting renamed, it’s the same thing as Moltbot, Clawdbot, etc.). It’s an example of when you max out almost every dimension we outlined above – fully agentic, full access, local-first, persistent memory, and it uses an interface people already have (messaging apps). It’s much closer to what many might envision a full AI assistant from the sci-fi movie “Her” would look like.
Finally, it’s worth calling out that while there are many applications of AI, the most commonly recognized one is ChatGPT, a large language model (LLM) chatbot. The back-and-forth chat nature contained in a box is a neat application for sure, but AI itself is a capability and it can be expanded far beyond the confines of a chatbot, applied in numerous areas from construction to healthcare to solving supply chain problems. Even in the most familiar consumer products today, the intelligence is still mostly imprisoned within the walls of the chatbox. There’s no reason it should be. In fact, eventually it will spread horizontally and vertically across functions and applications, possibly becoming as ubiquitous as copy and paste.
