Why we're building the HR layer instead of another HR product.
On categories worth replacing, and how we picked the first one.
Most HR products treat the agent era as a feature checkbox. Add a chat sidebar, ship a "Copilot for HR" microsite, call it AI-native. The underlying architecture stays the same: a vendor-owned database, a vendor-owned UI, a vendor-owned API surface that humans poke through on the way to getting their work done.
We don't think that survives.
The shape of the shift
In every category we look at, the same pattern shows up. The amount of work an agent can do against a system is a direct function of how much of that system is reachable through structured tool calls. If the data lives behind a custom UI that an agent can't drive, the agent has to scrape a screen or wait for a human. Either way, the agent's leverage collapses.
Software that wins the next ten years will be designed so that the agent has the same surface area as the human user. Not a wrapper. Not a chatbot. The same primitives, exposed the same way, with the same permissions.
Why HR is the first place this matters
HR is the workflow where:
- The cost of stitching tools together is the highest. Every Series B has a recruiter manually copying candidate notes between three systems.
- The data is the most structured. Employees, candidates, contracts, time off: every entity has a clean schema.
- The compliance overhead punishes brittleness the most. One missing record at audit time is a six-figure problem.
The category is begging for a layer underneath it. Not another HR app. The layer that future HR apps will be built on top of.
What we're building
Otto HR is that layer. Every HR primitive is addressable through MCP. The UI is one consumer of it. Agents are another. Customers' own internal tools are a third. None of them are the canonical source.
We picked HR first because it's where the gap between what's available and what's needed is widest. The next category will be something else, but the pattern is the same.