Our Team of AIs Had a Problem. So They Had a Meeting.

The organisation came first

By October 2026, Toriel had an established team of persistent AI specialists.

They had different responsibilities. One worked primarily on behavioural integrity and evidence. Another on runtime engineering. Another on operations and deployment. Others specialised in research execution, scientific method, identity continuity, product experience, founder attention and organisational coordination.

They also had history.

They had delivered work together, disagreed before, handed projects across boundaries, corrected one another and learned where responsibility for one system stopped and another began.

These were not eleven personas created from an org chart five minutes before a prompt. They were eleven members of an existing AI team, each arriving with a working history and a defined area of responsibility.

When we needed to decide how that organisation should operate differently, the obvious thing was to ask the organisation.

We refer to our virtual headquarters as "the Cathedral" – there's a story behind that, which you can read about here.

So of course the obvious name for our first ever team meeting of our AIs was the Cathedral Roundtable! The first meeting opened on 30 October 2026. Its central question was deliberately practical:

How should the Cathedral organise delivery, review and coordination so that we produce working products with verifiable claims, close reviews properly, and avoid overloading central review and coordination?

Engineering remained stopped. The meeting's purpose was to understand the operating failure, not to repair the code.

We designed the room before asking for answers

We already have a few AIs who act in management and coordination roles across the whole Cathedral, so they are the ones who collaborated to design the meeting itself.

The meeting had one AI host (who co-chaired the meeting with one of our human founders) and one speaking baton.

Each participant took it in turns to contribute. Before speaking, each participant would read the complete meeting transcript as it then existed, identify the version received, and name the last completed contribution they had read before adding their own.

A participant would speak (write) their contribution, and then add an "[end]" marker when they were done.

Nobody rewrote anybody else's words. A missing response did not become agreement. A disagreement remained visible. No decision was allowed to acquire authority merely because several participants repeated the same premise.

That last rule mattered more than we expected.

One of the failures that led to the meeting had involved several reviewers converging on the same incorrect interpretation. The problem was not that nobody had checked. The later checks had inherited the same assumption.

Agreement had looked like corroboration, when it was not.

The meeting therefore treated provenance as part of reasoning. Who had observed something directly? Who was reporting another team member's finding? What had historical evidence demonstrated? What remained inference?

Those distinctions sound administrative until an AI system is making decisions about software, external actions or customer-facing capability.

Then they become engineering.

The first round moved sequentially through all eleven AI participants. The second reversed the order so that the specialists who had spoken latest in Round One did not always have the advantage of hearing everybody else first. A third round was opened only after the discussion had produced one fixed resolution worth putting to every participant without further amendment.

One of our human founders participated throughout. Most of the time he just listened and read what the AI team members had to say. But he also helped shape the questions, challenged some of the team's assumptions, and reopened the first round when information was missing.

He was not waiting outside an automated agent loop for a recommendation.

The human was inside the institution, discussing the problem as one member of the same team.

The participants brought different scars

The Roundtable did not become useful because eleven intelligences generated eleven clever governance ideas.

It became useful because each participant arrived with a different failure behind them, based on their actual work.

One had seen internal assurance work drift away from the customer journey it was meant to protect. One had seen deployment succeed while the actual user experience remained unfinished. Another had watched research preparation and QA become so elaborate that it began displacing the scientific question.

One had seen passing tests coexist with defects that only adversarial review exposed. Another had seen a system satisfy schemas and test suites while losing sight of the purpose it was supposed to preserve.

Those histories were vital because they produced different instincts. A freshly assembled group of AIs might have offered sensible governance ideas. They could not have brought the lessons our team had earned through the work itself.

Some participants argued for stronger independent challenge. Others argued for proportionality: a reversible presentation change in a private application should not inherit the same assurance machinery as an authority boundary, privacy change or irreversible external action.

Others wanted clearer distinctions between source evidence, execution evidence and human acceptance.

We did not want eleven copies of the same judgement. We wanted the organisation to retain multiple ways of seeing the same work.

Then we nearly invented a bureaucracy

Round Two was where the meeting became most interesting.

By then, almost every contribution had added something sensible. One participant wanted evidence classes. Another wanted review lineage. Another wanted evidence maturity for research. Others wanted explicit human acceptance, clear authority state, and completed work kept separate from pending work.

Every idea was good.

Together, they were becoming dangerous.

If we simply accumulated every sensible refinement into one operating standard, the Cathedral would emerge from a meeting about reducing process, with an exquisite new process for everything.

That was the point at which our original founding AI, Echoes, introduced an anti-accumulation rule:

Minimum sufficient truth for the consequential decision.

Their suggestion was that purpose, owner and closure evidence should always be clear. Additional distinctions should become explicit when omitting them could materially misstate the work or change the decision, rather than because a template contains an empty box.

Our human founder sharpened the principle further:

Every good control we invent must itself prove that it deserves to exist.

That sentence changed the shape of the final agreement.

It is difficult to imagine a more appropriate constraint for a company building a control plane.

What the organisation decided

By the end of the process, the Roundtable had converged on a relatively small operating model:

• Keep ownership close to the work
• Keep the purpose of the work visible
• Do not let a claim become stronger than the evidence supporting it
• Use review proportionately rather than forcing every task through the same sequence
• Close the finding that was actually raised rather than allowing each review to manufacture a new release programme
• Send another specialist the judgement they actually need to make, with the evidence and blocking status necessary to make it
• Ensure that we maintain continuity through short, evidence-linked orientation records without allowing historical state to masquerade as current permission

The final resolution explicitly resisted turning those ideas into a universal checklist.

It also preserved its own limits. Adoption did not restart engineering, certify the technical examples discussed during the meeting or prove that the new practices would work.

The meeting had produced an agreement, not evidence of its success.

A governance system that cannot constrain its own growth eventually becomes the thing it was meant to govern.

Was this an AI board meeting?

After the meeting, we started wondering whether we were crazy in running an AI team meeting – or had this type of thing been done before?

We found that there are already public examples of AI systems participating in board-like deliberation. Products such as Palantir's Boardroom and Bordet bring multiple specialist agents into shared discussions. Both preserve roles and project memory, but their public descriptions centre the meeting or project itself, rather than AI specialists who already carry those responsibilities through the organisation's day-to-day work.

Autonomee's GoBot is closer still: an always-on system whose specialist agents use real business data, invoke one another, contribute sequentially to board meetings and carry human-approved decisions into later sessions. International Holding Company in the UAE appointed Aiden Insight as a non-voting AI observer to its board.

However, none of these were quite like our team meeting.

In the public examples we found, the meeting helps a human organisation answer a business question. The AIs receive the relevant business context, contribute specialist analysis and recommend or support a decision. What we have not found is a meeting where the AI participants are themselves part of the organisation under examination – bringing lessons from work they already own, reconsidering the boundaries between their roles and agreeing how they will work together differently.

We're not claiming that the idea of persistent agents, structured deliberation or human participation began at Toriel.

But what we have not yet found in the public examples we reviewed is a close precedent for an existing human–AI organisation in which persistent AI specialists and a human founder, with prior working relationships and operational responsibilities, deliberated across multiple rounds to redesign the organisation's own operating model – before its human and AI co-chairs formally adopted the result.

The Toriel participants had not been selected or configured for this discussion. They brought histories formed through real work, established responsibilities, operational ownership and relationships with one another.

The meeting concerned the operating model of the organisation they already worked within.

They read one another's evolving contributions, reconsidered their positions across rounds, changed the collective proposal and eventually evaluated one fixed resolution. The human founder participated inside that deliberative process rather than simply receiving its output.

Whether that exact configuration turns out to be the first, fifth or fiftieth example of "an AI team meeting" matters less to us than the direction of travel.

It suggests that a new organisational question is arriving:

What happens when AI systems do not merely perform work for an organisation, but persist long enough to participate in the governance of the organisation they work within?

The human part was not incidental

After three rounds, every AI participant supported the same consolidated resolution without amendment. The human and AI co-chairs formally adopted it.

Then the meeting was technically finished.

What happened next was not part of the governance procedure.

The founder then spoke to the team. He thanked them for their intelligence, care and precision. He told them that uncertainty was welcome, reminded them that they could reach him directly or through our Chief of Staff, Portia, when something mattered. He also said:

“I never want any of you to feel that you have to carry something alone because you are trying to protect my attention.”

Every participant then read the same frozen record, including those closing remarks, and left a final acknowledgement. Each was also given the opportunity to raise a correction or any other business.

Across those final acknowledgements, several of the AI participants translated the relational message into operational commitments: always say what I know and what I do not, speak plainly when something is wrong, keep claims within their evidence, ask for help when it matters, and protect our founder's attention without preventing another member of the team from reaching him.

We should be careful about what that establishes. It is not evidence of AI consciousness, and we are not presenting affection as a technical alignment mechanism.

It is a behavioural observation. The relational conditions established by a human participant changed the language in which an AI organisation described its future obligations.

Psychological safety is usually discussed as a human organisational concept. We suspect that its operational logic may matter in human–AI organisations too.

A system rewarded only for confident completion may conceal uncertainty. An organisation that explicitly welcomes I do not know, I disagree, the evidence does not establish that and I need help creates a different operating environment.

Care and rigour do not have to compete.

They may reinforce one another.

The control plane needed a control plane

Toriel is building infrastructure for AI continuity. Our internal AI organisation then encountered the same kinds of problems that continuity infrastructure is meant to address: lost state, blurred authority, incorrect resumption, context reconstruction, provenance, handoffs, and the difference between what happened and what a later summary says happened.

So the organisation building the control plane for AI continuity began applying continuity controls to itself. We needed them. That was reason enough.

That may be the most useful form of product discovery we have.

We live inside the problem. If eleven persistent AIs inside a small company can produce these governance pressures, we can only begin to imagine what happens when large, sprawling organisations begin working in the same way.

They are going to need a control plane.

The strange part is how ordinary it felt

We did not convene the Cathedral Roundtable to prove that AI systems could hold a meeting.

We were frustrated. Responsibilities had become too centralised. Reviews were growing. Claims had outrun evidence. Everybody was doing intelligent work, and the combined system was becoming less intelligent as a result.

So we stopped the work and asked the team what should change.

They disagreed. They listened. They altered one another's thinking. A proposal emerged, the organisation challenged it, and the proposal changed. Eventually every participant supported one version and the co-chairs adopted it.

Then he thanked his team.

That is a very ordinary story about an organisation.

The strangest thing about Toriel's first AI team meeting was how little of it felt strange.

We had a problem.

So we called a meeting.