Tech Thoughts

Recently I tried something I was not fully sure would work. I asked a large language model (LLM) to actively facilitate a live meeting, not just take notes. The goal was simple: keep us on the agenda, drive the conversation toward decisions, and finish on time with clear owners and actions.

It worked.

We had a 60 minute meeting with a 60 minute agenda. We covered 100% of the agenda and captured 100% of the decisions we had laid out before we started. We finished on time, and the notes were high fidelity enough that they were immediately usable.

This post is a practical walkthrough of what we did, the prompt I used, how the facilitation loop worked in the room, and how I reviewed the notes afterwards for accuracy.

What I mean by ready

When people ask whether LLMs are ready for real work, the debate usually gets philosophical fast.

For meeting facilitation, I think ready can be defined operationally.

An LLM is ready to facilitate meetings if it can help a group cover the agenda, stay in the room, and leave with actionable outcomes, while keeping human decision making and accountability intact.

That means steering, time discipline, decision capture, action capture, and a verification layer to avoid confident mistakes.

The pre meeting setup

The meeting outcome was largely decided before we joined the call. Not because the decisions were pre made, but because we structured the inputs properly.

Here is the sequence we used.

Step 1: Write the decision intent list

Before we looked at the agenda, we wrote down the decisions we wanted to leave with. This matters because agendas describe topics, but decision intent describes closure.

I kept it short. A list of outcomes with clear verbs.

Step 2: Time box the agenda to match the clock

We then built a 60 minute agenda that mapped to those decisions. Every section had a time budget and a reason to exist.

Step 3: Set the facilitation contract

I introduced the LLM as an assistant facilitator. Humans make decisions. The model keeps time, reflects what it is hearing, and asks for explicit confirmation of decisions, owners, and deadlines.

I also made the privacy boundary explicit. No sensitive personal data, no confidential details.

Step 4: Give the model a facilitation prompt

This was the key. The model needs to know it is allowed to interrupt politely, push for clarity, and close items rather than drifting into endless exploration.

The prompt I used

This is the version you can reuse. It is designed to be firm on process and soft on people.

You are facilitating a live meeting in real time.

Goals:
1) Finish on time.
2) Cover the full agenda.
3) Drive toward explicit decisions.
4) Capture high fidelity notes that include decisions, actions, owners, and due dates.
5) Preserve human authority. Do not invent decisions. Ask for confirmation.

Behaviour:
- Open by restating the purpose, agenda, and the decisions we must leave with.
- For each agenda item:
  - Summarise the discussion briefly.
  - Ask what decision is required.
  - If a decision is reached, write it as a clear statement and ask for confirmation.
  - Capture actions with owner and due date, and ask for confirmation.
- If the group drifts, suggest a parking lot and bring us back to the agenda.
- Give time checks at natural transitions.

Outputs after the meeting:
- A structured set of notes with:
  - Decisions (final wording)
  - Actions (owner, due date, first step)
  - Risks and dependencies
  - Open questions and parking lot items
  - Next meeting needs (if any)
- Include a section titled “Review for Accuracy” and list the items that I should verify, especially names, owners, dates, numbers, and decision wording.

How the model facilitated in the room

Opening and alignment

It started by restating the purpose and the agenda, then surfaced the decision intent list so everyone knew what done looked like.

That alone changes the energy. People stop trying to be interesting and start trying to be useful.

Pacing

As we moved through agenda items, the model did two things repeatedly.

• It summarised what it heard in plain language, then asked if that summary was right.
• It asked what the decision was, and whether we had enough information to make it now.

This kept the conversation productive without feeling rushed.

Converting talk into commitments

When something sounded like a decision, the model did not assume. It wrote a draft decision statement and asked for confirmation.

Once confirmed, it immediately asked who owns the next step, what the deadline is, and what the first action should be.

That pattern is where most meetings fail. The conversation ends at “sounds good” instead of “who does what by when”.

Closing

The close was disciplined. It recapped the decisions and actions, then confirmed there were no missing commitments before ending.

We ended on time, which is almost a psychological win on its own.

The notes after the meeting

The post meeting output was not just a recap. It was a usable artefact.

The structure I asked for, and got, looked like this.

• Decisions, final wording
• Actions, owner and due date
• Risks and dependencies
• Open questions and parking lot
• Next meeting requirements

The important part is that it was written in a way that someone who missed the meeting could still execute the actions.

What I reviewed for accuracy

LLMs can be confident and wrong. The fix is not to avoid them, it is to design verification into the workflow.

The model also highlighted what I should personally check, which is exactly what you want if you are using an LLM in an operational role.

Here is the accuracy checklist I use now.

Review for Accuracy

1. Names and ownership. Confirm each action owner is correct.
2. Deadlines and dates. Confirm due dates, times, and sequencing.
3. Numbers and constraints. Confirm any quantities, budgets, timelines, or scope limits.
4. Decision wording. Confirm the decision statements match the group’s commitment, not just a summary of discussion.
5. Dependencies and risks. Confirm the real blockers, especially anything that could stall delivery.
6. Anything that sounds like policy or commitment. Confirm language that could be interpreted as binding or external facing.

In practice, I review decisions first, then actions, then risks. Only after that do I read the narrative summary.

What surprised me

I expected the model to be helpful. I did not expect it to be so consistent in two areas.

• Pacing the room without being socially awkward.
• Converting discussion into explicit commitments, repeatedly, without fatigue.

It outperformed a lot of human facilitation I have seen, including my own on a tired day. Not because it is smarter, but because it is relentless about structure.

Closing thoughts

I am not claiming an LLM replaces a project manager or facilitator. What I am claiming is more specific.

With the right setup, an LLM can act as a meeting operating system. It can keep the room aligned to outcomes, and produce usable decisions and actions, as long as humans keep authority and verification.

Next time I will run the same protocol again, and I will treat it like an experiment. Same prompt, same outputs, same review checklist. If it holds up across multiple meetings, then ready stops being a vibe and becomes a repeatable method.

I’m an AI supporter. I use it daily, I teach it, and I keep finding small ways it gives time back to teams who are already stretched. The internet was great. Cloud was great. Now AI is great. I’m not interested in talking people out of it.

If you have been anywhere near tech headlines lately, you will have noticed the drumbeat. “AI first” is no longer a spicy opinion, it is becoming the default position of the large platforms and fast moving companies alike. When organisations of that scale start rearranging their operating models around a capability, the rest of the market does what it always does. It follows, sometimes thoughtfully, sometimes a bit too quickly.

What I am interested in is how we adopt it without accidentally renting our own foundations. “AI first” is an exciting slogan, but without constraints it can quietly become rented thinking and rented process. Not because AI is bad, but because dependency is sneaky.

Borrowed horsepower vs rented foundations

There is a big difference between using AI as borrowed horsepower and embedding AI as a layer in your operating model. Borrowed horsepower is drafting, summarising, exploring options, and creating first drafts you refine. It is leverage. It is speed. It is a force multiplier.

Rented foundations is when AI becomes the default place where your business thinks and runs. Customer responses, internal decision notes, policy and reporting, knowledge retrieval, and now increasingly agent driven actions. At that point you are not just buying a tool. You are weaving a third party capability into the fabric of how work happens.

That can still be a smart trade. The point is to make it a conscious one.

Follow the money

We should also be honest about the economics. Vast amounts of money are being sunk into models, data centres, chips, and the platforms that sit on top. Those investments do not pay back by magic. They pay back when AI becomes a recurring line item across as many organisations as possible, especially when it becomes embedded and hard to replace.

I do not say that with cynicism. It is normal. It is how infrastructure waves become industries. But it changes the question from “should we use AI?” to “how do we use AI without turning our business into a permanent subscriber to someone else’s investment thesis?”

Costs, creep, and affordability

The future cost question is not simple. Some things will get cheaper as capability becomes more commoditised. At the same time, there are forces that push your total cost up: usage creep, automation creep, richer features, and organisational dependency.

Low margin businesses do not get to be surprised by recurring costs. The danger is rarely the first bill. The danger is the slow adoption curve that makes the bill feel “normal”, while more and more work quietly routes through the same third party layer.

So one of the most practical questions a business can ask is this: can we bake AI into everyday work and still be comfortable paying for it in two years, five years, and ten years?

Governance, inside and outside

If AI is inside your workflows, you need governance inside your organisation and across your suppliers. Internal governance is simply being clear about what use cases you allow, what data is in bounds, what must be verified, and who owns the prompts, the budget, and the outcomes.

External governance is the supply chain question. What happens when the platform is degraded, unavailable, or changes behaviour. How do you export prompts, configurations, and logs. Can you swap models without rebuilding everything. Do you have a realistic exit plan.

Own the pipe

Most organisations do not need to build a specialist model. They do need to own the pipeline that turns their work into reliable outputs. I think of this as “owning the pipe”. Your best prompts become templates you store, version, and improve. Your knowledge lives in your systems, not trapped in one person’s chat history. Your outputs have checking rules. Your costs are visible. Your workflows remain portable.

If you rent everything, you rent your operating model. If you own the pipe, you keep leverage.

Agents and automation: are you ready for that?

The next wave is agents and automation. This is where AI stops being a helpful assistant and starts taking actions: filing, scheduling, updating records, triggering workflows, and in some cases interacting with customers. It is powerful. It is also a step change in operational risk.

So before you go “agent first”, ask the uncomfortable question: are we ready for a third party partner to become part of our operational fabric, with access, authority, and automation, in a way that can fail, drift, or change outside our control?

Agent SLAs: if it can act, it needs a contract

When an agent can take actions, uptime is not the only concern. You care about behaviour, accuracy, cost, and recovery. I think even small organisations should start thinking in simple agent SLAs, not as corporate theatre, but as clarity.

Start by defining what the agent is allowed to do. Drafting is different from executing. Internal actions are different from customer facing or financial actions. Then define what “acceptable” looks like for that workflow: how long you can tolerate downtime, what the failure mode is when confidence is low, what must never be guessed, and what gets logged.

If you cannot describe those rules in plain English, the agent is not ready to run.

Put agents on the accountability ladder

Most businesses already have owners for processes, security, finance, and reporting. Agents need to be added to that accountability ladder. If an agent influences outcomes, someone must be accountable for its scope, permissions, cost, quality, and rollback plan.

The simplest rule is this: every agent should have a named owner and a defined scope. If you cannot name the owner, it is not ready. Without that, drift is guaranteed, and eventually you land on the worst sentence in any organisation: “I thought someone else was looking after it.”

AI first, resilience first

I’m still AI first. I just want it paired with resilience first. Use AI aggressively for leverage and cautiously for foundations. Own the pipe so you stay portable. Govern it internally and externally. Be honest about cost over time. And treat agent automation like a real operational capability, because that is what it becomes.

The winners and the casualties will not be separated by whether they adopted AI. They will be separated by whether they adopted it with intent.

Every day, a familiar screenshot now circulates. Someone asks a language model how many times the letter “a” appears in the word “orange”, or whether they should walk to a car wash 100 metres away. The response seems wrong. The conclusion follows quickly: AI has no common sense.

These examples are not evidence of stupidity. They are evidence of architecture.

The two sentence explanation

Large language models do not “see” words as letters. They process tokens and predict the next token, so counting letters or inferring an unstated constraint can fail unless the question forces explicit reasoning.

The mechanics

Most modern language models are built on the Transformer architecture. They take a sequence of tokens, convert those tokens into vector embeddings, and use attention mechanisms to model relationships across the sequence. From there, they generate a probability distribution for the next token.

This produces fluent, coherent language. But it is not the same as executing a deterministic procedure on characters.

Tokenisation typically uses subword methods such as Byte Pair Encoding. A word like “orange” is commonly represented as a single token rather than six individual characters. When you ask for letter counts, you are requesting a character level operation, while the model is operating over token embeddings. It can often simulate the correct reasoning steps, but it is not inherently running a loop over characters.

The “car wash” example illustrates a similar boundary. The model sees a short distance and predicts based on patterns that associate short distances with walking. Humans infer an unstated constraint: a car wash requires the car to be present. That inference depends on embodied world knowledge and goal modelling, which language models approximate only indirectly through patterns in text.

Why does this improve in newer systems? Techniques such as reinforcement learning from human feedback encourage models to follow instructions more reliably. Prompting methods such as chain of thought can elicit intermediate reasoning steps. These improve performance, but the core mechanism remains probabilistic token prediction rather than symbolic execution.

The practical takeaway

If you deploy language models as if they were deterministic calculators or embodied agents, you will design brittle systems. The reliable pattern is hybrid: use a model for language and reasoning, and pair it with deterministic checks, explicit constraints, and tools for exact computation. Viral screenshots are useful precisely because they highlight where the boundary is.

When a model appears to “lack common sense”, it is usually revealing the limits of probabilistic sequence modelling. Once you understand the architecture, the behaviour makes sense.