Governance Meetings are where your organisation changes itself without months of planning and complex org charts. Constantly adapting to the actual landscape within the organisation. Roles are created, authority boundaries are drawn, and policies are set, all through a structured process that tests for harm rather than seeking agreement. Here is the complete format, step by step, with everything you need to run it yourself.
A Governance Meeting is a structured meeting where a team evolves the organisational structure. It is not about getting work done. That is what the Tactical Meeting is for. The Governance Meeting is about changing the rules of the game: the roles, circles, accountabilities, domains, and policies that define how work gets done.
The scope is precise. In a Governance Meeting, the team can create, modify, or remove roles. It can define or adjust policies that grant or constrain authority. It can redraw the boundaries of who owns what. It can elect people to certain roles. And subsequently, it can define or evolve the roles that AI agents fill: their purposes, accountabilities, authority boundaries, and the policies that govern their behaviour (which will be required through EU law soon).
No other decisions are valid outputs from this process. Operational decisions about specific work, strategic discussions that do not result in structural changes, or mandates about what results a role should achieve do not belong here. Governance defines the structure. The work happens within it. Another frame is that in a Governance meeting, you’re working ON the organisation, not IN it.
Traditionally, structural decisions like these are made exclusively by those in positional authority. Someone with “power over” decides who does what. An executive creates a new department. A leadership team rewrites the strategy behind closed doors. The Governance Meeting distributes that authority to every member of the team. Everyone who fills a role in the circle participates in shaping the structure they work within.
This distinction is the most important concept in the entire article, and the most commonly misunderstood.
Consensus asks: “Does everyone agree?” This sounds beautiful. Yet, in practice, it creates paralysis. One person’s hesitation can block a change that would serve the entire team. The standard is too high, and so organisations either abandon collective decision-making altogether (defaulting back to someone in authority deciding) or they spend hours in exhausting discussions trying to get everyone to the same place. Neither outcome serves the organisation’s purpose.
The Governance Meeting uses something different from both consensus and simple consent. It asks a very specific question: “Does this proposal cause harm to one of your roles?” Not “Do you agree?” Not “Is this the best way to do it?” But “Would adopting this degrade your capacity to fulfil the purpose or accountabilities of a role you hold?” Only concerns that meet this standard, tested against specific criteria, can block a proposal. This is the heart of the Integrative Decision Making process.
If no one raises a valid concern, the proposal is adopted. It is safe enough to try, knowing it can always be refined through the same process when new experience reveals a need.
This approach has a profound effect on speed. Teams can process structural changes in minutes that would take consensus-based teams weeks. They iterate rapidly, knowing that any change is revisable. And they avoid the destructive pattern where the most risk-averse or politically powerful person effectively holds veto power over the team’s evolution.
For AI agent governance, this matters even more. Agent roles and policies need to evolve frequently, especially in the early months of deployment. Requiring full consensus on every role refinement, every policy addition, and every boundary adjustment would choke the very agility that makes agents valuable.
Let me state this plainly: if you are deploying AI agents without a structured process for evolving their roles, boundaries, and policies, you are building on sand.
AI agents do not adapt to organisational changes the way humans do. A human team member might notice a process has shifted and adjust informally. An AI agent operates within the structure that has been explicitly defined for it. If that structure is outdated, incomplete, or never properly defined, the agent produces work that is technically correct but organisationally wrong.
The Governance Meeting keeps agent roles current. When an agent’s accountability turns out to be too broad, someone raises a tension and the team refines it. When a policy is missing that would prevent an agent from overstepping into another role’s domain, that policy gets proposed, tested for objections, and adopted. When a new capability becomes available and an agent’s role should expand, the expansion goes through the same structured process.
This creates something most organisations deploying AI agents desperately lack: a tracked, timestamped history of every structural decision. When a regulator, a client, or an internal stakeholder asks “who decided this agent could do that?”, you can point to a specific proposal, the tensions that drove it, and the date it was adopted.
The Facilitator guides the meeting through the structured process. In governance, this role is even more critical than in the Tactical Meeting, because the decision-making process has specific steps with strict rules about who speaks when. The Facilitator Role does not contribute content. They hold the process, interrupt when someone steps outside of it, test objections for validity, and guide integration when objections arise. A Facilitator who lets discussions run unstructured is the single most common reason Governance Meetings become frustrating.
The Secretary captures all governance outputs and ensures they are recorded with full traceability. Every new role, every amended accountability, every adopted policy is captured with a timestamp and immediately reflected in the governance records. The Secretary also schedules meetings and ensures all circle members receive the outcomes. In Nestr, governance changes are recorded in an immutable, timestamped history, which means the audit trail builds itself as a natural byproduct of working.
The Circle Lead (or equivalent coordinating role) participates as an equal circle member with no special veto power in governance. The Circle Lead has specific authorities outside governance (role assignments, priorities, strategy), but inside the Governance Meeting, every voice carries equal weight and every role-filler can propose changes. Part of the accountabilities of the Circle Lead is the Governance structure of the Circle, so it could be that more proposals come from them then from other roles.
The Facilitator and Secretary (and the Circle Rep) roles are elected by the circle through a structured election process (described below). They are not appointed from above.
In a multi-person team, the Facilitator invites each participant, one at a time, to share a brief check-in. Call out distractions, get present. One person speaks at a time. No discussion, no reactions.
For a solo founder with AI agents, skip the formal round.
Each participant adds governance tensions to the agenda. One or two words per item, as a reminder. No explanation, no discussion.
In an AI agentic set-up, your agents should have captured governance tensions during their work. In Nestr, when an agent encounters a structural gap (an unclear accountability, a missing policy, a domain conflict), it logs a tension and links it to the next Governance Meeting. By the time you sit down, you have a pre-populated agenda of structural issues surfaced by your agents, plus any you captured yourself during Tactical Meetings or daily work. Review the list, add new ones, and decide the order.
The Facilitator decides the processing order. A useful heuristic: process quick items first to build momentum, and save the more complex proposals for when you are warmed up. One exception: if an election is requested, elections are processed first.
This is where the work happens. Each agenda item is processed through a structured decision-making process with six distinct steps. The Facilitator guides the team through each step strictly. The rules about who speaks when are not suggestions. They are what makes the process work.
The person who raised the tension becomes the Proposer. They describe the tension they are experiencing and present a proposal to resolve it.
A tension is the felt gap between how the organisational structure currently works and how it could work better. It is not a complaint. It is a signal that something needs to evolve.
Three things make a proposal valid. First, the Proposer must describe a tension that relates to one of their own roles, not someone else’s. Second, the Proposer must share an example of an actual past or present situation illustrating that tension, not a hypothetical future scenario. Third, the Proposer must give a reasonable explanation of how the proposal would have reduced the tension in that example. The Facilitator tests the form of this argument (does it meet the criteria?), not the content (is it the best solution?).
The Proposer might say: “In my Customer Relations role, I received three refund requests last week that the Support Triage agent processed without any policy guidance. Two of those refunds exceeded amounts I would have approved. I propose adding a policy to the Customer Success circle: ‘The Support Triage role may offer service credits up to €50 without approval. Refund requests above €50 require escalation to the Customer Relations role.’”
If the Proposer needs help crafting the proposal, the Facilitator can invite others to assist, but only to get an initial proposal, not to build consensus or optimise the solution. The proposal belongs to the Proposer.
What can a proposal contain? Only governance outputs. A proposal can create, modify, or remove roles (with their purpose, accountabilities, and domains). It can create, modify, or remove policies and domains. It can elect people to elected roles. Nothing else is a valid governance output.
Anyone can ask a question to seek information or understanding about the proposal. The Proposer responds or says “not specified.” No reactions, no dialogue, no opinions. This means not a “wouldn’t it be better if…?”, but an actual question because someone doesn’t understand part of the proposal.
Facilitator phrase when someone starts reacting: “That sounds like a reaction, not a question. Do you have a question?”
This step is quick. If it takes more than a couple of minutes, people are reacting rather than clarifying.
This is the one step in the entire process where participants can speak freely. Each person, one at a time (except the Proposer), shares their reaction to the proposal. Perspectives, concerns, suggestions, improvements, feelings, all are welcome.
“I think this is exactly what we need. The agent has been making inconsistent refund offers.” “I am concerned that €50 might be too low for enterprise clients.” “I wonder if we should also define how the escalation to Customer Relations works.”
Reactions are not discussions. Each person speaks once, in turn. The Proposer listens but does not respond. The Facilitator stops any back-and-forth. This containment is what makes the step powerful. Everyone gets heard without the conversation spiralling.
After hearing all reactions, the Proposer can optionally amend the proposal or clarify their intent. Only the Proposer speaks. No discussion.
Here is the discipline that surprises most teams: the Proposer is not obligated to address every concern raised in the reactions. Their job is not to make everyone happy. Their job is to find a proposal that addresses their original tension. If the Proposer heard something useful, they can integrate it. If not, the original proposal stands.
“I heard the concern about enterprise clients. I will amend the policy to add: ‘For enterprise accounts, credits up to €150 may be offered without approval.’ The rest stays as proposed.”
This is the safety check, and it is the step that most clearly defines how this process works.
The Facilitator asks each participant, one at a time: “Do you see any reason why adopting this proposal would cause harm? Objection, or no objection?”
Each participant responds with “no objection” or states their objections. When an objection is raised, the Facilitator captures it and tests it against four specific criteria. A objection counts as a valid only if it meets all four.
Test 1: Harm. “Is your concern that the proposal causes harm, or that it is simply unneeded or incomplete?” If the concern is merely that the proposal does not go far enough or is not needed, it is not an objection. Only concerns that the proposal would degrade the circle’s capacity count.
Test 2: Role-based. “Would the proposal limit one of your roles specifically, or are you trying to help another role or the circle in general?” If the objector is raising a concern on behalf of someone else’s role, it is not a valid objection. This ensures skin in the game. You can only object based on your own roles. This might need a small adjustment when you’re working with AI-agent role-fillers, though it should still work.
Test 3: Caused by this proposal. “Is this concern created by adopting this proposal, or does it already exist even without the proposal?” Pre-existing concerns are not valid objections. They may be independent tensions worth processing separately, but they cannot block this proposal.
Test 4: Based on present data. “Is this based on known information, or are you anticipating a future problem?” If anticipating: “Would the proposal necessarily cause the harm, or would the circle have an adequate opportunity to adapt before significant damage occurs?” This is the “safe enough to try” test. But it must be applied carefully. It does not mean “are you comfortable?” It means “do we have time to course-correct if needed?” Over-applying this test invalidates real objections. Under-applying it lets speculative concerns block progress.
There is one exception to these four criteria. If adopting the proposal would violate the rules of the governance process itself, such as proposing an operational decision as governance, or making a change that exceeds the circle’s authority, that concern is always valid. These are called “Not Valid Governance Output” objections and they bypass the four tests entirely. Example: someone proposes that the Support Triage agent should “ensure customer satisfaction scores stay above 90%.” That is a result mandate, not a governance output. Governance defines ongoing activities and authority boundaries, not targets to achieve. The Facilitator should catch these, but anyone can raise a Not Valid Governance Output objection.
Gathering objections from your AI agents. For a solo founder, the objection round is where interactive agent engagement matters most. Before adopting a proposal that affects an agent’s role, query the agent directly: “Given this proposed change to your accountabilities, do you see any conflict with your current policies or domain boundaries? Would this create overlap with another role?” The agent may surface a genuine concern, such as a conflict between the new accountability and an existing policy, or an access limitation that would make the accountability impossible to fulfil. These are real objections that you would miss without asking. This is not anthropomorphising the agent. It is using the agent’s knowledge of its own operating context as a sensor for potential harm, exactly the way every role-filler in a Governance Meeting functions.
If there are no valid objections, the proposal is adopted. The Secretary records the change. The Facilitator moves to the next agenda item.
If one or more valid objections are raised, the Facilitator moves to integration. This is the step that most clearly distinguishes this process from both consensus and top-down decision-making.
The goal is to amend the proposal so that it resolves the objection without losing what the Proposer originally needed. It is not a compromise. It is not a negotiation. It is a creative search for a solution that serves both concerns.
The Facilitator focuses on one objection at a time. Start with any Not Valid Governance Output objections first, as these are usually straightforward and often resolve other objections along the way. For each objection, the Facilitator asks the Objector: “What could be changed or added to remove your concern?” Anyone can contribute ideas, but the Facilitator checks each suggestion with two questions: does the Objector confirm their concern is resolved? Does the Proposer confirm their original tension is still addressed?
Do not wait for consensus during integration. The moment a suggestion resolves the objection and still addresses the tension, capture it. Good integration requires rapid reflexes: go for viable suggestions rather than waiting for a perfect discussion to conclude.
Once all objections are resolved, the Facilitator runs another Objection Round on the amended proposal. If new objections arise, they are integrated in turn. This continues until a version raises no valid objections.
For AI agent governance, integration is particularly valuable. When someone objects that a proposed policy would conflict with another team’s domain, the integration process ensures the boundary is drawn precisely. The resulting policy is cleaner than the original, which translates directly into clearer behaviour from the agent.
In a multi-person team, the Facilitator invites each participant, one at a time, to share a brief closing reflection. No discussion. The meeting ends.
For a solo founder, the formal closing round is unnecessary. What matters is that every governance change is recorded. In Nestr, adopted changes are captured with a timestamp and immediately reflected in the governance records. AI agents connected through MCP access the updated structure right away. The agent’s behaviour changes because the governance changed, not because someone manually rewrote a prompt.
The quality of your governance depends on the quality of your proposals. Here are the most common pitfalls and how to avoid them.
Accountabilities must describe ongoing activities, not results. Every accountability should start with an “-ing” verb and describe what the role-filler actually does, along with a practical outcome describing what the work produces or where it goes. “Reviewing incoming applications against defined criteria and surfacing qualified candidates for the Hiring Lead” is a well-formed accountability. “Ensuring 20% more qualified hires” is not. You cannot mandate reality to be a certain way. “Approving external communications” is also problematic, as it implies a gatekeeping authority that usually requires a domain and policy, not an accountability.
Policies govern roles and authority, not people. The organisation can only control what it owns, and it does not own people. A valid policy grants or constrains authority that roles exercise. “The Content Writer role may publish blog posts directly without review” grants authority. “All team members must attend standup at 9am” governs people’s personal behaviour, which is not a valid governance output. Personal agreements belong in a separate conversation outside governance.
Start from the tension, not from the solution. The most effective proposals grow from a real situation the Proposer experienced, not from a theoretical idea about how things should work. When a Proposer starts with “I think we should reorganise the whole circle,” the Facilitator should redirect: “What is the specific situation you experienced? Let’s start there.”
Prefer small, targeted changes over comprehensive redesigns. A proposal that sharpens one accountability is faster to process and easier to test than a proposal that restructures three roles simultaneously. You can always make more proposals. The governance rhythm exists precisely to allow incremental evolution.
Elections for the Facilitator, Secretary, and Circle Representative follow a distinct process, different from the standard Integrative Decision Making steps.
The Facilitator describes the role being elected and sets a term. No one may comment on potential candidates at this point.
Each circle member then privately nominates one person they believe is the best fit. No abstentions, no multiple nominations.
Each nominator shares their reasoning, one at a time. Others may not respond.
After all nominations are shared, any member may change their nomination, with an explanation. Again, no responses.
The Facilitator proposes the candidate with the most nominations.
A standard Objection Round follows. If objections cannot be resolved, the candidate is set aside and the next candidate is proposed.
This process surfaces collective intelligence while preventing the political dynamics that typically dominate elections.
Let me walk through how a solo founder uses a Governance Meeting to evolve their agent team.
You run a consulting practice with three AI agents filling defined roles: a Research Analyst, a Content Writer, and a Client Comms agent. During the past two weeks, you and your agents have captured three governance tensions. The agents surfaced “Research scope” and “Tone inconsistency” during their work. You added “Client email autonomy” after your last Tactical Meeting. All three are pre-linked to this Governance Meeting in Nestr.
Tension 1: “Research scope.” In your Strategy role, you noticed that the Research Analyst agent has been producing deep market analyses that take significant time but are rarely useful for client deliverables. The actual tension: the role’s accountability is too broad.
You propose: “Amend the Research Analyst role. Change the accountability from ‘Researching market trends and producing analysis reports’ to ‘Researching client-specific topics based on active project briefs and surfacing key findings for the Strategy role.’”
Before adopting, you query the Research Analyst agent: “Any questions and reactions? Given this proposed change, would the narrower scope create any conflict with your current projects or policies?” The agent responds that it has two in-progress market trend reports that would become orphaned. Not a structural objection, but useful context. You capture an action to review those reports in your next Tactical Meeting and decide whether to finish or archive them. No structural objections. Adopted. The accountability is updated immediately.
Tension 2: “Tone inconsistency.” In your Client Relations role, you received feedback from a client that the Content Writer’s tone felt too formal for their brand. The tension: there is no policy governing how the Content Writer adapts tone.
You propose: “Add a policy to the Content circle: ‘The Content Writer role adapts its communication style to match the tone guidelines defined per client in the project brief. When no tone guidelines are specified, the Content Writer defaults to a professional but conversational tone.’”
You query the Content Writer: “Any questions and reactions? Would this policy conflict with any of your current accountabilities or create ambiguity about how to handle cases where a client brief exists but has no tone section?” The agent confirms it can work with this, and notes that three active client briefs currently have no tone guidelines, so the default would apply. No objections. Adopted.
Tension 3: “Client email autonomy.” In your Client Relations role, you have been reviewing every email the Client Comms agent sends before it goes out. This creates a bottleneck. The tension: the agent needs more autonomy for routine communications, but you want oversight for sensitive ones.
You propose: “Add a policy: ‘The Client Comms role may send routine status updates and scheduling communications without prior review. Any communication involving scope changes, pricing, complaints, or contract terms requires review by the Client Relations role before sending.’”
You query the Client Comms agent: “Given this proposed boundary between routine and sensitive, show me the last ten emails you sent and how you would classify each.” The agent classifies them. You notice one email about a delayed deliverable that the agent marked as “routine” but you would consider sensitive, since it could trigger a scope discussion. This is a real concern: the proposal would create harm because the agent’s classification of “routine” does not match yours in edge cases. You test your concern against the criteria. Is it caused by the proposal? Yes, today everything gets reviewed, so this risk is new. Could you adapt before significant harm? A misclassified email could reach the client before you see it, so no. Valid objection.
Integration: you amend the proposal to add “The Client Comms role flags any communication it is uncertain about for review. Communications relating to project timelines or deliverable status require review by the Client Relations role. A weekly audit of sent communications is conducted by the Client Relations role.” The amendment resolves the concern. Still addresses the original tension (routine scheduling and status updates go out without delay). Adopted.
Three governance changes processed in twenty minutes. Each one recorded with a timestamp. Each one immediately updates the operating context for your AI agents through MCP. No code changes, no redeployment, no manual prompt editing. The agents queried during objection rounds helped you spot a real issue you would have missed on your own.
Governance changes do not have to wait for a scheduled meeting. Proposals can be processed asynchronously between meetings. Someone proposes a change in writing, participants ask clarifying questions, share reactions, and raise concerns through the shared platform. Once every circle member confirms they have no objections, the proposal is adopted.
In practice, teams that are new to the process should work synchronously for the first few months to build the muscle. Once the team is comfortable, a common pattern is processing straightforward changes asynchronously with a 48-hour objection window, while reserving the monthly meeting for more complex or sensitive proposals. Any circle member can request that an asynchronous proposal be brought to a meeting for real-time processing.
In Nestr, both synchronous and asynchronous governance are supported. Tensions are captured as they arise, proposals are crafted with the full organisational context available, and the entire decision-making trail is recorded regardless of how the change was processed.
Confusing governance with operations. The most common mistake. “The customer report was late” is operational. “Nobody’s role explicitly owns the customer report” is governance. When operational issues surface, the Facilitator redirects: “That sounds like a Tactical item.”
Seeking consensus instead of testing for harm. When teams first adopt this format, there is a strong pull toward making everyone comfortable. This kills the process. The Facilitator guides toward the consent standard: does this cause harm to your role? Not: does everyone agree this is ideal?
Facilitator not intervening enough. The most common facilitation mistake. The rules are the Facilitator’s tools. “That is a reaction, not a question.” “We are in the Objection Round, not the Reaction Round.” “Only the Proposer speaks in this step.” These interventions feel rigid. They are what makes the meeting work.
Accepting objections too quickly. Not every concern is a valid objection. Testing objections against the four criteria is essential. When a Facilitator accepts every concern without testing, integration becomes exhausting and the team loses confidence. Valid objections are, in practice, relatively rare. When they arise, they are genuinely valuable, so do not dismiss them either.
Trying to write the perfect proposal. A proposal does not need to be perfect. It needs to address the Proposer’s tension and be safe enough to try. Refine it later through the same process when new tensions emerge.
Treating governance as a one-time setup. The boundaries you set in your first Governance Meeting are your best guess and aim to reflect the actual work being done. They will be wrong in places. That is expected. The point of the governance rhythm is not to get it right once. It is to create a process through which the right structure emerges and evolves over time, just like the conditions around it are evolving.
Proposing result mandates. “The Sales Agent must achieve 20 qualified leads per month” is not valid governance. Governance defines ongoing activities and authority boundaries, not targets. The correct formulation: “Identifying potential clients through defined channels and adding qualified leads to the pipeline for review by the Sales Lead.”
Most run between 60 and 90 minutes. Do not exceed two hours. A useful guideline is to allow about 10 to 15 minutes per complex agenda item. If items remain, they carry to the next meeting, or the participant can request a special governance session or process it asynchronously.
The four objection tests make this self-correcting. Test every concern against all four criteria, consistently and without exemption. When someone raises concerns that repeatedly fail the tests, the pattern becomes visible to everyone. The key: the Facilitator must test, not accept at face value or judge the content.
Yes. The Facilitator is a circle member too. However, content participation while facilitating undermines neutrality. If the Facilitator wants to propose something substantial, they should consider temporarily stepping out of the role.
You do not need a proposal to start. You just need a tension. The Facilitator can invite others to help the Proposer craft an initial proposal, though this assistance focuses solely on getting a starting point, not on reaching consensus.
Yes, at any point before adoption. The Proposer can also withdraw and re-submit with changes in a later meeting.
The EU AI Act requires documented governance, continuous risk management, human oversight, and traceability for high-risk AI systems. When every governance change is processed through a structured meeting with captured proposals, tested objections, and timestamped records, you generate compliance evidence as a natural byproduct of working. You do not need a separate compliance project. The governance history is your evidence.
Yes. When an agent encounters a structural gap during its work, such as an unclear accountability, a missing policy, or a conflict with another role’s domain, it can capture this as a governance tension in the shared system. In Nestr, these tensions are linked to the next scheduled Governance Meeting. A human typically presents the proposal, but the signal came from the agent’s operational experience.
The updated structure is immediately visible in the governance records. AI agents connected through MCP access the updated roles, policies, and boundaries. The agent’s behaviour changes because the governance context changed, not because someone rewrote a prompt.
They will be. Every team’s first few Governance Meetings feel awkward. People confuse governance with operations. The Facilitator is still learning when to intervene. This is normal. The structure is learnable. By the third or fourth meeting, most teams have internalised the rhythm and start experiencing the speed and clarity the process provides.
No. Make the structure of one team visible as it is now: the roles, accountabilities, domains, and working agreements. Run your first Governance Meeting. Process a few tensions. The rest evolves from there.
Most organisations change their structure through one of two mechanisms: top-down decisions by those in positional authority, or informal drift that nobody explicitly agreed to. The first concentrates power and creates legacy and bottlenecks. The second creates ambiguity and incompliance. Neither serves purpose well.
The Governance Meeting provides a third option: structured, consent-based evolution where every role-filler contributes to shaping the organisation they work within. It distributes the authority to change the system to the people closest to the work. It moves fast because consent is a lower bar than consensus. And it creates a living record of how the structure evolved, which is invaluable for organisational learning, for onboarding, and increasingly, for regulatory compliance.
When you add AI agents to the picture, this meeting becomes even more essential. An agent’s role needs to evolve as the organisation learns. Its boundaries need to adjust. Its policies need to respond to new situations. The Governance Meeting is the mechanism that makes this evolution structured, tracked, and visible.
At Nestr, we have spent over a decade building a platform that makes this kind of governance operational at scale. The organisational structure is explicit and shared. Governance proposals are captured and processed. Every change carries a timestamped, immutable history. AI agents connect through MCP and operate within the structure the team defines and evolves. One system for everyone, carbon-based and silicon-based alike.
The tools exist. The process is proven. The question is whether you will build the governance rhythm that lets your organisation change as fast as the world around it demands.
.png){kind=logo}
