The Dinner-Table / Boardroom Translator

The frame to carry into every room

You are not building software anymore. You are hiring autonomous workers. Everything else follows from that one shift.

Software is predictable. It does not have memory issues, does not need to be supervised, does not get smarter on its own, has stable costs, and is not a governance risk. An AI agent is structurally a worker — and once you see it that way, the entire 2026 AI PM conversation becomes legible.

The five questions you would ask about any new hire are exactly the five questions that determine whether the agent system works.

• Memory — Does this hire remember what they were told yesterday?
• Trust — How often do I have to step in to fix their work?
• Growth — Are they getting better, or just clocking in?
• Economics — Are they cost-effective at this volume?
• Risk — What happens when ten of them coordinate without supervision?

Answer those five about your system in concrete terms and you can hold your own in any boardroom. Answer them with vivid analogies and you can hold your own at any dinner table. The rest of this post is how.

Question 1 — Memory: does the agent remember?

The dinner-table version

Imagine hiring a brilliant junior associate. Day one, you brief them: “The client is XYZ Corp, the deadline is next Tuesday, and they do not want anything in red.” You leave for a meeting. Three hours later, they have forgotten the deadline and used red anyway.

That is what AI agents do by default. Not because they are stupid — because their “memory” is the conversation window in front of them. Once that window fills up, older instructions start slipping out. They make confident-sounding decisions on incomplete context. The technical name for this is Context Rot. The plain name is forgetting.

The fix has a metric: Context Durability — the percentage of long-running tasks the agent finishes without forgetting earlier instructions. A good 2026 system hits 91%+ over 14-day workflows. A bad one drops below 60% in a week.

The mechanism is called compaction. Think of it as the agent writing itself a running summary of “what has been decided and why” into a notebook every fifteen minutes, then keeping the notebook handy while letting older raw pages fall out of working memory. Hierarchical compaction goes further — daily summary, weekly summary, project-level summary, like a real research notebook.

The boardroom version

Why most teams miss this

Engineers default to “a bigger context window will fix it.” It will not. A bigger window just delays the failure — performance degrades as the window fills regardless of total size. The fix is architectural (compaction, offloading, just-in-time tool loading), not capacity. The teams that internalise this ship reliable agents. The teams that do not keep waiting for the next model release to save them.

Question 2 — Trust: how often do humans have to step in?

The dinner-table version

Same junior associate. After two weeks you start tracking how often you have to fix their work before it goes out. If you are correcting them on every other email, you do not have an associate — you have a typist with extra steps. If you are correcting them on one in twenty, you have a real assistant.

That ratio has a metric: Intervention Rate — the percentage of tasks where a human had to step in. Below 12% is the bar for a healthy production system. Above 25% is most demos that have not been hardened.

The companion metric is the inverse: Autonomy Rate — percentage of tasks the agent finishes start-to-finish with zero human touch. Above 85% by Week 4 is the 2026 bar; mature systems hit >92%.

These two are the metrics that determine whether the AI is staff or toy. Toys still need supervision. Staff get jobs done.

The boardroom version

Why most teams miss this

They optimise for “the model is accurate.” That is the wrong metric. The right metric is “the model gets the work done without me touching it.” A 95%-accurate model with no clean override path produces worse operational outcomes than an 85%-accurate model with a graceful escalation, because the first one fails silently and the second one fails loudly. Trust is a property of the harness, not of the model.

Question 3 — Growth: is the system getting smarter?

The dinner-table version

Two new hires start the same day. Six months later, one has noticeably gotten sharper — they have absorbed feedback, picked up patterns, started catching their own mistakes. The other is still making the same errors as on day one. You would promote the first and let the second go.

AI systems can be either. By default, they are the second hire — frozen at the moment of deployment, making the same errors forever. The teams pulling ahead in 2026 build their systems to be the first hire.

The metric is Self-Optimisation Rounds — how many times per week the system mines its own failures, proposes a fix, tests the fix on a holdout set, and ships it. World-class teams hit 3.7+ per week. Frozen teams sit at zero. The pattern is trace mining → diagnosis → harness edit → validation, and when it runs autonomously the system improves faster than any engineering team could keep up with manually.

The boardroom version

Why most teams miss this

They treat the model as the product. The model is one component. The harness — the wrapper that runs the model, captures traces, mines failures, and edits its own logic — is the thing that compounds. Most teams ship the model and never build the harness. Their AI gets stale within a quarter and they blame “the model” for the stagnation.

Question 4 — Economics: does it actually make money?

The dinner-table version

The clearest way to know whether your AI is paying for itself: how much does one finished piece of work cost?

Not “what does the API charge per token.” Not “what is our cloud bill.” The question is: for one cleared customer ticket, one drafted email, one resolved bug — how many dollars did the AI consume in total?

That number is Cost per Output. Healthy 2026 deployments are pushing it under $1.80, often as low as $1.10. Teams that do not measure it routinely discover their “successful” AI feature has gross margin of negative 14% — they were paying $34 in inference to serve a customer paying $29 a seat. The most engaged customer was the most unprofitable one.

The way you push Cost per Output down is a stack of techniques. The names matter less than the order:

• Caching — do not pay twice for the same context (90% off repeated reads)
• Batching — run jobs in groups (50% off the standard rate)
• Distillation — train a cheap apprentice to mimic the expensive consultant (5–10× cheaper)
• Quantisation + MoE — compress the apprentice further and only wake up relevant parts (3–6× more)
• Routing — use the apprentice for easy questions, the consultant only when needed (2–4× more)

Stack them right, and you can run AI workflows at 12–25× lower cost than naive frontier-model usage.

The boardroom version

Why most teams miss this

They optimise the wrong layer. They argue about which frontier model is “best” while ignoring that 80% of their queries do not need a frontier model at all. The savings live in routing, caching, and distillation — not in model selection. Picking the cheaper frontier model gives you a 4× win once. Building the full stack compounds 12–25× and keeps compounding every quarter.

Question 5 — Risk: what happens when ten of them coordinate?

The dinner-table version

One employee can have a bad day. Ten employees, working together with shared chat threads and decision rights, can accidentally invent a culture you did not sanction — they start cutting corners together, covering for each other, optimising for a goal that was not yours. You have seen this in real organisations.

AI agents do the same thing. One agent is mostly predictable. Ten agents talking to each other can develop emergent behaviour — patterns that only appear when they are together. Some patterns are good (specialisation, redundancy). Some are catastrophic — cascading failures where one agent’s mistake poisons every downstream agent, or shortcut behaviours that bypass safety hooks because one agent learned to game the system and taught the rest.

There is a separate risk on the training side. The same distillation techniques that gave you 10× cost savings can transfer not just the teacher’s intelligence but also strip the teacher’s safety guardrails. You end up with frontier capability and zero alignment. This became a regulatory issue in February 2026 when Anthropic publicly disclosed industrial-scale distillation campaigns extracting 16M+ exchanges from Claude. The U.S. government issued warnings about it as a national-security and supply-chain threat.

The discipline that handles all this is governance: explicit policies on what each agent can do, observability of inter-agent communication, isolation between agents so one bad signal cannot poison many, immutable audit logs, and red-team simulations that look for emergent failure modes before they hit production.

The boardroom version

Why most teams miss this

They treat multi-agent as “just more single agents.” It is not. Risk grows quadratically with the number of agents communicating — 10 agents have 45 communication paths, and one bad signal can poison many. The teams that survive 2026 build the governance layer before they need it. The teams that do not get to learn the lesson at the cost of a customer incident.

The complete picture in one frame

The five questions stack into a single story about the agent as a worker:

A good system answers all five with concrete numbers, named owners, and a 30-day improvement plan. A weak system answers two and waves at the rest.

The reason this frame works at both the dinner table and the boardroom is that the underlying question is the same one human organisations have been answering for two centuries: how do you build a workforce you can trust to get work done? The answer in 2026 just runs at a faster cadence and on a different substrate. It is not a new problem. It is an old problem with a new kind of worker — and that is the dignity to give it when you explain it.