What a Fractional CTO Does for Agentic AI

If you run a company of somewhere between five and fifty people, you probably have an AI pilot that half works, or a list of tasks you suspect an agent could do, and nobody on staff whose job it is to decide which of those ideas are worth building. A full-time CTO to make that call costs $250k or more before benefits, and a company that size usually can't keep one busy yet. A fractional CTO engagement with me runs $4,000–8,000 a month, at a fixed price. What follows covers what that money pays for, and when you should spend it on something else.

The first month is mostly decisions

The biggest one is which workflow goes first. I push hard for a single workflow, usually something your team does by hand every week and complains about, like drafting routine correspondence or copying records between two systems that don't talk to each other. It needs an owner on your side who will tell you plainly whether the agent's output is usable. Teams that start three agents at once tend to end up with three demos.

Then build or buy. Some of these conversations end with me recommending a SaaS product that already does the job, and you paying for that instead of for me. When the capability sits close to how you make money, I lean toward building it. Owning it means you can wire it into your own product and extend it in directions a vendor's roadmap will never cover. The subscription you stop paying is a minor bonus.

The third decision gets less attention than it deserves: where the agent touches your system of record, and with what permissions. An agent that reads your CRM carries a different risk from one that writes to it, and the two deserve separate scoping. I also design around how your team already keeps that data. If your people merge duplicate contacts, which is the right practice, the thing I build has to cope with merges. Asking you to change a sound habit to suit my code would be handing you my bug.

Then I build the first version

I write most of the code myself, in Claude Code, and the aim is a first version your team is using during the engagement. If you have developers, the split changes: I make the architecture calls, review what merges, and pair on the hard parts, and your people own the code. Integrations usually end up as MCP servers wrapped around tools you already pay for. Getting those ready for production is mostly auth, rate limits, and logging, which I covered in the post on production MCP servers.

Measure the prompts before you ship them

This is the habit I spend the most effort installing. The default way to change a prompt is to edit the wording, read a couple of outputs, and decide it looks right. Prompts have no compiler. Wording that reads correctly can push the model in the opposite direction, and the only way to see it is in the outputs, in bulk.

Two examples from my own work. The fit-scoring prompt in UseFireApp, one of my products, ended with a sample of the reply format: a JSON object with a score of 72. The first six scores it produced in production were 72, 72, 72, 72, 72, and 72. The format example is the last thing the model reads before it answers, and a small model copies it. Unit tests could not have caught it, because a mocked model returns whatever the test tells it to. The fix was a placeholder where the number had been, plus a test that fails if a digit ever appears in that example again.

The second mistake was mine. A scoring rubric on a client project was occasionally giving a perfect score to a junk record, so I added a line saying the top of the range was for profiles that stated the role outright. It read well. Most profiles do state the role outright, though, so the share of results at the maximum went from about one in ten to seven in ten. I reverted it.

The habit that catches both is small and dull. Keep a fixed set of real inputs, write down what a good answer looks like for each, and compare the spread of results on those same inputs before and after any change. On a support agent built on a reasoning model, that comparison showed that adding instructions about how to reason made answers worse. What worked was one sentence defining which sources did not count as an answer. Wrong answers to questions the sources didn't cover went from 4 in 72 calls to 0 in 78. I would not have predicted either result from reading the prompt.

Running it after launch

Once an agent runs unattended, you need a log of every tool call it makes, a spending ceiling, and someone who gets told when it fails. Put those in place before the agent touches real data, because the first time it is confidently wrong at night is a bad time to discover there is no record of what it did.

When you should hire someone else

If you need someone in standups five days a week, hire full-time. If you want a chat widget with your logo on it, a contractor can build that in a week for less than a month of my time. If you built your product with Lovable, Bolt, or Cursor and it is falling over under real users, start with the $1,500 vibe coding rescue audit and decide about ongoing help afterward. And if you sell an AI product and the problem is getting it into your customers' workflows, that is closer to forward deployed engineering, which I also do, under a different arrangement.

The fractional model fits when the expensive part is the decisions, and you want them made by the person who will also build the result.

How the price works

The $4,000–8,000 range depends mostly on how much I'm building versus advising. You pick a level of capacity for the month and keep pointing me at whatever matters most, and the price stays the same when the priority changes. If the scope is too uncertain to price yet, we start with a small fixed-price discovery piece and decide from there.

If that range isn't what you expected, tell me what you were expecting. I'll tell you whether I can work inside it or whether you should be talking to someone else.