Who to hire for an Airkit.ai project on Salesforce
Airkit.ai became part of Service Cloud in 2023, and the people who built it went on to shape Agentforce. Hire for the Agentforce Service work you will actually run, and test the partner on conversations, not slides.
Platform & ArchitectureMost buyers who land on this page are in one of two positions. Either they used Airkit.ai before Salesforce bought it and want to know who can look after that investment, or they have read that Airkit.ai underpins Salesforce's agent strategy and want a partner who understands that heritage. Both buyers need the same thing, which is a firm that can build, test and govern an AI service agent on the Salesforce platform. The brand on the proposal matters far less than whether the people in the room have shipped one.
What you are actually hiring for
Salesforce's announcement described Airkit.ai as a creator of AI-powered customer service applications. In its own words, "Airkit.ai enables Fortune 500 and fast growing businesses to build flexible, omni-channel customer engagement applications, and AI-based customer service agents." The same announcement said the company would become part of Service Cloud, and Salesforce completed the acquisition on 16 October 2023. The close is documented in the Salesforce newsroom announcement, which is the primary source for everything in this paragraph.
Two things follow. First, the product you would contract for today sits inside Salesforce's own agent offering, and the public record of what happened to a stand-alone Airkit.ai tenant is thin. Salesforce Ben, a trade publication, wrote that Airkit "is considered the basis of Agentforce", and its founder Adam Evans went on to lead Salesforce's AI business. That is useful context, but it is commentary, not a product statement. If you still hold an Airkit.ai contract, put one question to your account executive in writing: what is the supported route for this tenant, and on what dates? Do not take a partner's word for it.
Second, this page covers the work you would actually commission now, which is designing and running Agentforce Service agents on Service Cloud, with knowledge, Omni-Channel routing and your own systems behind them. If you are hiring someone to rebuild an existing Airkit.ai application, treat that as a migration with its own scoping, which the migration guide covers.
Skills and certifications that matter
Salesforce publishes its credentials on Trailhead, and the current names are worth quoting back to a partner. For this work the relevant ones are the Salesforce Certified Agentforce Specialist, the Salesforce Certified Agentforce Service Consultant, the Salesforce Certified Platform Integration Architect, and the Salesforce Certified Platform Developer or Platform App Builder for the people who will write the Flows and Apex that agents call. The full lists sit on Trailhead's consultant and developer credential pages, so you can check any name a partner offers.
A credential tells you someone passed an exam, and no more. The skills that decide whether an agent survives contact with customers are less tidy. You want someone who can write a subagent's instructions so that it stays inside its job (subagents were called topics until recently, and older material still uses that word), someone who can design the actions an agent may take and the permissions those actions run under, and someone who can build an evaluation set from real transcripts. You also want a person who understands Service Cloud itself, because every agent eventually hands a case to a human through queues, skills-based routing and a knowledge base, and a clever agent bolted onto a messy service org simply fails faster.
A first engagement worth scoping
Resist the urge to hire for the whole contact centre. A sound first engagement has these parts:
- One channel, usually web chat or messaging, where you already hold transcripts.
- Five to ten of the commonest contact reasons, written down in your customers' own words.
- A knowledge source the agent may cite, with a named owner for each article.
- Two or three actions the agent may take, such as looking up an order status or booking a callback, each with a defined permission set.
- A written handoff: which queue receives the conversation, what context travels with it, and what the customer is told.
- A test set drawn from at least a few hundred past conversations, scored before launch and again after.
That scope fits a pilot and produces evidence. It also gives you a basis for comparing quotes, because every firm is pricing the same bounded thing. The implementation guide takes the same pilot further into channel and case design.
Red flags specific to AI service agents
Generic CRM red flags still apply, but this work has its own. Treat any of the following as a reason to probe harder.
A partner who shows only the happy path. A real agent is wrong some of the time, and the interesting design question is what the customer experiences then. Ask to see a failed conversation from a past project and how the design changed afterwards.
A partner who cannot explain how the agent's access is limited. An agent that can read every case, or run an action as an administrator, is a data incident waiting for a prompt that asks nicely.
A partner who promises a deflection figure before seeing your transcripts. Containment depends on your contact mix, your knowledge quality and your tolerance for errors. Anyone quoting it in advance is selling, not measuring.
A partner who treats the knowledge base as someone else's job. The agent is only as good as the articles it can cite. If nobody owns article accuracy, the pilot will quietly teach the agent your out-of-date answers.
A partner with no view on testing. Ask how a change to a subagent's instructions is regression-tested before it reaches customers.
Where the effort really goes
Buyers tend to expect the agent itself to be the bulk of the work. In practice it is often the smaller part. Writing instructions for a subagent and wiring it to a Flow takes days. The weeks go into everything the agent depends on: cleaning the knowledge base so articles answer one question each, fixing case reasons so reporting means something, deciding what identity checks must happen before an action runs, and agreeing with the service team what a good handoff looks like. A partner who spends the discovery phase only on prompts has misjudged the job.
There is also a long tail after launch. Models change, products change, policies change and customers phrase things in new ways. A sensible partner proposes a tuning period, a weekly review of failed conversations for the first weeks, and a named person on your side who accepts or rejects changes. If a quote ends at go-live, ask who looks after the agent in month two, because that is when the first embarrassing answer usually surfaces.
Finally, think about where else the work reaches. Salesforce's announcement said the addition of Airkit.ai would "help Service, Sales, Marketing and Commerce teams move faster", and your agent will probably be asked to do more than service once it works. Pick a partner whose design can grow into order lookups, appointment booking or lead capture without a rebuild, and whose permission model was designed with that growth in mind, not retrofitted when the second team asks for access.
Ten questions to put to every candidate
- Which Agentforce Service agent have you taken live, on which channel, and what was the first thing that went wrong in production?
- Show me an evaluation set you built. How many conversations, who labelled them, and how did you score answers?
- How do you scope the actions an agent can run, and under which user context do they execute?
- What does the handoff to a human carry, and how do you stop the customer repeating themselves?
- How do you handle a subagent whose instructions work in testing but drift after a model or release update?
- Which of your people hold the Agentforce Specialist and Agentforce Service Consultant credentials, and will they be on my project?
- How would you decide which contact reasons should not be automated at all?
- What do you need from my knowledge team, and what happens when an article is wrong?
- If I held an Airkit.ai application before the acquisition, how would you inventory what it did and decide what to rebuild?
- What would make you advise me to stop the pilot?
The tenth question is the most revealing. A partner who has never stopped a pilot has probably never measured one.
Checking references and evidence
Logos on a slide prove that a contract existed. Ask for three better things. First, a reference who runs the service operation, not the sponsor, and ask them what the agent gets wrong. Second, a walk-through of a real evaluation report with customer details removed. Third, a sandbox or demo org in which the partner builds a small agent while you watch, using one of your own contact reasons. Twenty minutes of live building tells you more than a case study.
Be cautious about outcome claims. Salesforce's own announcement, which you can read in full on the newsroom page, makes no customer-level claims about results, and a partner's anonymised statistic is not independently checkable. Ask what was measured, over which period and against what baseline.
Commercial models and what goes in the statement of work
For a pilot, a fixed fee against a defined scope usually works, provided the scope names the channel, the contact reasons, the knowledge sources, the actions and the test set. Time and materials suits discovery and the tuning period afterwards, when the work depends on what the transcripts reveal. Avoid fees tied to a deflection figure unless both sides have agreed exactly how it is counted, because the measure can be gamed from either end.
The statement of work should say, in plain terms:
- The evaluation set, its size, who owns it and the pass mark for launch.
- The actions the agent may run and the permission set behind each.
- Who writes and approves subagent instructions, and how changes are released.
- A named owner for each knowledge article the agent may cite.
- What the partner hands over: instructions, test set, runbook and a recorded walk-through.
- The rollback: how the channel returns to human-only service, and who can trigger it.
Licensing is a separate conversation with Salesforce. A services quote is labour, and the licence guide explains what the cited announcement does and does not say about fees. The cost guide covers how to compare services quotes.
| Question | A good answer | A weak answer |
|---|---|---|
| What happens when the agent is wrong? | A designed handoff with context and a test for it | "It rarely happens" |
| How is access limited? | Named permission sets per action | "It uses an integration user" |
| How is quality measured? | Scored evaluation set from your transcripts | A deflection figure from another client |
| Who owns knowledge? | A named person per article | "Your team will sort that" |
| What would stop the pilot? | Specific thresholds agreed up front | No answer |
When you can skip a partner
A small team with a working Service Cloud org, a tidy knowledge base and one admin who has completed the Agentforce Specialist path can reasonably build a first agent alone. The sign that you can proceed unaided is that you can write the contact reasons, the actions and the handoff on one page without anyone disagreeing. If that page cannot be written, or if the agent will touch payments, identity checks or regulated advice, bring in a partner for the design and testing, even if you build the rest yourself. For wider context on what changed after the close, the what happened guide sets out the dates and what the announcement left unsaid.



