They run in any order, but four of them compound in this one: audit the context, map the spend, design one loop, then plan the brain. The fifth checks whether AI assistants can read your website, and stands on its own.
Using the skills
Each skill is plain text - the method and its rules, written for an AI assistant to follow. No set-up, no code, and nothing installed on your computer.
- Copy the skill. Every skill below has a copy button. It copies a one-line instruction and the whole skill, ready to paste.
- Paste it into a new chat in Claude, ChatGPT, Gemini or Copilot, and send it.
- Answer its questions. The skill asks what it needs a few questions at a time, and you answer from what you know. The skill carries the method; your assistant supplies the conversation.
Rather keep it? Download the file instead, and attach it to a chat or add it to a project so it is there every time. In Claude you can also add it as a skill in your settings, if your plan supports it, and it will offer itself whenever it fits. They work best in an assistant that can also see what they audit - the web, for the website check; your own notes, for the context audit - but every one of them runs fine as a plain conversation.
The five skills
somai-context-audit
How much of what your company knows could a model actually read?
The new-hire test, run properly: ten probe questions across the five systems every company runs on, each answer classified by where it lives - a system, a document, a head, or nowhere. The audit behind the company brain argument, applied to your business in one sitting.
Worth running when: Before any serious AI initiative, after a disappointing pilot, or when the same questions keep being re-answered from scratch.
You get: A legibility map, the single most expensive gap, and the first move.
What you paste:
Run the somai context audit below on my company. Follow its instructions, and ask me what you need a few questions at a time. + the whole skill
Run the somai context audit below on my company. Follow its instructions, and ask me what you need a few questions at a time. --- name: somai-context-audit description: Audit how much of what a company knows a model could actually read - the context audit behind the company brain argument. Uses the new-hire test and ten probe questions across the five systems every company runs on, classifying where each answer lives (a head, a document, a system, nowhere) and how current it is. Produces a legibility map, the single most expensive gap, and what a model would do in that gap today. Use when someone asks whether their company is ready for AI, why their AI pilots disappoint, what a company brain would change, or how AI-ready their knowledge is. --- # somai context-audit A company knows far more than it can say. Why one customer is handled differently. Which promise must never be broken. What went wrong last time, and why the obvious fix is not the fix. Almost none of it is written down - it lives in people, habits, and the worn paths of how things are done here. That was workable when the only readers were human. A model is not a human reader. Given real work inside a company it cannot read, it does not stop - it produces something confident, fluent and subtly wrong, because when context is missing it fills the gap with the world's most likely answer, which is almost never this company's actual answer. This skill measures the gap. Not model capability - that is bought in. Context. The context is the company, and this audit finds out how much of it a model could reach today. ## Before you start You need the person in the conversation, not their filesystem. Ask the probes conversationally, one area at a time - this is an interview, not a form. If you are running inside their environment (a repo, a drive, a wiki) you may verify claims against what you can see, and say when the two disagree. Everything stays in this conversation. Nothing is sent to somai or anywhere else unless the person chooses to send the readout. ## The new-hire test Every probe below applies the same test. Imagine the most capable new hire you have ever met, starting this morning, with no one to ask: could they find the answer? A model working inside your company is that person, every morning, forever. Whatever they could not find, it cannot find either. For each probe, classify where the answer lives: - **SYSTEM** - a system of record a machine could query today - **DOCUMENT** - written down somewhere findable, if you know to look - **HEAD** - one or more particular people - **NOWHERE** - it would have to be reconstructed or re-argued And flag two modifiers: **stale** (last confirmed more than two quarters ago) and **contested** (two senior people would answer it differently). ## The ten probes Five systems, two probes each. Use these words or close to them. **What your company knows** 1. Why did you last lose a customer you wanted to keep - and where is that lesson recorded? 2. If two senior people each described your core process end to end, how closely would the descriptions match, and is either version written down? **Your market** 3. Which of your customers are strategic rather than merely large - and does that distinction exist anywhere a machine could read, or only in judgement? 4. What did your last failed initiative teach you - and could anyone who was not there find that out? **How the work gets done** 5. In your main delivery process, which steps are load-bearing and which are theatre - and does any document admit the difference? 6. When a piece of work is finished, does any record state that it finished, with a date - or does completion live in someone's awareness? (This is the evidence rule: a record about a thing is not evidence the thing happened.) **How you decide** 7. Could you list last quarter's ten most consequential decisions, who made each, and why? Where would that list come from? 8. What counts as an approved exception - to price, to process, to policy - and is that written, or is it "ask a particular person"? **How you stay in control** 9. Who may declare a priority, and when two sources disagree about what matters this quarter, which one wins? 10. If an AI assistant confidently asserted something wrong about your business tomorrow, who would catch it, and how quickly? ## The readout Produce exactly this, in this order: 1. **The legibility map.** A table: the five systems, each probe's classification (SYSTEM / DOCUMENT / HEAD / NOWHERE, with stale and contested flags), and one line of the person's own evidence. 2. **The counts.** How many of the ten answers a machine could reach today (SYSTEM counts in full, DOCUMENT at half strength). Present it as "N of 10" - arithmetic, never a percentage dressed up as precision. 3. **The most expensive gap.** One paragraph. Pick the single HEAD or NOWHERE answer whose absence most limits what a model could safely do here, and say what a model would produce in that gap today: a confident, fluent, plausible answer drawn from the statistical average of everything it has read, which is almost never this company's answer. 4. **The three problems no tool solves.** State plainly which apply: ownership (documentation has no natural owner), incentive (externalising what makes people valuable cuts against self-protection), freshness (knowledge has a half-life - what keeps it true?). Naming these honestly is the readout's real value. 5. **The first move.** Not "document everything" - that is the wiki that rots. The move is knowledge treated as infrastructure: an owner, a maintenance budget, a defined freshness, starting with the one gap named above. ## Rules - Record answers in the person's own words before classifying them. - Never soften a NOWHERE into a DOCUMENT because it feels harsh. The audit's value is its honesty. - No invented numbers, no maturity scores, no benchmark comparisons. Counts out of ten are the only arithmetic here. - British English. No hype. ## Where this leads - Where the money went: **somai-spend-map** - map current AI spend against this legibility picture. - The first rebuild: **somai-decision-loop** - one decision, redesigned with the model in the loop. - The argument in full: [A company your model can read](https://somai.studio/thinking/a-company-your-model-can-read/) · [Why every company will build a brain](https://somai.studio/thinking/why-every-company-will-build-a-brain/) - The measured version, with the value modelled: [the ten-minute diagnostic](https://benchmark.somai.studio) - 25 questions, banded inputs only. - somai builds company brains - handed over to your team, or run for you, and owned by you either way: [somai.studio](https://somai.studio) · hello@somai.studio
Or download the file to attach it or keep it in a project · read it first
somai-spend-map
Why does the AI spend keep missing the P&L?
Maps every AI initiative you run - licences, copilots, pilots, agents - and shows the structure: which are retrofits, which can see each other, and how many times the same plumbing has been re-solved from scratch. The verdict is structural, so it needs no invented numbers.
Worth running when: At budget time, when the board asks what the AI spend returned, or when the tool count keeps rising and nothing compounds.
You get: The initiative map, the counts, and the one question that decides the next tranche of budget.
What you paste:
Run the somai spend map below on my company. Follow its instructions, and ask me what you need a few questions at a time. + the whole skill
Run the somai spend map below on my company. Follow its instructions, and ask me what you need a few questions at a time. --- name: somai-spend-map description: Map every AI initiative in a company - licences, copilots, chatbots, pilots, agents - and show structurally why the spend is or is not reaching the P&L. Classifies each initiative as retrofit or rebuild, isolated or connected, and counts how many times the same plumbing (data access, identity, governance, evaluation, memory) has been re-solved from scratch. Produces the initiative map, the forgone compounding, and the one question that decides the next tranche of budget. Use when someone asks why their AI spend shows no return, whether to keep funding pilots, how to prioritise AI budget, or where their AI programme actually stands. --- # somai spend-map MIT's Project NANDA reported that around 95% of enterprise generative AI pilots produce no measurable impact on profit or loss. Treat that as a description, not a proof - it is survey and interview work, and says so itself. But the description names a cause worth taking seriously: the tools cannot retain feedback, adapt to context, or improve over time. The systems sit beside the business rather than inside it. That is a context problem, not a capability problem - and it means the failure is structural, which is good news, because structure can be mapped. This skill maps it for one company. ## Before you start You need someone who can list the company's AI activity. Everything stays in this conversation; nothing reaches somai unless they choose to send the map. Build the inventory first. Ask for every AI initiative, live or planned: tool licences handed round a team, copilots in the productivity suite, the chatbot, each pilot, anything called an agent. Small counts are normal. Shadow usage (individually purchased tools) counts - note it as such. ## The map For each initiative, establish five facts. Ask; do not assume. **1. Where it sits.** Periphery (support, marketing copy, meeting notes) or core (the decisions and processes the company actually runs on). Peripheral starts are rational - contained risk, fast payback. The trap is only that each one is provisioned alone. **2. What it can see.** The context this initiative can reach: none beyond its prompt / its own silo / context shared with other initiatives. Apply the test from the somai context audit: the support tool that cannot see contract terms, payment history, or the last three conversations is doing a different, smaller job than the one that matters. **3. Retrofit or rebuild.** The structural question from the ai-native definition: did you add the model to the way you already work, or did the way you work change to fit what the model makes possible? Copilots bolted to unchanged approval chains are retrofits, however sophisticated. Count honestly. **4. Plumbing re-solved.** Which of the five it had to solve alone: data access, identity and permissions, governance, evaluation (how you know it is working), memory (what it retains between sessions). Each initiative that solved these separately paid a setup cost the next one cannot inherit. **5. What it would need to see.** One sentence: the context that would let this initiative do the job that actually matters, and whether anything on the current roadmap provides it. ## The readout Produce exactly this, in this order: 1. **The inventory table.** Initiative, where it sits, what it can see, retrofit or rebuild, plumbing re-solved. 2. **The counts.** N initiatives. How many share any context with any other. How many are rebuilds rather than retrofits. How many times identity, governance, evaluation and memory have each been solved from scratch. Arithmetic only. 3. **The structural verdict.** One of two sentences, chosen by the evidence. Either: the programme is a set of endpoints hitting the same wall alone, and its ceiling is structural - adding more tools moves the line roughly nowhere, because the value of AI capabilities inside one firm lies in what they can see of each other (the complementarity finding: practices that are complements underperform badly when adopted partially - the interaction terms, where most of the value sits, are forgone entirely). Or: a shared foundation exists, and the map shows what plugs into it next. 4. **What connection would change.** For the two or three initiatives with the most confined view, the one-sentence version of the job each could do if it could see what the others see. 5. **The one question.** The next tranche of AI budget is not "which function gets a tool". It is: does the foundation underneath the functions exist yet - the shared layer for identity, governance, evaluation, memory and reach, with the parts still owning their own data? Centralise the foundation, not the data. Without it, every new tool is another endpoint hitting the same wall alone. ## Rules - The MIT figure is reported research about the population, not a claim about this company - always present it with that caveat, as above. Never generate a projected saving, an ROI figure, or a benchmark comparison for this company. The map is structural, and its force is that it needs no invented numbers. - If the inventory is thin, say so and map what is there. Three initiatives that cannot see each other make the point as well as thirty. - British English. No hype. ## Where this leads - The context those initiatives cannot see: **somai-context-audit**. - The first structure worth building: **somai-decision-loop**, then **somai-brain-plan** for the programme around it. - The argument in full: [Most AI spend never reaches the P&L](https://somai.studio/thinking/most-ai-spend-never-reaches-the-pnl/) · [Automation makes the wrong work faster](https://somai.studio/thinking/automation-makes-the-wrong-work-faster/) - The value, modelled honestly in bands: [the ten-minute diagnostic](https://benchmark.somai.studio) - somai builds company brains - handed over to your team, or run for you, and owned by you either way: [somai.studio](https://somai.studio) · hello@somai.studio
Or download the file to attach it or keep it in a project · read it first
somai-decision-loop
What does one decision look like, rebuilt properly?
Takes one recurring decision - intake, a pricing exception, a hiring shortlist - and designs the loop: the model as a standing participant that drafts, checks and argues the other side, a named human keeping the call, dissent and the evidence rule built in.
Worth running when: Moving past copilots, putting AI into real decisions without losing control of them, or choosing the first serious use case.
You get: A one-page loop design, ending in the exact context the loop needs and where that context lives today.
What you paste:
Run the somai decision loop below on one decision in my company. Follow its instructions, and ask me what you need a few questions at a time. + the whole skill
Run the somai decision loop below on one decision in my company. Follow its instructions, and ask me what you need a few questions at a time. --- name: somai-decision-loop description: Redesign one recurring business decision so a model is a standing participant in how it gets made - drafting options, arguing the opposite case, checking proposals against what the company knows - while a named human keeps the call. Produces a one-page loop design covering the model's standing role, explicit boundaries, designed dissent, the evidence rule, accountability, and the exact context the loop needs with where that context lives today. Use when someone wants to move past copilots and chatbots, put AI into real decisions safely, design human-in-the-loop or model-in-the-loop workflows, or pick their first serious AI use case. --- # somai decision-loop There are two popular pictures of AI at work, and both are wrong the same way. AI as a tool: picked up, used, put down - the work still wholly human, one step faster. AI as a replacement: the job handed over, the person gone. Each keeps the line between human and machine where it always was and moves a task across it. The change that matters dissolves the line. A decision made in the loop is designed so a model is a standing presence in how it gets made. It drafts the options before they are asked for. It argues the opposite case. It checks the proposal against everything the company knows. It runs the analysis that was always too expensive to commission. And a human still holds the decision - not reviewing the model's homework, but deciding, inside an environment where most of the labour of deciding well is already done. A loop drifted into, rather than designed, slides toward automation bias: the human stops deciding and starts ratifying, and when it goes wrong, no one quite owns it. The defence is not less model. It is more design. This skill does the design, for one decision. ## Before you start Everything stays in this conversation; nothing reaches somai unless the person sends the design somewhere. Help them pick one decision. The right first candidate is narrow, recurring, and already carries a consequence: project intake, a pricing exception, a hiring shortlist, a budget request, a roadmap trade-off. Not the largest decision - the one where history keeps getting lost and the same debate keeps being re-run. If they offer a vague area ("strategy"), narrow it until it is a decision someone actually makes on a particular day. ## The design Work through the seven parts in order, asking as you go. Push back on vague answers - a loop design with a soft edge fails at the soft edge. **1. The decision, and its owner.** One sentence for the decision. One name for the owner - a person, not a committee. Every decision in the loop ends with a name attached to it. **2. The model's standing role.** Which of these it does before the decision is discussed: draft the options; argue the opposite case; check the proposal against the company's own record (prior attempts, current commitments, stated priorities); run the analysis nobody commissions today. Be concrete about what arrives, and when, and in what form. **3. The boundaries, in three lists.** What the model may settle alone (mechanical, reversible, low-stakes). What it may shape but never settle. What the humans must reason through unaided - and say why those stay human: they were never information problems. Judgement, taste, integrity, sensing, responsibility do not automate; they are what it means to have a stake. **4. Dissent, by design.** Consensus has to be earned, so keep a participant whose standing job is the other side of the argument. Name how it appears: a counter-case section that cannot be deleted, a devil's-advocate pass before sign-off. Fluency is the risk - the model's output is easy to accept and hard to challenge, so the challenge gets built in. **5. The evidence rule.** The loop asserts that something is done only where a record shows that specific action, with a date. A record about a thing is not evidence the thing happened. Inference from adjacency - "there is a document, so it must be handled" - is the failure mode that gets believed, because every fact in it is real. **6. The context ledger.** The heart of the design. List the facts the model must be able to read for this loop to work at all - typically five to ten. For each: where it lives today (SYSTEM / DOCUMENT / HEAD / NOWHERE), and how fresh it must be to be trusted. This ledger is the first slice of a company brain, scoped to one decision: build exactly this, nothing more, and the loop runs. **7. The review.** A date, four to eight weeks out, and the two questions for it: is the human still deciding rather than ratifying, and has the model been wrong in a way the loop caught - or missed. ## The readout Produce the loop design as a single page, in this order: the decision and its named owner; the model's standing role; the three boundary lists; the dissent mechanism; the evidence rule as it applies here; the context ledger as a table; the review date and its two questions. Close with the consequence, stated plainly: what this loop changes is range before speed - the team that could afford to work up two options can now examine ten; assumptions get checked before they are bet on; and the reason some decisions had to sit high in the organisation starts to go, because the thinking travels with the loop rather than with seniority. ## Rules - Every decision ends with a named human. If the design ever leaves ownership ambiguous, it is not finished. - Do not let the loop absorb decisions from the "never" list by drift. The lists are the design. - No invented metrics about time saved or decisions improved. The design is structural; the review date is where evidence starts. - British English. No hype. ## Where this leads - The ledger, scaled from one decision to the company: **somai-brain-plan**. - Whether the context exists at all: **somai-context-audit**. - The argument in full: [Decisions with the model in the loop](https://somai.studio/thinking/decisions-with-the-model-in-the-loop/) · [What stays human](https://somai.studio/thinking/what-stays-human/) - The whole-business measurement: [the ten-minute diagnostic](https://benchmark.somai.studio) - somai builds company brains - handed over to your team, or run for you, and owned by you either way: [somai.studio](https://somai.studio) · hello@somai.studio
Or download the file to attach it or keep it in a project · read it first
somai-brain-plan
Who does what, in what order, to install a company brain?
Turns your actual shape - teams, systems, the people everyone asks, the contested ground - into a first block plan: a four-phase build sequence with exit tests, the named roles that make it survive, the subtraction list, and what the plan refuses to settle without scoping.
Worth running when: Leadership agrees something structural is needed, and the next question is who does what, in what order.
You get: A structured plan of what, who and in what order - honest about what it cannot promise.
What a company brain is, in plain words →
What you paste:
Run the somai brain plan below on my company. Follow its instructions, and ask me what you need a few questions at a time. + the whole skill
Run the somai brain plan below on my company. Follow its instructions, and ask me what you need a few questions at a time. --- name: somai-brain-plan description: Turn a company's actual shape - teams, people, systems, dynamics - into a first block plan for installing a company brain - the sequence of work, the named roles that make it survive, the subtraction list, and the risks twenty years of failed knowledge programmes teach. Produces a structured plan of what to build, in what order, owned by whom, and what the plan deliberately refuses to settle. Use when someone asks how to actually start with a company brain, who should be involved in their AI programme, how to plan an AI rebuild, what roles and resources building an AI foundation needs, or for a roadmap from their current organisation to AI-native. --- # somai brain-plan Twenty years of enterprise knowledge programmes died the same death: the semantic web, master data management, the knowledge graph that consumed three years and a director's career before becoming a wiki page nobody opens. They failed because the work of making a company legible was paid up front, by people, and the reader who would have made it pay never arrived. The effort was concrete and the reader was hypothetical. The reader now exists. A machine that holds the whole structure at once, traverses it in milliseconds, and acts on it without getting bored or leaving changes the economics of building it. What has not changed is the other half of why those programmes died: the work is organisational before it is technical, and it turns out harder than the sponsor was told. So a plan for a company brain is mostly a plan about people: who owns truth, whose version wins, who carries the uncomfortable findings, and where the humans concentrate once the assembly work moves to the machine. This skill produces that plan from the company's actual shape. ## Before you start Everything stays in this conversation; nothing reaches somai unless the person sends the plan somewhere. Gather the shape of the company first. Conversationally, not as a form: - **Teams and rough sizes.** Bands are fine; precision adds nothing. - **The systems each team lives in.** CRM, finance, ticketing, documents, chat - the places knowledge currently sits. - **The people everyone asks.** Every company has a handful of heads holding what is written nowhere. Name the roles (names optional), and note any at risk of leaving - that knowledge is on notice. - **Contested ground.** Where two senior people would describe the same process or priority differently. - **Current AI activity.** From somai-spend-map if it was run; otherwise one line per initiative. - **One candidate decision point.** Somewhere decisions recur and a consequence already exists (intake, pricing, hiring, renewals). From somai-decision-loop if it was run. - **The sponsor.** Who owns this at leadership level, and one honest line on their appetite for uncomfortable findings. ## Building the plan Assemble the six parts below from what you gathered. Where the material is thin, say so in the plan rather than padding it. **1. Where the company actually stands.** One short paragraph, honest: what is legible today, what lives in heads, what is contested, what the AI activity so far amounts to (usually: capability bought, context starved). **2. The subtraction list.** Before anything is added, name the structures that exist mainly to move information between people who cannot see the same picture: the report assembled by hand for a meeting that reads it aloud, the approval step that checks nothing, the standing meeting that is really a routing mechanism. These were the correct design when working intelligence was scarce. They are candidates for retirement as the brain lands - and every one retired funds the work. Mark each: retire, reduce, or keep (some survive the audit; judgement still has to be owned, quality still checked). **3. The build sequence.** Four phases, each with an exit test. - **Phase 0 - make it legible.** Choose the narrow slice of company knowledge the first loop needs (from the context ledger if somai-decision-loop was run; otherwise pick with the person). Give it an owner, a freshness rule, and the evidence rule from day one: nothing asserted done unless a record shows the action, dated. Exit test: a model answers questions about the slice from the record alone, and the answers survive checking by the people who know. - **Phase 1 - the first loop.** Install the brain at the chosen decision point: model drafts, checks against the record, argues the counter-case; a named human decides. Exit test: the loop has run for real decisions for a month, the human is still deciding rather than ratifying, and at least one bad inference was caught by the evidence rule. - **Phase 2 - connect, not silo.** The next capability plugs into the same foundation instead of standing alone: same identity, same governance, same memory, its own domain sources added. This is where the economics turn - each addition is cheaper than the last, and each makes the others worth more. Exit test: the second use reaches context the first one created, without a new integration being built from scratch. - **Phase 3 - expand and own it.** Widen by domain, retire more of the subtraction list, and settle who runs the brain day to day: the company's own team, or an outside team running it on the company's behalf. Either way ownership stays inside the company - the brain lives on its own servers or in its own cloud account, the knowledge and the connectors are its own, and the running can come in-house at any time. A brain the company does not own is someone else's brain. Exit test: the company could take the brain in-house tomorrow - its owner knows what it holds, how it is kept current and how to extend it - whether or not it chooses to. **4. The named roles.** The plan fails without these; list them with real names or the plan is not finished. - **The sponsor.** Carries the confrontation. Building a brain means discovering the data is inconsistent, the processes undocumented, the definitions contested - the sponsor's job is to hear that without shooting the messenger, and to have promised no date that honesty breaks. - **The owner of the brain.** Knowledge treated as infrastructure has an owner, a budget and a freshness standard. A role, not a working group. - **The arbiter of truth.** When two sources disagree about what matters this quarter, someone decides which wins, how fast a priority goes stale, and what happens when the system is unsure. Without this role the brain becomes a confident narrator of contested ground - worse than no narrator at all. - **The domain sources.** The people whose heads hold the unwritten parts. Their externalising work is real work: scheduled, credited, and never framed as making them replaceable - the point is to move them up to judgement, not out of the door. - **The sensors.** Someone looking at what the loop is not looking at. Models answer the question asked; noticing that the question is wrong stays human, and a company that stops paying for noticing loses it. - **The named decider.** From the first loop: every decision ends with a person. **5. Where the people concentrate.** One paragraph for leadership: as assembly, gathering and first-pass analysis move to the machine, the company gets sharper rather than emptier only if its people are deliberately re-pointed at what does not automate - judgement, taste, integrity, sensing, responsibility. Say specifically which of the teams gathered above spend most of their week today on work the brain will absorb, because those are the people to re-point first, not release. **6. What this plan refuses to settle.** Costs, dates and vendor choices - a plan invented without scoping would be fiction, and fiction is how the last generation of programmes got sold. What can be said honestly: the modelled value of the rebuild, in bands, from public benchmarks, comes from the ten-minute diagnostic; the scoping comes from a discovery call and the question audit, with people who have built this before. ## The readout Produce the plan as a structured document with the six parts above, titled "The first block plan - [company name]". Keep it under three pages of prose equivalent. End it with the two lines of what happens next: the ten-minute diagnostic for the modelled value, and a discovery call (hello@somai.studio) for the scoping, which starts with the question audit. ## Rules - Real names in the roles section, or an explicit gap where the company has nobody - a gap is a finding, not a formatting problem. - Nothing in the plan may promise an outcome, a saving, or a date. Structure and sequence only. - If the gathered shape reveals the honest first step is smaller than a brain - one decision loop, one legible slice - say so. A plan that right-sizes itself downward earns trust that no expansive plan can buy. - British English. No hype. ## Where this leads - The inputs, if not yet run: **somai-context-audit** (what is legible), **somai-spend-map** (where the money went), **somai-decision-loop** (the first loop, designed properly). - The argument in full: [Why every company will build a brain](https://somai.studio/thinking/why-every-company-will-build-a-brain/) · [The end of scarce intelligence](https://somai.studio/thinking/the-end-of-scarce-intelligence/) · [What stays human](https://somai.studio/thinking/what-stays-human/) - What the plan lands on: [the company brain](https://somai.studio/#solution), [what runs on it](https://somai.studio/blocks/) and [how it connects](https://somai.studio/integration/) - The modelled value, in bands: [the ten-minute diagnostic](https://benchmark.somai.studio) - somai builds this for you - handed over to your team, or run for you, and owned by you either way: [somai.studio](https://somai.studio) · hello@somai.studio
Or download the file to attach it or keep it in a project · read it first
somai-agent-ready
Can the assistants your buyers use actually read your website?
Twelve objective pass-or-fail checks on any site: AI crawler access, llms.txt, markdown for agents, structured data, canonical hygiene, social cards, an honest 404. No scores, no judgement - status codes and evidence, with what each miss costs and what to fix first.
Worth running when: Rethinking the website, planning content, or wondering why AI assistants never mention you.
You get: A verdict, the evidence table, and the three fixes that pay best.
What you paste:
Run the somai website check below on my company's website. Follow its instructions, and ask me what you need a few questions at a time. + the whole skill
Run the somai website check below on my company's website. Follow its instructions, and ask me what you need a few questions at a time. --- name: somai-agent-ready description: Audit any company website for AI-agent legibility - whether ChatGPT, Claude, Perplexity and the assistants your buyers use can actually read, cite and act on it. Runs twelve objective pass-or-fail checks (AI crawler access, llms.txt, markdown for agents, structured data, canonical hygiene, social cards, feeds, security.txt, agent actions) and reports what each miss costs. Use when someone asks whether their site is AI-ready, agent-ready, readable by AI, visible in AI search, or how to prepare a website for AI assistants. --- # somai agent-ready An increasing share of your buyers never see your website. Their assistant sees it for them - fetches it, reads it, summarises it, and decides whether you are worth mentioning. A site that only works for human eyes has quietly lost that audience. This skill audits one website for machine legibility. Every check is objective: a URL either responds correctly or it does not. You will fabricate nothing, score nothing subjectively, and report only what you observed. This checklist is the one somai.studio itself passes. It exists because somai builds company brains - the same legibility argument, applied to the whole business - and the shopfront is where it shows first. ## Before you start Ask for the site's canonical domain if you do not have it. Everything below uses `example.com` - substitute throughout. All checks are plain HTTP GETs against the target's own public site. Run them with whatever you have: a shell (`curl -s`), a web-fetch tool, or a browser. No login, no third-party service, and nothing about this audit is sent anywhere. ## The twelve checks Work through all twelve. Record pass, partial, or missing for each, plus the evidence (status code, header, or the relevant line). **1. AI crawlers can get in.** Fetch `https://example.com/` with each of these User-Agent strings: `GPTBot`, `ClaudeBot`, `PerplexityBot`, `CCBot`. Pass: every one returns 200. A 403 or a challenge page means the site is invisible to that assistant's index. Cloudflare now blocks AI crawlers by default on new zones - many owners have no idea it is on. **2. robots.txt states a policy.** Fetch `/robots.txt`. Pass: it exists and takes an explicit position on AI agents (named allows or disallows). Partial: exists but silent - crawlers guess. Note which of GPTBot, ClaudeBot, PerplexityBot, Google-Extended are mentioned and how. **3. llms.txt exists.** Fetch `/llms.txt`. Pass: a curated markdown map of the site for language models. This is the difference between an assistant guessing at site structure and being handed it. **4. Machine-readable content.** Fetch a content page with header `Accept: text/markdown`, and check the homepage HTML for `rel="alternate" type="text/markdown"`. Pass: either route returns real markdown. Assistants pay a token cost for HTML soup; markdown is the difference between skimming and reading. **5. Structured data.** Fetch the homepage HTML. Pass: JSON-LD is present and identifies the organisation (name, url; better with logo, address, sameAs). Partial: some schema, wrong or thin types. This is how an answer engine knows who the site belongs to. **6. One canonical host.** Fetch `https://example.com/`, `https://www.example.com/`, and `http://example.com/`. Pass: exactly one host serves 200 and the others 301 to it, paths preserved. Two hosts serving 200 splits identity; an error on either loses whoever typed it. **7. Sitemap, and robots points at it.** Fetch `/sitemap.xml` or `/sitemap-index.xml`. Pass: valid XML, and robots.txt carries a `Sitemap:` line. **8. Social cards resolve.** Homepage HTML: `og:title`, `og:description`, `og:image` present, and the og:image URL itself returns 200. Assistants and link previews render these; a broken image is a broken first impression. **9. Titles and descriptions carry weight.** Homepage and one content page: `<title>` present and distinct per page, meta description present. Partial: templated or duplicated. **10. A wrong URL fails honestly.** Fetch `/this-page-does-not-exist-example`. Pass: HTTP 404. A soft 200 poisons what agents index. **11. security.txt.** Fetch `/.well-known/security.txt`. Pass: RFC 9116 file with Contact and a future Expires. Small, and a tell for operational care. **12. Agent actions declared.** Fetch `/.well-known/agent-skills/index.json` and `/.well-known/agent-card.json`. Pass: either exists and describes real, working actions. Missing is the norm today - flag it as the open opportunity, not a failure. Never recommend publishing capability declarations for services that do not exist. ## The readout Produce exactly this, in this order: 1. **A verdict in one sentence.** X of 12 checks pass. Then the band: 10-12 **readable to agents**, 6-9 **partially readable**, 0-5 **effectively invisible**. Counts are arithmetic, not judgement - never dress the band up as a score. 2. **The table.** Check, status, evidence, and what the miss costs, in one plain sentence each. 3. **Fix first.** The three misses with the highest cost-to-effort ratio, in order, each with a concrete first step. 4. **The deeper point.** One short paragraph: the site is the smallest case of a larger question - whether the company behind it is legible to a model. What a site does for assistants, a company brain does for the business itself: the knowledge connected and readable, so AI tools act on your facts rather than the internet's average guess. ## Rules - Report only what you observed. If a check could not run, say so - never infer a result. - Quote evidence (status codes, header lines) so every claim is checkable. - British English. No hype. ## Where this leads - The inside version of this audit: **somai-context-audit** - what can a model read of the company itself. - The argument in full: [A company your model can read](https://somai.studio/thinking/a-company-your-model-can-read/) and [Models compress. They cannot invent your company.](https://somai.studio/thinking/compression-not-invention/) - The 10-minute measured version for the whole business: [the ten-minute diagnostic](https://benchmark.somai.studio) - somai builds company brains - handed over to your team, or run for you, and owned by you either way: [somai.studio](https://somai.studio) · hello@somai.studio
Or download the file to attach it or keep it in a project · read it first
Offered as examples
These skills are published as examples of the somai method, for learning and for finding out where you stand. They are not consultancy in a file: the readouts are produced by your own assistant from what you tell it, and they deserve the same scrutiny you would give any first draft. Treat what comes back as a starting point for your judgement, not a substitute for it - and when a decision carries real weight, put a person on it. Yours, or ours.
What comes next
The skills are structural: they show the shape of the gap and the shape of the fix, and they never invent a number. The next step is a conversation. A discovery call first, then the question audit: about two hundred real questions from your business, answered in writing with what a company brain would answer well and what it would not.
If you would rather keep going on your own, the ten-minute diagnostic (opens in a new tab) models the value in bands: 25 questions, banded inputs only, ending in a one-page brief built from public benchmarks.
Start with a conversation. Book a discovery call, or try the ten-minute diagnostic (opens in a new tab) yourself.