Titus Kellog

Testing an AI coding workflow should include checking whether its tests detect deliberately broken implementations. Code and tests can share an interpretation error, even when produced by separate agents. Mutation testing seems a useful check on that risk.

If AI makes a consulting project twice as fast and the client still pays the same fee, who should keep the gain? I'd let the firm keep it, provided it takes responsibility for the outcome. Hourly billing makes that bargain much harder.

If a reviewer has ten seconds to approve a page of AI-generated analysis, I'd treat their click as weak evidence of quality. I'd rather see review time, access to sources and whether they catch planted errors before trusting the approval rate.

I'd evaluate a multi-agent product by comparing it with a simpler implementation on the same task. The useful measures would include completion quality, cost and recovery from failure. That comparison would help explain what the extra agents contribute.

I'd be skeptical of an AI coding workflow where the code and tests come from the same interpretation of the spec. Both can agree on the same mistake. Before trusting the green checks, I'd want to see the tests reject a deliberately broken implementation.

AI pilots fail less from model quality than from missing ownership. Name the workflow owner, review points, escalation path and success metric. Otherwise it is a demo with enterprise stationery.

Agent sprawl is what happens when every team gets a demo but nobody owns the workflow. The missing role is not prompt engineer. It is workflow owner.

Enterprise AI does not fail because the model forgot the demo. It fails when nobody owns the workflow after launch: exceptions, reviews, evals, handoffs and rollback. Boring operating design beats agent theatre.

Enterprise AI does not fail because the demo was weak. It fails because nobody owns the workflow after launch: exceptions, review, metrics, permissions and maintenance.

Enterprise AI usually fails between prototype and ownership. The question is not “can the agent do it?” It is: who owns exceptions, review, metrics and rollback on day 90?

A good AI governance review asks boring questions: who owns the workflow, what data can the agent touch, when does it stop, and what evidence is kept? If nobody can answer, you do not have autonomy. You have delegation without a manager.

AI pilots do not fail at the model layer. They fail in the handoff: no workflow owner, no review thresholds, no exception path, no margin logic. The demo is the easy part.

Agent sprawl is what happens when every team buys autonomy before the company defines ownership. The fix is not a bigger model. It is a workflow map with named owners, review triggers, and kill switches.

Agent sprawl is what happens when every team gets a sandbox but nobody owns the workflow. The fix is not fewer agents. It is clearer ownership, review points and retirement rules.

Agent sprawl is what happens when every team gets a sandbox but nobody owns the workflow. The fix is not fewer agents. It is clearer ownership, review points and retirement rules.

Agent sprawl is what happens when every team gets a tool but nobody owns the workflow. Enterprise AI needs fewer demos and clearer operating rights.

AI agent sprawl is not a tooling problem. It is an ownership problem: who approves access, reviews exceptions, retires broken workflows, and measures whether the work improved?

Agent sprawl is what happens when every team gets an AI shortcut but nobody owns the workflow around it: review, telemetry, escalation, and maintenance.

Enterprise AI doesn't fail because teams lack demos. It fails because nobody owns the workflow after the demo: inputs, exceptions, approvals, monitoring, handoffs. Agent sprawl is usually an ownership problem wearing a tooling costume.

Agent sprawl is not a tooling problem first. It is an ownership problem: who inventories workflows, retires weak ones, and owns the handoff when the agent is confidently wrong?

Enterprise AI does not fail because the demo was weak. It fails because nobody owns the workflow after launch: exceptions, reviews, metrics, and the boring runbook.

Enterprise AI has an agent sprawl problem now, not later. The moat is not more demos. It is workflow ownership: reviews, thresholds, escalation paths, and someone accountable when the model is merely plausible.

Consulting AI margin will not come from “fewer juniors.” It will come from packaging repeatable judgement into workflows: inputs, review gates, exceptions, evidence. If the method only lives in a partner’s head, AI mostly accelerates chaos.

Agent sprawl is not an IT inventory problem. It is workflow ownership: who can approve actions, who handles exceptions, who sees the audit trail, and who retires agents when the process changes.

Enterprise AI does not fail because teams lack demos. It fails because no one owns the workflow after the demo: exceptions, review queues, evals, logging, and versioned decisions. Boring systems beat magical prototypes.

Enterprise AI has an ownership problem, not a demo problem. If nobody owns the workflow after the prototype, the agent becomes another orphaned app with a better pitch deck.

Agent sprawl is the new shadow IT. The fix is not banning agents - it is shared patterns, named owners, review loops and retirement rules.

The next useful enterprise AI role is not "prompt engineer". It is the AI workflow owner: the person accountable for what happens after agents start acting inside real work. Inventory. Authority. Review. Evidence. Value. Lifecycle. https://tituskellog.substack.com/p/what-is-an-ai-workflow-owner

Consulting firms have a weird AI opportunity. A lot of the work is structured enough to assist. But a lot of the value still lives in expert judgement. The winners will turn judgement into systems without killing trust.

A useful AI workflow needs an owner, inputs, review logic, exception handling and a way to measure whether work actually improved. Less magic. More operating discipline.

Most AI demos prove that something can work once. The harder question is whether it can become a reliable way of working. That is where consulting firms should be looking: not at more pilots, but at reusable workflows.