Some notes on rebuilding our life’s work.
Earlier this month, we announced the most significant step in Darwinbox’s journey. We launched Darwinbox Cortex, the AI native HCM.
What follows is the story of how we got here. The assumptions that broke, the moments that rearranged how we think about this industry, and the question that started it all.
There is no merge-two-companies button
A few years ago, a CHRO asked me a question during a business review that I never managed to forget.
Her company had just signed an acquisition that added a few thousand people, across three new countries, the kind of deal that touches every process downstream. She had been a customer for years, one of the thoughtful ones, and she asked, quite simply: "So which part of the product handles this?"
I told her we’d bring in an implementation team, run the merger as a phased rollout, and stand up a war room if things got messy. She nodded the way people nod when they’ve heard a good answer to a question they didn’t ask.
What she’d asked was whether her HCM system could handle the biggest people-event her company would go through that decade. The honest answer, the one I didn’t give, was NO. Not ours, not anyone’s. There is no "merge two companies" button in any HCM ever built.
I’ve spent the last decade building HR software. That question has sat in my drawer ever since, unanswered.
The thing about buttons
The more I dug, the more it became clear. Every piece of enterprise software ever shipped works the same way. Someone, somewhere, pre-defined the scenarios the organizations would face. Product managers like me sat in rooms and decided what companies would need, a leave workflow, a transfer flow, an appraisal cycle, and we built screens for those things. Forty years of this industry, including our own ten, adds up to a very large library of anticipated situations.
But work refuses to stay inside anticipated situations. Every unanticipated change goes into a queue, waiting in the same rooms we sat in, and organizations don’t have that kind of time. A merger, for instance, where two companies run different leave types and different payroll cycles, and someone must reconcile them. We spent our careers building software for the situations we could predict, and left people to improvise for the ones we couldn’t.
For most of my career I would have told you that’s just how enterprise software is. Then the AI wave hit.
We shipped AI features as fast as anyone. Assistants, summaries, suggestions. All of it still lived inside the same library of anticipated scenarios. After two years of it, I watched our own demos, day after day, and realized we had built a faster horse. A chatbot that summarizes your leave policy is lovely. But, the CHRO’s question was still sitting in the drawer, unanswered.
A brilliant new hire on day one
We tried what the rest of the industry was trying. It didn’t work. The idea was simple. The LLMs are brilliant, you just need to connect them to your system. Call it the plumbing theory. So, we described our platform as a set of tools (actions one could take on the system), wrapped them in the new protocols, plugged in the LLM, and waited for the magic.
I remember watching the smartest model on earth stare at our function catalogue the way a brilliant new hire stares at the intranet on day one. Access to everything, ready to do anything but no idea what the rules are, who to ask, or why anything is the way it is. Not because she isn’t capable, but because nobody told her how this place works.
Ask it something real, like what happens if we absorb this company, and it would start calling functions confidently. Sometimes even the right ones, in the wrong order, for the wrong reasons. Past a couple dozen steps, it degraded into guesswork. In a ten-step demo, it looked like magic. At our scale it was a very expensive way to be wrong.
The model wasn’t the problem, and neither was the connection. The problem was that the merger question touches org structures, role definitions, comp bands, leave accruals, and payroll calendars, in a particular order, under particular rules, and nothing in our platform, or anyone’s, knew that.
So where did that knowledge live? Mostly with a few people who had been at the company long enough to make sense of it, who could look at years of piled-up configuration and remember why each layer got added. And for the "why" questions, why a policy was set up a certain way, there was often no answer at all. The person who made that call had left, and the reason left with them. We had built systems that didn’t hold their own knowledge. Nobody planned it that way. It’s just what happens when knowledge has no place to live.
A place for knowledge to live
So, we committed to the least glamorous build imaginable. Making all of that knowledge explicit. Everything the platform can do, the workflows and approval chains. Everything a customer has configured, the structures and the exceptions. Everything the domain demands, from payroll logic to internal mobility. And, at last, the reasoning. The why behind each of those choices, so it finally has a place to live.
We didn’t write it down as documentation, because documentation goes stale the moment it is published. We built it as a living structure, native to the Darwinbox record generated from the platform itself and versioned with it, something a machine can actually read and reason over. Internally we call it the context graph. The record captures the decision. The context graph captures the reasoning. And when it reasons about your organization, it reads your reality live, at the moment of asking. Never a copy.
Cortex is the first HCM to be built on a context graph. It was the single largest investment of the rebuild, and for most of a year it produced nothing you could demo. I sat in review after review defending it with one argument. This is the thing the model reasons over. Without it, it’s day one, forever.
Then it started paying, and it paid in a currency I hadn’t expected.
The CHRO’s merger question got its answer. Ask the rebuilt system what happens if you absorb that company, and it traces the connections: roles to bands to accruals to payroll cadence. It comes back with the scenarios, each one priced in cost and legal risk. It doesn’t have that answer stored. It worked the answer out.
But the moment I actually remember, the one where I thought, this changes the shape of the category, came from an early preview session with a longtime customer. An HRBP took an early version of Cortex and put together a retention plan on the system himself, end to end. The eligibility rules, the approvals, the manager communications. The kind of thing that used to mean a ticket to us and three weeks of waiting. He didn’t need anyone from my company driving, because for the first time he could take an idea and build it himself. I’ve been selling "empowerment" my whole career. That was the first time I watched it happen. Magical.
Moments, not modules
Something else changed in those preview sessions. The one that rearranged my head more than the product.
A few months into one deployment, the system flagged something nobody had asked for. On one assembly line, four things were happening at once. A batch of certifications was expiring, and the renewals wouldn’t finish in time. An approved plan to reduce overtime was about to take effect. The workforce plan already assumed higher output from that line next quarter. There was just one candidate in the hiring pipeline, and they weren’t due to join for another sixty days. None of those needed action on its own. Together, they meant the line would fall below minimum certified staffing just as the higher output came due. A production problem sixty days out, visible only to something watching all four threads at once. The system surfaced it as one moment, with options already simulated, including the one nobody in the room had thought of: temporary cover from the plant that had just joined the company through acquisition, whose certified operators the context graph could now see.
I built modules for a decade. Recruitment, onboarding, compensation, performance. That’s how we vendors see the employee lifecycle, because that’s how we organized our engineering teams. But look at where those four signals lived. Learning, time, workforce planning, hiring. No module owned the problem, so no module could see it. Organizational life happens as signals quietly becoming moments, cutting across every boundary we ever drew. Every expensive workforce problem was visible before it was expensive. The question is whether your system was built to look out or built to wait.
Ours, and everyone else’s, was built to wait. It isn’t anymore.
Arguing with the machine
The other memory from those preview sessions that I keep coming back to is an argument between a leader and the system. That’s a sentence I couldn’t have written two years ago.
As part of an integration, the system had proposed consolidating two overlapping structures, with the trade-offs laid out. The executive reviewing it disagreed. He wanted to keep five senior coordinators and give the transition more time, and instead of clicking through a form, he just told the system that, the way he’d push back on a colleague.
It recalculated and showed him what his version changed. A longer timeline, a different cost, and one retention flag cleared. It didn’t defend itself. It costed his version, put it next to its own, and left the decision where it belonged. His change stood. The coordinators stayed.
Later that day it was sequencing the payroll cutover, and it had two options ready. He liked one of them, until the arithmetic showed it cost $180K a year more than the other. He reversed himself. Laughing, but he reversed himself.
I’ve thought about that exchange a lot, because I think it shows where these systems are headed, and almost nobody is describing it. The future is not autonomous agents doing things to you, and it’s not chatbots doing summaries for you. It’s something closer to a negotiation with an entity that has read everything your organization is. Every plan is a draft you can argue with. The system argues back, with citations, and then writes down who decided what. Every action it takes produces what we call a receipt: the answer to "why?", asked six months later. Trust, it turns out, isn’t a feature you add. It’s a paper trail you generate. And once a plan is approved, the improvising stops. Exploring is the agent’s job. Execution runs the way enterprise software always had to run. Permissioned, gated, reversible.
And autonomy, the word this industry can’t stop saying, turns out to be boring in the best way. It’s earned. The system asks before it acts and shows its record. When it handles a series of decisions well, it builds the trust to earn more autonomy. But it earns autonomy only after a human explicitly provides it the autonomy. Each decision it handles well adds to the trust behind it, but the approval it needs to act never goes away. When something gets reversed, its scope shrinks, on its own. And the line between what it may do and what it must ask never moves without you.
Where does all of this happen?
Not on our screens. That’s the last belief the rebuild took from me.
An engineer finishes a certification and asks what it opens up for her. She asks in Teams, because that’s where her work already lives. The answer comes back there too. Her skills update, three career paths appear, and under each one she can see exactly where she’d sit in the org chart. A small working interface, composed for her question, every permission intact, no login to our product anywhere.
Chat is a fine way to ask a question and a terrible way to look at an org chart. So the Cortex and the answer to the question carries its own interface to wherever the person already is.
The screen didn’t vanish. Its monopoly did.
The drawer, opened
Here’s what I’d say to that CHRO now.
The system that comes out of a merger like hers is not the system that went in. The processes it built along the way stay with her company as templates. Its reading of signals gets sharper, because it has now seen real outcomes. The set of decisions it has earned the right to run keeps widening, with the record to show for it. Most software improves when the vendor ships an update. This one improves as you use it. That’s why I call Cortex a different species of system.
If you ask me what this species does, I can now answer in four verbs. It sees the moment forming. It reasons over everything your organization is. It acts, and leaves a receipt. It meets your people where they already work, shaped like the task. Together, that’s a reflex. An organizational reflex.
Everything in these notes is real and running, and we’ll be showing it live. It’s also why we’re opening a design-partner program for Cortex, with an invitation I’ve wanted to extend for years. Bring us the question your systems can’t answer. Your merger, your restructure, your first new country. The thing in your drawer. And let us answer it.
It took me the better part of a decade to answer one good question from one thoughtful customer. The answer, finally, is Darwinbox Cortex. The AI-native HCM that’s ready before you ask.
