Setting Up a Live AI Agents Workshop

What a live AI agents workshop actually is

A live AI agents workshop is a session where several people run a coding agent at the same time, usually on their own machines, and at least one person needs to watch more than one of those agents working in real time rather than reviewing a recap afterward. That live-watching requirement is what separates it from a slide talk or a recorded demo.

The scale changes the problem. Watching one person's terminal over their shoulder is easy. Watching ten agents at once, each running at its own pace and sometimes stopping to ask a question, is a different exercise, and most of the failure modes in a badly run workshop trace back to nobody deciding in advance how that visibility was going to work.

Plan the session around the three decisions that actually determine whether it goes well: where the agents run, how credentials are handed out, and how the facilitator sees what is happening.

• A workshop is live if someone needs to see several agents working at the same time, not just hear a summary.
• Scale is the real difficulty: one terminal is easy to watch, ten at once is not.
• Decide where agents run, how keys are issued, and how visibility works before the room fills.

Amazon Connect is a different product, not a workshop platform

Amazon Connect is AWS's cloud contact center service, and its AI agent features, Agent Assist for a human representative and Agentic Self-Service for unattended handling, are built around phone and chat support, not coding agents in a terminal. Access to those agents runs through ordinary AWS identity controls: an IAM role scoped to the Connect instance and AWS Secrets Manager for anything a Lambda function behind it needs.

AWS does run real, hands-on training for Connect, through AWS Workshop Studio at catalog.workshops.aws, its standard platform for self-paced immersion days across AWS services. That is a legitimate thing to attend if your workshop goal is learning to build a Connect contact flow. It has nothing to do with supervising a room of people running Claude Code, Codex or another coding agent, which is what most people typing this query are actually trying to set up.

If your subject is a coding agent workshop, treat Amazon Connect as unrelated and skip it. The rest of this page is the actual setup.

• Amazon Connect's AI agents (Agent Assist, Agentic Self-Service) target contact centers, not coding agents.
• AWS Workshop Studio at catalog.workshops.aws is real, but it is Connect-specific training, not a coding-agent workshop tool.
• A coding agent workshop does not need Amazon Connect at any point.

Decide where the agents run before anything else

There are two realistic shapes. The first is everyone on their own laptop, running whichever coding agent you chose locally, with nothing shared except the brief they are all working from. This costs nothing extra and needs no lead time, but it means every attendee needs the tool installed and working before the session starts, which is the single most common cause of a slow opening.

The second is a shared cloud workspace, such as a per-attendee GitHub Codespace, where everyone gets an isolated container with the tool pre-installed. This removes the setup problem but adds its own cost and lead time: someone has to provision and pay for those environments in advance, and a flaky network turns a shared cloud setup into a shared outage.

Pick based on your actual constraint. A short session with a known, prepared group can usually get away with local laptops and a very clear pre-read. A public workshop with mixed skill levels is often better served by pre-provisioned cloud workspaces, even at the extra cost, because it removes the one failure point you cannot fix live.

• Local laptops: no extra cost, but every attendee must arrive with the tool already installed.
• A shared cloud workspace per attendee: removes setup friction, adds provisioning cost and a network dependency.
• Match the choice to how prepared and how mixed-skill the group actually is.

Give every attendee their own key, not one for the room

The fastest way to leak a credential at a workshop is to hand one key to the whole room, written on a slide or dropped in a shared chat. Someone will screenshot it, paste it somewhere public by accident, or still have it working weeks after the session, because nobody owns revoking a key nobody individually received.

The better pattern is one credential per attendee, scoped as narrowly as the exercises allow and set to expire at or shortly after the session ends. Most model providers and many internal systems support a short-lived or scoped token for exactly this kind of temporary access; use it rather than reusing a long-lived production key because it was convenient to have on hand.

This is the same failure this page's sibling page on workshop key safety covers in more depth, including what to do about a key that already made it onto a projected screen. Treat it as a checklist to run before the room opens, not something to improvise once people are seated.

• One shared key for the whole room is a near-guaranteed leak.
• Issue one scoped, short-lived credential per attendee.
• Decide revocation before the session, not after someone asks whether they still have access.

Making several live agents visible to one facilitator

Screen sharing is the obvious default and it works fine for a one-on-one or a small group, but it does not scale past a handful of screens, and switching between shared screens mid-session loses whatever was happening on the ones you are not looking at.

A terminal multiplexer such as tmux or zellij lets one person arrange several panes, each running a different agent, into a single projected view, which works well for a live demo where you are driving all the agents yourself rather than watching attendees' individual machines.

If attendees are running their own agents on their own Macs and you specifically need a facilitator to see one attendee's terminal live, Forkbench's Live Link opens a view of a Thread to someone invited into it, without handing over control of the attendee's machine. The limit is worth stating plainly: Live Link only opens for someone invited into that specific Thread, it is not a broadcast tool for watching a whole room at once, and it only covers agents an attendee chose to run inside a Forkbench terminal on their own Mac.

• Screen sharing works for a small group, not for watching many agents at once.
• A terminal multiplexer lets one presenter project several agents from a single machine.
• Forkbench's Live Link gives an invited facilitator a live view of one Thread; it is not a room-wide broadcast and only covers agents run inside Forkbench on a Mac.

A run of show that actually holds up

Write down the sequence before the day arrives, because live sessions drift the moment something small goes wrong, and a written plan is what gets you back on track instead of improvising in front of the room.

Test the whole path, credential issuance through to the facilitator's view, with two or three people a day before the real session. Most problems that derail a workshop were visible in a small test run and ignored because the main run felt too close to cancel and fix properly.

• Send setup instructions and any required installs at least a day in advance, with a working test step attendees confirm themselves.
• Have a fallback for a dead network: a local-only exercise that needs no shared cloud workspace.
• Issue credentials right before the session starts, not the night before.
• Revoke or expire every workshop credential the same day, and confirm it actually stopped working.
• Run the full path once with two or three people before the real session.