Community Events & Workshops

We start from the FastAPI service we deployed to Railway in [the previous workshop](/workshops/end-to-end-agent-deployment), strip out FastAPI, and swap it for a custom AWS Lambda runtime. The runtime handles both the static frontend and the streaming agent API. We deploy one container image as a Lambda Function URL with SSE streaming. Most of the code-writing work is delegated to a coding agent (Codex). The exact prompts I used are quoted verbatim. This was a freestyle session, so it also surfaces a fair amount of meta-discussion: how to work with agents, when to trust them, and when to slow down and read the code. ## Links Related material: - [Previous workshop: end-to-end agent deployment](/workshops/end-to-end-agent-deployment) ## The shift versus the previous workshop The diagram below shows where Lambda fits in the request path: ```mermaid flowchart LR UI["Frontend UI<br/>vanilla JS, SSE"] LAMBDA["Lambda Function URL"] RUNTIME["Custom Lambda runtime<br/>backend/lambda_runtime.py"] AGENT["Agent loop"] SEARCH["FAQ search tool<br/>minsearch"] OPENAI["OpenAI Responses API"] UI -->|GET / and assets| LAMBDA UI -->|POST /ask, /ask/stream| LAMBDA LAMBDA --> RUNTIME RUNTIME --> AGENT AGENT -->|tool call| SEARCH AGENT -->|model call| OPENAI RUNTIME -->|JSON or streamed SSE| LAMBDA ``` The agent loop, the search tool, the renderer abstraction, and the frontend are unchanged from the previous workshop. What changes is the web layer and the deployment pipeline: - FastAPI is gone. A custom Lambda runtime (`backend/lambda_runtime.py`) handles routing, static file serving, and SSE streaming directly against the Lambda Runtime API. - The Dockerfile is rebased on `public.ecr.aws/lambda/python:3.14` instead of `python:3.14-slim`. - Deployment is done with `./deploy.sh`, which builds a container image, pushes it to ECR, and deploys a CloudFormation stack that creates the Lambda function and a Function URL with `RESPONSE_STREAM` invoke mode. - Railway and the GitHub Actions promotion workflow are gone. The benefit of moving to Lambda is the same in plain words: with Railway or Render you pay for a server that has to be up all the time. With a Lambda Function URL you only pay per invocation, which fits tools and small agents that are used occasionally. ## Extra material Additional pages outside the main flow: - [Appendix: isolating the AWS environment](/workshops/lambda-agent-deployment/tutorial/aws-account-isolation) - how to spin up an isolated AWS sub-account, mint short-lived credentials, and ship them to the box that runs the agent. Linked to the reproducible scripts in [aws-account/](https://github.com/AI-Shipping-Labs/workshops/tree/main/2026/2026-05-05-lambda-agent-deployment/aws-account).

We build a FAQ chatbot from notebook to production. You start with a Jupyter notebook that calls the OpenAI Responses API with a single `search` tool, then wrap it in FastAPI, add a vanilla-JS frontend with streaming (SSE), containerize with Docker, deploy to Railway, and wire up a GitHub Actions CI/CD pipeline. Each step is done alongside a coding agent. The prompts are included verbatim so you can reproduce the workflow with any agent you like. ## Links Useful resources for this workshop: - [Starting notebook (gist)](https://gist.github.com/alexeygrigorev/8c92913c23ec23e77ce8b355053ac531) ## The app you will build The final app looks like this: ```mermaid flowchart LR UI["Frontend UI<br/>vanilla JS, SSE"] API["FastAPI app"] AGENT["Agent loop"] SEARCH["FAQ search tool<br/>minsearch"] OPENAI["OpenAI Responses API"] UI -->|POST /ask or /ask/stream| API API --> AGENT AGENT -->|tool call| SEARCH AGENT -->|model call| OPENAI API -->|JSON or SSE| UI ``` The final app is a minimal teaching-assistant chatbot for the [DataTalks.Club Data Engineering Zoomcamp FAQ](https://datatalks.club/faq). One tool is exposed to the model: `search(query)`. Everything else is the web layer, the container, and the deploy pipeline.

Join us for the official launch of AI Shipping Labs! Valeriia and I are launching a new community for AI builders. In this session we'll walk through: - What AI Shipping Labs is and who it's for - The community structure: building sessions, group learning, accountability circles - How the platform was built (almost entirely by AI agents working autonomously) - The tiers and what you get at each level - Live Q&A Whether you're a software engineer moving into AI, an ML engineer who wants to go deeper, or anyone who wants to build and ship AI products — this is for you. Early members get a personal onboarding call to understand your goals and how the community can help.

A newer, combined version of this workshop is available: [Coding Agent with Skills](/workshops/coding-agent-v2). We start from the coding agent from the prerequisite workshop and turn it into a general-purpose coding agent with two reusable behavior layers: skills and slash commands. Skills are loaded by the agent when the user's request matches a skill description. Commands are invoked by the user with a leading slash and rendered into prompts before the agent acts. ## Links External resources for this workshop: - [Starting notebook](https://github.com/alexeygrigorev/workshops/blob/main/agent-skills/notebook.ipynb) - [GitHub fetch skill](https://github.com/alexeygrigorev/workshops/blob/main/agent-skills/gh-fetch-skill.md) - [Prototype implementation](https://github.com/alexeygrigorev/workshops/tree/main/agent-skills/prototype) - [Prerequisite coding-agent workshop](https://github.com/alexeygrigorev/workshops/tree/main/coding-agent) - [ToyAIKit](https://github.com/alexeygrigorev/toyaikit) - [OpenCode](https://github.com/anomalyco/opencode) - [OpenCode skills documentation](https://opencode.ai/docs/skills/) - [AgentSkills spec](https://agentskills.io) ## The agent you will build The final workshop system looks like this: ```mermaid flowchart LR USER["User"] RUNNER["ToyAIKit runner<br/>OpenAI Responses"] LLM["OpenAI model"] CODETOOLS["Coding tools<br/>read, write, tree, bash, search"] SKILLTOOL["skill(name) tool"] LOADER["SkillLoader"] SKILLS["skills/*/SKILL.md<br/>scripts and templates"] COMMANDS["commands/*.md"] COMMANDTOOL["execute_command(name, args)"] USER -->|plain request| RUNNER USER -->|/command| RUNNER RUNNER --> LLM RUNNER --> CODETOOLS RUNNER --> SKILLTOOL SKILLTOOL --> LOADER LOADER --> SKILLS RUNNER --> COMMANDTOOL COMMANDTOOL --> COMMANDS ``` The project stays small enough to understand in a notebook, but it mirrors the pieces used by real coding agents. The coding tools let the model read, write, search, and run commands. The skill loader turns `SKILL.md` files with YAML frontmatter into tool-loadable instructions. The command loader turns markdown files like `review.md` or `test.md` into reusable prompt templates.

We start with a DataTalks.Club Data Engineering Zoomcamp FAQ assistant, then add checks that keep the agent on topic, block unsafe responses, and show how to cancel wasted work when a guardrail fails. The workshop uses the OpenAI Agents SDK for built-in guardrails, then rebuilds the same idea with tools and plain `asyncio` so you can use it with other agent frameworks. ## Links The external resources: - [Related course: AI Bootcamp: From RAG to Agents](https://maven.com/alexey-grigorev/from-rag-to-agents) - [FAQ data used by the agent](https://datatalks.club/faq/) - [AI Hero email course for the docs.py loader](https://alexeygrigorev.com/aihero/) - [OpenAI Agents SDK guardrails documentation](https://openai.github.io/openai-agents-python/guardrails/) ## The notebook you will build The final notebook has guardrails around a tool-using FAQ agent: ```mermaid flowchart LR USER["User question"] INPUT["Input topic guardrail"] FAQ["FAQ assistant agent"] SEARCH["search_faq tool<br/>minsearch index"] OUTPUT["Output safety guardrail"] ANSWER["User-facing answer"] OPENAI["OpenAI model calls"] USER --> INPUT INPUT -->|passes| FAQ INPUT -->|trips| ANSWER FAQ --> SEARCH FAQ --> OPENAI INPUT --> OPENAI OUTPUT --> OPENAI FAQ --> OUTPUT OUTPUT -->|passes| ANSWER OUTPUT -->|trips| ANSWER ``` The base agent can already search the FAQ, but it tries to answer unrelated questions too. The input guardrail blocks questions outside the course domain. The output guardrail checks the agent response for policy problems such as promising deadline extensions or writing homework for a student. The later parts show the same checks as tools and as a small async runner that can cancel work when a guardrail trips.

We build a deep research agent over the DataTalks.Club podcast archive. The workshop starts by downloading and indexing YouTube transcripts, then turns that ingestion code into a durable Temporal workflow. After the data is searchable, we build a Pydantic AI research agent, add a summarization sub-agent for long transcripts, and wrap the agent run in Temporal too. ## Links The main resources for this workshop: - [Temporal CLI install notes](https://github.com/alexeygrigorev/workshops/blob/main/temporal.io/temporal-install.md) - [DataTalks.Club podcasts](https://datatalks.club/podcast.html) ## The system you will build The final system looks like this: ```mermaid flowchart LR YT["YouTube transcripts"] CACHE["Cached transcript files<br/>GitHub fallback"] FLOW["flow/<br/>Temporal ingestion"] ES["Elasticsearch<br/>podcasts index"] AGENT["agent/<br/>Pydantic AI research agent"] SUM["Summarization sub-agent"] TW["Temporal workflow<br/>agent run"] OPENAI["OpenAI"] YT -->|fetch_subtitles| FLOW CACHE -->|fetch_transcript_cached| FLOW FLOW -->|index_video| ES AGENT -->|search_videos| ES AGENT -->|summarize| SUM AGENT -->|model call| OPENAI SUM -->|model call| OPENAI TW -->|durable execution| AGENT ``` The ingestion side has the parts that usually fail in production: network calls, YouTube blocking cloud IPs, proxies, Elasticsearch writes, and long loops over many videos. Temporal gives that side retries, observability, and durable execution. The agent side uses the indexed data to answer questions from the podcast archive and then uses Temporal again so long agent runs can survive failures.

We build a course FAQ assistant from the bottom up. First we expose a plain Python `search(query)` function to the OpenAI Responses API. Then we turn the same idea into a reusable agent loop, compare `toyaikit`, OpenAI Agents SDK, and PydanticAI, and finally move the FAQ tools behind an MCP server that can be used from a notebook, PydanticAI, Cursor, and VS Code. ## Links The main resources: - [AI Bootcamp: From RAG to Agents](https://maven.com/alexey-grigorev/from-rag-to-agents) - [Prerequisite workshop: Building a Coding Agent](/events/building-coding-agent-python-django) - [Data Engineering Zoomcamp FAQ source document](https://docs.google.com/document/d/19bnYs80DwuUimHM65UV3sylsCn2j1vziPOwzBwQrebw/edit?tab=t.0) - [Parsed FAQ JSON](https://github.com/alexeygrigorev/llm-rag-workshop/blob/main/notebooks/documents.json) - [FAQ parsing notebook](https://github.com/alexeygrigorev/llm-rag-workshop/blob/main/notebooks/parse-faq.ipynb) ## The system you will build The final setup looks like this: ```mermaid flowchart LR NOTEBOOK["Jupyter notebook"] OPENAI["OpenAI Responses API"] FRAMEWORKS["Agents SDK<br/>PydanticAI"] MCPCLIENT["MCP clients<br/>toyaikit, PydanticAI, Cursor"] MCPSERVER["FastMCP server<br/>SSE or stdio"] TOOLS["FAQ tools<br/>search, add_entry"] INDEX["minsearch index<br/>FAQ JSON"] NOTEBOOK -->|function calling| OPENAI NOTEBOOK --> FRAMEWORKS FRAMEWORKS -->|tool calls| TOOLS NOTEBOOK -->|MCP client| MCPCLIENT MCPCLIENT -->|MCP protocol| MCPSERVER MCPSERVER --> TOOLS TOOLS --> INDEX ``` The FAQ data comes from the Data Engineering Zoomcamp FAQ. The first half of the workshop keeps the tools inside the notebook so you can see the agent loop directly. The second half moves the same tools into `mcp_faq/`, which makes them reusable by any MCP client.

A newer, combined version of this workshop is available: [Coding Agent with Skills](/workshops/coding-agent-v2). We build a small project bootstrapper for Django: a coding agent that takes a plain-language app request, copies a working Django template, reads and writes files through tools, and iterates until the generated app runs. The first implementation uses the OpenAI Responses API through `ToyAIKit`, then we try the same idea with OpenAI Agents SDK, `PydanticAI`, Anthropic, and Z.AI. ## Links The main resources: - [ToyAIKit](https://github.com/alexeygrigorev/toyaikit) - [Django template repo](https://github.com/alexeygrigorev/django_template) - [Todo app made with Z.AI](https://www.loom.com/share/b4c47e3491504375b9244ea69fe095df) - [Related course: AI Bootcamp: From RAG to Agents](https://maven.com/alexey-grigorev/from-rag-to-agents) - [Related workshop: Hands-on with AI Agents and MCP](https://maven.com/p/3b1afc/hands-on-with-ai-agents-and-model-context-protocol-mcp) ## The app you will build The coding agent is a notebook-based chat interface backed by an LLM and a small set of filesystem tools. You give it a request like `to-do list`. The agent edits a copied Django template and leaves you with a project you can run. ```mermaid flowchart LR USER["You<br/>short app request"] CHAT["Jupyter chat UI<br/>ToyAIKit"] RUNNER["Agent runner<br/>Responses API or framework"] TOOLS["AgentTools<br/>read, write, tree, grep, bash"] DJANGO["Copied Django template<br/>project folder"] LLM["LLM provider<br/>OpenAI, Anthropic, Z.AI"] USER -->|type request| CHAT CHAT --> RUNNER RUNNER -->|tool calls| TOOLS TOOLS -->|modify files| DJANGO RUNNER -->|messages and tools| LLM DJANGO -->|make run| USER ``` Two screenshots show what the finished workshop output looks like. The first one shows the notebook chat after the agent plans and starts calling file tools:  The second one shows one of the generated Django todo apps:  ## Result The simplest version is intentionally small. It runs in Jupyter, uses local filesystem tools, and edits one copied Django project folder. That is enough to understand how larger coding agents work under the hood: prepare a template, expose the right tools, give the model precise instructions, and iterate on the generated code.

We compare AI coding tools by asking them to help build the same small app: Snake in React. The session is a comparison, not a single production build, so the walkthrough follows the tool categories: chat applications, coding assistants and IDEs, project bootstrappers, and agents. ## Links The main resources: - [Lovable Snake preview](https://preview--hungry-hissing-haven.lovable.app/) - [AI Dev Tools Zoomcamp](https://github.com/DataTalksClub/ai-dev-tools-zoomcamp) - [AI Engineering Buildcamp](https://maven.com/alexey-grigorev/from-rag-to-agents) - [RAG agents workshop](https://github.com/alexeygrigorev/rag-agents-workshop) - [LLM Zoomcamp](https://github.com/DataTalksClub/llm-zoomcamp) ## The comparison The same app appears in several workflows: ```mermaid flowchart LR PROMPT["Prompt<br/>implement snake in react"] CHAT["Chat apps<br/>ChatGPT, Claude, DeepSeek, Ernie, Microsoft Copilot"] IDE["Coding assistants and IDEs<br/>Claude Code, GitHub Copilot, Cursor, Pear"] BOOT["Project bootstrappers<br/>Bolt, Lovable"] AGENTS["Agents<br/>tools, file access, computer use"] CHATAPP["Local app<br/>snake-chatgpt"] CLAUDEAPP["Local app<br/>snake-claude-code"] PREVIEW["Hosted app<br/>Lovable preview"] PROMPT --> CHAT CHAT --> CHATAPP IDE --> CLAUDEAPP BOOT --> PREVIEW AGENTS --> IDE AGENTS --> BOOT ``` The workshop code includes two Vite React projects. `snake-chatgpt` keeps the game in one component and is useful for seeing what a chat app can produce from a short prompt. `snake-claude-code` splits the page shell from the game component, adds score, start and restart flow, `WASD` controls, and a walls versus pass-through mode.

We build a search engine from scratch over DataTalks.Club Zoomcamp FAQ documents, starting with TF-IDF text search, adding cosine similarity and field boosting, then moving through SVD/LSA and BERT embeddings to vector search. The `TextSearch` class built during the workshop became the basis for the [minsearch](https://github.com/alexeygrigorev/minsearch) library used in later RAG and agent workshops. What we cover: - TF-IDF text search with sklearn, cosine similarity, field boosting and keyword filtering - A reusable `TextSearch` class (the foundation of minsearch) - Vector search using SVD and NMF embeddings - BERT embeddings for semantic search that respects word order Originally delivered at a [DataTalks.Club](https://www.youtube.com/@DataTalksClub) live session in 2024, updated in 2026 with refreshed examples and tooling. ## Links Resources not included in the workshop materials list: - [DataTalks.Club YouTube channel](https://www.youtube.com/@DataTalksClub) ## The search engine you will build The workshop covers two approaches to search over the same FAQ data: ```mermaid flowchart LR DOCS["FAQ documents<br/>DE/ML/MLOps Zoomcamp"] TEXT["Text search<br/>TF-IDF + cosine similarity<br/>field boosting + filtering"] VEC["Vector search<br/>SVD / NMF / BERT embeddings<br/>cosine similarity"] CLASS["TextSearch class<br/>(became minsearch)"] DOCS --> TEXT DOCS --> VEC TEXT --> CLASS VEC --> CLASS ``` Text search uses TF-IDF vectorization with field boosting (question weight 3x) and keyword filtering. Vector search replaces sparse representations with dense embeddings (SVD, NMF, then BERT) to handle synonyms and word order. The `TextSearch` class combines TF-IDF across multiple fields with boost weights and keyword filters, and later became the [minsearch](https://github.com/alexeygrigorev/minsearch) library.