Global AI Assistant

An enterprise ATS and CRM does not get complicated on purpose. It gets complicated one reasonable request at a time. A customer needs one more pipeline stage. A different customer needs a custom field on the company record, and a report that groups by it. Nobody ever asks for less. After enough years the product genuinely can do almost everything a recruitment agency needs, and almost nothing is where you would guess.

That cost does not land on the buyer. It lands on the recruiter who does the same eight things forty times a day. Move a candidate a stage forward. Log the call that just ended. Check which submissions are still sitting with the client. Every one of those is a known, finished, well built feature, and every one of them sits three or four deliberate navigation choices deep: which module, which view, which filter, which record, then the action.

In research the complaint was never that the feature was missing or badly designed. It was that getting to it broke the thing the recruiter was actually doing. They had a candidate on the phone, a sentence in their head, and a product that wanted them to remember its information architecture first.

MCP is Anthropic's protocol and I did not design it. What I owned was the server on the other side of it, for a web application that already existed and had ten years of behaviour baked in: which of the platform's capabilities became tools, what each tool would accept and return, how the agent's view of a workspace stayed inside that user's permissions, and what the agent was supposed to do when a sentence did not cleanly map to anything. Most of the work was not protocol work. It was deciding what the product was willing to let an agent do.

Confirmation was the first real fight. Gate everything and you have taught the recruiter to click through gates without reading, which is worse than no gate at all, because now the product looks like it asked. So actions got ranked by reversibility and blast radius, and only the top band was gated. The wording changed too. A confirmation that asks whether you are sure gets a reflex. A confirmation that states three candidates move from Shortlisted to Interview and one email goes to a named person gets read, because it contains something the recruiter can check.

Trust behaved differently from adoption, and for a while the metrics hid it. People used the assistant, then opened the record by hand to verify it had done what it said. That is not adoption, that is supervision, and supervision costs more than the navigation it replaced. What moved it was making every result carry its own evidence, the changed field, the value it held before, a direct link. Verification had to be one glance inside the answer, or people would keep going to look for themselves.

Latency ran straight into the expectation that a chat box sets. Type a sentence, get an answer, two seconds, that is the contract everyone arrives with. A grounded multi-step run against a real enterprise workspace does not honour it and no amount of engineering was going to make it. Streaming the reasoning was what bought the time: naming the intent, then the tool it picked, then the retrieval it ran. A spinner spends the user's patience. A sequence of true statements about what is happening earns some.

The last one has no clean answer. Sometimes the model misreads intent on a record that matters, on a real candidate, on a live requirement, in front of a client. You do not design that away, you design for the minute afterwards. Narrow writes, single record by default, an undo wherever the underlying platform could support one, and a per-action audit trail that recorded the sentence the recruiter said alongside the change the agent made. When something did go wrong, the team could see exactly what was asked and exactly what happened, which is the difference between a bug and a mystery.

It became the single AI assistant for recruiters on the platform: one centralised interaction layer standing in front of a set of separate product navigation paths that had each grown up on their own. Not a feature inside a module. The way you addressed the product.

The more durable change was internal. Once a tool surface existed, new functionality had a second design question attached to it, alongside where does this live in the UI came how would an agent invoke this, and what is it allowed to do with it. Tool design became part of feature design rather than an integration task at the end. That is a shift in how a product team thinks, and it outlasts any particular assistant.

Public figures for this one do not exist, so there are none here. Adoption, latency and time saved were tracked internally and are not mine to publish, and an invented number would be worth less than the omission.

I would build the tool surface from recordings of recruiters talking, before writing a single tool. The first set was derived from the product's own information architecture, because that was the map we had, and it made the assistant fluent in the product's vocabulary instead of the user's. We spent months translating afterwards. I would also ship the audit trail and the undo layer before the first write tool rather than alongside it. Both were treated as safety work to be built in parallel, and both turned out to be the thing that made recruiters willing to let go of the mouse.