Paying for the Same Work Twice

Recently, a detail in the reporting about Accenture’s Claude spending caught my attention: the project code.

On October 15, Joseph Cox reported for 404 Media that Accenture had changed how it funded employees’ Claude use. Reporting described a centrally funded $29 monthly amount, with additional spending charged to an approved project. Accenture subsequently disputed the description of a firm monthly limit, telling Forbes that the figure illustrated one part of its funding approach.

That qualification matters. So does the question the project code leaves open: has someone already done this work?

Imagine two teams commissioning substantially the same competitor briefing. Each uses an approved tool. Each charges the right project. Each produces something useful. Somewhere in the firm, an earlier assessment already answers the question.

The accounting can be clean on a job that was done twice.

Every fresh chat

We can become very precise about the cost of producing an answer. We can count tokens, infrastructure, evaluation, and the people who keep a service reliable. Cost per completed piece of work brings us closer to understanding value. But that measure depends on what we allow to count as a new piece of work. Every fresh chat can make an old question look new.

A stored answer

The temptation is to treat this as a retrieval problem. Find the earlier answer and use it again.

For some requests, that works well. A semantic cache can recognize that a question resembles one already answered and return the stored response. Fifty employees asking about the same current policy may need the same answer, provided they are all permitted to see it.

The competitor briefing asks more of us. Two requests can sound alike while concerning different customers, contract years, or decisions. Finding a similar document begins the inquiry. Someone still has to judge whether it applies.

A stored answer tells us that a system produced something. A reviewed briefing carries an additional fact: someone accepted responsibility for it.

Who stands behind it

That responsibility is the part I want to follow.

Who owns the analysis? What question did it answer? Who reviewed it? Who may use it? What change would make it obsolete?

Those questions describe what I would call a work registry: a searchable record of work the organization has accepted, with enough context to judge whether it remains useful. The document can stay where it lives. The registry connects it to an owner, a purpose, and the conditions under which someone can rely on it. We already have places for the file. A shared drive or a wiki can hold the briefing long after anyone remembers who stands behind its claims or which ones still hold. The registry names that responsibility.

Consider what happens when the next team needs that competitor briefing. They find the existing assessment. Its owner confirms that the central argument still holds, identifies changes in pricing and leadership, and flags an earlier claim that the evidence no longer supports. The team updates those sections, preserves the source trail, and records which claims were refreshed and which were retired.

There is still work to do. Reading takes time. Checking applicability takes judgment. A refresh may require new research. The earlier investment gives that effort a starting point, and the record makes the decision visible.

It should also leave room for a fresh assessment. A different customer, a changed market, or an independent review can justify doing similar work again. Recording that reason helps the next person understand the choice.

The cost of keeping it

The economics have to support this behavior. If finding an owner and arranging a review takes longer than opening a new chat, people have a practical reason to start over. If teams absorb all the effort of maintaining shared work while only other teams benefit, ownership becomes a burden.

An approved shared asset needs someone with time to keep it useful. When another team uses it, their project code should carry the cost of the lookup, judgment, and handoff. The record should also credit the owner’s contribution to that work. A refresh should reflect the work that changed. Recreating an applicable result deserves a question about why it was necessary. If the only work the books can see is a new chat, the person keeping the briefing current is spending time so someone else can go faster.

This also puts a limit on the registry itself. Searching, reviewing, and maintaining records all carry costs. A short-lived answer may be cheaper to produce again. The case for a registry is strongest where work requires substantial research, review, or responsibility, and where others are likely to need it.

The project code makes consumption visible. Making prior work usable requires a different kind of attention: someone must keep track of what the organization knows well enough to stand behind.

The next competitor briefing may begin with a prompt. I wonder how often its most valuable first step will be finding the person who owns the last one.

Madam I’m Adam