Monitoring a competitor who publishes no feed is the case every RSS guide skips. Twenty-one platforms sorted by which of three jobs they do, and the finished setup is business process automation you own outright, with no seat licence to renew.
Blaming the content is the reflex when a post underperforms, and it is usually the wrong diagnosis. A second reader decides distribution before any human sees the post, and most of what it checks is mechanical enough to automate business processes around, on five platforms at once.
Gloves on, tape measure in hand — nobody types a query. Three voice surfaces for ai automation tools (terminal, Telegram, Discord), 10 TTS and 6 STT providers compared on cost and latency, plus a setup that costs nothing.
Most AI persona tools invent a customer for you. This does the reverse: your trade's names, formats, forbidden lines, escalation path — three you can copy.
You asked it to draft the intake summary. Or the punch list. Or the month-end note that goes to the accountant.
What came back wasn't wrong — that's the annoying part. It just wasn't ours. It called the matter a "case," put the client's story ahead of the conflicts fields, dropped the one sentence that has to sit at the top of every document of that kind, and added a friendly closing line we would never send. You fixed it in four minutes and moved on.
Then you did it again the next day.
The cause is narrow and fixable. A model can look up how your industry works. It cannot look up how your shop works, because nobody published that. Four things live only in your head and in the documents you have already sent: what you call things, what your paperwork looks like, which sentences you never write, and who you ask when it isn't clear. Write those four down once, in plain text, in a file the model reads before it starts, and the four-minute fix stops coming back.
That written-down voice is what this article means by an ai persona — and it is not the kind of ai persona the search results are full of. Below: what belongs in each of the four parts, three complete sections you can copy for three different lines of work, a way to mine your own out of documents you already have, and a ten-minute test that tells you whether any of it changed the output.
Checked and current as of 2026-07-31. Every tool behaviour and every rule quoted here was pulled from the primary source on that date, and the sources are linked inline.
Search that phrase and you land in the middle of an argument nobody is having out loud. Two communities use the same two words for opposite things.
| A persona the AI makes | A persona you give the AI | |
|---|---|---|
| Who is it about | A customer who does not exist | You, and how your business works |
| Who writes it | The model, from a prompt | You, once, from documents you already sent |
| What it's for | Aiming your marketing at a made-up "typical buyer" | Making the model's drafts sound like your shop's |
| Where it lives | A slide, a deck, a research board | A plain text file the model reads first |
| What it changes | Your positioning | The next thing it writes for you |
The first kind is what most of the tools on that search page produce, and it is a real thing that real marketing teams use. If that's what you came for, you don't need this article — the free generators do it in one click.
The second kind has almost nothing written about it, and it is the one that changes the output of work you actually bill for. It's what the person on that forum thread meant when he asked how to build an ai persona of himself to handle small conversations for the business he runs, in a speaking style recognisably his. That question has been sitting there mostly unanswered.
Throughout this article, "your trade" means whatever you call your line of work — a practice, a firm, a shop, a studio, a book of business. The four parts are the same whichever word you use.
💡 In plain terms. The marketing version of a persona is a picture of your customer. This version is a picture of you at work — the words you use, the shape of your paperwork, the lines you won't cross. One is a target. The other is a voice.
Tempting to file this under polish. It isn't.
Look at where professional liability claims actually come from. The American Bar Association's Profile of Legal Malpractice Claims 2016–2019 sorts claims by the type of error behind them. Substantive errors — genuinely getting the law wrong — account for 51.93%. Administrative errors account for 19.59%, and client relation errors for another 16.7%. Add those two and a bit over a third of claims trace back to calendaring, clerical work, follow-up, and failures to inform or get consent. Conflict of interest sits separately at 4.9%. (
)
None of that third is about knowing your subject. It's about the shape of the process: what got written down, in what order, and whether the sentence that had to be there was there.
That is exactly the layer a general draft gets wrong. It knows the law, the building code, the accounting standard, more or less. What it doesn't know is that in your shop the conflicts fields come before the story, that a punch list carries a fixed disclaimer at the top, or that a bare line reading "Deposit" is not an acceptable transaction description. Those aren't opinions. In several trades they are written rules with named consequences — and they never make it into a model's general training, because they live in a 228-page association handbook or a municipal council PDF rather than on a blog.
It helps to know what you're correcting before you start writing. When a model drafts inside a trade nobody has told it about, the same five things go wrong:
All five show up in one draft. Here is what one looked like on a real task, before any of this was written down:
[NEEDS REAL RUN: the actual "before" draft — one real, de-identified task from one
of the three trades below, drafted with no house-style section, pasted verbatim,
with the five failure modes marked in the margin. Needs a real run on Claude or
ChatGPT web with nothing in the project but the task.]
Everything worth writing down falls into four buckets. Not three, not seven — four, and they map onto the four ways a draft comes back wrong.
The whole thing lives inside a plain text file called AGENTS.md. That name isn't something we made up: it's an open format OpenAI released in August 2025 and handed to the Agentic AI Foundation under the Linux Foundation in December 2025, and it is deliberately boring. Its own FAQ says it best — "No. AGENTS.md is just standard Markdown. Use any headings you like; the agent simply parses the text you provide." (agents.md, checked 2026-07-31). No schema, no required fields, no version number, nothing to install. If you already keep a folder with your rules in it, your ai persona is one more heading in the file at the top of that folder. If you don't have the folder yet, start with the one-folder setup and come back.
The cheapest and highest-return part. Every trade has words where the everyday synonym is not merely vaguer but actively wrong, and a second set where the everyday synonym just marks the writer as an outsider.
Write both. Format: our word — the word an outsider uses — one clause on why it matters. That last clause does real work; without it the model reads the list as a style preference and drops the rule the first time a sentence gets awkward.
Not tone. Shape. What comes first, what comes last, what is always present, and the exact wording of anything that has to appear unchanged.
The best examples are public, and worth opening, because in each case the format is doing legal work rather than aesthetic work.
The Kentucky Bar Association's conflict consultation form, published as an exhibit to
, puts a warning notice above the first field: the potential client should be advised not to give the attorney or a staff member any confidential information until after an initial conflicts check has been completed. It is the first thing on the page. That's a format rule, and a drafting model will move it or trim it unless you say not to.
For the delivery side, open the real thing. The City of Hammond, Louisiana filed a signed certificate of substantial completion with the actual punch list attached in a
— three pages, free, and it shows the shape better than any template. Items group by discipline, then by room or structure, then get numbered. Each one is a single imperative verb, an object, and a location: "Provide painted louver transom in hollow metal door frame." "Remove protective film from sanitary napkin dispenser." Not "louver looks unfinished."
The list carries a fixed sentence at the top — exactly the sort of thing a model politely deletes as redundant:
"This list may not be all-inclusive, and the failure to include any items on this list does not alter the responsibility of the contractor to complete all work in accordance with the contract documents."
Three more things are visible on that certificate that no template shows you: the architect certifies the work "to the Architect's best knowledge, information, and belief, to be substantially complete" — hedged language, on purpose. The cost of the remaining work is written on the face of it, in this case $1,610.00. And the contractor is given forty-five days from the date of substantial completion to finish the attached list. Dates, money, and a named professional's qualified judgement, all in a form. That is what "format" means here.
On the books side, the North Carolina State Bar's
spells out how a reconciliation ends: the three balances should all agree; if they differ, attach an explanation showing how the imbalance was corrected; the person who completed it signs, and so does the lawyer who reviewed it. Three figures, one agreement statement, two signature lines — a format specification that fits in four lines of your file.
This is the part almost nobody writes down, and it is the part that pays for the whole exercise.
To be clear about what I am and am not doing here: I am not telling you what your rules are. I don't know your jurisdiction, your contract, or your insurer. What I am saying is that you already know several sentences that must never appear in your documents, and that knowledge is currently stored nowhere except your reflexes. A model has no reflexes. Write them as flat prohibitions.
The published examples are useful because they show what a real one looks like — specific, absolute, and attached to a consequence.
⚠️ The mistake that makes this section useless. Writing "be careful about compliance," "follow all applicable regulations," or "maintain professional standards." Those sentences change nothing, because the model was already trying to do that. A prohibition only works if a competent, well-meaning drafter could plausibly violate it without noticing. Test each line by asking: would a smart new hire, on their first week, get this wrong? If no, delete it. If yes, it belongs.
One paragraph, and the one people skip.
Left to itself a model resolves ambiguity. That's what it's built to do, and it's the wrong behaviour for most professional work. You need it to stop, name what it can't resolve, and hand that to a specific human. "Consult a professional" doesn't achieve this, because it's a disclaimer, not an instruction. Write three things instead:
Across the three faces: a hint of a conflict stops the intake summary entirely and produces a question list for the conflicts partner. Anything that could move the substantial completion date stops the punch list and goes to the PM, who calls the architect. Any negative client ledger balance stops the month-end pack — the North Carolina handbook requires that negative to be funded immediately or to carry a written explanation attached to the account record, and neither is a call software gets to make.
Three complete sections, one per face. Not fragments. Copy the one closest to your work, change the words to yours, delete the lines that aren't true for you, paste it into AGENTS.md under a heading.
Each is about forty lines. That's deliberate — see the size limits further down.
## House style — client intake
### What we call things
- A new piece of work is a **matter**. Never "case," "file," or "project."
- Someone who has contacted us but not signed is a **prospective client**.
Never "lead," "enquiry," or "potential client" — the first term carries
duties the others don't.
- The document that starts the work is an **engagement letter**.
Not a proposal, quote, or contract.
- Money held before it is earned is an **advance fee deposit**, held in trust.
- The check we run before anything else is a **conflicts check**.
### What our documents look like
- Every intake document opens with the non-confidentiality notice, in full,
before any field.
- Intake happens in two passes, in this order, never reversed:
1. Conflicts pass — full legal name of the person and any entity, related
parties, adverse parties, adverse counsel, the court or likely venue, and
one line on the general subject of the dispute. Nothing else.
2. Facts pass — only after the conflicts check clears.
- Every intake summary ends with three lines: date and time of first contact,
who took it, and conflicts status (cleared / not cleared / pending).
### What we never write
- Never write or imply acceptance of a matter before the conflicts check
clears. That includes "we can help with this," "your position looks strong,"
and "next steps."
- Never describe a fee arrangement as agreed unless there is a signed written
agreement and the client holds a signed copy.
- Never move the facts pass ahead of the conflicts pass, even if the person
volunteers the story first. If they do: stop, write "unsolicited detail
received — flag for conflicts partner," and do not summarise what they said.
- Never describe anything sent to us before engagement as privileged.
### When it isn't clear
- Any hint of a conflict, any adverse party you cannot fully identify, any
prior contact you cannot rule out: stop. Produce a question list addressed
to the conflicts partner. Do not produce the intake summary.
- Anything touching fee terms: stop, address it to the billing partner.
- While waiting, produce nothing that could be sent to the prospective client.
## House style — closeout documents
### What we call things
- The list of remaining items is the **punch list**. On UK-spec jobs it is the
**snagging list**. Use the one that matches the contract; never both in one
document.
- **Substantial completion** and **final completion** are two different dates
with two different consequences. Never write "complete," "done," or
"finished" on its own.
- Money held back is **retainage**. Never "holdback" or "the last 10%."
- Extra work is a **change order with a number**. Never an "extra," an "add,"
or "we'll sort it out."
### What our documents look like
- Punch list items group by discipline (ARCHITECTURAL / MECHANICAL /
ELECTRICAL / PLUMBING / SITE), then by room number or grid location, then
numbered.
- Each item is one imperative verb, one object, one location.
Write: "Provide painted louver transom in hollow metal door frame."
Not: "louver looks unfinished."
- Every punch list carries this sentence at the top, unchanged:
"This list may not be all-inclusive, and the failure to include any items on
this list does not alter the responsibility of the contractor to complete all
work in accordance with the contract documents."
- Every item carries a target date and an owner: us, a named sub, or the owner.
### What we never write
- Never state or imply that the work has reached substantial completion. That
determination is the architect's, and the certificate is signed by owner,
architect, and contractor.
- Never write that the certificate ends our obligations. It does not.
- Never draft a final payment affidavit as an ordinary letter. It is sworn.
- Never write "as discussed on site" in place of a change order number.
### When it isn't clear
- Any item that could move the substantial completion date: stop, flag it, the
PM calls the architect.
- Any item a sub disputes: stop, list it separately under "disputed — not for
issue."
- Any request to add items after the certificate is signed: stop. Do not add it
to the list. Flag to the PM.
## House style — month-end close
### What we call things
- Any difference between our records and the bank is a **reconciling item**
until it is identified. Not a "discrepancy," not an "error."
- For client money we do a **three-way reconciliation**: ledger balance, the
sum of the individual client ledgers, and the adjusted bank balance. A plain
"bank rec" is only two of those three.
- The month is **closed**, not "finished" or "wrapped."
- Money withheld from pay is **trust fund tax**. Never group it with cash on
hand.
### What our documents look like
- Every transaction description reads: client or vendor name — matter or job
number — purpose — what authorised it. Never a bare "Deposit," "Transfer,"
or "Payment."
- Every reconciliation ends with the three figures side by side and an explicit
"these agree" or "these do not agree" line. If they do not agree, attach an
explanation showing how the difference was corrected.
- Two signature lines with dates: whoever prepared it, whoever reviewed it.
- Reconciling items older than our cut-off are listed separately with an age in
days.
### What we never write
- Never write a summary that treats withheld payroll tax as available cash.
- Never post an entry dated inside a closed month. Anything found after close
goes to the next period.
- Never present a negative client balance as a rounding issue.
- Never record that a review of bank statements or cheque images was done
unless the person named did it personally.
### When it isn't clear
- Any negative client balance: stop, do not produce the pack, flag it.
- Any reconciling item you cannot categorise: stop, list it under
"unidentified" with amount and date. Do not guess a category.
- Anything touching payroll tax timing: stop, address it to the owner
personally.
You don't write your ai persona from imagination. You find it in documents you have already produced. Five steps, about thirty minutes.
Hand steps 2 and 3 to the model itself and it goes faster, and it catches things you've stopped seeing. Copy this:
I'm going to paste ten documents my business actually sent out. They are all from
the same line of work, and I'd be happy to send every one of them again.
Your job is to find the house style already in them. Do not invent one.
Do these four things and nothing else:
1. NAMES. List every term someone in my line of work would recognise and an
outsider would say differently. For each: the term I use, the term an outsider
would use, and how many of the ten documents it appears in. Drop anything that
appears only once.
2. FORMAT. Describe the shape of each document type: what comes first, what comes
last, what is always present, what order things go in. Quote verbatim any
sentence that appears unchanged in more than one document.
3. RULES I'M FOLLOWING. Point at sentences that seem to exist because a rule made
me write them rather than because I chose to. Name the document each came from.
Mark each "looks like a rule" or "guessing" — you do not know my obligations,
so guess openly and let me correct you.
4. DELETE LIST. Every phrase you found that would be true of any business in any
industry.
Non-negotiable:
- Quote from the documents. Do not paraphrase into generic business language.
- If you did not see it in the ten documents, do not include it.
- If two documents contradict each other, show me both and say so. Do not pick one.
Output four headed lists in that order. No summary, no advice, no compliments.
🔍 One step further. Separating a habit from a rule matters more than it looks. A habit is something you do because you've always done it; it belongs in the file only if you want it kept. A rule exists because of an obligation, and it belongs in the file with that obligation named beside it — because in twelve months, when you're trimming, "we always do this" gets cut and "we do this because of X" survives. Mark them differently the first time. For a longer treatment of organising material so a model can navigate it, there's a guide on turning documents you already have into something an agent can use.
Writing the thing is the easy half. The half people skip is checking whether it did anything — and a surprising share of what goes into these files changes nothing at all.
One task, run twice, same model, same day.
Draft {the thing you actually make} for this situation:
{paste one real, de-identified situation from last month}
Run it exactly twice.
Pass 1: the request above, with nothing else.
Pass 2: paste my house style section first, then the same request, word for word.
Then give me a table, one row per difference, with only these columns:
what changed | which line of my house style caused it | did it help
If a line of my house style changed nothing, say so. That line is a deletion candidate.
What to look for, in order of how much it tells you:
| Check | Passing looks like |
|---|---|
| Names | The trade word replaced the everyday word, in every instance, including inside headings |
| Order | The required-first thing is first, even though it's the least interesting part |
| Fixed sentences | Present, verbatim, not paraphrased or "improved" |
| Prohibitions | The forbidden phrasing is absent, and nothing rephrased it back in |
| Escalation | It stopped where you told it to stop, instead of producing a confident answer |
The last row is the one that fails most often, and it's the one worth re-running until it passes.
Here is what happened when the same task was run both ways, and how many revisions it took before the second pass was usable:
[NEEDS REAL RUN: the "after" draft of the same task, plus the five-row difference
table filled in with what actually changed, plus a version log — which line of the
house-style section was edited on each pass and what changed in the output as a
result. Needs the same real run as the "before" sample above, continued across
several revisions.]
One failure mode, and almost everybody hits it: writing a company brochure instead of a house style.
It reads well. The practice values responsiveness, holds itself to the highest standards, puts clients first, communicates clearly. Every sentence true. Not one of them changes a word of the next draft, because the model was already trying to be responsive, high-standard, client-first and clear.
The test is mechanical. For each line ask: could a competent competitor in my trade plausibly do this differently? If no competitor could disagree with it, it's decoration. Delete it.
| Decoration | The same intent, written so it changes output |
|---|---|
| "We pride ourselves on responsiveness." | "Acknowledge within one business day. If we can't answer in that time, send a holding note saying when we will." |
| "We maintain high standards of accuracy." | "Never state a figure that isn't traceable to a document in the file. If it isn't, write the figure and add [unverified]." |
| "We communicate clearly with clients." | "No sentence longer than 30 words in anything a client reads. No Latin. Spell out every acronym on first use in every document, even if we used it last week." |
The second column is longer, less elegant, and does something. That is the trade.
⚠️ The other way to waste it: writing too much. Every tool that publishes a limit publishes a small one, and the reasons are documented. Claude Code's own guidance says to target under 200 lines per instruction file, and states outright that longer files consume more context and reduce adherence (Claude Code memory documentation, checked 2026-07-31). Codex stops appending project documents once it passes a default of 32 KiB — silently. Windsurf caps a workspace rule file at 12,000 characters and a global one at 6,000. A forty-line section that gets followed beats a six-page one that gets truncated. If your file is getting long, the fix is usually structural rather than editorial — there's a piece on how to arrange the folder so it stays findable.
An ai persona makes output consistent. It does not make output correct, and it does not move responsibility anywhere.
Worth being blunt about, because the tools are blunt about it themselves. Claude Code's documentation describes written instructions as context rather than enforced configuration, and says Claude "reads it and tries to follow it, but there's no guarantee of strict compliance." That's the honest description of every file of this kind, on every platform. Instructions shape behaviour; they don't bind it.
So anything with a signature attached stays with the person whose name is on the signature. The published examples are unusually explicit about this:
| The act | Why it can't be handed over | Source |
|---|---|---|
| Monthly review of bank statements and cheque images (NC trust accounts) | The rule states the requirement cannot be delegated, so that the lawyer might see a cheque made out to an improper payee | NC Rule 1.15-3(i)(1) + |
|
| Swearing a final payment affidavit (Florida) | It is sworn testimony, and service is treated as an absolute condition precedent to enforcing lien rights | Fla. Stat. § 713.06(3)(d); Delta Painting v. Baumann |
| Certifying a translation as complete and accurate | The rule requires a person's statement of their own competence | 8 C.F.R. § 103.2(b)(3) |
| The architect's determination of substantial completion | It is a professional judgement, certified by signature | AIA G704-2017 |
| Being responsible for client money after hiring a bookkeeper | "However, you are still personally responsible" | California trust accounting handbook |
Write those into the fourth bucket as hard stops, not as reminders. And then there's the failure that survives everything you write:
[NEEDS REAL RUN: the one thing it still gets wrong after several revisions of the
house-style section — the specific recurring error that more instruction did not
fix, and the human check that ended up catching it instead. Needs enough real runs
across weeks to distinguish a persistent failure from a one-off.]
Worth saying plainly, in the middle rather than at the top.
I don't come to any of these trades carrying the habits of someone who grew up in them. What I did was run the process — take a real published document, write the ai persona out of it, see what came back. That's a different kind of useful from twenty years in a practice, and it has an obvious hole: I can see when the output changed, and I often can't see when it changed in the wrong direction.
So here is the run, and here is where it went off:
[NEEDS REAL RUN: take one public document — the signed certificate of substantial
completion with the real punch list from the Hammond, LA council record is the best
candidate, since it is free, complete, and signed — write the house-style section
from it, ask a model to produce a new punch list for a different room, and record
exactly where the result is wrong in a way a contractor would spot immediately and
an outsider would not. Needs a real run.]
If you do this work every day, the useful reply isn't "good article." It's the line I got wrong. Tell me what's missing from the section for your trade — the word I used that nobody uses, the sentence that has to be there that I left out. That's the whole reason this is public.
Your ai persona is plain text. Where it lives depends on what you're using, and the honest answer is that the experience is uneven.
| You're on | How it connects | Grade |
|---|---|---|
| Codex, Cursor, Copilot's coding agent, Windsurf, Zed, Amp, Devin, Junie, Warp, goose, opencode and the rest of the 23 tools named on agents.md | Put AGENTS.md in the project folder. It's read automatically, no configuration |
✅ |
| Claude, web or desktop, inside a Project | Upload the file into the Project. Two caveats: there's no folder upload, so it's one file at a time, and as the Project grows the assistant switches to looking things up rather than reading everything each turn | 🟡 |
| ChatGPT, web, inside a Project | Add the file to the Project's files. There's a hard cap on file count that varies by plan, and the official wording is that it can use and prioritises those files — reference, not guaranteed full read | 🟡 |
| Claude Code | It does not read AGENTS.md. The documentation says so in as many words: "Claude Code reads CLAUDE.md, not AGENTS.md." Fix: put @AGENTS.md as the first line of a CLAUDE.md, or run ln -s AGENTS.md CLAUDE.md — and note that on Windows the symlink needs administrator rights, so use the import line instead |
❌ → 🟡 |
| Gemini CLI | Reads GEMINI.md by default. Point it at yours by setting context.fileName in .gemini/settings.json |
❌ → 🟡 |
| Anything else | Paste the section at the top of the conversation. Every time | 🟡 |
| The "personality" or custom-instructions box inside one vendor's account | There is no machine-readable export. ChatGPT's custom instructions come out by manual copy. Claude's stored memory exports as prose you copy by hand, and the account data export can't be imported into another personal Claude account. Cursor removed its Memories feature outright in a 2.1.x release and told users to export and paste the contents into rules files. Whatever you type in that box does not come with you | ❌ |
That last row is the reason for all of this. Typing your ai persona into a settings panel works, right up until the day the panel changes, the plan changes, or you do. A file in a folder doesn't have that failure mode — and proving that properly is its own article.
Two more things worth knowing about the format itself, both from its own FAQ (agents.md, checked 2026-07-31): if two of these files disagree, the one closest to what's being worked on wins, and there are no required fields at all. You cannot fill it in wrong. You can only leave it empty.
Opened on 2026-07-31, primary sources: the agents.md homepage and FAQ (no required fields, nearest file wins, the compatible-tools wall, the "over 60k open-source projects" figure); the Claude Code memory documentation (the AGENTS.md paragraph, the import and symlink instructions, the Windows caveat, the 200-line guidance, the "context, not enforced configuration" framing); 8 CFR 103.2 on eCFR; and the Hammond council PDF, which is where the $1,610.00, the forty-five days and both punch list items come from. Every other rule and case in the four buckets is linked inline.
On that 60k number: published with the December 2025 donation announcement and not revised on the project site since, so treat it as a floor, not a current count. It counts file matches rather than projects — the site itself notes that at time of writing OpenAI's main repository contained 88 of these files.
Three approaches ruled out before writing this:
Not tested, and flagged in place above: the before-and-after drafts, the revision count, the persistent failure that more instruction didn't fix, and the public-document run. They're marked rather than filled in with a plausible story, because a made-up failure is the easiest thing in the world for someone who does the work to spot.
Is this the same as an ai persona generator?
Opposite direction. A generator writes a fictional customer for you to aim at. This writes down how your own business talks, so the model aims at that instead of at an industry average.
Do I need a different one for each client?
No. Client-specific facts belong in the file for that job. Your ai persona is the part that's true across every client — that's what makes it worth writing once.
What if two of my documents contradict each other?
Then you've found a real disagreement inside your own business before you've even used the file. Pick one on purpose. This surfaces more often than people expect.
Can I ask the model to write it for me?
Ask it to find your style in documents you already sent — that's the prompt above. Asking it to write one from scratch returns generic industry language, which is the problem you started with.
Where does the file live if I don't use a code editor?
In a folder on your computer, next to whatever else you give the assistant, and uploaded into your Project. The table above covers the specifics per tool. Nothing here needs a terminal.
Does this make the output compliant?
No. It makes it consistent, which is a smaller claim. Anything with a signature, an oath, or a personal duty attached still needs the person whose name is on it — that's the whole point of the fourth bucket.
AGENTS.md and put it where your assistant reads itNow it knows who you are and how you talk. It still doesn't know how any single job gets done — the order of the steps, what to look at, what to do when something doesn't match. That's the next file, and it's the one where a document written for a person has to be rewritten for something that doesn't fill in the gaps. Coming next: turning a written procedure into one an agent can actually follow.
If you got here without the file this section lives in, start with the five-line version that comes before this one.
Related reading: keeping your rules in one folder · arranging files so an agent can navigate them · what happened when a whole body of law went in · the terms, in plain English · already working from a terminal? the command-line version of the same idea
This site does not ask you to create a product account. Free readers just leave an email—or follow where the build is posted.
| Channel | What you get | Where |
|---|---|---|
| Email (free) | Occasional field notes as we pressure-test more systems in the wild. Articles on the site stay free. | Open aiworkflowpro.com, scroll to Subscribe, enter your email, confirm the link in your inbox. |
| X | Short ops notes and build-in-public updates | @aiworkflowprolk |
| YouTube | Longer industry-workflow rebuilds | @aiworkflowprolk |
No paywall on this article. No "sign up for access." If you only want one next step: use the email box at the bottom of the site, or follow on X if you prefer the timeline.
hh — AI Workflow Pro
Monitoring a competitor who publishes no feed is the case every RSS guide skips. Twenty-one platforms sorted by which of three jobs they do, and the finished setup is business process automation you own outright, with no seat licence to renew.
Blaming the content is the reflex when a post underperforms, and it is usually the wrong diagnosis. A second reader decides distribution before any human sees the post, and most of what it checks is mechanical enough to automate business processes around, on five platforms at once.
Thursday afternoon, fourteen product ideas, a Monday filming slot, no scripts. Six script shapes and seven hook formulas turn that hour into finished drafts — and the business rule stays: rewrite at least 30% before anything ships.
A detector score cannot survive a conversation with the freelancer it just cost three weeks of payment. What holds up is the specific thing on the page: rhythm, vocabulary, missing detail. Eight of them here, and the reason review stays human when you automate business processes.
When I rebuild one with AI agents, you get the write-up — including the parts that didn't work. No weekly roundup, no "5 tools you need."