How to Demo Your AI Agent Live Without It Falling Over

What the live demo is actually for

The invitation usually arrives phrased as a favour. Bring the agent along and show us — nothing formal. It is not nothing formal. Somewhere between the third and fifth round, a hiring loop at a Bengaluru product company or a London scale-up asks you to run your own agent in front of them, on their call, and then hands the keyboard over metaphorically by asking: can we try one?

Three things are being measured in that half hour, and only one of them is the agent.

• Can you bound a non-deterministic system? Anyone can get an agent to work once. The question is whether you have thought about iteration caps, timeouts, cost ceilings and kill switches, or whether you are relying on the run going well.
• Do you know how you would know it regressed? The demo is a sample of size one. The interviewer wants to hear about the golden set behind it, the failure taxonomy, the regression tests, and the cost per successful task. If those exist, the demo is a formality. If they do not, the demo is theatre.
• How do you behave when something breaks in public? This is the axis candidates underestimate most, and the one that separates people who have run agents in production from people who have run them on a laptop.

As of September 2026, the loops we see most often for agent-shaped roles in both India and the UK look something like this: a screening conversation, a live coding or AI-assisted round, a system-design round, and a portfolio or demo round. The demo round is the least well-defined of the four and therefore the one where preparation buys you the most. Our guide to the wider loop, including the live coding and AI-assisted rounds, covers the rest; this one is about the twenty minutes when your own agent is on screen.

One framing worth carrying through the whole piece: the demo should be confirming something the panel already half-believes about you, not introducing you. If your proof of work is discoverable before the call — a public repo, an eval harness, a portfolio built on proof of work rather than a résumé, a Verified Builder profile with the projects listed — then the live run is a corroboration. If the demo is the first evidence anyone has seen, you are asking a non-deterministic system to carry your entire candidacy in one take. That is a bad bet with any model, in any year.

Why agent demos break in ways normal software demos do not

A CRUD app demo fails in ways you can rehearse away. It fails on a missing migration, a stale cache, a certificate. Run it three times and you have found them. Agent demos have a different failure surface, because the thing you are demonstrating decides at runtime what to do next, and that decision is a distribution rather than a branch.

The recurring modes, roughly in the order they ruin interviews:

• Over-reasoning. The agent plans, revises the plan, considers alternatives, plans again, and never calls a tool. On a reasoning model with a generous thinking budget, this can eat ninety seconds of silence while five people watch a spinner. It is not a crash, so nothing in your code catches it.
• Runaway tool calls. The mirror image. The agent decides that the answer is one more search away, forty times. Costs climb, the context fills with noise, and the answer gets worse as it goes. Frameworks do guard this — LangGraph raises a GraphRecursionError once a graph passes its recursion_limit, and the OpenAI Agents SDK raises MaxTurnsExceeded past max_turns — but the defaults were not chosen with your demo in mind, and both are the kind of thing worth re-checking against the current documentation before you rely on them, and an uncaught framework exception on screen reads badly whatever it says.
• Retrieval drift on an unseen query. Your rehearsed queries hit documents you know are in the index. The interviewer's query lands in a thin region of the corpus, pulls three barely relevant chunks, and the agent answers confidently from them. This is the single most common way a demo goes wrong on someone else's question.
• Prompt regressions. You tightened the system prompt on the train that morning. It fixed the case you were worried about and broke two you were not. Without versioned prompts and an eval loop between change and deploy, you will not find out until the panel does.
• Non-determinism between runs. Even at temperature zero, tool ordering, retrieval ties, provider-side batching and model updates make repeated runs differ. The run you rehearsed is not the run they will see.
• The model changing underneath you. If you call an alias rather than a pinned version, the provider decides which model you demo on. This is a real and recurring hazard; we have written separately on verifying which model you are actually being served and on how a default model will get swapped under you.
• Network, rate limits and provider latency. Their office wifi, their VPN, a captive portal, an egress rule that blocks your provider's domain, a rate limit you have never hit because you have never run twelve retries in ninety seconds. And, periodically, a genuine provider latency spike that has nothing to do with you at all.

Notice what these have in common: almost none of them raise an exception you would catch in a normal test suite. They produce a run that is slow, or expensive, or wrong, but not obviously broken. Which is exactly why the fix is a budget, not a try-except.

The pre-flight checklist: pin, freeze, cap, budget

Everything survivable about a live agent demo comes from four verbs. Pin what a third party could change. Freeze what you could change by accident. Cap what the agent could do too much of. Budget what costs time or money. Work through this the day before, not the hour before.

Pre-flight checklist for a live agent demo. Settings are starting points for a ten-minute slot, not universal values — tune them against your own eval runs.

Guard	A sane setting	What it prevents	How you make it visible on screen
Pinned model version	Exact model identifier, never a floating alias	The provider rotating the default underneath your rehearsed behaviour	Print the resolved model id as the first line of the run header
Pinned prompt	Prompt file committed, hashed at load time	A last-minute wording tweak silently regressing two other cases	Print the prompt hash next to the model id
Locked dependencies	A lock file plus a pinned interpreter version, inside a container built yesterday	A transitive upgrade changing tokenisation, retries or JSON parsing	Run the demo from the container, and say so
Frozen index	Immutable snapshot with a build identifier and a document count	Retrieval drift because someone re-embedded the corpus on Monday	Print index build id and document count in the header
Seeded fixtures	A reset script that recreates known rows and files	The demo depending on a record that a cleanup job removed	Run the reset script in front of them; it takes four seconds
Cached expensive calls	Recorded HTTP cassettes for the rehearsed path, live calls for the open path	A provider latency spike on the one run that counts	Say which parts are replayed and which are live — always say it
Max iterations	Around 10 to 15 for a demo task	Runaway tool calls and the forty-search spiral	Show the step counter in the trace as it climbs
Per-step timeout	15 to 25 seconds, propagated into every tool call	One hanging tool eating the entire slot	A timed-out step that logs and continues is a good look
Wall-clock budget	60 to 120 seconds per run	Dead air, which is the real enemy on a video call	Stream partial progress so the panel sees movement
Cost ceiling	A per-run cap in your gateway or harness, checked every step, so a breach shows up within one step's spend	An invisible retry storm turning into a real bill	Print cumulative cost per step; interviewers love this
No-progress check	Halt on the third consecutive identical tool-call-plus-observation fingerprint	The loop that repeats the same failing call forever	Halt with a readable reason, not a stack trace
Offline fallback	Recorded run, plus a small local model behind the same interface	Their wifi, their VPN, the provider's bad afternoon	Switch in under twenty seconds and keep talking

The caps are the part people skip, so here is the shape of them in code. This is illustrative rather than a library — the point is that all five guards live in one place, and that hitting one raises something with a sentence a human can read.

import time
from dataclasses import dataclass

@dataclass
class RunBudget:
    max_iterations: int = 12
    per_step_timeout_s: float = 20.0
    wall_clock_s: float = 90.0
    cost_ceiling_usd: float = 0.40
    no_progress_after: int = 3


class BudgetExceeded(Exception):
    """Raised so the demo shows a guard firing, not a hang."""


def run_agent(task, agent, budget: RunBudget | None = None):
    budget = budget if budget is not None else RunBudget()
    started = time.monotonic()
    spent_usd = 0.0
    previous = None
    repeats = 0

    for step in range(budget.max_iterations):
        elapsed = time.monotonic() - started
        if elapsed > budget.wall_clock_s:
            raise BudgetExceeded(
                f"wall clock {elapsed:.1f}s over budget {budget.wall_clock_s}s"
            )
        if spent_usd > budget.cost_ceiling_usd:
            raise BudgetExceeded(
                f"spend ${spent_usd:.3f} over ceiling ${budget.cost_ceiling_usd}"
            )

        # Never let a single step outlive the run it belongs to.
        remaining = min(budget.per_step_timeout_s, budget.wall_clock_s - elapsed)
        result = agent.step(task, timeout_s=remaining)
        spent_usd += result.cost_usd

        print(f"step {step:>2}  {result.tool:<18} "
              f"{result.latency_ms:>5}ms  ${spent_usd:.3f}")

        if result.done:
            return result

        # No progress = same tool, same arguments, same observation,
        # immediately after the last step. Compare with the previous
        # fingerprint only, so an A, B, A, B alternation does not trip it.
        fingerprint = (result.tool, result.args_digest, result.observation_digest)
        repeats = repeats + 1 if fingerprint == previous else 1
        previous = fingerprint
        if repeats >= budget.no_progress_after:
            raise BudgetExceeded(
                f"no progress: {repeats} identical consecutive steps on {result.tool}"
            )

    raise BudgetExceeded(f"hit iteration cap of {budget.max_iterations}")

Three details matter more than the rest. The per-step timeout is clamped by the remaining wall-clock budget, so a late step cannot overshoot the run; candidates routinely set both and then let the last step blow through the total. The no-progress fingerprint includes the observation, not just the call, and it is compared only with the step immediately before it — an agent that makes the same search and gets the same empty result three times running is stuck, whereas one that alternates between two calls, or retries with a corrected argument, is still doing something. And the spend check happens at the top of each step rather than before the call, so a run can pass the ceiling by one step's worth of tokens before it halts; set the ceiling with that headroom in mind, or project the next step's cost before you make the call.

Design three paths — and show the failing one on purpose

Do not prepare a demo. Prepare three, and run them in this order.

The happy path. One task you have run a hundred times, on frozen fixtures, that finishes inside your wall-clock budget with a visibly correct result. Its job is to establish that the thing works and to get the panel comfortable. Keep it short. Two minutes, not six. Resist the urge to narrate every step; you will want that time later.

The deliberately hard path. A task you chose because it is genuinely difficult for your architecture — an ambiguous instruction, a query needing two retrieval hops, a tool that returns a malformed payload you handle. This is where you show judgement rather than function. Say out loud why it is hard, before you run it. If it succeeds, you have demonstrated depth. If it half-succeeds, you have demonstrated honesty, and you can talk about what would fix it.

The failure path. A run where you trigger a guard yourself and let the panel watch it fire. Pull the network for a tool call and show the retry, the backoff and the graceful degradation. Feed a task designed to loop and let the no-progress check halt it. Point a tool at a permission it does not have and show the refusal. This is the segment candidates never prepare, and it is consistently the one that changes minds — the discipline behind it is the same one covered in designing agents that fail safe, with bounded blast radius and kill switches.

There is a reason this works. Interviewers who have shipped agents have all been burnt by a demo that worked in the room and fell over in the first week of production. Their scepticism is trained. A candidate who volunteers the failure mode, bounds it, and shows the guard catching it is answering the question the panel was actually going to ask, before they ask it. In most loops, that candidate beats the one whose demo merely worked.

The "type your own query" moment, without gambling

At some point the interviewer will ask to try one themselves. Never refuse this — refusing reads as a confession. But you can shape it so that it is a test you are prepared for rather than a coin flip.

Three moves, all of which take seconds and all of which are things a well-built product should do anyway.

Scope the corpus out loud, before they type. Something like: this index has about four thousand UK company filings from 2023 to 2025, so anything about a company's financials in that window is fair game; it knows nothing about people, nothing about litigation, and nothing after 2025. That sentence does three jobs. It gives them a productive question to ask. It makes any out-of-scope answer a demonstration rather than a failure. And it signals that you think in terms of what a system does not cover, which is a senior habit.

Make the out-of-scope response a real, tested path. The refusal should name the boundary and offer the nearest thing the agent can do: I do not have litigation records in this index. I can tell you what the filings say about provisions and contingent liabilities for this company, if that helps. Write it, test it, put it in your eval set. An agent that declines cleanly on an out-of-domain question is a strictly better result than one that confabulates, and every experienced interviewer knows it. If you have never run that path, they will notice, because untested refusals come out either curt or waffly.

Keep the open run inside the same budget. Same iteration cap, same wall-clock ceiling, same cost cap. Do not quietly relax the limits because you want their question to succeed. If their query hits the cap, that is useful information for both of you, and you say so.

If your corpus contains anything you do not control — user-supplied documents, scraped pages, anything a third party wrote — assume it can carry an injection, and demo with that assumption visible. On an open query round, being able to say we treat every retrieved document as untrusted, here is where that boundary sits is worth more than a clean answer.

The eval is the interview, not the demo

Here is the thing candidates find hardest to accept: the people you most want to impress are the ones least impressed by a working demo. They have seen dozens. They know a demo is one sample from a distribution, chosen by the person being assessed, on data that person controls. What they cannot fake for themselves, and therefore what they weigh heavily, is the unglamorous apparatus around it.

Have four artefacts ready to put on screen the moment the conversation turns this way.

• The golden set. Thirty to a hundred and fifty tasks with expected outcomes, versioned in the repo, with a note on where they came from. Sets derived from real usage beat invented ones every time — the method is in building evals from production logs by doing error analysis first and in our guide to running a human annotation pipeline. Be ready to say why a task is in the set.
• The failure taxonomy. A named, counted list of the ways your agent gets things wrong: retrieval miss, wrong tool selected, malformed arguments, tool error mishandled, correct plan abandoned early, hallucinated citation. With counts against the current version. This single artefact does more to establish seniority than any amount of demo polish, because it proves you have looked at your own failures systematically rather than anecdotally.
• Regression tests that run. Ideally in CI, gating a merge, in the pattern described in putting your evals in CI for prompt and agent regression. Show a run. Show one that failed and the commit that fixed it.
• Cost and latency per successful task. Not per token, per successful task — the distinction is the whole of LLM unit economics. If you can say "£0.11 per successful task at p50, £0.34 at p95, and here is why the tail is fat" — or, for a team that budgets in rupees, "₹6 at p50, ₹19 at p95, and the tail is the reranker" — you are having a different conversation from every other candidate that week. Both sets of figures here are illustrative and independent of each other; what matters is that you quote them per successful task, in the currency the business actually plans in.

Scoring the run itself deserves a word too. Outcome alone is a weak signal for agents; the trajectory and the tool calls carry most of the information, which is the argument made in evaluating agents on trajectory, tool calls and outcome. And if you are asked how you keep an eval honest once you start optimising against it, the answer lives in building evals your agent cannot game. Both are questions a good panel will actually ask.

Narrating trade-offs while the run is going

The dead time while an agent thinks is not dead time; it is your best speaking slot, and most candidates waste it apologising for latency. Fill it with the three things a senior listener is waiting for.

What you chose not to build, and why. "There is no planner here. For this task distribution a fixed three-stage pipeline beat a planning loop on both accuracy and cost in my evals, so the flexibility was not worth the variance. If the task mix widened I would revisit it." That is a design decision with a reason and a trigger for reversing it, which is exactly what a staff-level conversation sounds like.

What it costs per run, and where the money goes. Know which step dominates. "Reranking is sixty per cent of the cost and fourteen per cent of the quality gain; I keep it because the failure mode without it is confident wrong answers, which is expensive in a different way."

How you would know if it regressed. Name the metric, the threshold and the alarm. "If tool-call validity drops below ninety-four per cent on the golden set, CI fails and it does not merge. In production I would tail-sample traces and alert on the same metric weekly." If you have instrumented anything, say what — the OpenTelemetry-based approach to agent traces and cost attribution is a good thing to have opinions about.

The same discipline applies to how you describe your own use of AI tooling while building the thing. Be specific and unembarrassed about it; the guidance in talking about AI-assisted work in interviews holds here, and a panel watching an agent demo will absolutely ask how much of the agent an agent wrote.

When it breaks: recovery, logistics and what to leave out

Assume it will break at least once. The difference between candidates is entirely in the next sixty seconds.

The recovery script

Have the shape of the response memorised, and use it in order. Name it, bound it, convert it.

Name it, immediately and without apology. Do not narrate hope. The worst version of this is thirty seconds of "it is usually faster than this, let me just…" while everyone watches a spinner. Say what has happened in one sentence, in the first three seconds.

Bound it. Say what class of failure it is, whether you have seen it before, and roughly how often. This converts an incident into a known quantity, and known quantities are what engineers are hired to produce.

Convert it into evidence. Every failure is an invitation to open the artefact behind it — the trace, the taxonomy entry, the eval case, the guard's configuration. A candidate who responds to a failure by opening their failure taxonomy has turned the worst moment of the demo into the best one.

Actual phrasing matters more than the theory here, so rehearse these until they are boring. Adapt the specifics to your own system.

Recovery phrasing for the six things most likely to go wrong on camera. Say it in the first three seconds, then move on within a minute.

What just happened	What to say, roughly
A guard halted the run	"Right — that is the no-progress guard firing. It stopped on the third identical search in a row, which is the behaviour I want. Let me show you the trace."
A thin or wrong answer on their query	"That is the retrieval-miss case, number two in my failure taxonomy. It is a known slice of my golden set and it is the one I have not fixed yet — the fix is a query-rewrite step, and I have not built it because it adds a round trip I cannot yet justify."
A rate limit or provider error	"That is a rate limit from the provider, not my budget. I have a local fallback behind the same interface — twenty seconds and we carry on with a smaller model, and you will see the quality difference, which is honestly a useful comparison."
The wall-clock budget expired	"Ninety-second budget and it used all of it, so on this task I would call that a fail. Here is the step trace — most of it went on reranking, which is the first thing I would cut."
Something you cannot explain	"I do not know what that is yet, and I am not going to guess on camera. Let me note the trace id, carry on with the next path, and I will send you the diagnosis this evening."
The network or share drops	"Losing you — switching to the tethered connection now. If it is not back in twenty seconds I will play the recorded run and we can talk over it."

The conversion move is worth practising on its own, because it is the one that changes the verdict: "since we are here, this is exactly the case I would want a regression test for — let me add it to the golden set while we talk, it takes ten seconds and it is what I would do at work." You have just demonstrated the loop the job is actually about.

Then move on. One minute, maximum. Do not debug live unless they ask you to, and if they do ask, treat it as a different exercise entirely: think out loud, form a hypothesis, check one thing at a time, and say what you would look at next if this were production.

Remote-interview logistics

Most of these interviews are remote, in both markets, and a meaningful share are cross-border — a Bengaluru candidate interviewing with a London team, or the reverse, which is its own logistical exercise covered in landing remote global roles from India and the UK. The unglamorous details cause more demo failures than the models do.

• Share a window, not a desktop. It bounds what leaks — notifications, tabs, that other client's folder name.
• Font size, twice as large as feels sensible. Screen-share compression is brutal on 12pt terminal text, and half your panel is on a laptop. Set terminal and editor to something you would call comical at your desk, and shorten your prompt so the path does not eat the line.
• Test on the actual platform. Zoom, Google Meet and Microsoft Teams all degrade shared video differently. Do a five-minute dry run on the one in the invitation, with a friend on the other end telling you what is legible.
• Tether, and know how to switch. Have a phone hotspot paired and tested before the call. In practice, be ready to switch mid-call in under twenty seconds, which means having done it once.
• Never demo on conference or co-working wifi without a fallback. Captive portals, blocked egress and shared-bandwidth collapse are all normal. If you are demoing from a venue, assume the network is hostile.
• Time-zone arithmetic. An India–UK loop is a four-and-a-half or five-and-a-half hour gap depending on the time of year, and a demo slot that lands at 21:00 IST is a demo slot where your home network is congested. Ask for the slot you can control.
• Have the recording open in a second tab. A clean, narrated, full-run capture of the happy path and the hard path, made yesterday. You are not planning to play it. You are planning to have it.

What to leave out entirely

Four things belong nowhere near a live interview demo.

• Live fine-tuning. Nobody has ever been hired because a training run started successfully on a call, and the failure surface is enormous. Show the artefacts and the eval delta instead.
• Anything you are running for the first time in front of them. The path you have not run end to end at least ten times is not a demo, it is a gamble on which you have staked the round.
• An unbounded budget. Demoing without caps says either that you do not know they are needed or that you did not bother. Both are worse than the demo being slightly less impressive.
• Secrets on screen. This one is not just embarrassing, it is a live incident. Before the call: run a secret scanner over the repo (gitleaks, trufflehog and detect-secrets all do this well); move every key into environment variables loaded from a file you never open on camera; redact keys and bearer tokens in your log formatter, not just in your head; check that traces and any observability dashboard you might open are not showing customer records or tenant identifiers; rename any fixture that carries a real client's name; and close the password manager, the email client and the other terminal. The broader discipline is in least-privilege credentials for AI agents. A candidate who casually exposes a production key has answered a security question nobody needed to ask.

Demoing under NDA

Most of the best agent work being done across India and the UK right now is inside somebody's company, under an agreement that says you cannot show it. The wrong response is to demo the real thing on a client tenant and hope. The right response is a public shell around private work.

Keep the shape, drop the specifics. Substitute a public or synthetic corpus of similar structure and scale for the client's documents — Companies House filings, open government data, a public documentation set, or generated records with the same messiness. Rename the domain. Then reproduce the hard part faithfully, because the hard part is not the data: it is the tool contracts, the retry and repair logic, the guard configuration, the eval harness and the failure taxonomy. All of that is your engineering, and none of it is confidential.

Say plainly what you have done: the original is under NDA, so this is a clean-room reconstruction on public filings; the architecture, the guards and the eval set mirror the production system, the data does not. That is a stronger position than a vague description of impressive work nobody can see, and it is a well-trodden path — see proof of work when your best work is under NDA and, if you want the reconstruction to double as a public artefact, shipping a public agent plus eval harness as your proof of work.

Which brings the argument back where it started. The reason the reconstruction is worth building is not the demo — it is that it exists before anyone asks. A live run is one sample, taken under pressure, on someone else's network, at a time you did not choose. A public repo, an eval harness with a real golden set, and a Verified Builder profile listing what you have actually shipped are the same evidence, available at any hour, in a form that survives a bad wifi day. Worth knowing how the badges here work, because it makes the same point: on AI Tech Connect the Founding Builder badge goes to the first hundred Builders to reach Verified, and Verified is earned from endorsements by other people, not granted at signup. Creating a profile starts that clock; it does not finish it. Which is the argument in one line — the work of making your proof of work visible accrues over weeks, and it is not work you can improvise in the twenty minutes when your agent is on screen. Put the profile up now and let it be the artefact doing this job when you are not in the room. The demo then becomes what it should always have been: a confirmation, not an audition.