Answer-Only or Action-Taking? Scoping the Assistant
A B2B SaaS company asks you to "build an AI support assistant". In the first five minutes of the design interview you learn that (a) the help centre has ~5,000 articles updated daily, (b) about 40% of tickets are "where is my invoice / change my plan / refund this charge" requests that today require a human to look at the account, and (c) the company serves several thousand customer organisations from one system.
- Explain why "can the assistant act, or only answer?" is the first architectural fork, and what changes in the design on each side of it.
- Recommend a phasing and justify it in terms of risk, evaluation and cost.
- Which single requirement from (a)–(c) is a hard-failure constraint, and where in the system do you enforce it?
1. Why the fork matters
An answer-only assistant is a fixed workflow: rewrite → retrieve → re-rank → generate with citations. Its worst failure is a wrong or ungrounded answer. An action-taking assistant adds tools that read and write account state, which makes it a (constrained) agent loop whose worst failure is a wrong action — money moved, data changed, an unauthorised lookup. That changes almost everything downstream: you now need a policy engine that is not the LLM, an explicit user-confirmation step for mutating tools, idempotency and audit logs, per-turn step and token budgets, and an evaluation slice that checks tool choice, arguments and "zero unconfirmed writes", not just answer quality. Latency also changes: each tool step is another model call.
2. Phasing
Ship the answer-only workflow first (over the help centre, with a
confidence gate and hand-off), then add read-only tools
(get_account_summary, get_order) for authenticated users, then
low-risk writes (create_ticket), and only then high-risk writes
(issue_refund, plan changes) behind the policy engine and
confirmation. Justification: a fixed workflow is deterministic, cheap
to evaluate and hard to hijack; each unit of autonomy has to earn its
place with measured value against a real baseline. It also gives you
an evaluation set, traces and a hand-off path before the assistant
can do anything irreversible, and the 40% "account" tickets are still
served by the bot drafting and a human confirming (agent-assist)
during the early phases.
3. The hard constraint
(c) — multi-tenancy. Cross-tenant data exposure is a hard failure
regardless of answer quality. Enforce it in the retriever (every
query carries the caller's tenant/visibility filter as metadata) and in
the tools (every call is caller-scoped and authorised server-side;
get_order only returns orders the caller owns). Never enforce it by
asking the model to behave — the model should have no authority to
widen scope, so a jailbreak cannot obtain what the tools will not
return. Include cross-tenant probe cases in the offline eval set.
Share this question