AI

An AI assistant is only as good as its context.

The gap between a useless AI assistant and a genuinely helpful one is not the model. It is context. An assistant that can see your projects, your messages, and your documents answers questions a generic chatbot never could. Context is the product.

I run engineering, so I spend a lot of time around the part of an AI assistant that people think is the magic: the model. And I want to start by saying the thing that surprises people most. The model is mostly not where the value lives. The frontier models are extraordinary, and they are also widely available, which means the model is increasingly a commodity that everyone can reach. The gap between an AI assistant that wastes your time and one that genuinely changes how you work is almost never the model. It is the context. An assistant that can see your actual projects, your messages, your documents, and your customers can answer questions that a generic chatbot will never touch, no matter how capable its underlying model is.

This is easy to say and easy to underestimate, so let me be concrete about what it means in practice. A generic assistant is a brilliant stranger. It knows a great deal about the world and nothing about your world. It can write you a project plan in the abstract, but it cannot tell you whether your project is behind, because it has never seen your project. The moment an AI assistant can see your work, the questions you can ask it change category entirely, and that change is the whole point.

Why context, not the model, is the product

Consider the difference between two questions. The first is "how should I structure a customer onboarding process?" Any capable model answers this well, because the answer lives in its general knowledge. The second is "which of my customers are stalled in onboarding right now, and why?" No model can answer that from training data, because the answer lives entirely in your data. It requires the assistant to see your customer records, your open tasks, your messages, and the state of each account, and to reason across all of them at once.

The first kind of question is mildly useful and you could get the same answer from a search box. The second kind is the reason AI at work matters, and it is unreachable without context. Every genuinely valuable thing I have seen people do with an AI assistant falls into that second category. Summarize where this customer stands. Tell me what changed on my projects this week. Draft a reply to this message using what we actually agreed last month. Find the contract that is blocking this deal. None of these are about the model's intelligence. All of them are about what the model can see. That is why I tell my team that AI context is the product, and the model is the engine. A great engine in a car with no windows still cannot drive you anywhere useful.

The hard part is assembling the context, not calling the model

Here is the part that gets glossed over in every AI demo. Giving an assistant real context is genuinely difficult engineering, and it is most of the work. The model is one API call. Knowing what to put in front of it for a given question is the entire problem. When you ask about a customer, the assistant has to figure out which records are relevant, pull the related tasks and messages, decide what matters and what is noise, respect who is allowed to see what, and assemble all of it into something the model can reason over, all in the time it takes you to expect an answer. That retrieval and assembly is where AI productivity is actually won or lost.

This is also why bolting an assistant onto a single tool produces such thin results. An assistant that only sees your calendar can only answer calendar questions, and most real questions cross boundaries. The interesting ones span your tasks and your messages and your customers, because that is how work actually spans them. If those things live in separate products that cannot see each other, no assistant built on any one of them can reach across, and you are back to a brilliant stranger who knows about your meetings and nothing else.

The architecture that makes context possible is therefore not the assistant itself. It is everything underneath it: one place where the work lives, a permission model the assistant inherits so it never shows someone what they should not see, and a retrieval layer fast and precise enough to find the right context for an open-ended question. We spend far more engineering effort on those three things than on the model integration, and that ratio is correct. The model is the last and easiest mile.

Context has to respect the rules

There is a constraint that makes this harder and that you cannot compromise on. An assistant with access to everyone's work is a liability unless it sees exactly and only what the asking person is allowed to see. The context that makes the assistant useful is the same context that makes it dangerous if it leaks across permission boundaries. So the assistant cannot have its own view of the data. It has to inherit the user's view, so that asking it a question can never surface something the user could not have found themselves.

This is not a footnote. It is a core part of why context-rich AI at work is hard to build responsibly. The naive version, where you index everything and let the model retrieve freely, is both a security problem and a trust problem, and trust is the thing that gets an assistant adopted at all. People will use an assistant that knows their work only if they are certain it respects the same boundaries the rest of the system does. Get that wrong once and you do not get a second chance with that customer.

What a context-aware assistant changes about work

When an AI assistant actually knows your work, the way you interact with your tools shifts. You stop navigating to information and start asking for it. Instead of opening four screens to reconstruct where a customer stands, you ask and get a synthesis drawn from all four. Instead of reading every message to find what changed, you ask what changed. The assistant becomes less like a chatbot and more like a colleague who has read everything you have access to and remembers all of it, which is a thing no human colleague can be.

The productivity gain is real but it is not the kind that shows up as a faster keystroke. It shows up as questions answered that you previously would not have bothered to ask, because reconstructing the answer by hand was not worth the time. Those are the highest-value questions, the ones about state and status and what to do next, and they were effectively priced out of existence by the effort of gathering the context yourself. A context-aware assistant makes them nearly free, and that changes what a person can stay on top of.

This is exactly why we built Ask Atlas as an assistant that sees across tasks, projects, inbox, documents, and customers rather than as a chatbot bolted onto one of them. The assistant in Atlas is not impressive because of the model behind it, though the model is excellent. It is useful because it can see the work, inherits your permissions while doing so, and assembles the right context for whatever you ask. If you remember one thing, let it be this: when you evaluate any AI assistant for real work, do not ask how smart the model is. Ask what it can see, and how carefully it handles what it sees. That answer tells you whether it will change your work or just impress you for an afternoon.

F

Farhan

Farhan is the solo builder of wrxstack. He designs, writes, and ships Atlas and Portfolio on his own, and writes here about product, engineering, careers, and the craft of building software as one person.