Superintelligence Steering Committee: A Charter for Company AI

A superintelligence steering committee, in practical terms, is a small standing group that decides how a company's most capable AI systems may act, who approves changes to them, and what evidence it reviews before extending their reach. Most mid-sized companies do not need a large membership or a long mandate. They need a one-page charter that names the decisions the group owns, the approval level attached to each kind of action, and a fixed set of items reviewed every quarter.

Key takeaways

• A charter should fit on one page and name the decisions the group owns, not just the topics it may discuss.
• Assign approval levels by consequence: what an agent can read, change, send, spend or commit on the company's behalf.
• Keep membership small and give each seat one accountability that cannot be delegated away.
• Review the same short evidence pack every quarter: permissions, incidents, evaluation results, changes and open risks.
• Reopen the charter when an agent gains a new tool, memory source or channel, not only when the calendar says so.

Why a company AI steering group needs a written charter

Companies usually discover the governance problem sideways. A sales team connects an assistant to the customer records, an operations lead adds a tool that writes to a shared folder, and months later nobody can say who approved the access or who answers when the output is wrong. A steering group stops that drift. A charter converts an informal conversation into a standing duty with defined limits.

The word superintelligence describes where the field may be heading, but the governance task for a company is concrete now. The systems you run have memory, tools, permissions and operating context, and each of those changes what the company can do. The NIST AI Risk Management Framework treats governance as an ongoing function rather than a one-time sign-off. A charter is the simplest document that makes that function real, because it names who decides, on what basis, and when the decision is revisited.

Who sits on the committee and what each seat owns

Keep the group to four or five people. A typical composition includes an executive sponsor with final authority over scope and budget, an operations leader who owns the processes agents touch, a technology lead responsible for integrations and access, a finance or risk representative who reviews spending and exposure, and someone accountable for data and legal questions. Smaller companies may combine seats, but only where the same person can answer for both accountabilities.

Give each seat one thing it owns outright. The sponsor owns the final call on what an agent is for. The operations leader owns the success criterion and acceptance tests for each role. The technology lead owns the permission map, which lists every tool, memory source and channel an agent holds. When a seat has no clear object of ownership, the committee tends to become a meeting that approves whatever arrives. For a broader view of how governance fits a company of this size, see AI Governance for Companies: A Lightweight Start for Mid-Sized Firms.

Decision rights: what the group decides and what it does not

Decision rights say who may make which decision. Write them as verbs, so each one can be checked. The committee should hold the following rights:

• Approve a new agent role together with its success criterion.
• Approve any new tool connection, memory source or outbound channel.
• Set the approval level that applies to each class of agent action.
• Pause or retire an agent after an incident or a failed review.
• Accept the quarterly findings and assign a named owner to each remediation item.

The committee should not hold day-to-day task routing, routine prompt adjustments within an approved role, or exceptions for individual tickets. Those belong to the named agent owner, who reports them in the quarterly pack. Keeping this line clear prevents the committee from becoming a bottleneck and keeps its attention on decisions that change what the company is exposed to.

Approval levels: a decision guide for agent actions

Approval levels should follow consequence, not the technology used. A workable scheme has four levels, and each agent action should be mapped to exactly one of them.

• Level one, read and draft: the agent reads approved sources and produces internal drafts. The agent owner approves the role once, and no individual action needs sign-off.
• Level two, reversible internal change: the agent updates internal records that can be restored from a known state. The owner reviews the change log at the end of each week.
• Level three, external or committed action: the agent sends messages outside the company, commits spending or alters a customer-facing record. A named person approves each instance or a defined batch.
• Level four, restricted: anything involving personal data, pricing commitments, contract terms or credentials. The committee approves it in writing, with a rationale and an expiry date.

Access should follow least privilege, and each action should be checked against the permission granted to that role rather than assumed from earlier use. The OWASP Authorization Cheat Sheet is a useful reference for the questions to put to the technology lead.

Illustrative scenario: a regional services company gives its agent read access to service histories and permission to draft replies to customers. The committee places drafting at level one and sending at level three, so a named coordinator approves each message. After the first quarterly review shows that the drafts need few edits and the incident log is clean, the committee moves one narrow category of routine confirmations to batch approval. The change is recorded, dated and reviewable.

What the group reviews each quarter

The quarterly meeting should be short and built on evidence. Ask each owner to bring the same pack every time, so that trends are visible and nobody relies on memory. The standard pack should contain the following items:

• The permission map, comparing each tool, memory source and channel an agent holds against what its role requires.
• Incidents and near misses, including how each was detected and whether the approval levels worked as intended.
• Evaluation results against the success criterion from the original engagement, measured on the same test set so that changes are comparable.
• Every approved change, its reason, and whether it was later reversed.
• Usage and cost, read as unit economics against the expectations of the budget owner, following the approach described by the FinOps Foundation.
• Open risks, including prompt injection exposure from external documents or web pages, which the OWASP prompt injection prevention guidance covers in practical detail.
• Each decision taken, with its owner and its next review date.

For a step-by-step version of the permission part of this pack, see Quarterly AI Agent Permission Review: Steps and Evidence.

How to write the charter on one page

A good charter is short enough to be read before every meeting. Work through it in this order:

• State the purpose in two sentences: which agents the committee governs and why the company needs a standing group.
• List the members by seat, with the single accountability each one holds.
• Write the decision rights as verbs, and separate the committee's decisions from routine operations.
• Attach the four approval levels to action types, using examples drawn from your own processes.
• Set the quarterly agenda and the evidence pack, naming the owner of each item.
• Define an emergency path: who may pause an agent between meetings, and how that pause is recorded and reported.
• Set a review date for the charter itself, along with the events that reopen it early, such as a new tool connection or a new agent role.

Store the charter next to the permission map and version it like any other operating document. When a team asks for a new capability, route the request through the same documented path so the committee sees what changed and why. The process is described in How to Request and Approve Changes to a Managed AI Agent.

How Be Human's managed approach supports the committee

Be Human designs, implements and operates personalized AI infrastructure in which each agent keeps its identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which gives the committee a concrete object to govern rather than a general ambition. Managed operations then provide monitoring, recurring evaluations, permission review, incident response and controlled improvements. Those records form the evidence pack the group reviews each quarter, so the meeting works from what the agent actually did. Changes follow a documented request path, so the committee sees every alteration to permissions, tools or approval levels.

If you are not yet sure which task should come first under a charter like this, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

How often should a superintelligence steering committee meet? Quarterly is a sound default for the standing review, with an extra session when an incident, a new tool connection or a new agent role requires a decision. Between meetings, the sponsor and the technology lead should hold a defined power to pause an agent, and record that pause in writing. Short written decisions usually carry more weight than long meetings.

Does a small company need a steering committee at all? A small company may need only a sponsor and one technical owner who maintain a short charter. The core need stays the same: a written list of decisions, approval levels and a regular review of what agents can access. Combining seats is acceptable where one person can answer for both accountabilities.

Who should chair the committee? The executive sponsor is usually the better chair, because that role carries final authority over scope and budget. The chair sets the agenda and makes sure every decision is recorded with an owner and a review date. The technology lead should attend every meeting, since access questions are often settled there.

What should happen when the committee disagrees? Record the disagreement and the options considered, then let the sponsor decide within the limits of the charter. If the question involves a level four action, require a written rationale and an expiry date for the approval. Revisit the decision at the next quarterly review, using the evidence the group gathered in the meantime.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.