Why We Didn't Use an Agent for Payroll, Even Though We Could

We had a technically feasible way to use an agent in payroll, but chose not to adopt it at delivery. The client's employees frequently went on temporary assignments to other cities. Different rules applied, and the hardcoded logic needed repeated changes. We had to consider who would look after those changes once the feature was built.

This was a Feishu AI operations and management automation project that ran from June to August 2026. There were two of us. I handled requirements, product design, and some of the weekly reporting and operations agents. We delivered in August, with the final scope focused on meetings, weekly reporting, and project collaboration.

The proposed payroll setup was straightforward: scripts would calculate under explicit rules, while an agent organized information and connected the steps. That approach remains worth considering. Looking back, though, “change the program whenever the rules change” bundled several different jobs into one sentence.

An employee changes cities. What needs to change in the system?

Consider a few possibilities to see where a reassignment might hold up the work. These illustrate the problem; they do not reconstruct particular reassignments in the project.

Suppose each city's rules are already settled, and a move changes only the employee's location and relevant dates. The main job is updating the input. Complete the record, and the program may be able to recalculate under existing rules. People moving frequently does not necessarily mean code must change frequently.

A more involved case is one where the business has agreed on a new rule, but the program does not support it yet. Someone needs to put the rule into configuration or code and check that it has been expressed accurately. The decision exists. Asking the business to discuss how the calculation should work all over again may only delay implementation.

The organization might also not have settled which rules apply to this kind of temporary assignment. That needs a business decision first.

To the person using the system, the last two cases can both look like “it can't calculate this yet.” One needs a maintainer to update the program; the other needs the business to settle the rule. Treat them alike, and a maintainer may end up making a business decision while editing code. Or a simple input error may send everyone back into a policy discussion.

Knowing where the program stopped is not enough to tell us whom to ask first.

Once the rules are in a table

When hardcoded rules keep needing changes, a configuration table is an obvious idea. Separate the versions, scope, and effective dates from the calculation code, and an agreed change may become a configuration update instead of another call to a developer.

A few questions follow. Who makes the update? Which version do they use? Do earlier records need recalculating afterward? Whoever maintains it needs a clear rule in time, must express it correctly in the system, and must let the next person know what changed.

If the business has not decided, a convenient configuration screen just offers a convenient blank. Product builders can develop a hopeful expectation: we have prepared all the fields, so perhaps the organization will get its answers together too. The table can decide where an answer goes. It cannot decide when everyone will have one.

An agent could help find supporting material, compare versions, and organize the questions. If a person needs to confirm the result, give them the differences and sources together. Otherwise, the interface looks simple, with just a “confirm” button, while the person behind it has to investigate the whole thing again.

In Ironies of Automation (1983), Bainbridge points out that work left to people after automation, including exception handling, also needs support.^[1] She was writing about industrial control. I borrow that perspective to reconsider our proposal: once a program takes over part of the job, is the rest any easier for people to do?

Better conditions deserve another look

If the rule source were clear, changes could be configured accurately, and people were responsible for ongoing updates and checks, I would not reject the approach simply because the business changes often. Updating a table of settled rules takes a different kind of effort from finding someone to settle the rule and then changing the program each time.

Making it configurable is not enough. A rule may be clear while nobody updates it before use. Or an update may leave the next person unsure which calculations it affected. I would still advise against handing the whole payroll process to an agent under those conditions. A few fewer steps do not by themselves make the result dependable.

The scope can start smaller. Give settled calculations to scripts, use an agent to help organize material and compare changes, and leave unresolved interpretations with the business. If the script is already enough, the agent needs something useful to add. There is no need to invent a job for it just to keep AI in the proposal.

I did not fully measure this project's maintenance costs, so I cannot say it proved that automation cost more than it saved. What we did encounter was repeated adjustment of hardcoded logic as employees moved temporarily between cities. A team of two has to consider both what it can implement now and how much support it can provide after handover.

I stand by the decision then and would reassess it if the rules and maintenance arrangements improved. That choice had specific reasons; it does not establish that AI is unsuitable for payroll.

Next time, take one change all the way through

For a similar request, I would ask the business earlier for a recent, real change and follow it through: how the rule is settled, how the information enters the system, what needs updating, and who checks the result. I would also look at where work stops when a key person is temporarily unavailable.

If the program cannot express an agreed rule, fix the implementation. If the rule has not been settled, deal with the business decision first. If every step works but the saving remains unclear, record the time spent confirming, waiting, updating, and reviewing, then compare.

When the next employee temporarily changes cities, I want the person taking over to know what to do and whom to turn to with a problem. Seeing that would give me more confidence in the proposal than watching it produce one calculation.