Most "AI in tax" answers skip the operating layer. They put a chatbot in front of a treadmill that has no constraint identified, no inspection point, no pull signal, no exception handling, no feedback loop. The chatbot is a toy. The treadmill is unchanged. There is a third path. Foundations first.
The AI conversation in tax right now
Every Head of Tax I talk to is having the same conversation. The CFO wants to know what they are doing with AI. The audit committee asked at the last board meeting. The IT team is offering pilots. The advisor is selling a chatbot. Meanwhile, the close is still thirty days. The FAR still does not reconcile in March. Last quarter's audit request took two weeks to assemble.
When I say every Head of Tax I talk to, the sample is specific. Over the past few years I have sat inside the tax operations of close to thirty percent of the ATO's Top 100. The pattern this article names is the pattern I keep seeing across that base. The fixes are the ones I am currently building inside TaxTime, where we are at the forefront of agentic tax operations as a product. The article is what I have learned across the base. The platform is where the learning is being applied at the edge.
There is real pressure to act. There is also the experience that tells them most of what they are being shown will not move the dial.
This article is for that conversation. It is for the leader who has watched enough "AI for tax" demos to know that the model is rarely the bottleneck. It is for the one who can feel that something has to change but does not want to spend a year and a budget on a chatbot that will sit unused.
The premise here is simple. Ninety days into most AI pilots, the team goes back to the spreadsheets. The model was not the problem. The function the model was dropped into was not ready to receive it.
There is a third path. Foundations first. Build the operating discipline that makes an agent useful before the agent arrives. The discipline is older than AI. It comes from Goldratt's factories, from Andy Grove's Intel, from Toyota's production lines, from Deming's quality movement. It has a modern name in software engineering. It has not yet been translated into tax. That is what this article does.
The framing word for the whole thing is harness. The harness is the standard work, the controls, the exception handling, and the learning loop that surround a worker. The worker can be a person or an agent. The harness is the same.
Without the harness, agents do not survive contact with the tax function. With it, agents compound. The team gets off the treadmill. The function gets to impact.
That is the argument. Here is how it is built.
The harness
The word comes from machine learning. An eval harness is the scaffolding that surrounds a model and tests its output against a known answer. The model on its own is just a function. The harness is what makes the function trustworthy. Without it, you have a thing that produces confident sentences. With it, you have a system you can measure and improve.
Translate that into a tax function and the picture clarifies fast. The "worker" in a tax function is whoever is doing the work. A preparer, a reviewer, a manager, an outsourced service centre, an offshore team, an AI agent. The harness is what surrounds them. It is the workpaper template they fill in. The controls that check what they enter. The reconciliation that fails when the totals do not tie. The sign-off chain that records what was approved and by whom. The post-close retro that turns this cycle's mistakes into next cycle's controls.
When the harness is strong, the work survives any worker. A new joiner can pick it up. An offshore team can run it. An agent can run it. When the harness is weak, the work lives in a senior preparer's head, in a bespoke spreadsheet, in the email chain. Change the worker and the work collapses.
The harness matters more than the agent for the same reason the manufacturing line matters more than the worker on it. A great worker on a bad line cannot save the line. A great agent on a bad line cannot save it either. The reverse is also true. A good line tolerates an average worker. A good harness tolerates an average agent.
This article names five laws of the harness. The operating disciplines that have to hold for a tax function to absorb an agent. Under those five laws sits one architectural choice that the literature does not always name explicitly but which makes the difference between a harness you can talk about and one you can build. That comes first.
Who this is for
The five laws in this article apply to a tax function as a whole. The angle of attack changes depending on who you are.
For the CFO. The question on your desk is what tax is doing with AI before the next board meeting. This article is the answer that does not require a six-figure pilot. The harness is what makes any AI investment land. Without it, the pilot stalls in ninety days. With it, every model the function licenses next year compounds. The first investment is the harness. The agent is the second.
For the Head of Data and AI. You have been pulled into tax because the CFO wants an answer. You are looking for a function with declared interfaces, observable state, and reproducible outputs. This article is the operating discipline that gives you all three. The harness is the engineering substrate. The agent is the application on top. The architecture in the next section is where the engineering rigour lives.
For the Head of Tax. This article is for you. The five laws name what you already feel. That the close, the audit, and the agent question all converge on the same operating discipline. Use it as your investment case. Use it as your board paper. Use it as the thing you point the team at on Monday morning.
For the Tax Manager. Every Monday-morning action below is yours to test. Pick one law per close cycle. By the end of the quarter you have rebuilt the harness in five concrete pieces, none of which required permission or budget. The senior judgement that makes you valuable becomes the layer that survives every transition the function will go through.
For the Tax Preparer. The harness is what protects your work, not what replaces it. A weak harness is the one that makes you the bottleneck and the blame point. A strong harness is the one that catches the error at the source, lets the work flow when the data is ready, and turns the close from heroics into routine. The agent that arrives lives inside the harness. The judgement that is yours to develop is what the harness is built around, not what it replaces.
The architecture under the harness. Atomic workpapers and loose coupling
The operations canon (Goldratt, Grove, Toyota) was written for factories where steps are physical. Steel moves down a line. Each step does something visible. The next step cannot start until the previous one finishes. The boundaries between steps enforce themselves.
In a tax function the steps are logical, not physical. There is no physical line. There are only spreadsheets, mappings, workpapers, sign-offs, and the assumed connections between them. Logical steps are easy to entangle. A change to one workpaper bleeds into the next because the boundary between them is a convention, not a wall. Six months later, no one remembers which calculation depends on which input.
The architectural fix is borrowed from software engineering. Software learned this lesson the hard way through fifty years of tangled codebases. The principle is loose coupling. Each component declares what it needs as input. Each component declares what it produces as output. The boundaries are explicit. You can change one component without breaking the next, because the contract between them is written down.
Applied to tax, this is what atomic workpapers mean. A fixed asset workpaper is a self-contained unit. It declares its inputs. The FAR balance, the prior-year closing position, the tax depreciation rules. It declares its outputs. The current-year tax depreciation, the temporary difference, the rollforward balance. It can be run on its own. It can be audited on its own. It can be replaced on its own. The next workpaper that depends on its output reads it through a defined interface, not by reaching into the spreadsheet.
A research-and-development workpaper is the same. A consolidation workpaper is the same. Each one atomic. Each one with declared inputs and outputs. Each one independently runnable. Each one independently auditable.
Contrast this with the architecture most tax functions actually run. The fixed asset numbers live in a tab of a master workbook. The R&D adjustments live in a different tab. The consolidation logic reaches across all of them with cell references. A change to the FAR roll cascades through five tabs and breaks the consolidation. The team finds out at sign-off. The fix takes three days. Nobody can explain afterwards what changed and why.
That is what tightly coupled looks like. Every workpaper depends on every other workpaper in undeclared ways. The function is a single tangled artifact masquerading as a set of components.
The atomic-workpaper architecture matters for two reasons. The first is that it makes the five laws below executable. You cannot find your constraint if every step depends on every other step. You cannot pull when the next workpaper is ready, because you cannot tell when a workpaper is ready. You cannot stop the line on a defect, because the defect is everywhere.
The second reason is the one that becomes obvious only when the agent arrives. An agent loop needs something to verify against. It needs a clean input. It needs a defined output. It needs a way to know it is done. An atomic workpaper provides all three. A tangled workbook provides none. We come back to this in Law 5.
The engineering properties this gives you are worth naming, because the Head of Data and AI on your team is going to ask. Atomic workpapers are typed. The input schema and the output schema are declared, not implied. They are idempotent. Running the same workpaper twice against the same inputs produces the same output. They are replayable. Any workpaper, any prior period, can be re-run against the data as it was. They are versioned. The rule applied to a transaction is the rule that was in force at the time, not the rule today. They are observable. Every run leaves a trace of inputs read, outputs produced, time taken, exceptions raised.
None of this is exotic in software engineering. All of it is exotic in tax. The reason the principle is worth importing is that it is the only architecture an agent can safely live inside. An agent needs a typed contract to call. An agent needs idempotency so the loop can retry. An agent needs replay so the eval suite can score it against historical truth. An agent needs versioning so a re-run does not silently apply a 2027 rule to a 2024 transaction. An agent needs observability so the human in the loop knows what happened. The engineering properties are not nice to have. They are the substrate the agent runs on.
Law 1. The constraint
The first law comes from Eliyahu Goldratt and the Theory of Constraints. Every system has one constraint. The whole system runs at the speed of that one step. An hour saved at a non-constraint is an hour lost. An hour saved at the constraint is an hour saved for the entire function.
In a tax function the constraint is rarely where you would guess. It is often one of four. The reviewer with the deepest knowledge, because everything ends up in her queue. The workpaper template that takes eight hours to populate, because it has not been refactored since the team was half the size. The consolidation logic that runs at the end and surfaces all the defects at once. The GL availability window, because nothing downstream can start until the load completes.
Most teams have never named theirs. They optimise everywhere. They buy a faster spreadsheet add-in. They onshore one role and offshore another. They run a workshop on "ways of working." None of this touches the constraint. The system keeps running at the speed of the one step nobody named.
From practice
The constraint is almost always time, and it surfaces at the preparer. One person carries the deep knowledge for a workpaper. The clock runs against them while everyone else waits. The better managers I work with respond by parallelising. They diversify the risk by skilling other preparers to run atomic workpapers in parallel. The constraint only moves when more than one person can run the same step at the same time, to the same standard.
Monday-morning action
For your next close, time-stamp each handover. The point at which one workpaper passes to the next. The point at which a preparer hands to a reviewer. The point at which the reviewer hands to a manager. Look at where the queue is longest. That is your constraint.
Why this matters for AI
An agent at a non-constraint is a screensaver. It runs. It produces something. The work in front of it is not the work that gates the close. Find the constraint before you find the model. If your constraint is the reviewer's queue, the agent that helps is the one that prepares the queue better, not the one that drafts emails faster.
Law 2. The cheapest inspection point
The second law comes from Andy Grove and the production model in High Output Management. Grove makes the point with breakfast. If the dish is bacon and eggs, the cheapest place to reject a bad egg is at the supplier, before it ever reaches the kitchen. The most expensive place is the customer's plate. The earlier you catch a defect, the cheaper it is. The later, the worse.
Every defect in a tax close has the same cost curve. A general ledger line that does not map to a tax account costs five minutes to fix at data load. The same defect at sign-off costs five days, because by then it has propagated through three workpapers, two reconciliations, and a draft return. The same defect surfaced at audit costs five weeks, because it now requires correspondence, a re-lodgement, and a position memorandum.
The harness gets the inspection point right. Controls are baked into the data load. Mapping rules fail the load if a GL line has no tax destination. Reconciliations fail at the workpaper boundary if the totals do not tie. Sign-off is the last place anything is caught, not the only place.
Most tax functions get the inspection point wrong by accident. They built the close before the controls. The controls got bolted on at sign-off because that was the moment a human was in the loop. The result is a function that catches every defect at the most expensive place.
From practice
Fixed assets is the obvious one. If the FAR data does not load cleanly, the temporary difference reconciliation breaks and the balance sheet stops aligning with the current tax adjustment. Caught at the load, it is a five-minute fix. Caught at journal posting, the preparer is out of context, the report has been drafted, and three workpapers downstream have to be reworked. Same error, two orders of magnitude in cost.
Monday-morning action
Pick one error your team caught at sign-off last cycle. Trace it backwards. Where could it have been caught for one-tenth the cost? Document the gate. That is your next control.
Why this matters for AI
An agent on bad input produces bad output, confidently. Inspection at the cheapest point is the difference between an agent that produces audit-ready work and an agent that amplifies garbage at machine speed. Build the gate at the input. The agent works inside it.
For the CFO. This is the cost-curve argument in finance terms. Every defect caught at sign-off costs ten times what it would have cost at the source. Every defect missed at sign-off and caught at audit costs ten times that again. The harness shifts the catch point upstream. The investment is one-off. The cost reduction compounds every cycle. The audit risk reduction compounds for the life of the function. There is no second category of investment in operations that returns on this curve.
Law 3. Pull, not push
The third law comes from Toyota. Calendar-driven work is push. The schedule says start Workpaper Seven on Monday. The preparer starts. The GL might not be ready. The fixed asset feed might not have landed. The work begins anyway. Three days later when the real data arrives, the workpaper is redone from scratch.
Signal-driven work is pull. Workpaper Seven does not begin because it is Monday. It begins because the GL load is complete, the fixed asset feed has landed, and the prior workpaper has signed off. The trigger is a fact, not a date. When the fact arrives, the workpaper opens. Until then, it waits.
The difference compounds. A push system guarantees rework, because the calendar is rarely aligned with the data. It also guarantees burst loading at the reviewer. Everything starts on Monday, everything finishes Friday, everything queues for the same person. A pull system distributes load by definition, because work begins when it is ready, not when it was scheduled.
Most tax functions run push. The close calendar is a master schedule. Every workpaper has a start date and a due date. Those dates are set before the cycle. The actual data lands on its own schedule. The collision is absorbed by the team, in late nights and rework.
From practice
Smart teams ask what is ready. The smartest pull ahead of the time constraint. The cleanest example I have seen is the soft close. The team reconciles eleven months as they go. When the full year arrives, the work in front of them is one month, not twelve. The annual close stops being a sprint, and the time constraint barely lands.
Monday-morning action
Pick one workpaper. Replace its calendar trigger with a data trigger. Even if the trigger is a manual Slack message that says "GL is loaded, you can begin." The point is to break the assumption that the date is the signal.
Why this matters for AI
Agents need signals. An agent that fires on a date produces date-quality work, which is to say work against whatever the input happened to be on that date. An agent that fires on a signal produces signal-quality work, which is work against an input that is actually ready. Pull is the difference.
Law 4. Build-in quality. Jidoka
The fourth law comes from Toyota again. Jidoka means "automation with a human touch." The line stops when a defect is detected. The system refuses to proceed if it cannot proceed honestly. The defect is fixed at the point it occurred, not at the end of the line.
In a manufacturing line, jidoka is a cord above the workstation. Pull the cord, the line stops. In a tax function, jidoka is a workpaper that refuses to calculate the DTA if the balance does not tie. A consolidation that refuses to run while one entity is unsigned. A sign-off step that records what the signer saw, not just that they signed.
The principle is the same. Quality is not added at the end. Quality is the system stopping when it cannot proceed honestly. The defect surfaces at the moment it occurred, not at audit eighteen months later.
Most tax functions do not have jidoka. They have inspection. A reviewer looks at the output. If the reviewer notices the defect, the defect is fixed. If the reviewer does not, the defect rolls through. Inspection depends on the reviewer being present, alert, and senior enough to catch the right things. Jidoka depends on the system. The line cannot proceed past the defect even if the reviewer is asleep.
From practice
The clearest example I can give is a repairs and maintenance capitalisation error. Catch it at the provision stage and the fix is a corrected workpaper and one journal. Miss it, and have the ATO catch it at the Justified Trust review, and the cost compounds. Reconciliations to produce. Letters to respond to. Analysis to defend the position. The reviewer's trust that no other similar mistakes are sitting there. The potential penalties and interest. Same error, two completely different outcomes.
Monday-morning action
Identify one place in your close where the line should stop but does not. A workpaper that calculates from a balance that does not tie. A sign-off that records the signer but not what was approved. A reconciliation that produces a number even when the inputs are off. Document it. That is your next control.
Why this matters for AI
An agent without jidoka ships confident wrong answers. An agent with jidoka halts and asks. The difference is not the model. It is the harness. The system around the agent has to be able to refuse what the agent produces if the agent produces something wrong. Without that, agentic tax operations is one wrong number away from a reputational crisis.
For the Tax Preparer. The errors that travel are the ones nobody caught at the source. The line not stopping is what makes the close stressful, because every defect that gets through ends up being your defect to explain. Jidoka inverts that. A workpaper that refuses to produce a number from bad input is a workpaper that cannot blame you for an answer you never gave. The harness with jidoka in it stops asking you to be perfect. It lets you be the senior judgement, not the last line of defence.
Law 5. The learning loop
The fifth law has three names from three eras of the same idea.
In the 1950s, W. Edwards Deming called it PDCA. Plan, Do, Check, Act. The work is planned. The work is done. The result is checked against the plan. The plan is adjusted based on what was learned. The cycle repeats.
In the 1970s, Toyota called the same idea kaizen. Continuous improvement. Every cycle ends with small adjustments that survive into the next one. The improvements are not heroic. They are routine. The accumulation is what matters.
In the 2020s the same idea has a new name in modern AI engineering. The agent loop. Anatoli Kopadze recently summarised it cleanly in a piece widely shared among AI builders. The shape is identical to PDCA, with one new participant.
DISCOVER → PLAN → EXECUTE → VERIFY → ITERATE
The agent runs through the loop. It discovers what needs doing. It plans. It executes. It verifies its own work against a defined gate. If the gate passes, the loop exits. If the gate fails, the agent iterates, taking what was learned into the next pass.
Peter Steinberger, quoted in the same piece, put it more bluntly.
You should not be prompting coding agents anymore. You should be designing loops that prompt your agents. — Peter Steinberger
The deepest insight in the modern agent literature is that the verifier is the heart of the loop. Without a real check that can fail the work, the agent grades its own homework. The model that did the work is too generous a grader. The loop becomes the agent agreeing with itself on repeat. Nothing improves.
This is where the atomic-workpaper architecture from earlier earns its weight. Atomic workpapers are exactly the verifier surface that an agent loop needs. Declared inputs. Declared outputs. An objective test that can fail. The totals tie or they do not, the FAR reconciles or it does not, the rule applies or it does not. Tangled spreadsheets cannot serve as a verifier, because there is no clean boundary at which to check. Atomic workpapers can.
Kopadze offers a four-box test for whether a loop is worth building at all. The task has to repeat. (A tax close repeats monthly, quarterly, annually.) Something has to be able to automatically reject bad output. (Reconciliations, rules, tie-outs.) The agent has to be able to do the work end to end. (One workpaper at a time, yes.) And done has to be objective, not a judgement call. (The number ties or it does not.) Tax operations pass all four. Most knowledge work does not.
The metric that decides whether a loop is paying for itself is cost per accepted change. Not tokens spent. Not iterations run. Cost per accepted change. If the agent produces ten outputs and you discard six, the loop is costing more than it is giving back. Track that one metric and the loop either gets sharper or gets retired honestly.
From practice
The best learning loop I have seen in a tax function is also the simplest. Review comments from the prior period become input for the next period. Missed accrual deductions. Missed deductible prepayments. Repairs and maintenance recapitalisations. The team that treats review comments as test cases for the next cycle stops making the same mistakes. The team that treats them as an inbox to clear keeps making them.
Monday-morning action
Run a thirty-minute retro on your last close cycle. Three improvements. Documented. Assigned. By the next close, those three are controls, not anecdotes. One improvement that survives is the test of whether the loop exists at all.
Why this matters for AI
The learning loop is the difference between an agent and a chatbot. A chatbot answers. An agent runs the loop. The harness improves the agent by giving it sharper verifiers. The agent improves the harness by surfacing the workpapers where the verifier kept failing. Close by close, both get better. That is what compounding looks like. Anything that does not compound is not agentic. It is automation with extra steps.
For the Head of Data and AI. The eval loop in a tax function is a regression suite over the close. Golden datasets are prior-period workpapers with known-correct outputs. The agent runs against the inputs, the verifier compares to the output, accept rate per workpaper class is the metric that matters. Below threshold and the workpaper class is not yet ready for the agent. Above threshold and the agent runs while the team focuses on the workpapers it cannot do. The whole loop is observable, replayable, and versioned. This is not bolt-on. This is the discipline you already apply to model deployments, translated into the tax function.
For the Tax Manager. The question you will be asked first is which workpapers to delegate to the agent. The right answer is the ones the verifier already exists for. High volume, low judgement, declared inputs, objective tie-out. Fixed asset depreciation. Trial balance mapping. Intercompany reconciliations. Routine accrual reversals. The agent runs these first because the eval loop can prove the output is right. The team keeps the workpapers where judgement is the value. The harness is the line you draw between the two. The line moves as the agent earns trust on each workpaper class in turn.
Putting the harness together
The five laws and the atomic-workpaper architecture interlock. Each one matters because the others matter.
A constraint that has been identified is meaningless if the work that flows through it is not pulled when ready, because the constraint just absorbs the burst load it would have absorbed anyway. Pull is meaningless if the workpapers are not atomic, because there is nothing to be ready or not ready in a discrete way. Atomic workpapers are meaningless without jidoka, because a clean boundary does not help if the line cannot stop at it. Jidoka is meaningless without inspection at the cheapest point, because defects caught late have already cost too much. Inspection at the cheapest point is meaningless without a learning loop, because the same defects will keep arriving. And the learning loop only compounds if all of the above are in place, because the loop needs verifiers and verifiers are everything above.
The harness is a system. Five laws, one architecture, one loop that ties it all together.
This is where TaxTime sits. The platform is the harness made real. The architecture is a tax ledger. A single, queryable, drillable record that ties the constituent parts of the tax function together. The general ledger flows in. The opening positions are carried forward. The tax rules are applied as declared. The workpapers are atomic, each one with explicit inputs and outputs. The calculation runs at the ledger, not at the report. The presentation reads from the ledger. Every number on every report drills back through every adjustment to its source line in the GL.
What this gives the function as a whole is lineage, which is the property that every number can be traced backwards through every transformation that produced it, and observability, which is the property that every workpaper run is logged with its inputs, outputs, exceptions, and duration. Lineage answers the auditor's question. Observability answers the engineer's question. Both are by-products of the architecture, not features added after the fact.
Contrast that with how most tax stacks are actually architected. The general ledger feeds into a mapping layer that aggregates dozens of lines into summary buckets. The summary buckets are pulled into the tax engine. The tax engine calculates against the summary, not the source. The reports present the result. There is no drill back. There is no way to ask, why is the deferred tax balance up by $4 million this quarter, and get an answer from the platform. The answer lives in the head of whoever ran the close. Mapping obscured the inputs. Aggregation hid the working. Calculation downstream means the audit trail starts after the inputs are already lost.
That is the difference between a harness and a black box. The harness explains itself. The black box produces a number. In an agentic future, only one of these is survivable.
The fix takes a quarter, not a year. One law a month, applied. By the end of the quarter the harness is real. By the end of two quarters the agent is compounding.
For the CFO. The investment shape matters. The harness is built in a quarter, not a year, because the unit of work is one law per month applied to the function the team already runs. There is no transformation programme. There is no six-month implementation. There is no consulting wave. The Head of Tax leads it, because every law lives in the close. The CFO funds it, because every law removes a recurring cost or a recurring risk. The agent that arrives in the next quarter or the next year then runs free inside it. The first investment is the harness. The second, much smaller, is the agent.
What it costs, what it returns
Every CFO reading this is doing the same arithmetic. What does the harness cost. What does it return. What is the cost of not building it.
The cost is one quarter of focused leadership attention from the Head of Tax, applied one law at a time. There is no transformation programme to commission. There is no six-month implementation to fund. The unit of work is small enough that the team rebuilds the harness inside the work it is already doing, not alongside it.
The return is straightforward. The cost of a defect drops by an order of magnitude when it is caught at the source rather than at sign-off, and by two orders of magnitude when it is caught before the auditor finds it. The cost of the close drops because the constraint moves, the work pulls when ready, and the line stops on defects. The cost of the audit response drops because the lineage is in the platform, not in the senior preparer's head. The capacity returned to the team is the capacity that goes into impact work.
The cost of not building the harness is the cost of the AI investment that does not land. The chatbot pilot that stalls after ninety days. The model the team licenses that nobody trusts. The board paper that has to be re-written next year because the answer changed but the working did not. The harness is the prerequisite that makes the AI line item on the budget worth the money. Without it, the AI spend underperforms regardless of the model. With it, the AI spend compounds.
For the Head of Tax. A board paper in seven lines
If you are presenting this argument upward, the spine of the case is short. Lift these directly.
- Tax operations is a production system. It runs at the speed of its constraint. It improves through its learning loop. The same disciplines that run modern manufacturing run modern tax.
- Most AI investment in tax stalls because the investment is layered onto a function that cannot absorb it. The model is rarely the problem. The harness around the model is the problem.
- The harness has five laws. Constraint identification, cheapest inspection point, pull-not-push scheduling, build-in quality, the learning loop. Under all five sits one architectural foundation. Atomic workpapers with declared inputs and outputs.
- The harness is built in a quarter, one law per month. There is no transformation programme, no six-month implementation, no consulting wave required.
- Catching a defect at source costs an order of magnitude less than catching it at sign-off, and two orders of magnitude less than catching it at audit. The harness shifts the catch point. The savings compound every cycle.
- The harness is the prerequisite for every dollar of AI investment in tax to land. Without it, the AI pilot stalls. With it, every model the function licenses next year compounds.
- Off the treadmill, on to impact. The harness is how the function gets there.
Off the treadmill. On to impact.
The tagline we close every TaxTime post with is not a sign-off. It is the argument.
The treadmill is the work that runs the team. The reviewer drowning in March. The workpapers rebuilt every cycle because the inputs landed late. The audit request that takes two weeks to assemble because the lineage is in someone's head. The post-close retro that gets cancelled because the next close has already started. That is the treadmill. The team is not getting anywhere. The treadmill is just moving faster.
Impact is the work that moves the function forward. The position taken because the data was clean enough to take it confidently. The Justified Trust evidence that arrives the same day it is requested. The hour the Head of Tax spent in a board meeting instead of in a workpaper. The advisor relationship that is about strategy, not data preparation. That is impact.
The harness is what moves a function from the treadmill to impact. Not by working harder. By building a system that does the treadmill work as a by-product of being well designed. The harness is the architecture. The agent inside the harness is the leverage. Together, they get the team off the treadmill and on to impact.
This is the foundation of an agentic-enabled tax function. The agent is not the foundation. The harness is. Build the harness first. The agent that arrives next quarter, next year, or three years from now will land softly into a system that knows how to use it.
Three predictions
If the argument in this article is right, three things follow over the next twenty-four months.
The first is that the AI investments landing in tax right now will sort themselves into two categories by the end of next financial year. The ones that landed in a function with a harness will be compounding. The ones that did not will have quietly stalled, and the line item will be re-allocated to the next pilot. The model the function bought will be less of a factor in the outcome than the architecture it was dropped into. By 2028, the case studies will all read the same way. Harness first. Agent second.
The second is that operating-discipline language will become standard in tax leadership conversations. Constraint. Cheapest inspection point. Pull. Jidoka. Learning loop. These terms will appear in board papers, in vendor pitches, in role descriptions. The teams that fluency-test their advisers on this vocabulary will identify the serious ones quickly. The teams that do not will fund the wrong programmes for one more cycle.
The third is that the tax platforms surviving the agentic transition will be the ones with a tax ledger that explains itself. The platforms that aggregate upstream and calculate downstream will keep selling for a while. They will not earn the agent renewal. The architecture is the moat, and the moat compounds faster than the renewal cycle. By 2028, the question every tax leader asks of a platform vendor will be the same one. Show me the lineage. The vendors that cannot are gone within the cycle.
Off the treadmill. On to impact.
Sources and further reading
The five laws are not new. They have been tested for decades in other industries. The translation into tax is what this article does. For the reader who wants to go to the source.
- Eliyahu M. Goldratt. The Goal. Theory of Constraints. Law 1.
- Andy Grove. High Output Management. Production model, leverage, cheapest inspection point. Law 2.
- Jeffrey K. Liker. The Toyota Way. Heijunka, kanban, jidoka, kaizen. Laws 3, 4, and 5.
- W. Edwards Deming. Out of the Crisis. PDCA. The original learning loop. Law 5.
- Anatoli Kopadze. "Loops explained." The modern agent loop, the verifier, the four-box test. Law 5.
- Peter Steinberger. Quoted in Kopadze. "You should be designing loops that prompt your agents."
Two sibling pieces on the TaxTime site also matter for the reader following this thread. Why MCP is the tax operations breakthrough no one is talking about explains the protocol that exposes the harness to an agent. The four levels of AI in tax places the agentic level inside the broader landscape.
.png)
.png)
