Cobalt and Balt: two products, and which one you need

Cobalt is where your recruitment data is written, Balt is what puts it to work. The first is an ATS paired with a CRM, the second is an agent that lives in Teams and in Slack, and the short answer to “do I need both” is no.

Both products come from the same house, which makes the question fair and the answer slightly suspect. So here is what makes it true, straight away: Balt connects to the ATS you already have, and it was built that way for a reason that has nothing to do with commercial strategy. An agent that accepted only one system of record would not be a product, it would be a feature of that system, sold separately.

What exactly is Cobalt?

Cobalt is an ATS-CRM aimed at IT services firms and recruitment agencies, meaning the system where the facts of your business are written down: candidates, clients, open requirements, interviews held, placements signed. It is a database with views, filters and history, and the platform sets out to replace the usual stack of the sector, the one where the CRM, the applicant tracking, the sequencing tool and the staffing spreadsheet each live on their own.

An ATS is a place. You go there, you search, you update, you leave. There is nothing outdated about that shape and it will remain necessary for a long time, because you do need somewhere the truth is written once and findable by everyone, including two years later when whoever typed the record has left.

Cobalt also publishes figures on its market, and its annual study on recruitment in IT services firms gives the order of magnitude that explains why the sector is equipping itself: an average bench rate of 11.4% lasting 41 days, and AI adoption in recruitment rising from 8% in 2024 to 30% in 2026. These are the same figures underpinning our analysis of the bench as a staffing problem rather than a sourcing one.

What exactly is Balt?

Balt is an agent that works inside your team’s messaging and acts in your tools, instead of waiting for you in an interface. You write to it in Teams or Slack the way you would write to a colleague, it fetches what it needs from the connected systems, and it returns a finished result rather than a suggestion to rework.

The fundamental difference from a piece of software is not the conversation, which is only a surface. It is the direction of travel. You go to an ATS; an agent comes to you, into the channel where the team is already talking, and it can turn up without being summoned because an assignment ends in three weeks or a promised follow-up never went out.

Everything else follows from there. It remembers your preferences so it does not ask again every Monday, which immediately raises the question of what it should forget, and it chains tools in an order it chooses rather than following a script written in advance.

Why two products, and not one more feature in the ATS?

Because we started with the other answer and it did not hold. The first version of what became Balt was a panel inside Cobalt’s interface, to the right of the candidate record, with an input box and good intentions.

It worked technically and nobody used it, for a reason that took us a few weeks to accept. An account manager who spends the day in Teams does not open the ATS to ask a question, they ask the person sitting next to them, or they do not ask at all. The panel demanded exactly the gesture the product claimed to remove, that of going somewhere, and it demanded it at the worst moment, once the user had already found what they came for.

The lesson seems to generalise well beyond our case, and it explains why so many assistants embedded in business software go unused despite their quality. The value of an agent does not come from its proximity to the data, which a connection settles, but from its proximity to the conversation where the work is decided. We have developed that observation elsewhere, from the angle of what happens to software when the interface stops being where work happens.

Can you use Balt without Cobalt?

Yes, and that is the case for most of the teams using it. Balt plugs into the ATS in place, into the messaging, the calendar and the documents, and nothing requires that data to travel through another product of the house.

This independence is not a concession made reluctantly, it is what makes the agent useful. A forty-consultant firm that has spent three years populating its ATS is not going to switch because a vendor shipped an agent, and it is right not to: migrating a system of record is a project in its own right, with its data reprocessing and its six months of debris. Demanding that migration in order to deliver an agent would amount to charging for a house move in order to install a coffee machine.

It is also why we take the question of connection protocols seriously, to the point of devoting a whole article to it. An agent that can only talk to its own vendor’s tools reproduces exactly the silo it claimed to remove, and the buyer only notices on the day they want to plug in the ninth tool.

What do the two together actually bring?

Together they do not add an integration, they remove a copy. It is a distinction that looks thin on an architecture diagram and shows up every day in practice.

When the ATS and the agent are designed together, a client’s context, its preferences, its history of refusals, its usual lead times, is written in one place and read as it stands. When they are not, that context ends up duplicated: some in the ATS fields, some in the agent’s memory, some in the account manager’s head. Each copy ages at its own speed and the divergence never announces itself, which is exactly the problem we describe about companies running twelve isolated agents.

So the gain is real and it is modest, and I would rather say it that way than turn it into a sales argument. You gain freshness and you lose a source of silent error. You do not gain a new capability, because the agent plugged into a third-party ATS does the same work.

Which one should you start with?

With whichever answers your dominant pain, and the test fits in one question: is your data reliable?

If the information lives in a shared spreadsheet, in personal inboxes and in the memory of three people, take the system of record first. An agent sitting on doubtful data does not grow suspicious the way a human would about a record dated 2023: it reasons on it and returns a perfectly credible, wrong result, which costs more than having no agent at all. We have written a whole article on this sequence, because it is the most common ordering mistake, and it explains why you clean what the agent touches at the moment it touches it rather than the whole database first.

If your ATS suits you and the lost time sits around it, in follow-ups that drift, meeting notes nobody records and Monday reviews prepared on Sunday, take the agent. There is no canonical order between the two, and the question is settled by where your team hurts.

What neither one does for you

Neither sends a message to a candidate without a person releasing it. That is a design rule rather than a default setting you loosen after three months, and it applies to a rejection as much as to a harmless follow-up.

The reason is easy to state and expensive to hold: an action that leaves the company commits your brand in front of someone who did not sign up to talk to a machine. The gain is then measured in delay and in drafting cost, never in removed control, and that is the line we set out in who approves what when an AI writes to your candidates.

Which leaves the question everybody asks next, and it is the right one: how do you check that an agent delivers what it promises before signing? It is settled with your own files rather than with a demo, and the protocol comes down to thirty cases replayed three times.