A domain-expert agent is not a chatbot with your logo on it
A chatbot answers questions. An agent does things: reads the documents that arrived overnight, drafts the reply, updates the record, opens the ticket, hands the exception to a person. The difference is not the model. The same model sits behind both. The difference is everything built around it — and that is where most "AI agent" projects either earn their keep or quietly become a demo.
"Domain expert" is a useful bar because it is concrete. An agent is a domain expert when it answers from your data rather than from the internet's average, when it can act inside the systems you actually run, and when someone can check its work.
What it actually does
Inside a company, an agent's day is unglamorous. It watches an inbox or a queue. It reads a contract and flags the clauses your team would flag. It turns an interview transcript into a structured profile. It reconciles receipts against statements and asks a person only about the ones that don't match. It writes the first draft of the weekly report from the numbers, not from memory.
None of those tasks needs "unprecedented scale." They need to be right, to run inside the tools the team already uses, and to know when to stop and ask.
Four things that make it reliable
1. Grounding. The agent retrieves from your documents and records before it answers, and its answers point back to where they came from. This reduces invented facts; it does not eliminate them, and anyone who tells you otherwise is selling something. The practical work is in what gets indexed, how it's chunked, and what the agent does when the retrieval comes back empty — "I don't have that" is a correct answer.
2. Structure. Some questions are about relationships, not documents: which customers share a supplier, which contracts reference the same clause, which incidents cluster around one system. Modelling those relationships explicitly — a graph over your entities — lets the agent follow a chain of links instead of guessing at it. It is worth building when the questions are relational. It is overkill when they aren't, and most first agents don't need it.
3. Fine-tuning, for the right reason. Fine-tuning does not teach a model your business; grounding does that. Fine-tuning teaches it a format, a tone, a narrow task — and can cut latency and cost when the same kind of request runs thousands of times a day. Reach for it late, and for those reasons.
4. Evaluation. You cannot manage an agent you don't measure. A test set of real cases with known-good answers, run every time a prompt or a model changes; a second model grading the first against a rubric; and a person reviewing a sample every week. Without this, "it seems to work" is the only signal you have, and it is not one.
The gate
Early on, a person approves every action the agent proposes. That is not a limitation to apologise for; it is how the agent learns the edge cases and how the team learns to trust it. Each correction becomes a rule. When corrections approach zero for a class of actions, the gate opens for that class — and stays closed for the ones that still surprise you. Autonomy is something an agent earns, one kind of action at a time.
Where it lives
A domain-expert agent runs inside the access you grant it — your cloud, your permissions, your audit log — because that is where the data is and where the actions happen. If a vendor's plan starts with moving your data out, ask what the agent is for.
The hard question is rarely "can we build an agent." It is "which one pays off first, with the data we actually have." That is a two-week question, not a two-quarter one.