Native, partner, or custom — where your HR agents should actually live

Three things are true at once in 2026. The Workday roadmap ships more native AI every release. The marketplace has more partner agents than ever. And inside most HRIS teams, someone is building something in Flowise or LangChain on the side because they wanted to and now it works. Making sense of all three at once is the strategy question, and most teams over-rotate on the third one because it is the most fun to talk about.

What each option actually is

Native Workday agents are agents Workday itself ships as part of the product. Recruiting agents, talent mobility agents, contract intelligence, payroll, contingent sourcing, and an expanding list. They sit inside Workday's cloud, use Workday's data model, respect Workday's security, and update on Workday's release cycle. You configure them. You do not build them.

Partner agents are agents built by Workday partners and published through the marketplace. Paradox for conversational recruiting. Phenom for talent experience. Beamery for talent intelligence. Pymetrics for candidate assessment. Most are deeply integrated with Workday and look like a Workday extension to the end user. A separate category, often confused with partner agents, is the agents Workday has acquired and folded into the platform: HiredScore for recruiting, Evisort for contract intelligence, Sana for the conversational front door. These are native now, not partner products, even if some HR teams still treat them like marketplace add-ons.

Custom agents are agents you or a partner build on top of Workday using Workday Extend, Flowise (which Workday acquired), or another agent platform. You design the workflow, write the prompts, manage the integrations, and own the lifecycle. The freedom is total. So is the responsibility.

The default we recommend

Native first. Partner where it fills a clear gap that native does not. Custom only where the use case is specific enough that no packaged option fits and the value justifies the build.

That default sounds boring. It is also the one we have seen work across the most clients. The teams that default to "we build everything custom" end up maintaining a portfolio of agents that mostly replicate something Workday will ship next year. The teams that default to "we buy everything" end up locked into vendor roadmaps for problems that were specific to their own operating model.

A short worked example. An HRIS team had four agent ideas on the list: candidate screening, an HR policy question assistant, an internal mobility recommendation engine, and a workflow for a country-specific compliance process tied to their own internal policies. Three of those mapped onto existing native or partner products. They picked the products and were live within a quarter. The fourth was specific enough to their own operating rules that nothing on the marketplace fit. They built it custom. Total time to market across all four was less than they would have spent building one of them from scratch.

When native is the right call

When the use case is broadly applicable across Workday customers. When the data lives entirely inside Workday. When you want updates to ride along with Workday's release train. When you do not have, or do not want to build, internal agent engineering capability.

Native agents have a particular strength most teams underrate: they will keep improving on Workday's schedule whether you do anything or not. Skills Cloud, Document Intelligence, the various forecasting agents. The roadmap moves under your feet in a good way. Teams that build their own version of these things spend more on maintenance every year than the native version costs.

When partner is the right call

When a use case is well-defined enough that one or more partners have built a serious product around it, and you would not gain anything by reinventing it. Recruiting is the obvious category. Talent mobility, contract intelligence, contingent sourcing, conversational recruiting. The partners that have been in the marketplace for several years are usually a faster, more reliable choice than building from scratch.

The trade-off to look at clearly: cost over five years. Partner agents are subscription products. They look manageable in year one and grow in line with your headcount, usage, or both. A 50,000 euro annual subscription is 250,000 euro across five years. That is a real number. Whether it is the right number depends on what it replaces and what the agent actually does. The right time to push back on partner pricing is at renewal, with usage data in hand.

A second trade-off: vendor roadmap risk. The partner sets their own direction. If the feature you need stays in the backlog, you wait. If the partner gets acquired or sunsets the product, you migrate. None of this is hypothetical. The marketplace has seen exits before. Build the dependency consciously.

When custom is the right call

When the use case is specific to your operating model in a way the marketplace cannot serve. Local labour processes that depend on your own policies. Industry regulations that only apply to a handful of companies. Cross-system workflows that run across Workday and several internal tools where no partner has built the integration. Or when the use case is your competitive edge and you do not want to depend on a vendor's prioritisation.

Custom agents also make sense when the data the agent operates on is your own and not generally available. Internal job architecture. Proprietary skills taxonomies. Internal mobility logic that reflects your specific career frameworks. A generic agent will not have this context. Yours will.

The honest counterweight: custom agents are not free. You pay in build effort, ongoing maintenance, regression testing on each Workday release, and the operational burden of running a system you own end to end. A useful sanity check: if you cannot name the person who will own this agent in 18 months, you should not start building it now.

What changes the answer at scale

A few patterns worth knowing. Once you have three or four custom agents in production, the marginal cost of the next one drops sharply. The platform investment is paid down. The team understands the patterns. The integration plumbing is already there. At that point, custom becomes more economic for problems that would not have justified a one-off build.

The opposite is also true. The first custom agent in an organisation that has no Extend capability, no integration tooling, and no AI governance is expensive in ways that look more like a transformation programme than an app build. That is fine, it just needs to be in the business case honestly.

Native and partner options also expand each year. A use case that was custom-only in 2024 may have a native or partner answer by 2026. The strategy should be revisited annually. The right answer changes faster than most HRIS roadmaps do.

The architectural piece that ties it together

Workday's emerging Agent Gateway and Agent System of Record (ASoR) concepts are meant to bring native, partner, and custom agents into a single governance plane. The Gateway is the front door for non-native agents to talk to Workday using shared protocols (MCP, A2A). The ASoR is the central registry where agents are governed, monitored, and given KPIs the way workers are.

This matters strategically because it shifts the "native vs custom" question. As Workday's agent layer matures, the cost of mixing native, partner, and custom agents in one operating model is meant to drop. You will be able to run a portfolio of agents from different sources with shared governance, shared identity, and shared monitoring. That makes the case for "native first, custom where it adds value" stronger than ever, because the operational tax for mixing is lower than it used to be.

A short test to apply per use case

Four questions per use case. Does Workday already ship something close, or have a roadmap entry within the next two releases? If yes, default to native. Does a credible partner in the marketplace solve it with a product you would not have built better? If yes, partner. Is the use case specific to your operating model, your data, or your competitive position? If yes, custom. And, the last test: would you still build this in 18 months if Workday shipped a native version of it tomorrow? If the answer is no, do not build it now.