How to Make an AI-Agent Lightning Talk Verifiable: A Public PASS–FAIL–PASS Demo on One Slide

On May 30, 2026, around thirty people attended MiyakodeIT's AI-agent lightning talks at the former Kyoto Prefectural Assembly Hall. Presentations covered social media workflows, local language models, multi-agent systems, document creation, and other practical subjects. With so many different approaches, listeners need a way to tell what a demonstration actually established and whether they could reproduce it.

A successful screen without the input and conditions offers little basis for comparison. To show what stronger evidence could look like, we use a publicly implemented starter demonstration from Netsujo's Agent Role Contracts. This does not claim that anyone presented that demo at the May 30 event. The walkthrough below is an editorial reconstruction from public source and historical CI evidence; it is not a new run made for this article.

Why choose this particular demo?

A private prompt, paid API or hidden customer dataset can make a flashy live demo impossible for a listener to reproduce. The Agent Role Contracts starter offers published JSON inputs, a deterministic checker and, crucially, an intentional failure. It does not attempt to show an autonomous agent editing files in production. It isolates the narrower question of detecting contradictory declarations before execution.

In the fixed October 15, 2026 source snapshot, an implementer is declared to have write scope `src/**` and a reviewer is declared read-only. Changing the task's requested path provides three cases whose expected results are asserted in the demo source.

A filled-in, one-slide reproduction note

A reader with Git and Node.js 22.5 or later can run the repository demo:

```sh

git clone https://github.com/suirindo/agent-role-contracts.git

npm --prefix agent-role-contracts run demo --silent

```

That command checks out whatever the repository's default branch contains at the time of cloning. To reproduce the particular source revision in the table, check out `966e3c2` after cloning and before running the demo. The README's `PASS → FAIL (expected) → PASS` is documented expected output, not output newly observed by the authors for this article.

Why the failure is part of the successful explanation

If the allowed scope is `src/**` but the requested task points to `secrets/production.txt`, `TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY` is the intended diagnostic. Correcting the task makes it pass again. The paired inputs show listeners that the checker is not simply returning success for every declaration.

We can also point to historical execution evidence without conflating revisions. In the September 30, 2026 GitHub Actions run, an Ubuntu/Node 24 job logged a passing starter test for rejecting an out-of-scope task and 198 passed tests with zero failures in that job. That result belongs to the older commit used in the CI run, not to the October 15 source snapshot.

The exit-code distinction is worth making visible on the slide. Running the starter CLI directly with an invalid task returns exit code 1. The automated demo returns exit code 0 when it correctly encounters and verifies the expected failure. Showing only a green overall exit code would obscure what was tested.

What this does not prove

The demonstration checks task and authority declarations. It does not open or change the targeted files. It does not show a sandbox or operating system blocking a real write, prove the executor obeyed its contract, or authenticate an independent reviewer. Claiming that the entire AI-agent operation was proven safe would exceed the evidence.

For an actual lightning talk, show the input and expected outcome first. If you run the demo live, capture the actual environment, date, commit, stdout and exit code and distinguish them from expectations. If you do not execute it, identify the result as a source-documented expectation. This makes it possible for a listener to retry the same test and meaningfully discuss differences.

The first lightning talk guide covers general preparation; the focus here is keeping one AI demo's claim, input, result and limit on a single slide. Find future opportunities on the events page; speaker slots vary by event.