Ask ChatGPT or Claude how to fix a Workday problem and you get a good list of steps. Then you do every one of them yourself, in your tenant, by hand. The model isn't the limit; reach is. A chat assistant can't see your tenant, so it can only describe the clicks. An AI agent that is signed in to Workday as you can read the real setup, make the change after you approve it, and check that it worked.

One ticket, two answers

Take a ticket every Workday admin has seen: "Priya's time-off requests stopped going to her manager." (Priya is an example; the situation is common.)

A chat assistant answers along these lines: it can't see your tenant, but this usually happens when the condition on the manager's approval stops matching the worker. Open the Request Time Off business process, find the condition on the manager's approval, compare it with Priya's organization, edit the rule, then test it. Every click is still yours.

An agent signed in to the client's Sandbox tenant works the same ticket in the tenant:

  1. It reads Priya's latest request.
  2. It reads the business process and the condition rule on the manager's step.
  3. It checks Priya's organization since the last reorganization, and finds that her new organization isn't in the rule.
  4. It shows the change it wants to make and the tenant it will make it in, and waits for approval.
  5. Once approved, it adds the organization to the rule and reads the rule back from Workday.
  6. It tests the fix as Priya, with Start Proxy, and confirms the request now reaches her manager.

Both answers are built on the same kind of AI model. The difference is what each one can reach in Workday, and who checks the work.

What "making the clicks" involves

People configure Workday in task screens, and when a change has no web service, the screen is the only way in. An agent that works for Workday admins has to work those screens, and there are two reasonable ways to do it:

  • On screen: the agent types each step into the visible screen in a browser you can watch. It is slower, and you see everything.
  • Straight in: the agent enters the change straight into Workday, which is faster on tasks it has done before. Each step is listed as it happens, and the saved result opens in the browser at the end.

kiweely offers both as a setting. Our guide to making Workday changes that have no API covers how to tell whether a change has a web service, and what to require when it doesn't.

The safeguards that make this acceptable

An agent that can change a client's Workday has to be held to stricter rules than a person, because it works faster than anyone can watch. These are the rules kiweely follows:

  • It works as you. It signs in with your own Workday account, so Workday security decides what it can see and change. Its changes appear in Workday under your name, like any change you make.
  • Nothing changes without your yes. Every change shows a card that names the tenant and the change, and nothing is saved until you approve it.
  • Production is handled one change at a time. A Production tenant connects only after a warning you confirm. There, changes are made one at a time and read back.
  • Some lines it never crosses. It never installs an Extend app in a tenant for the first time, never promotes anything to Production, never promotes a data model change without asking, and never turns on Full Access by itself.
  • You can watch it work. Sign-in and work in the tenant happen in a browser on your screen, and you can stop it at any time.

When a chat assistant is still the right tool

Use a chat assistant when you want to understand something: how condition rules evaluate, what a calculated field function does, how to phrase a requirement. It is quick and costs nothing to ask. Use an agent when the answer has to end up in a tenant, and someone has to check that it did.