You build an AI assistant inside your business software.

You ask it questions. It finds the information. The answers make sense. You start thinking you’ve built something people will actually use.

Then someone else tries it.

They use different words. Leave out a detail you would have included. Ask a follow-up that seems obvious to them.

Suddenly, the assistant struggles.

It asks for information they think it should already know. Answers a narrower question than they asked. Or confidently returns something that misses the point.

Your first instinct might be to improve the prompt.

But there’s a more uncomfortable possibility:

You’ve learned how to make the assistant work. Your coworkers haven’t.

That difference can hide a lot.

The builder is supplying an invisible translation layer

This is a problem I’ve been working through while building an assistant for everyday business operations.

When you build a system, you learn its internal vocabulary.

You know which information lives in which application. Which actions it supports. What the fields are called. Which details help it find the right record.

That knowledge starts shaping how you talk to it.

You might ask:

Show my overdue maintenance tasks assigned to me.

Someone else might ask:

What am I behind on?

Those requests could overlap. But the second leaves much more for the assistant to determine.

Behind on what? Tasks? Messages? Approvals? Work that someone else is waiting for?

The builder often supplies those boundaries without noticing.

Part of the apparent intelligence is happening in the builder’s head before the message gets sent.

A chat box can preserve the old learning curve

The promise of a conversational interface is that people can describe what they need.

But putting a text box over software doesn’t automatically make that software easier to use.

If someone has to learn the correct nouns, specify the source application, and phrase requests in a supported pattern, they’re still learning an interface.

The interface happens to accept sentences.

Imagine a coworker asking:

What’s still waiting on me?

A useful answer may require understanding their identity, responsibilities, assigned work, pending approvals, and unresolved handoffs.

If the assistant responds:

Please specify the record type.

it has handed part of its job back to the user.

The person came with a business question. The system responded with a database question.

Natural language input is only useful when the system can connect it to the way people understand their work.

Everyday language contains more context than it appears to

Consider a few things someone might type:

Anything urgent?

Did we handle that leak?

What happened with her application?

Same thing, but for last week.

These are incomplete descriptions in isolation. Inside a working relationship, they can be perfectly ordinary.

People rely on shared context. They use pronouns because a person or issue was just discussed. They say “handled” because they care about whether the problem remains.

An assistant needs to determine how much of that context it actually has.

That includes distinguishing between questions like:

What information is available?
What work remains?
Who needs to act next?
What changed since the last conversation?

Those questions can involve the same records while requiring very different answers.

Finding the right records is part of the job. Understanding why the person needs them is another.

Ambiguity needs judgment

This doesn’t mean the assistant should guess its way through every vague request.

Sometimes “her application” could refer to several people. Sometimes “urgent” has no agreed definition. Sometimes the relevant information isn’t available.

The useful response depends on the uncertainty.

If the conversation clearly identifies the person, use that context.

If there are two plausible people, ask a focused question.

If only part of the requested information is accessible, explain the coverage of the answer.

For example:

I can check your assigned tasks and pending approvals. I don’t have access to your email, so this won’t include requests sitting there.

That gives the user something useful while preserving an honest boundary.

The important distinction is between uncertainty the system can resolve and uncertainty that needs the person’s judgment.

Ask for the missing decision, rather than making the user reconstruct the whole request.

“Me” is a permissions question too

There’s another reason an assistant can work differently for its builder.

The builder may have broader access.

An owner might be able to see every property, account, task, and conversation. A coworker may have access to a smaller set of information.

So “What needs attention?” cannot produce the same answer for everyone.

The assistant has to understand who is asking and apply that person’s permissions throughout the retrieval process.

An owner’s successful test doesn’t establish that the same question will work for a maintenance worker, leasing operator, or bookkeeper.

Each person needs a useful answer within their actual role.

That belongs in the product’s design from the beginning.

Test the translation you’ve stopped noticing

Testing with the builder’s favorite questions can reinforce the problem.

You already know what works. You’re likely to keep supplying the details that make it work.

I want to test with people who know the business but haven’t learned the assistant’s internals.

Ask them to use it for real work. Watch the first question they type. Then watch what happens when the answer misses.

Do they repeat themselves?

Change to more formal language?

Add an application name?

Abandon the question and open another screen?

Those behaviors show where the assistant is making them adapt.

When a request fails, the next step should be to identify the underlying gap: missing context, incomplete data coverage, unclear ownership, permissions, or a misunderstood intent.

That gives you a problem to solve across a whole class of requests.

Adding one more phrase to a list of recognized wording can leave the underlying problem intact.

The product should carry more of the burden

A useful assistant needs to tolerate the way work is actually discussed.

Shorthand. Follow-ups. Corrections. Half-finished thoughts. Different vocabulary from different roles.

It also needs to know when to slow down and clarify.

Building that is harder than making a small set of well-phrased questions produce good answers. It requires understanding the business well enough to connect ordinary language to the right information, within the right boundaries.

But that’s where the value is.

If I have to stand beside someone and translate every question into wording the assistant understands, I’m still part of the interface.

The real test comes when someone who doesn’t know how you built it can use it without you standing beside them.