An AI agent that builds your compensation bands

Why this project started

• 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.

• 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.

Key challenges, and how I addressed them

The live band table has no version history, so an agent can't safely edit it in place

• The existing band table does not support draft status, no version control, no 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.

My approach: scoping every AI edit to a session. Each chat holds its own working draft, and nothing touches the live table until you publish, which merges the result in.

Why this trade-off is acceptable: We ship the agent's value now instead of being blocked on months of infrastructure. The session-based editing gives users a safe space to draft comp bands without affecting their existing data.

Compensation modeling looks nothing alike from one company to the next

• 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 extensive architecture, multiple levels and tracks.

• One rigid flow fails one of them.

My approach: designing for both mental models. Small orgs one-shot the whole table; large orgs build in chunks, e.g. one market per session (see the post-publish affordances below).

My approach: exploring two ways to build bands with AI

• Both options share the same entry point, generation flow, and merge-based publishing.

• They split on one thing: what editing through chat does to the table.

👉 All the work shown here is currently in progress and being refined.

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:

1. manual

2. row-level through an inline AI action

3. 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.

Next: once the direction is chosen, I'll design it out in full (states, edge cases, confidence scores etc.) and then validate with internal compensation experts and a cohort of top customers.