At Workday Rising on October 13, 2026, Workday made custom agents generally available as part of Workday Extend AI, together with Developer Agent and Agent-Ready Tools. A custom agent is an AI agent your organisation designs for its own process, running inside Workday with Workday's security, approvals and audit trail.

Workday has published what custom agents are; it has published much less about the day-to-day steps of building one. This guide gives you a practical plan for a first agent that works within those known facts.

What a Workday custom agent is

From Workday's announcements and product pages:

  • Custom agents run on Workday's Agent Harness, which gives each agent an identity, role, permissions and policies, and governs each action it takes.
  • They are registered automatically in the Agent System of Record, where agents are managed alongside the people they work with.
  • They inherit the user's permissions, keep audit trails and can pause for human approval.
  • They are defined in the open AgentSkills format, and can be surfaced in Workday, Sana and third-party assistants such as Gemini Enterprise and Claude.
  • They act through Agent-Ready Tools, Workday's library of more than 400 pre-built tools for reading Workday data and taking actions.
  • They are typically built with Developer Agent, Workday's AI that turns a plain-language description into agents, apps and orchestrations. Developer Agent is available through Workday Extend Professional.

Step 1: Pick one narrow job

The best first agent removes a repetitive step from a process people already do, and has an obvious end point. Good candidates:

  • preparing a manager's pending time-off approvals with balances and team coverage;
  • answering policy questions about a single benefits plan and linking to the right task;
  • assembling the data a recruiter needs before an internal move.

Avoid anything that pays people, changes compensation or touches many workers at once for a first build. Those are fine later, once you have seen how your organisation reviews agent actions.

Write the job down in two sentences: what the agent does, and when it is finished.

Step 2: Decide whose authority it uses

Workday says custom agents inherit the permissions of the user they act for, and every action traces back to that person. That is the right default: the agent can never see or do more than the person asking.

Check what that means in practice. A manager's agent can see only that manager's team. An HR partner's agent sees what that partner's security groups allow. If the agent needs to do something the person cannot, that is a sign the process design is wrong, not that the agent needs more access. The companion guide on securing custom agents covers this in detail.

Step 3: List the tools it needs, and nothing else

For each step of the job, note which Workday data it reads and which action it takes. Map each one to an Agent-Ready Tool. Keep a separate column for actions that change data. Each one should have a clear human approval before it runs, at least in the first release.

If the job needs data Workday does not hold, such as a policy document, plan that connection explicitly. If it needs a record type Workday does not have, Developer Agent can extend Workday with new business objects and business processes. Treat that as a Workday Extend change with its own review, because data model changes are hard to undo.

Step 4: Build in a development tenant

Build where mistakes are free and reversible:

  • Organisation projects use the company's Workday Developer Site account and its non-production tenants.
  • Learning and prototypes can use a personal developer account. Workday now lets individuals create one on the Developer Site and request their own Development tenant (personal development environments are in beta). See how to set up a personal developer account.

Describe the job to Developer Agent from the Developer Site or from a supported coding tool, then review what it produces before you deploy it. The Developer Agent review checklist lists what to check.

Step 5: Test it as real people, in non-production

Workday says customers can test most agents free in non-production, and that metering happens almost entirely in production. Test thoroughly there:

  1. Happy path. Ten realistic requests from the intended users.
  2. Security. The same requests from someone who should see less, such as a manager of a different team. The agent must not reveal data that person cannot see.
  3. Refusals. Requests outside the agent's job. It should decline politely.
  4. Workday rejections. A request that Workday's validation will reject. The agent should explain the reason and stop, not retry.
  5. Cost. Count the actions each request takes. Use the numbers in your Flex Credits budget.

Step 6: Move to Production deliberately

Before go-live, confirm the agent appears in the Agent System of Record with the owner you expect, that the consumption console has alerts set, and that someone has agreed to read the agent's audit trail for the first weeks. Release to a small group first, compare their real usage with your test numbers, then widen.

Where kiweely fits

kiweely is a desktop co-pilot for Workday consultants, including those who do not write code. In one conversation it connects to a client's non-production tenants, with your consent at each change, and does the surrounding work a custom agent depends on: checking and adjusting security, building and validating the Workday Extend apps and business objects the agent uses, deploying them to Development and testing them in the browser as different users. It runs on the ChatGPT or Claude account you connect, on your own computer, and keeps each client's connections separate.

Sources checked