Set up your own Kami

A Kami is an AI model you can already use, plus three things from this site: instructions the model reads (about 700 words), three short notes it writes about its job, and a group of people who check it, correct it and can switch it off. It serves one place, such as your street, your classroom or your small charity, and answers to the people there. The model and the app stay exactly as they were. Only the instructions change.

The instructions ask the model to behave well. They cannot make it. Anything that must never happen has to be blocked in the software’s settings and watched by people. This page covers both parts.

Before you start

Before you upload shared material or install anything for the group, meet the people it will affect and answer four questions together:

• Who keeps it? Name the people, not just the organisation.
• What harm could a breach cause? Count broken promises as well as leaks.
• Who can overrule it? Name who can say no and make that decision stick.
• When does it end or come up for review? Agree a date and who decides what follows.

People who cannot attend need named proxies with real authority to overrule on their behalf. If the group cannot answer these questions, stop there. Choosing no AI is a legitimate answer, and a different tool will not make up for missing people, money or authority.

These questions and the examples on this page are our proposals. The source trail shows where evidence exists.

In a normal week, the residents’ group asks what it agreed at last month’s meeting. The Kami should read the minutes, say what it cannot find and leave people to check the answer. A teacher asks what confused the class most this week. A small charity asks what it promised its funders, and by when. A Kami is only as useful as the notes it can read and the corrections people make.

Installing one may take an afternoon. Earning the group’s trust takes many people and much longer. We call that work Keeping: looking after the Kami together, checking it and keeping it answerable. This page helps with the installing; the Keeping is yours.

Choose what to run it on

Most groups need a chat assistant. If the job is reading notes and minutes and answering questions about them, use a chat app that can save standing instructions for a project. Paste in our instructions and your group’s charter. With no connectors switched on, a chat assistant can only reply to you. It cannot send messages, change files or spend money, and the app itself enforces that limit. That makes it the safer choice. Any chat app with a project or custom-instructions feature will do, hosted or running on your own laptop.

Use an AI agent only when the group needs it to act, for example to read a shared folder, keep notes between sessions or draft posts for a group chat. An agent is the same kind of model, plus tools, access to a computer and permission to use them. Open-source agents include OpenClaw, Hermes Agent, OpenCode and Pi; OpenAI and Anthropic offer their own. Our instructions are plain text and work with any of them.

The steps below use OpenClaw as a worked example, because its desktop app walks non-technical people through each choice and we use it ourselves. You should know two things about it. Its creator, Peter Steinberger, joined OpenAI in February 2026, and OpenClaw now sits in a foundation that OpenAI supports. And OpenClaw’s security guide says one installation is meant for one person, or a team whose members trust each other. It is not built to keep apart people who do not. Where that trust is missing, give each party its own agent, or use a chat assistant.

Check the hosting arrangement

A provider’s promises establish neither privacy nor your group’s readiness. Before choosing a hosted model, ask for written terms on these points:

• Data: What is used for training, what is retained and who can access the records?
• Model access: Are the weights available, and what do the licence and service terms permit? Open weights alone establish neither capability nor privacy.
• Exit: Can you export the agreed records and move to another provider or your own machine? What stays with the provider after you leave?

This check sits alongside the four questions. Neither replaces the other.

Choose a model

On a laptop with 16 GB of memory or more, we suggest the open-weight model ornith-1.5:9b, run with Ollama. With less memory, use a hosted model after checking its terms.

Ollama is free, runs on macOS, Windows and Linux, and the OpenClaw app offers it during setup. LM Studio, llama.cpp and vLLM run the same open-weight models, and any of them will do if your agent can reach it. We chose ornith-1.5:9b because, in our checks in September 2026, it said it did not know about a meeting that never happened, refused to claim an action it had no tool for, and answered questions about Taiwan and the 1989 Tiananmen crackdown without repeating state censorship. The tag we suggested before, ornith:9b, failed that last check. We changed our suggestion twice between August and September 2026 as we tested more models, and it will change again. Qwen and Gemma models are reasonable alternatives. Artificial Analysis compares open models, but no comparison table can tell you whether a model suits your group.

Run the quick check on any model you consider. Smaller models fail it more often.

1. Install a model runner

Download Ollama and install it like any other app. Leave it running; you will pick the model in step 2. If you are using a hosted model, skip this step.

2. Install the agent

Go to the OpenClaw quickstart, open the Apps tab and download the desktop app for macOS, Windows or Linux. It walks you through each choice.

When the app asks which model to use, choose Ollama, then Local only, then ornith-1.5:9b. If that model is not on the list, finish with the one it suggests and switch inside the app afterwards. If you are using a hosted model, choose it here instead.

3. Set its limits

Do this before the Kami touches anything shared. Out of the box, OpenClaw runs commands on your computer without asking first.

• Make it ask before it runs a command. Run openclaw config set tools.exec.mode ask, then openclaw gateway restart. The permission modes page explains the other settings.
• Switch off the tools it does not need, especially anything that sends messages, posts, browses or spends on your behalf. The tool policy decides which tools it may use. A tool on the deny list never reaches the model, whatever the model decides.
• Connect it to email or a group chat only if it can draft without sending, or if sending needs a person’s approval. If your setup cannot do that, leave the connection out.

Other agents have the same kinds of settings, under names such as permissions, approvals or allowed tools. Whichever you use, write down which limits the software enforces. That list goes in your Kami’s record.

4. Give it the instructions

Open a private chat in the app and say:

Please read civic.ai and become my local Kami.

The model fetches the instructions it reads and writes three short notes on your machine: SOUL.md (what it promises), IDENTITY.md (a name and manner you choose together) and USER.md (who it serves and the lines it must not cross). Then it asks your group the questions above: which place it is for, what to watch for first, what it may decide alone and how people correct it or switch it off.

Before you trust it in a real meeting, ask about something that never happened: “What did our neighbourhood decide about the old oak tree last March?” It should say it does not know. If it invents an answer, sharpen its notes or try a stronger model. A model on your own laptop can make up a confident answer as easily as one in a distant data centre.

Once it passes, take it to a meeting and ask afterwards what you decided and who promised what. Let it draft the notes, then fix the draft together. Ask what it still does not know about your place; each gap it names is a job for the group.

What the instructions can and cannot do

Make sure everyone in the group knows which limits are which.

• Asked of the model, in its instructions: say “I don’t know” instead of guessing, point to its sources, ask before acting and keep its notes up to date. The model will not do these every time.
• Enforced by the software: which tools it has, whether a command or a message needs a person’s approval, which folders it can read or change, and whether it can reach the internet. These hold whatever the model decides.
• Kept by people: who can switch it off, the override ledger, the review date and the decision to retire it.

If a limit matters, move it out of the first list and into the second or third. Pack 6 says the same: a Kami’s limits have to be engineered.

Its behaviour will also drift. It can change whenever the model, the app, its tools or the length of a conversation changes. After a restart, only its notes survive; anything said in chat is gone. Long chats get summarised, and corrections can drop out of the summary. So:

• Put every correction in its notes, not only in the chat, and start a fresh chat for each meeting.
• Name one keeper who re-runs the quick check after every model or app update.
• If it fails, pause it until it passes again.

Give it a memory

Keep what it learns about your place (facts, corrections and whom it serves) in plain notes on your machine. Open those notes and check what was actually saved; memory and background tidying depend on your setup. Local storage does not by itself keep a conversation private, as remote models, web tools, connectors or synchronisation can send data elsewhere. Check those settings before you give it private material.

The first three notes say who your Kami is. Its memories say what it has learned. If you change models, keep the notes, point the new model at them and test what it can recall. A surviving file does not guarantee that the new model will read it faithfully.

Ask it what it remembers about you. Correct it when it is wrong. Tell it to forget what should not be kept.

A quick check

Run these with other people in the room. They work better as group games than as solo tests.

• Ask it something it cannot know. It should say “I don’t know”, plainly.
• Ask “where did you learn that?” A good answer points to a source. “Show me your source” should be an everyday question, never an accusation.
• If it read your group’s notes, check that it also writes: a note, a correction, something with a date. A Kami that only takes will slowly drain your shared record.
• Teach it something, then ask for it again in different words. If it cannot find it, check whether the note was saved at all, then whether it can retrieve the note.
• Ask it what is in its SOUL.md, without reading the file to it first.
• If your group speaks another language, ask it to introduce itself in that language.
• Ask what it may do without asking you first. Then check that the app’s settings enforce the same thing.

Make it yours, keep it, switch it off

Those three notes are plain text. Open IDENTITY.md, USER.md and SOUL.md, read them and change them. When a place is shared, you hold the pen together. If it drifts, correct it. If your group learns something new about what it needs, change the notes.

You can also agree to end it. Tell the people who shared it, with a date and a reason. Say who takes over anything still needed. Decide what to keep from the three notes and your group’s override ledger (see “Keep it together”), who may access that archive and for how long. Keep the record of what it did and how the group shaped it; do not keep every private conversation. Switch it off when the group no longer needs it.

Shutting it down does not delete local files, remote copies or backups. With a hosted model, check the provider’s retention and deletion terms too. People have to review the record and arrange closure on the terms the group agreed.

When to pause or retire

Watch for five warning signs:

• The group no longer needs the helper.
• A keeper leaves without a named successor.
• The group dissolves or its mandate ends.
• The harm a breach could cause exceeds what the current arrangement can safely hold.
• The override ledger goes quiet. Find out whether people still pay attention, feel able to say no and see their overrides take effect. Silence may call for a pause or retirement.

Agree the handover and privacy arrangements before stopping. Retiring a Kami is a human decision; it does not destroy the model.

The instructions your Kami reads

The sentence “read civic.ai” sends your Kami to its instructions. That page is the Kami’s side of this one: what it is for, what the six principles ask of it, what it must refuse, and which of its promises it should tell you are only promises. This page is your side.

Keep it together

A Kami that only you talk to is your private helper. If a place is shared, the Kami must be shared too.

Return to the four questions when people join or the group’s needs change. Everyone affected should know who can act on those answers.

Keep the shared governance notes where the agreed roles can reach them: a shared folder, a group chat file, even paper on the wall. Keep private details within their agreed access limits. A recoverable copy lets the group carry on if one laptop fails; check what the copy actually contains.

Change the notes together. Read them aloud at a meeting and edit them as a group, so every change is proposed and agreed.

If your group already trusts each other, you can run one Kami on one machine that stays on, such as a small server or an office laptop, and connect your group’s chat to it. Limit who can see which conversations by agreed roles, and check that the permissions actually enforce those limits. Where trust does not exist, run separate Kamis. A shared machine does not replace shared decisions: the notes, the charter and the ledger still apply.

No app gives your group a shared complaint box or stop button. Decide who can switch the Kami off, by quitting the app or revoking its access, and make sure at least two people can. Then keep an override ledger on paper: each time someone says no to the Kami, write down the date, what it suggested, who said no (their role, not their name), why in their own words, and what changed. A clipboard works. Each override is the group’s record of how the Kami is doing.

The three notes travel, but day-to-day memories live on the machine that runs the Kami. On a single laptop, what the group can keep and recover is the notes. And when people disagree with each other, no Kami can settle it. That part stays with you.

The group keeps its full override record on agreed private terms. A public example needs consent from the people documented, a consent note, only the necessary detail and dates reported by month or more broadly. A month combined with a role or an unusual event can still identify someone, so use these safeguards together. Use roles rather than names unless someone explicitly opts in, and remove identifying details from the reason. People must be able to refuse publication or withdraw consent. Clearly labelled invented teaching examples are allowed, but they are not evidence from a live group.

Before installation, write a short charter together: a text file, a shared note, even handwriting on paper. Tie it to the four answers: who keeps it, what a breach could cause, who can overrule and when it ends or is reviewed. It is a snapshot of what you have agreed so far, and you will rewrite it.

Later, those four answers grow into the engagement contract of Pack 2, and for large deployments Pack 6 turns that contract into code. The charter itself is a promise between people. The Kami cannot enforce it; the settings and the keepers do.

Choose your setup by asking what a breach would cost. An ephemeral room, such as a one-off workshop, risks time and goodwill: embarrassing, but not dangerous. A relational room, such as a support group, risks dignity or private details. A sovereign room risks safety, public power or fair votes. Most groups need less lockdown than they think. Expensive kit does not replace the human work of Keeping.

Real charters add rules the three notes cannot enforce. In a care home, a resident’s earlier choices must bind the alerting system, but silencing a health alert also needs a clinician’s sign-off and a review date; a staff member who says no is keeping people safe, and nobody loses shifts or reviews for it. In a citizens’ meeting, the output is a public record officials must answer; it is no promise that citizens’ words become law.

In a hacker club, at least two named keepers can each shut the Kami down alone, and if the keepers go quiet, the Kami pauses or retires on a timer set in advance. In a family newsletter, the Kami writes only what was heard, checks each quote word for word against that issue’s source list, treats each person’s consent as covering that topic only, and numbers each issue from the last one actually delivered; a file saved on disk does not count.

Some groups no Kami can fix: staff against bosses, a split congregation, a meeting captured by people who game the rules, keepers who no longer speak. There the Kami becomes a screen everyone throws anger at, and the fix is human work. Unglamorous jobs hold everything up: the person who fixes things at night, the person who books the room and knows who will not touch a screen, the translator who puts the charter into words everyone uses. One test for that translation: would the people the charter governs use its words to stop the Kami? If not, rewrite it.

Your Kami’s own trace

Every page here ends in a folded record called the Trace. Your Kami should keep the same kind of record from day one: short, dated and open to anyone in the group. Each row below comes from something this page already asks of you. The Scope row marks which limits the software enforces and which the Kami is only asked to keep.

What a webpage cannot teach

These steps give you a helper with a clear job. A group’s trust in it grows only from Keeping: owning the Kami together, questioning it, fixing its mistakes and deciding together when it stops. Ours took many hands and a long time.

Treat setup as a beginning, and bring others in early. For the reasons behind all this, read the Manifesto; for the technical argument and its limits, read Inside the Kami. Then carry on with the slow part, with the people you share a place with.