Compensation bands, built by AI
Project
Compensation Band Builder · Deel
Year
Ongoing
Why this project started
Problem:
Customers build compensation bands two ways today: by hand, or by bulk-importing what they have. Either way, the work sits with them.
Building bands well is specialist work. Companies routinely pay outside consultants to do it.
Opportunity:
Deel has reliable pay data across 150+ countries, already surfaced in a separate product, the Salary Insights tool. The data was strong, but wasn't actively used.
Agents changed that. AI is now capable enough to build the bands from that data directly and that is what we set out to do.
Scope of Work
Agentic design
System thinking
Interaction design
Key challenges
Existing table doesn't support version control
The existing band table does not support draft status, version control, or rollback.
Letting an agent rewrite a live table with none of that is a data-loss risk.
Building the full versioning infrastructure first would take significant time.
How I'm addressing it: Each AI chat session holds its own draft, and nothing touches the live table until you publish. That way, we ship the agent's value now instead of being blocked on months of infrastructure.
Compensation modelling varies between customers
How a company builds bands depends on its size, its markets, and how deep its job architecture runs.
A single-market startup has a small, simple table. An enterprise spans many countries with multiple levels and tracks.
How I'm addressing it: designing for both mental models. Small orgs can one-shot the whole table; large orgs can build in chunks.
Solution: exploring two ways to build compensation bands with AI
This is Deel's first complex agentic workflow and my work here will shape org-wide AI interaction patterns.
Option A: The table as a canvas
One source of truth that updates in place.
Start in a side chat panel with questions; the moment bands generate, the panel opens into a split view (table left, chat right).
Every edit mutates that same working table, each change is behind an approve-or-undo gate.
Review happens in one table, rather than a growing stack of versions.
Option B: The table as a chat artifact
Building happens linearly: ask in plain language, the agent works out the bands and displays the table below.
Further edits generate a new version below, instead of altering the previous table.
Touched rows are highlighted; the full history stays in the chat.
Scroll back and rewind to any earlier table.
After the first publish
The empty state gives way to the full table with three ways to edit:
manual
row-level through an inline AI action
multiple rows at once (through a new session).
The three exist because customers don't all build the same way: single-market orgs one-shot it; enterprises build one market per session.
Where this is now
I've coded both concepts and shared them with stakeholders.
We are now deciding which to ship: split-view canvas for immediacy and focus or linear chat artifact for auditability and rewind.
Since this is Deel's first complex AI flow, no components existed for it. So I'm defining the patterns that will be used org-wide for agentic flows.
