Alfred should be hired by a CFO
If an AI agent cannot be connected to the financial statements, it is probably a science project.
I run my fractional CTO work through my company called Ugly Code. It is a one-man agency, although that description hides a slightly stranger org chart.
There is me. There is Alfred. And there is Viki, my very human assistant, who handles some of the operational work and, unlike Alfred, can notice that a situation is weird without first being given a database column called situation_is_weird.
Ugly Code sells my time, judgment and execution. I work with a small number of companies, helping them make technical decisions, design systems, build products and deploy AI. The commercial details vary, but the underlying production constraint is very simple:
There are only so many hours of me available.
Unfortunately, running the business generates a large amount of work that clients do not pay me to do.
My calendar needs to be managed. Deliverables need to be tracked. Client relationships need context and follow-up. Hours need to be reconstructed. Invoices need to be created and sent. Contracts need to be found. Statements of work need to be drafted, reviewed and signed. Commitments made during calls need to reappear before they become embarrassing.
None of this work is optional.
A company without contracts, invoices or relationship management is not a delightfully lean agency. It is a hobby with legal exposure.
But most of this work does not need to be done by me.
That is the economic job Alfred was hired to perform.
AI ROI is brutally simple
Ugly Code is a useful place to study AI because the link between time and revenue is unusually direct.
When the business has more client work available than I have time to deliver, every hour spent on avoidable administration carries an opportunity cost. It is an hour I cannot spend on billable client work.
So I do not need a forty-tab AI transformation dashboard to evaluate Alfred. The core question is:
Can I bill more hours without working more hours?
The rough calculation looks like this:
Alfred’s contribution = additional billable hours actually invoiced × my realized hourly rate, minus Alfred’s fully loaded cost.
The words “actually invoiced” are doing a lot of work there.
Suppose Alfred removes twenty hours of administration from my month. That does not automatically mean he created twenty hours of financial value.
Perhaps I turn ten of those hours into client work. Those ten hours can be valued at my realized rate. Perhaps I spend five of the remaining hours with my family and five at the gym.
That may be an excellent return on Alfred for me as a human being, but Ugly Code cannot record “David is slightly less overwhelmed” as revenue.
There are two ledgers here.
One is the company ledger. It records additional billable work, avoided costs, faster collections and Alfred’s operating expenses.
The other is my life. It records free afternoons, fewer forgotten commitments and not waking up at midnight because I suddenly remembered an unsigned SoW.
Both matter. They are just not the same thing.
This is the mistake hiding inside most AI ROI claims. A company saves five hundred employee hours and immediately multiplies those hours by an average salary. Voilà: three million dollars of annual value has materialized in PowerPoint.
But unless salaries fall, hiring is avoided, output increases or the freed capacity is redirected into something valuable, no financial saving has occurred.
The company has created capacity, not cash.
Researchers at the Federal Reserve Bank of St. Louis found that people using generative AI reported saving an average of 5.4% of their working hours. The researchers also made the important point that these gains may not show up in measured productivity if workers simply absorb the saved time as leisure. That is not necessarily bad for the worker, but it is very different from improving the economics of the company. (stlouisfed.org)
At Ugly Code, the conversion is visible. If Alfred saves me time and my billable hours rise while my total hours remain stable, he is cooking. If my billable hours do not rise, I need to identify what happened to the capacity before claiming victory.
Agents are labor
The AI industry is slowly arriving at the same conclusion from the seller’s side.
Andreessen Horowitz has described the shift as “software becoming labor.” Sequoia has made a similar distinction: traditional cloud companies sold access to software, while AI companies increasingly sell completed work. Sierra, for example, has promoted outcome-based pricing in which customers pay for resolved conversations rather than for software seats.
This makes sense.
A CRM gives a salesperson somewhere to work. A sales agent performs part of the work.
Accounting software stores invoices. An invoicing agent prepares them, checks them, sends them and follows up.
A project-management tool shows a list of late deliverables. An agent finds the late deliverables, determines who is blocking them, prepares the follow-up and escalates the problem.
The unit of value is moving from access to execution.
But there is a strange gap in how companies respond to this shift. Vendors increasingly price agents as labor, while buyers continue evaluating them as software.
The buyer asks how many seats the product has, how many tokens it uses and how many workflows ran last month.
Those are cost and activity metrics.
They do not tell us whether we should keep the agent employed.
If an agent performs work, it needs to be evaluated through the economics of that work. That is why I think agents should be hired by CFOs.
Not because the CFO should choose the model or build the integration. The CFO should establish the economic admission criteria.
Alfred’s job description at Ugly Code
Alfred’s job is not to “make Ugly Code AI-first.”
That sounds impressive and means absolutely nothing.
His job is to reduce the amount of non-billable operating work required to run Ugly Code without increasing relationship risk, financial mistakes or missed commitments.
A client relationship generates a continuous exhaust of information. There are emails, calls, Slack messages, calendar events, deliverables, decisions, promises, files and invoices. The individual pieces are rarely complicated. The difficulty is maintaining context across all of them while moving between several companies and several technical problems every day.
I use Alfred to hold that context.
Before a meeting, he can bring together the relevant communication, current deliverables and unresolved decisions. After the meeting, he can extract commitments and connect them to the correct project. He tracks whether a promised deliverable is approaching, whether someone is waiting for me and whether a follow-up disappeared into the swamp.
When invoicing time arrives, the relevant activity already exists in structured form instead of requiring me to perform forensic archaeology across calendars and chat histories.
Contracts and statements of work follow a similar pattern. Alfred can locate the current agreement, pull together the scope discussed with the client and prepare the boring first pass. But committing Ugly Code to a scope, price or deadline still requires human approval because those decisions have consequences.
This is essentially the division of labor I described in Becoming an AI-First Operator: processing goes to silicon; consequence stays with the human.
Alfred processes and remembers. Viki coordinates, reviews and handles the ambiguous human bits. I make the decisions for which I am accountable.
This is not a failure of automation. It is the operating model.
Alfred works because Viki exists
There is a popular fantasy that agents become valuable when humans disappear from the workflow.
My experience has been almost the opposite.
Alfred becomes more useful when the human responsibilities around him are explicit.
Viki can look at a draft and understand that, while it may be technically correct, sending it would be socially insane. She can recognize that a client’s short message is probably not a request for information but a signal that something else is wrong. She can coordinate across incomplete information and ask me a question before a small ambiguity turns into a contractual commitment.
Alfred is faster and has access to more context. Viki has judgment grounded in an actual relationship with me and the people involved.
I remain accountable for the final output.
This matters financially because human supervision is part of Alfred’s cost.
If Alfred consumes a few hundred dollars of infrastructure but requires twenty hours of Viki’s time and ten hours of mine to repair his work, he is not a cheap agent. He is a very expensive intern with an unusually complicated electricity bill.
The fully loaded cost includes models, infrastructure, subscriptions, maintenance, debugging, human review and failures. It also includes the time spent building something that later becomes too fragile to use.
I wrote about the other side of this in The cult of tokenmaxxing. The AI industry wants token consumption to feel like progress. But tokens are not output. They are a metered input sitting on a P&L. More can be rational when more produces valuable work, but consumption itself is not the achievement.
Nor is autonomy.
In Agents have a half-life, I argued that the reliability of an agent decays as it chains more unchecked decisions together. Alfred therefore does not receive a vague objective and disappear for three days to operate Ugly Code autonomously. His work is broken into shorter processes with explicit state, memory writes, validation and human checkpoints.
The human checkpoint is not an embarrassing temporary patch we will remove when the next model arrives. It is a financial control.
I already know what negative AI ROI looks like
Last year, I nearly killed Lumberjack by trying to automate it.
I moved the publication from Substack to Ghost because I wanted more control over SEO, distribution and automations. Instead, I introduced enough infrastructure and maintenance that the new system consumed the time it was supposed to save.
Worse, I tried to automate away part of the writing process itself.
That was a category error. Writing Lumberjack is not administrative output. Writing is how I figure out what I think. By removing myself from the process, I did not merely reduce the quality of the content. I removed the activity that made the publication valuable to me in the first place.
Eventually, I returned to Substack and admitted that trying to automate Lumberjack had helped kill its soul.
This is the kind of project a CFO should kill.
It increased technical complexity, added maintenance cost and weakened the core asset. It may have produced more automation, but it destroyed value.
The lesson is not that automation is bad. It is that you need to understand which work is overhead and which work is the business.
Writing is part of the product at Lumberjack.
My judgment and client relationships are part of the product at Ugly Code.
Reconstructing an invoice from three calendars is not.
A good agent removes the work that surrounds value creation without removing the thing that creates the value.
This is why “hours saved” is such a dangerous metric when used alone. Not all hours are economically equivalent. Saving me an hour of invoice administration is useful. Saving me an hour of thinking deeply about a client’s architecture may make the business worse.
The CFO needs to know the difference.
From Ugly Code to boring businesses
Ugly Code makes the calculation unusually easy because time maps directly to revenue. In a larger business, the chain becomes longer, but the principle remains the same.
Suppose an agent prepares quotes for a commercial maintenance company. Reducing quote turnaround from three days to three hours is not the financial result. The result appears only if the company sends more quotes, wins more jobs or needs fewer people to process the existing volume.
The financial bridge might look like this:
Faster quoting → more completed quotes → additional won work → contribution margin → EBITDA
An invoicing agent follows a different path. If it sends invoices immediately after jobs are completed, it may not create any new revenue or EBITDA. But it can shorten the time between performing the work and collecting the cash.
That bridge is:
Faster invoicing → lower invoice lag → lower receivables → released working capital
A scheduling agent might improve technician utilization, reduce overtime and prevent missed appointments. A relationship agent might reduce churn. A purchasing agent might reduce inventory or improve gross margin.
Each agent needs its own causal chain.
And each causal chain should end somewhere in the financial statements.
This is what I would eventually want to bring into a portfolio of boring businesses. Alfred would not arrive with an abstract mandate to automate the company. He would arrive to attack a measured operational constraint.
Perhaps the company loses work because quotes are slow. Perhaps technicians spend too much time driving. Perhaps the founder is the only person who knows how to price unusual jobs. Perhaps completed work spends two weeks waiting to become an invoice.
The process would begin with the financial symptom, work backwards to the operational cause and then determine whether an agent is an appropriate intervention.
Not every problem needs AI. Sometimes the correct answer is a checklist, a database constraint or hiring a competent person.
The Lumberjack Method is about finding a good enough substitute, not the most computationally impressive substitute.
The Value Ledger
I want every agent to have a tiny financial record attached to it, like a Value Ledger.
It does not need to become another enormous reporting system. For Ugly Code, I mostly need to know how many non-billable hours the process required before Alfred, how many it requires now, how much recovered capacity became billable, what happened to invoice timing and what the entire system costs to operate.
A larger company would add the relevant operational metric and financial line. A quote agent would be connected to quote volume, conversion and contribution margin. A collections agent would be connected to days sales outstanding and bad debt. A scheduling agent would be connected to utilization, overtime and gross margin.
The ledger should also record confidence in the attribution.
If revenue rises after Alfred goes live, Alfred does not automatically get credit. Prices may have increased. Demand may have improved. A salesperson may have become better. The company may simply have had a lucky month.
Businesses are not laboratory experiments, so perfect attribution is impossible. But we can at least resist the urge to credit the agent with everything good that happens after deployment.
The ledger also prevents double counting. If an agent creates additional billable capacity and I count the resulting revenue, I cannot count the same hours again as theoretical labor savings. If invoicing releases working capital once, I cannot present that as recurring annual profit. If Viki uses her freed capacity for a new responsibility, I need to identify the value of that responsibility rather than pretending her salary vanished.
Financial discipline is mostly the art of not lying to yourself in a spreadsheet.
So who actually hires the agent?
The title of this article is intentionally reductive.
The CFO should not deploy an agent alone.
The CTO needs to determine whether the system can be built securely and reliably. The COO needs to determine whether it belongs in the real workflow rather than the imaginary workflow described in a process document. Employees need to surface the weird exceptions that become invisible in executive meetings. The agent needs a human manager who owns its day-to-day performance.
But the CFO should decide whether the economic case is real.
The CTO decides whether the agent can work.
The COO decides how the agent should work.
The CFO decides whether the agent deserves the job.
At Ugly Code, all three people are unfortunately me.
But changing hats still matters.
The engineer in me wants Alfred to be more capable. The operator in me wants Alfred to make the business easier to run. The CFO in me wants to know whether the additional capability produces more cash than it consumes.
That last person is usually the least impressed by the demo.
I do not care how many tasks Alfred completed. I care whether billable utilization improved.
I do not care how many hours he theoretically saved. I care whether those hours became invoices, lower costs or a deliberate improvement in my life.
I do not care how autonomous he appears. I care whether his work is reliable after including the cost of supervision and failure.
I do not care how many tokens he consumed. I care about the return on those tokens.
The future company will employ humans, software and agents. The distinctions will become increasingly blurry, but the economics will not.
Every agent consumes capital. Every agent introduces risk. Every agent exists to produce an outcome.
Give it a job. Give it a manager. Define its authority. Calculate its fully loaded cost. Connect its work to the financial statements. Promote it when the cash appears. Restrict it when the risk becomes unacceptable. Fire it when the numbers stop making sense.
The companies that win will not be the ones with the largest agent workforce.
They will be the ones earning the highest return on it.
Agents should be hired by CFOs.
Because “look how much work it did” is something a proud parent says.
A business just needs the cash.