A key enterprise platform — used by thousands of staff — had an onboarding bottleneck. Every new user had to be created and have their access scoped by one of a handful of specialists. The process took ~15 minutes per request, the specialists were a single point of failure, and the queue stretched into days during peak hiring weeks.

The actual work — ‘collect these fields, validate them, hit this API’ — was deterministic. The bottleneck was that humans were the API. A new joiner waiting two days for platform access isn't a security control; it's a process failure.

The brief was to replace the specialist queue with a self-service conversational interface that's safer than a form (because it can guide and validate) and cheaper than a human (because it's a chatbot).

1 · Greet & scope

User lands in the chatbot via the enterprise portal. SSO context tells the bot who they are and what they're entitled to request. The bot offers the request types they can self-serve.

2 · Conversational intake

Instead of a form, the bot asks for the required fields one at a time in natural language, validating each (does this team exist? is this role pattern valid? does the requested access overlap something they already have?).

3 · Confirm & commit

User sees a structured summary of what's about to be created. One tap to confirm. The bot makes the POST/PUT calls to the platform's internal API. Success or specific failure is reported back in plain language.

4 · Audit

Every conversation is logged with inputs, validation outcomes, API calls, and final state. Compliance can trace any access decision back to its origin conversation.

A form would have been faster to build. But forms are unforgiving — fill in the wrong field combination and you get a validation error wall. The specialists doing this work weren't just API-calling; they were also coaching users through edge cases.

• The bot can ask follow-up questions when a field looks unusual, the way a specialist would.
• Validation errors are explained in context: “That team doesn't exist — did you mean Acme-Ops or Acme-OpEx?” rather than “invalid team_id”.
• Common patterns get short-circuited (“you want the same access as your manager? Done.”).
• The system prompt is the place where business rules live, in plain English, reviewable by the team that owns the rules — not buried in a validation library.

The specialists weren't made redundant — they were promoted out of the toil. Their job now is owning the rule set the bot follows, handling the exceptions the bot escalates, and improving the bot's coverage. The work that scales by talent rather than throughput.

• The bot only ever calls API endpoints that are scoped to the user's entitlements (resolved via SSO context server-side, not from anything the user types).
• A confirmation step with a structured summary precedes every mutating call. The LLM never directly fires POST/PUT — it proposes them; a deterministic tool handler validates and executes.
• Anomalous request patterns (e.g. someone asking for elevated access shortly after onboarding) are flagged for review rather than auto-approved.
• Every conversation is recoverable from logs: full inputs, model outputs, API requests, final state. This is the audit trail compliance needed before they signed off.

• Build the eval suite around realistic edge-case conversations before launching, not after. We had to walk back two early auto-approvals.
• Add explicit user-facing ‘skip to a specialist’ affordance at every turn. Users who insisted on a human got one anyway, but they had to ask twice.
• Treat the tool-handler validation layer as the security boundary, not the system prompt. Belt and braces — but the braces are the deterministic code, not the LLM.