The demo works in an afternoon. Making it safe to put in front of real users is the work. These answers describe that work in engineering terms, not magic.
An assistant answers: it reads what it is given, including your documents, and replies to a person who decides what to do next. An agent acts: it has a fixed set of tools (search a system, create a ticket, file a report, send a message), decides which to use, and carries out a defined job, with a person approving anything that changes a system. Most teams need an assistant first and an agent for one narrow, repetitive job second.
The jobs that are boring, frequent and well defined: assemble the weekly report from three systems and send it for approval; triage incoming support tickets against a runbook and draft the reply; reconcile two lists and flag the differences; watch a queue and escalate what matches a rule. The test for a good first agent is that you can write its job description in one paragraph and its failure modes in another.
A safety classifier in front of the model that checks every input, with keyword rules as a fallback for the moment the classifier is slow or down. A fixed list of tools, each with its own permission. A human approval step for anything that changes a system. Rate limits per user and per hour. A cost ceiling per day. A retention rule enforced by the database. And a trace of every request. None of this appears in a demo; all of it appears in the first incident.
A written set of test cases the system must pass before launch and on every change: inputs with the expected behaviour, including the awkward ones (off-topic requests, attempts to make it ignore its rules, questions it must refuse, questions it must escalate). They run automatically, the way unit tests do for code. Without evals, every prompt change is a guess; with them, a change that breaks a behaviour fails before it ships.
Two places. Before an action that changes anything outside the conversation, an approval step: the agent proposes, a named person confirms. After the fact, a review queue: a clinician, a manager or an analyst reads a sample of what the system said, flags what was wrong, and the correction goes back into the knowledge base. The review queue is how the system gets better; the approval step is how it never gets worse unnoticed.
The Model Context Protocol is a standard way to give a model tools and data: a server exposes functions and resources, and any compatible model client can use them. It matters when the same tools should serve several assistants or several vendors' models, or when a tool already exists as an MCP server. For a single agent with three tools, a plain function interface is simpler and we use that instead.
Token use is metered per request and per user, so a runaway loop or an abusive user hits a limit, not your card. A daily ceiling stops the system rather than the budget. Cheaper, faster models handle classification and routing; the capable model is used where the answer needs it. Caching of repeated context cuts the bill further. A cost dashboard shows all of it, and the alert reaches a person before the ceiling does.
To the model provider, for the length of the request, under the provider's business terms, which for the providers we use exclude training on your data. Nowhere else. Identifiers are removed from inputs where the use case allows it. Conversations are stored in a database you own, in a region you choose, with a retention rule that deletes them on a schedule. The privacy answer is written into the architecture document before a line of code, and we will sign an NDA.
Claude from Anthropic for most assistant and agent work, with smaller models in the same family for the safety classifier and routing where speed matters more than depth. Other frontier models where a client already has a contract or a workload fits them better. The architecture does not depend on one vendor; the prompts, evals and traces travel with you.
Through retrieval over a knowledge base you control: your documents, policies and approved answers, chunked and indexed, with the relevant pieces placed in the model's context for each request. The review queue adds corrections to that knowledge base, so the system learns from its reviewers without retraining anything. Answers cite what they used, so a reviewer can see why the model said what it said.
Every request: who asked, what went to the model (the full prompt), what came back, which tools ran, how long each stage took, what the safety classifier decided, and what the person approved. Every admin action and every retention purge, in one log. "What happened" is a query, not a meeting. Retention is yours to set.
It will be, sometimes. The design assumes it: the classifier catches dangerous inputs, the approval step catches dangerous actions, the review queue catches wrong answers after the fact, and the trace shows exactly what went wrong so it can be fixed in the knowledge base or the evals. A system that is wrong visibly and correctably is safe to run. A system that is wrong silently is not, however good its demo was.
An assistant over your own documents with the safety layer, review queue, evals and audit trail is a matter of weeks. An agent with a few tools and an approval flow is similar, plus the time to connect each system. The demo is the first week; the rest is the part that lets you put it in front of real people. The written quote fixes both the scope and the timeline.
Send the one paragraph that describes its job. We reply within a working day with what it would take to run it safely.
