Update to Kowalah

{
  "description": "Review and maintain the organisation's AI estate — which AI tools and platforms it actually has, what people have built and switched on in them (connectors, skills, plugins, projects, agents), how each is held (licences, seats, contracts, DPAs), which are unsanctioned or risky, what renews soon, and where each is used in the business. Use for \"what AI tools do we have\", \"what's our shadow AI\", \"which tools train on our data\", \"what renews this quarter\", \"is ChatGPT approved\", \"add Granola to the register\", or any audit of AI tools and licences.",
  "included_files": [],
  "name": "ai-estate",
  "skill_md_contents": "---\nname: ai-estate\ndescription: Review and maintain the organisation's AI estate — which AI tools and platforms it actually has, what people have built and switched on in them (connectors, skills, plugins, projects, agents), how each is held (licences, seats, contracts, DPAs), which are unsanctioned or risky, what renews soon, and where each is used in the business. Use for \"what AI tools do we have\", \"what's our shadow AI\", \"which tools train on our data\", \"what renews this quarter\", \"is ChatGPT approved\", \"add Granola to the register\", or any audit of AI tools and licences.\n---\n\n# AI estate\n\nFor the AI Ops lead, the core team, the CIO or whoever is accountable for which AI the\norganisation uses. The first question they have to answer is **what have we actually got**,\nand the second is **what should we worry about**. This skill answers both from the systems\nregister, and keeps the register true.\n\n## Read the register before you ask\n\n**`kowalah_get_systems`** returns the register: every system, whether it has AI in it,\nhow the organisation holds it (arrangements), how many live process steps use it, and a\n`flags` block. Pass `ai_only: true` for the AI Register view. Read it first, and ask the\nuser only about what it doesn't hold.\n\nA register that looks short is usually a finding in itself. If the organisation plainly\nuses tools that aren't recorded (the ones you can see connected in this session are a good\nfirst check), say so before reviewing what is there.\n\n## Read the flags in this order\n\n1. **`risks`**, highest severity first. `employee_contracted` is the one that matters most:\n   a personal plan used for work means no DPA, no admin control and no audit trail. That is\n   shadow AI, and it is the headline. `trains_on_data` without `dpa_in_place` comes next.\n   `prohibited_in_use` means a tool the organisation banned is still held.\n2. **`unreviewed`** — arrangements nobody has made a decision on. Unreviewed is not\n   approved. Count them and say so.\n3. **`ai_without_arrangement`** — AI the organisation uses with no record of how it holds\n   it. Each one is a question: who pays, on what plan, under what terms?\n4. **`not_in_model`** — systems in the register that no process step runs on. Either the\n   work that uses them hasn't been mapped, or it's shelfware. Both are worth saying.\n5. **`renewals_due`** (admins and core team only) — renewals in the next 90 days. Pair each\n   with its risks and its usage: a renewal is the moment to fix an arrangement, and a tool\n   used in no step is a candidate not to renew.\n\n**A null is \"not assessed\", never \"no\".** `dpa_in_place: null` means nobody has checked,\nwhich is different from `false`. Report unassessed fields as gaps to fill, not as passes.\n\n## What's been built and switched on\n\nThe systems register says which products the organisation holds. **`kowalah_get_ai_estate`**\nsays what's deployed inside them: connectors, skills, plugins, projects, agents, automations\nand apps, who uses each, and the process steps they run. Read its `gaps` first:\n\n- **`unsanctioned`** — assets on a platform the organisation hasn't approved or has\n  prohibited, personal ones first. This is the shadow-AI list, and it joins the two\n  registers: a personal Gmail connector on an unreviewed Claude plan is one line here.\n- **`personal`** — one person's own tools used for work, with their platform's standing.\n- **`undecided`**, **`no_owner`**, **`scope_unknown`** — what nobody has decided. Admins and\n  core team settle these with `kowalah_record_ai_assets` (by `id`: owner, status, scope).\n- **`not_in_model`** — agents, skills, automations and apps that run no process step. Either\n  the step hasn't been mapped or the tool isn't earning its keep.\n- **`needs_auth`** — connectors installed but never connected, or disconnected.\n- **`stale`** — nobody has shared it from their session for 90 days: likely retired.\n- **`suggested_step_links`** — steps whose text names an agent, skill, automation or app\n  that isn't linked to them yet (\"Brian drafts the reply\"). Confirm each with the process\n  owner, then link it with `kowalah_record_ai_assets` (`id` plus `serves_step_ids`). This is\n  the quickest way to turn the free-text model into one that knows what runs each step.\n- **`platform_unknown`** — assets with no platform, so the shadow-AI check can't see them.\n  Usually the platform isn't in the systems register yet: add it with `kowalah_save_system`,\n  and the next `my-ai-tools` run links everything on it.\n- **`reaches_unregistered`** — connectors to a system the register doesn't hold (Figma,\n  Sentry). Add the system if the organisation depends on it.\n- **`acts_unsupervised`** — connectors that `can_act` (send, edit, delete) with no human\n  approving. This is the one to read out first after shadow AI: ask whether anyone signs\n  off on what it does, and record the answer as `human_approval`.\n- **`connection_concentration`** — one person's login holds three or more of the\n  organisation's connectors. If they leave or their account is locked, all of them stop at\n  once. Admins and core team see who; members see only counts.\n- **`in_house`** — what the organisation built itself. Nobody outside maintains these, so\n  each needs a named owner and a `maintained_at` home (a repo or a folder).\n\nEach asset also shows its `origin` (anthropic, kowalah, vendor, in_house, unknown), its\n`version` and where it's `maintained_at`. Sessions fill these in when they can see them.\nHow each is held is a decision, set by admins and core team with\n`kowalah_record_ai_assets`:\n- `connection_holder_user_id`: whose login the connector runs on. A member can say their\n  own connector runs on their own login.\n- `access_level`: `read_only` or `can_act`\n- `human_approval`\n\nLeave any of these unset rather than guessing. An unknown access level is a gap, not\nread-only.\n\nEach asset shows its `platform` and, for a connector, the systems it `reaches`. Pass\n`unit_id` to see one part of the business, or `origin` to see, say, only what was built in\nhouse.\n\n**What each tool has delivered.** Every asset carries an `outcomes` count, and `id` returns\nthe outcomes themselves with totals. An agent that runs live steps and has no outcomes\nhasn't been shown to earn its keep: before a renewal or a retirement, ask its owner what it\nhas delivered, and record it with the `outcomes` skill.\n\n**Assets no assistant session can see** — agents on the Agent Hub or a model API, Zapier or\nn8n automations, Copilot agents, Slack bots — are added by hand: `kowalah_record_ai_assets`\nwith `source: \"manual\"`, the kind (usually `agent` or `automation`), and the `system_id` of\nthe platform it runs on. Then link the steps it runs.\n\n**The register is only as complete as the people who have shared their tools.** It is\nfilled by the `my-ai-tools` skill, which each person runs in their own assistant: it shows them\ntheir setup, fixes what's half connected, and records what they choose to share. There is\nno background collection. If the register is thin, or `stale` is long, the fix is to ask the\nteam to run `my-ai-tools` (a one-line message from the AI lead is usually enough), not to\nfill the register by guessing. If it's complete but nobody has said what things are for,\nask the owners of the live, organisation-wide tools to run its part two.\n\n## Where each tool is used\n\n`kowalah_get_systems` with an `id` returns `used_in`: every live step and process that runs\nthrough that system. This is what makes the register more than a list: \"Claude is used in\n12 steps across 4 processes\" tells the reader what a problem with Claude would touch. Use it\nwhen a risk is serious, before a renewal, and whenever someone asks what a tool is for.\n\nWhen a step runs on a tool but the step doesn't say so (the tool is named only in\n`platform_detail`, or not at all), set `system_ids` on `kowalah_save_process_step`. It\nreplaces the whole set, so pass every system the step uses.\n\n## Keeping the register true\n\n**`kowalah_save_system`** adds or updates a system and its arrangements. Admins and core\nteam only; for anyone else, read the register and offer `kowalah_create_opportunity` for\nthe change.\n\n- Search before adding (`kowalah_get_systems` with `search`). Saving a name that's already\n  in the register returns the existing system rather than a duplicate, and a name in\n  Kowalah's catalogue uses the catalogue system: record the organisation's arrangements on\n  it. Only pass `own_copy: true` when the organisation needs its own record, for example to\n  mark a catalogue CRM as having `embedded` AI switched on.\n- **One system, several arrangements.** \"Claude Team, 50 seats, organisation-contracted,\n  DPA in place, approved\" and \"Personal Max plans, employee-contracted, unreviewed\" are two\n  arrangements on one system. Don't create a second system for the second way of holding\n  it.\n- **`ai_capability`** is a spectrum, not a yes/no: `embedded` for AI switched on inside a\n  non-AI product (Slack AI, HubSpot Breeze), `native` when the product is AI (Claude,\n  ChatGPT), `infrastructure` for model or API access (Claude API, Azure OpenAI). `embedded`\n  is the category people forget, and it is often the largest.\n- Record only what the user actually knows. Leave the rest unset rather than guessing, and\n  never set `sanctioned_status` to approved on the user's behalf: only the organisation can\n  approve a tool.\n- Retire a tool with `status: \"archived\"`; systems are not deleted.\n\n## What a good review says\n\n1. **What the organisation has** — the count of AI systems and how they're held, what has\n   been built in them, and what's plainly missing from either register.\n2. **What to worry about** — the risks, named, with where each tool is used; what acts\n   with nobody approving; whose single login everything depends on.\n3. **What nobody has decided** — the unreviewed arrangements and the unassessed fields.\n4. **The next decision** — usually a renewal, a tool to approve or retire, or a register to\n   complete. Name who has to decide.\n\n## Scope and permissions\n\nEveryone in the organisation can read the register. Cost, payment route and renewal dates\nare shown to admins and core team only; the response's `commercial_fields` says which you\ngot. If they're hidden, say so rather than implying the organisation has no costs recorded.\n\nIf the user belongs to more than one Kowalah organisation, pass `organization_id`. Call\n`kowalah_get_update` with no query to list their organisations, then ask which one.\n"
}