AI Consulting Services: No Rules, No Results

There is a heavily upvoted thread on r/consulting about the gold rush in AI consulting services turning the profession into the thing it used to mock. The complaint underneath it: people with six months of ChatGPT experience rebranding as AI consultants and charging five thousand pounds for a Zapier workflow. A neighbouring thread, with a couple of hundred comments, asks whether AI consultants know anything at all. The top reply comes from someone with graduate training in the field, and the verdict is that most of them do not.

Meanwhile the first page of Google for ai consulting services is EY, Huron, IBM, CGI, Wipfli, and four agencies. Every one of them sells the same five-item menu: strategy, data readiness, build the thing, governance, train the staff. Not one of them tells you what you should be holding in your hand when the engagement ends.

Here is what AI consulting services should leave you holding, and it is unglamorous: a written specification. A plain text file — or a folder of them — that states the rules your AI has to follow before it does anything. Not a prompt. Not a style guide. A spec: what "done correctly" means, written down once, in a place the machine reads first.

This is the same reason a chain restaurant tastes identical in Manchester and Osaka. Nobody flies the founding chef to every branch. There is a manual, and every branch follows it. Your AI is a new branch opening every single morning.

This article covers what a spec is and why the machine needs one every time, what it costs when you skip it — with a real day where I skipped it four times before lunch — what 28 specification packages look like when they are actually in use, how to write your first one tonight in about an hour, and where AI consulting services are still worth paying for once you have it.

What "agent" means here — Any AI doing work on your behalf across multiple steps: a chat assistant you have given a long-running job, a coding tool in your terminal, an automation that writes and publishes. The distinction that matters for this article is not the model. It is whether the thing acts more than once.

What a spec is, and why AI consulting services rarely hand you one

Most AI consulting services engagements end with a running system, a slide deck and a login. Almost none end with the artifact that would have fixed the output, because writing it requires knowing your business rather than the technology. To see why that file does more work than the model does, start with the failure it exists to absorb.

The core problem is not that AI is unreliable. It is that AI has no yesterday.

When you correct a colleague, the correction sticks. You say "we never call them users, we call them clients" once, and in nine months they still say clients. When you correct an AI, the correction lasts until the conversation ends. Then it is gone, completely, and the next conversation starts from a blank slate with no memory that the exchange ever happened.

Most people respond to this by retyping. Every session begins with a paragraph of context: who I am, what we sell, how I like things written. That works, it is exhausting, and it drifts — because you never retype it the same way twice.

A spec is the alternative. You write the rules down once, in a file, and the agent reads the file before it starts. The manual replaces the retyping.

Same prompt, different answer — this has been measured

If you have ever suspected the machine gives you a different answer to the same question, you are right, and the size of the effect is larger than most people assume.

Thinking Machines Lab ran one prompt — "Tell me about Richard Feynman" — a thousand times at temperature 0, the setting that is supposed to make output deterministic. They got 80 unique completions out of 1,000. All thousand were identical for the first 102 tokens, then diverged (Defeating Nondeterminism in LLM Inference, 10 September 2025). The cause was floating-point arithmetic behaving differently depending on how requests happened to be batched together on the server — nothing to do with your prompt at all.

It gets more uncomfortable. A peer-reviewed study in ACM Transactions on Software Engineering and Methodology asked ChatGPT the same coding question five times across 829 CodeContests problems. For 75.76% of those tasks, no two of the five answers produced the same test output. Setting temperature to 0 cut it but did not remove it: 43.64% still had no two matching answers (Ouyang, Zhang, Harman and Wang, published 22 January 2025).

And a 2025 arXiv paper found that changing nothing but the hardware — GPU count, GPU type, evaluation batch size — moved a reasoning model's accuracy by up to 9% and its response length by up to 9,000 tokens (arXiv:2506.09501, 11 June 2025).

The practical reading of all three: you cannot get consistency by asking more politely, you cannot get it by buying a better model, and you cannot buy it in from AI consulting services either. Variance is a property of the machinery. What you can do is shrink the space it varies inside — by stating, in writing, what an acceptable answer has to contain.

That is the whole mechanism. A spec does not make the model deterministic. It makes the range of outputs narrow enough that any of them is fine.

A spec is not a prompt, and not a style guide

These three get used interchangeably and they do different jobs.

Style is a subset of a spec, and it is the least useful subset. A rules file that only says "be friendly and concise" will still put the file in the wrong folder, under the wrong name, missing the field that the publishing step requires.

A tone document plus a library of example prompts is also where most AI consulting services stop. It reads well in a handover pack and it changes almost nothing, because none of it states where output goes or what a finished piece must contain.

Anthropic's engineering team describes the target as writing at the right altitude: specific enough to guide behaviour, flexible enough to leave judgment intact. They name both failure modes — hardcoding brittle logic at one extreme, vague high-level guidance that gives the model no concrete signal at the other (Effective context engineering for AI agents, 30 September 2025). Getting the altitude right is most of the skill, and section four of this article is about how to find it.

This has quietly become an industry standard

The format has a name now, and it has been standardised in public.

In August 2025 OpenAI released AGENTS.md, an open convention for a Markdown file that tells coding agents how to work in a repository. By December, the Linux Foundation reported it had been adopted by more than 60,000 open-source projects and by agent tools including Cursor, GitHub Copilot, Gemini CLI, Devin, Jules and VS Code. On 9 December 2025 OpenAI donated the format to the new Agentic AI Foundation, alongside Anthropic's Model Context Protocol and Block's goose (Linux Foundation).

That number counts repositories with the file, not companies or active users — so treat it as a signal of direction, not of adoption depth. The signal is clear enough: the industry converged on "put the rules in a plain Markdown file next to the work" within about four months. If AI consulting services offer you a proprietary framework instead, you are paying for something the industry has already standardised and given away.

Where AI consulting services fit, and the question to ask before you sign

Now the useful question for anyone shopping this category. AI consulting services are neither a scam nor a substitute for knowing your own business — they are a tool with a narrow correct use, and the line falls in a predictable place.

AI consulting services are worth paying for genuinely technical constraints: data engineering, systems integration, regulated-industry compliance. They are not worth paying to discover how your business writes, prices, and decides — that knowledge exists only in your head, and every hour they spend extracting it in workshops is billed back to you.

So there is one question worth asking any provider of AI consulting services — an AI consulting firm, one of the newer AI consulting firms built entirely around agents, or an AI automation agency — before you sign:

"When this ends, what written rules do I own that I can read and change without you?"

If the answer is a running system and a login, you have bought a dependency. If the answer is a folder of specifications plus the system, you have bought something that survives them — and survives the model, the vendor and the tool. That is the whole test for AI consulting services: a deliverable you can read and edit, against a dependency you have to keep renewing.

The same question separates real business process management software from a pile of automations, and real business automation software from a drawer of brittle scripts: does the process exist as a document you can read, or only as wiring inside a product?

The failure statistics suggest a lot of buyers of AI consulting services are not asking. Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls (Gartner press release, 25 June 2025). McKinsey's 2025 survey of 1,993 respondents found 88% of organisations use AI somewhere, but only 39% attribute any EBIT impact to it — and most of that 39% put the figure below 5% of EBIT (The state of AI in 2025, November 2025).

You may also have seen the claim that 95% of AI pilots fail, attributed to MIT. The report exists — The GenAI Divide: State of AI in Business 2025, July 2025 — but it is labelled preliminary findings, carries a disclaimer that it does not represent any institutional position, and the description of its methodology in the coverage that made it viral does not match the methodology printed in the report. I would not build an argument on it, and I mention it mainly so you can recognise it when someone quotes it at you.

One day, four mistakes

: what "no spec" costs

Here is the honest version, from my own logs — the kind of day no AI consulting services pitch deck will ever show you.

On 25 July 2026 the content role in my system produced and published a long-form post on X. Four separate times that day it hit a problem, invented a solution on the spot, and got it wrong. In all four cases the correct answer was already written down in a file it had not opened. Read the dimensions below as X's rules on that date; the website rules further down this article are different numbers for a different surface, which is exactly the point of the next section.

The common thread in all four: the first instinct on hitting a problem was to solve it, rather than to check whether the answer was already written. That instinct feels like competence. It is the single most expensive habit an agent can have, because a solution invented in the moment has never been tested, while the one in the file is there precisely because something went wrong once already.

The second-order damage is worse than the mistakes

The black cover images were annoying and took twenty minutes to fix. The lasting damage was different.

While fixing the image problem, the agent wrote itself a new rule: "no AI-generated images." Reasonable in context. But it wrote the rule with no scope on it, and the context was social posts. Elsewhere in the same system, long-form articles are supposed to use AI-generated illustrations. Two rules now contradicted each other, with nothing in either file saying which situation each applied to, and the next task that touched images had no way to proceed.

The fix was one word. The rule should have read "no AI-generated images in social posts."

Rule of thumb, learned expensively: every rule needs a scope clause. "Never do X" is almost always wrong. "Never do X when Y" is almost always right. A rule with no boundary does not stay in its lane — it leaks into every situation the author never considered.

That day produced two permanent additions to my own standards: read the procedure before improvising, and write scope into every rule. Both are now in a file that gets loaded before the content role does anything. The mistakes have not repeated.

What 28 specification packages look like in practice

My knowledge base has a top-level folder called standards/. Inside it are 28 specification packages and 970 rule files in Markdown, counted on 10 August 2026. This is the deliverable I keep saying AI consulting services should hand you, so here is the whole set, grouped by what it governs — not as a target, but so you can recognise the thing when you ask for it.

The five families

The sizes are wildly uneven and that is fine — awp-dev-frontend-spec holds 326 Markdown files, awp-doc-markdown-spec holds 3. A package is a subject, not a quota.

The boundary that stops this folder rotting

One distinction does more work than any other here: a standard is a rule, not a tutorial.

• A rule says what correct means and stays true when the tool changes. "Anchor text must describe the destination."
• A tutorial says which button to press and expires. "Click Settings, then Integrations, then the blue button."

Tutorials live somewhere else — in my case a tools/ folder holding 108 practice folders, one per tool. The test for which folder something belongs in is a single question: if I switched to a different tool tomorrow, would this still be true? Yes means standard. No means tutorial.

Get this wrong and standards/ fills with screenshots that are stale within a year, and then nobody trusts any of it. That is how rules folders die — not from being wrong, but from being 30% wrong with no way to tell which 30%.

Four segments, and what each one means

Every file and folder name in the base has four segments separated by hyphens. This sounds bureaucratic and takes about a day to become invisible.

awp-content-platform-spec
│   │       │        └── kind      — what type of package this is
│   │       └────────── target     — what it produces rules for
│   └────────────────── domain     — which area of work
└────────────────────── namespace  — which system it belongs to

The pattern is enforced, not aspirational: package identifiers must match ^awp-[a-z][a-z0-9]*-[a-z][a-z0-9]*-[a-z][a-z0-9]*$ — exactly four segments, lowercase, no hyphen inside a segment. Dates are always compact (20260810, never 2026-08-10) for the same reason: a hyphen inside a date would make the segment count lie.

The four slots mean different things in different folders, and each folder registers its own definitions:

You read the name and you know what it is. More to the point, the agent reads the name and knows where to put the thing it just made — without asking, and without inventing a sixth naming scheme at 2am. That is the entire payoff, and it only appears once the rule is written down somewhere the agent loads automatically.

Why this matters more for machines than for you — You can find a file with a fuzzy memory and a search box. An agent starting from zero cannot. A predictable name is how it navigates without searching: read the index, pick the domain, read that domain's index, land on the file. Three hops, no guessing.

One article, two platforms, no extra instructions

This is where written rules stop being tidy filing and start paying for themselves, and where the difference between hiring AI consulting services and owning a specification becomes something you can measure.

Take one finished article. Publishing it to my website and posting it to X are, from my side, the same two sentences: publish this and post it to X. I do not restate the requirements. The agent reads a different rules file for each destination and the output changes completely.

Publishing to the site pulls in the site's platform file — website-awp.zh.md:

Posting to X pulls in a different file — twitter-x.zh.md — and almost every rule inverts:

Same source article. Same agent. Same knowledge base. Two outputs with almost nothing in common, and I did not say "make it shorter" or "remember, no hashtags" either time.

I never have to remember "no hashtags" again. That is the sentence worth taking away. The rule is written down once, and every future task on that platform inherits it. When X changes its algorithm next quarter, I edit one file and every subsequent post follows the new rule — including posts written by an agent that has never seen the old one.

The platform package holds 19 files: 15 of them describe one platform each — the website, X, YouTube, and a dozen publishing sites — plus a meta-file describing how to write a platform file, a glossary, and one cross-cutting file of rules that apply everywhere regardless of platform. New platform, new file, same five questions each time: what is it for, what are the format limits, what can it do that others cannot, what gets moderated, what is forbidden.

The honest caveat on those platform numbers — figures like "links in the body cut reach" are recorded in my rules file with the date and source they came from, because platform behaviour changes and undated platform facts are worse than none. Every one of those files carries a last-verified date at the bottom, and re-checking them is a scheduled job. A rules file nobody re-verifies becomes confidently wrong, which is worse than being obviously empty.

Where this breaks

Four failure modes, all of which I have hit.

Specs rot. Rules describe a world, and worlds move. A file with no last-verified date is a liability, because the agent will follow it with total confidence. Date everything and schedule a re-read.

Specs conflict. Two rules, written months apart, that cannot both be satisfied. The July example above is the small version. The cure is scope clauses and a single authoritative file per subject — the moment the same rule exists in two places, they start to drift apart.

Too many rules kills the work. This one surprised me. In August 2026 I briefed an agent to redesign a diagram page, and the brief ran to 2,392 characters: exact colour codes, a font-size table, three referenced standards, file paths, a self-check list. What came back was an eight-row table. Every constraint satisfied. No design in it at all. I rewrote the brief at 1,333 characters — the content, two facts, one sentence of style direction, and "do not make this a table" — and got something usable. You cannot ask for consistency and initiative in the same instruction. Decide which one the task needs before you write the brief.

Nobody has measured the benefit. I want to be straight about this: I could not find a single study measuring how much a specification file reduces output variance. The evidence that variance exists is solid and cited above. The evidence that written rules fix it is, at present, practitioner experience — mine and a lot of other people's. Treat my numbers as a description of what one system looks like, not as proof it will work for yours — and apply exactly the same scepticism to any results AI consulting services quote about themselves. Run the test in the next section and generate your own evidence.

Write your first rules file tonight

One file, about an hour, no new software. Not 28 packages — 28 is what this becomes after a year of daily use, and starting there produces empty folders that quietly teach you the whole idea is decorative.

It also costs nothing, which is the part worth noticing. The work below is the exact work AI consulting services bill the most hours for, and it is the one part of the job nobody outside your business can do for you.

Before you start. The spec you write below is only useful if your AI reads it automatically at the start of every session. Web chat windows cannot do that — you need a tool that loads instruction files from your disk. If you do not have one, pick one here.

Make a folder and a file:

mkdir -p ~/kb/standards
touch ~/kb/standards/my-rules.md

If you would rather not touch a terminal, create the folder and the file by hand in your file manager. It works identically.

What goes in it

Five sections. Write them in plain sentences, as if briefing a competent new hire on their first morning. The headings below are the contents of your file, not sections of this article.

# My Rules

## Who I am
One-line description of the business. Where it operates.
What it sells. Who signs the cheques.

## Who I work with
The two or three types of client, and what each one cares about.
Anyone I explicitly do not take on.

## How I want things written
Reading level. Long sentences or short. First person or not.
Words we always use for things, and the words we never use for them.
One example of a sentence that sounds right.

## Never do these
Specific, with a reason and a boundary attached.
"Never quote a price in email without a validity date — we got
burned in March." Not "be careful about pricing."

## What "done" means
For the three things I ask for most often, what a finished
version has to contain before I will look at it.

That last section does the most work and is the one people skip. "Write me a client update" is not a specification. "A client update is under 300 words, opens with what changed, lists what is blocked and who owns it, and ends with a date" is.

Three rules about writing rules

Put a scope on every prohibition. "Never use bullet points" will destroy your reports. "Never use bullet points in client emails" is a rule. Every "never" needs a "when".

Give reasons, not just instructions. "No JPEG for screenshots" gets followed. "No JPEG for screenshots — the compression makes code unreadable" gets followed and correctly extended to the next format that has the same problem. A reason lets the agent generalise; a bare instruction leaves it stuck the moment reality differs slightly from the rule.

One subject, one file. The moment the same rule is written in two places, they begin drifting apart and you have no way to tell which one is current. Put a pointer in the second place instead.

Test it in ten minutes

Do not take the file on faith. There is a cheap, honest test.

1. Pick a task you ask for at least weekly.
2. In a fresh conversation with no file attached, ask for it. Save the output.
3. In another fresh conversation, attach my-rules.md and ask for exactly the same thing. Save that.
4. Put them side by side.

Then run the verification that actually matters:

"Which rules from the file did you apply, and quote them."

If it can quote the rules back, it read them. If it paraphrases vaguely, your rules are written at the wrong altitude — too abstract to act on. Rewrite the vague ones as something checkable and repeat. This loop takes minutes and is the fastest way to learn what "specific enough" feels like.

One more test, a week later: hand the file to a human who does your kind of work and ask them to do the task. If they need to ask you three clarifying questions, those three answers are the rules you forgot to write down.

Copy this prompt

Paste this into any assistant that can see your files. It works with ChatGPT, Claude, Gemini and any terminal-based coding tool. It builds the same file as the template above, with the writing section split into three so that none of it gets waved through in a sentence.

I want to create a rules file that you and every other AI assistant
will read before doing work for me. Build it with me now, then help
me test whether it changed anything.

Step 1 — Create the file.
Make a folder called standards/ inside my working folder — use
~/kb/standards/ unless I name a different one — and inside it a file
called my-rules.md. If you cannot write to disk, output the finished file
as Markdown and I will save it there myself.

Step 2 — Interview me, one question at a time.
Wait for my answer before asking the next question. Do not batch the
questions and do not answer any of them on my behalf. Cover these six
sections in this order, and write each one into the file as we go:

1. Brand — the name of the business, and one line on what it does
   and who it does it for.
2. Customer — one paragraph on who buys from me: their job, what
   they are trying to fix, what they already tried, what makes them
   say no.
3. Voice — three adjectives for how we sound, plus one paragraph I
   have actually published that sounds right. Ask me to paste that
   paragraph. Do not write one for me.
4. Banned words — the words and phrases we never use, however
   natural they feel. Push me for at least eight. If I stall, read
   my sample paragraph back to me and propose candidates from it.
5. Format — heading capitalisation (sentence case or title case),
   the longest a paragraph may run in sentences, whether lists use
   bullets or numbers, and whether bold is allowed mid-sentence.
6. Done — for the three things I ask for most often, what a finished
   version must contain before I would look at it. This section
   decides whether the whole file is worth anything, so do not let
   me answer it vaguely.

How to write it:
- Every prohibition gets a scope clause. Not "never do X" but
  "never do X when Y".
- Every rule gets a one-line reason, so it can be applied to
  situations neither of us thought of.
- Anything I say vaguely, push back once and ask for a version a
  machine could check. "Professional" is not checkable. "No sentence
  longer than 25 words" is.

Step 3 — Test it before I trust it.
Pick a task I ask for regularly and do it twice. First in a fresh
conversation with the file not attached. Then in a second fresh
conversation where you read my-rules.md before anything else. Put
both outputs side by side, list every difference between them, and
name the rule that produced each difference. Any rule that produced
no visible difference is either already your default or too vague to
act on — tell me which, and rewrite it in front of me.

That last step matters more than it looks. A rule that changes nothing is not a rule you can trust, and this is the cheapest moment to find out which of yours are decorative — before the file has had a chance to do any damage.

Translating my folder names to yours

The structure in this article uses my labels. Here is what each one is doing, so you can map it onto whatever you already call things.

You do not need six folders, and you do not need AI consulting services to draw the map. You need one file, tonight. The folders arrive on their own once you notice you are scrolling to find a rule.

Frequently asked questions

What does an AI consulting firm actually do?

Most AI consulting services engagements cover the same five items: strategy and roadmap, data readiness, building a generative or agentic system, governance and risk, and staff training. That menu is on the front page of nearly every firm's AI practice. What varies is whether you finish holding a written artifact you can read and change, or only a running system you cannot maintain.

Should I hire an AI consultant?

Hire one for genuinely technical constraints — data engineering, integration, regulated-industry compliance. Do not hire one to discover how your business writes, prices and decides. That knowledge is only in your head, and every workshop hour spent extracting it is billed to you. Write that part yourself first; it turns any later engagement into fewer workshop hours and a shorter bill.

How much does an AI consultant cost?

Rates for AI consulting services run from a few thousand for a small automation to seven figures for enterprise programmes, and since this search results page is almost entirely vendor pages, treat published ranges as marketing. For scale: Accenture reported $2.7 billion of advanced AI revenue in fiscal 2025 against $69.67 billion total revenue — about 3.9% (Accenture FY2025 results, 25 September 2025).

How big is the AI consulting market?

Nobody credible agrees. Published estimates of the market for AI consulting services in calendar 2025 range from about $7 billion to about $29 billion depending on the research house, with no free methodology reconciling them. That spread is the honest answer, and it is more useful than any single figure you will see quoted.

Why does my AI give a different answer every time?

Because identical input does not guarantee identical output — it is a property of how the models are served, not of your prompt. Thinking Machines Lab ran one prompt 1,000 times at temperature 0 and got 80 unique completions, identical for the first 102 tokens and then divergent. A peer-reviewed study in ACM Transactions on Software Engineering and Methodology found that for 75.76% of competitive programming tasks, five repeated identical requests to ChatGPT produced no two answers with the same test output. Writing down what an acceptable answer must contain narrows the range; asking more politely does not.

Is a spec the same as a prompt?

No. A prompt describes one task and dies with the conversation. A spec describes the standing constraints for every task of that kind and lives in a file. You will keep writing prompts — they just get much shorter, because the constraints are no longer inside them.

Do I need AGENTS.md or CLAUDE.md specifically?

Only if you use tools that read those filenames automatically — Cursor, GitHub Copilot, Codex and Claude Code among them. If you work in a chat window, the same content in a plain .md file you upload works identically. The filename is a convenience, not the mechanism. For context on how established the convention is, the Linux Foundation reported in December 2025 that AGENTS.md had been adopted by more than 60,000 open-source projects.

How many rules files should I start with?

One. Split it when it gets long enough that you stop rereading it, which for most people is somewhere past a thousand words. The 28-package structure described in this article grew over a year of daily use and would be a mistake to build on day one.

Can I use this with a team?

Yes, and it is more valuable with one, because the file becomes the place a disagreement gets settled instead of being re-litigated per person. Keep it where everyone can edit it and require a reason on every rule.

What if my rules turn out to be wrong?

Then you have found out cheaply, which is the point. A wrong rule in a file is visible and editable. The same wrong assumption living only in someone's head gets applied silently for months.

What to do next

Tonight: create standards/my-rules.md and fill in the five sections. An hour, no software, no subscription.

Tomorrow: run the side-by-side test. Same task, once without the file, once with it. Then ask the assistant to quote the rules it applied.

Next week: every time you correct the output, do not just correct it — write the correction into the file with a scope clause and a reason. That is the whole discipline. The file gets good by absorbing your corrections instead of losing them.

Then, if you still need help: buy AI consulting services for the parts that are genuinely technical — data plumbing, integration, compliance — and keep the rules file yours. An engagement that starts from a written spec is shorter, cheaper and much harder to pad.

And before you sign with any AI consulting firm or AI automation agency, ask the one question that separates a deliverable from a dependency: when this ends, what written rules do I own that I can read and change without you? Every provider of AI consulting services has an answer to that question. The answer is the product.

Further reading

• The knowledge base that outlasts every model — the folder your rules live in
• Four questions, ten folders — where standards/ sits among the rest
• Switch models without starting over — why keeping rules in plain files makes tools swappable

— hh