Docker recently completed an internal 24-hour hackathon that had a fairly simple goal: create an agent that helps you be more productive.<\/p>\n
As I thought about this topic, I recognized I didn\u2019t want to spend more time in a chat interface. Why can\u2019t I create a fully automated agent that doesn\u2019t need a human to trigger the workflow? At the end of the day, agents can be triggered by machine-generated input.<\/strong><\/p>\n In this post, we\u2019ll build an event-driven application with agentic AI. The event-driven agent we\u2019ll build will respond to GitHub webhooks to determine if a PR should be automatically closed. I\u2019ll walk you through the entire process from planning to coding, including why we\u2019re using the Gemma3 and Qwen3 models, hooking up the GitHub MCP server with the new Docker MCP Gateway<\/a>, and choosing the Mastra agentic framework.<\/p>\n Docker has a lot of repositories used for sample applications, tutorials, and workshops. These are carefully crafted to help students learn various aspects of Docker, such as writing their first Dockerfile<\/a>, building agentic applications<\/a>, and more.<\/p>\n Occasionally, we\u2019ll get pull requests from new Docker users that include the new Dockerfile they\u2019ve created or the application updates they\u2019ve made.<\/p>\n Sample pull request in which a user submitted the update they made to their website while completing the tutorial<\/em><\/p>\n Although we\u2019re excited they\u2019ve completed the tutorial and want to show off their work, we can\u2019t accept the pull request as it\u2019ll impact the ability for the next person to complete the work.<\/p>\n Recognizing that many of these PRs are from brand new developers, we want to write a nice comment to let them know we can\u2019t accept the PR, yet encourage them to keep learning.<\/p>\n While this doesn\u2019t take a significant amount of time, it does feel like a good candidate for automation. We can respond more timely and help keep PR queues focused on actual improvements to the materials.<\/p>\n The goal:<\/strong> Use an agent to analyze the PR and detect if it appears to be a \u201cI completed the tutorial\u201d submission, generate a comment, and auto-close the PR. And can we automate the entire process?<\/p>\n Fortunately, GitHub has webhooks that we can receive when a new PR is opened.<\/p>\n As I broke down the task, I identified three tasks that need to be completed:<\/p>\n Analyze the PR<\/strong> \u2013 look at the contents of the PR and possibly expand into the contents of the repo (what\u2019s the tutorial actually about?). Determine if the PR should be closed.<\/p>\n Generate a comment<\/strong> \u2013 generate a comment indicating the PR is going to be closed, provide encouragement, and thank them for their contribution.<\/p>\n Post the comment and close the PR \u2013 <\/strong>do the actual posting of the comment and close the PR.<\/p>\n With this setup, I needed an agentic application architecture that looked like this:<\/p>\n Architecture diagram showing the flow of the app: PR opened in GitHub triggers a webhook that is received by the agentic application and delegates the work to three sub-agents<\/em><\/p>\n The first thing I did was pick an agentic framework. I ended up landing on Mastra.ai<\/a>, a Typescript-based framework that supports multi-agent flows, conditional workflows, and more. I chose it because I\u2019m most comfortable with JavaScript and was intrigued by the features the framework provided.<\/p>\n After choosing the framework, I next chose the tools that agents would need. Since this was going to involve analyzing and working with GitHub, I chose the GitHub Official MCP server<\/a>.\u00a0<\/p>\n The newly-released Docker MCP Gateway<\/a> made it easy for me to plug it into my Compose file. Since the GitHub MCP server has over 70 tools, I decided to filter the exposed tools to include only those I needed to reduce the required context size and increase speed.<\/p>\n The .env file provided the GitHub Personal Access Token required to access the APIs:<\/p>\n Now, I needed to pick models. Since I had three agents, I could theoretically pick three different models. But, I also wanted to reduce model swapping if possible, yet keep performance as quick as possible. I experimented with a few different approaches, but landed with the following:<\/p>\n PR analyzer \u2013 ai\/qwen3<\/a> \u2013 I wanted a model that could do more reasoning and could perform multiple steps to gather the context it needed<\/p>\n Comment generator \u2013 ai\/gemma3<\/a> \u2013 the Gemma3 models are great for text generation and run quite quickly<\/p>\n PR executor \u2013 ai\/qwen3<\/a> \u2013 I ran a few experiments, and the qwen models did best for the multiple steps needed to post the comment and close the PR<\/p>\n I updated my Compose file with the following configuration to define the models. I gave the Qwen3 model an increased context size to have more space for tool execution, retrieving additional details, etc.:<\/p>\n With the models and tools chosen and configured, it was time to write the app itself! I wrote a small Dockerfile and updated the Compose file to connect the models and MCP Gateway using environment variables. I also added Compose Watch<\/a> config to sync file changes into the container.<\/p>\n The Mastra framework made it pretty easy to write an agent. The following snippet defines a MCP Client, defines the model connection, and creates the agent with a defined system prompt (which I\u2019ve abbreviated for this blog post).\u00a0<\/p>\n You\u2019ll notice the usage of environment variables, which match those being defined in the Compose file. This makes the app super easy to configure.<\/p>\n const SYSTEM_PROMPT = ` const mcpGateway = new MCPClient({ const openai = createOpenAI({ export const prExecutor = new Agent({ I was quite impressed with the Mastra Playground, which allows you to interact directly with the agents individually. This makes it easy to test different prompts, messages, and model settings. Once I found a prompt that worked well, I would update my code to use that new prompt.<\/p>\n The Mastra Playground showing ability to directly interact with the \u201cPull request analyzer\u201d agent, adjust settings, and more.<\/em><\/p>\n Once the agents were defined, I was able to define steps and a workflow that connects all of the agents. The following snippet shows the defined workflow and conditional branch that occurs after determining if the PR should be closed:<\/p>\n With the workflow defined, I could now add the webhook support. Since this was a simple hackathon project and I\u2019m not yet planning to actually deploy it (maybe one day!), I used the smee.io<\/a> service to register a webhook in the repo and then the smee-client<\/a> to receive the payload, which then forwards the payload to an HTTP endpoint.<\/p>\n The following snippet is a simplified version where I create a small Express app that handles the webhook from the smee-client, extracts data, and then invokes the Mastra workflow.<\/p>\n const app = express(); app.post(“\/webhook”, async (req, res) => { if (!payload.pull_request) if (payload.action !== “opened” && payload.action !== “reopened”) const repoFullName = payload.pull_request.base.repo.full_name;<\/p>\n const initData = { res.status(200).send(“Webhook received”);<\/p>\n const workflow = await mastra.getWorkflow(“prAnalyzer”).createRunAsync(); const server = app.listen(3000, () => console.log(“Server is running on port 3000”));<\/p>\n const smee = new SmeeClient({ At this point, I can start the full project (run docker compose up) and open a PR. I\u2019ll see the webhook get triggered and the workflow run. And, after a moment, the result is complete! It worked!<\/p>\n Screenshot of a GitHub PR that was automatically closed by the agent with the generated comment.<\/em><\/p>\n If you\u2019d like to view the project in its entirety, you can check it out on GitHub at mikesir87\/hackathon-july-2025<\/a>.<\/p>\n Looking back after this hackathon, I learned a few things that are worth sharing as a recap for this post.<\/p>\n Going beyond the chatbot opens up a lot of automation possibilities and I\u2019m excited to be thinking about this space more.<\/p>\n It took many<\/em> iterations to develop prompts that guided the models to do the right thing consistently. Using tools and frameworks that let you iterate quickly help tremendously (thanks Mastra Playground!).<\/p>\n I experimented with quite a few models to find those that would handle the tool calling, reasoning, and comment generation. I wanted the smallest model possible that would still work. It was easy to simply adjust the Compose file, have environment variables be updated, and try out a new model.<\/p>\n I was having struggles writing a prompt that would get the final agent to simply post a comment and close the PR reliably \u2013 it would often post the comment multiple times or skip the PR closing. But, I found myself asking \u201cdoes an agent need to do this step? This step feels like something I can do programmatically without a model, GPU usage, and so on. And it would be much faster too.\u201d I do think that\u2019s something to consider \u2013 how to build workflows where some steps use agents and some steps are simply programmatic (Mastra supports this by the way).<\/p>\n Due to the timing, I didn\u2019t get a chance to explore much on the testing front. All of my \u201ctesting\u201d was manual verification. So, I\u2019d like to loop back on this in a future iteration. How do we test this type of workflow? Do we test agents in isolation or the entire flow? Do we mock results from the MCP servers? So many questions.<\/p>\n\n This internal hackathon was a great experience to build an event-driven agentic application. I\u2019d encourage you to think about agentic applications that don\u2019t require a chat interface to start. How can you use event-driven agents to automate some part of your work or life? I\u2019d love to hear what you have in mind!<\/p>\n View the hackathon project on GitHub<\/a><\/p>\n Try Docker Model Runner<\/a> and MCP Gateway<\/a><\/p>\n Sign up for our Docker Offload beta program<\/a> and get 300 free GPU <\/strong>minutes to boost your agent.\u00a0<\/p>\n Use Docker Compose<\/a> to build and run your AI agents<\/p>\nThe problem space<\/h2>\n
The plan to automate<\/h2>\n
Building an event-driven application with agentic AI<\/h2>\n
1. Select the right agent tools<\/h3>\n
\n mcp-gateway:
\n image: docker\/mcp-gateway:latest
\n command:
\n – –transport=sse
\n – –servers=github-official
\n – –tools=get_commit,get_pull_request,get_pull_request_diff,get_pull_request_files,get_file_contents,add_issue_comment,get_issue_comments,update_pull_request
\n use_api_socket: true
\n ports:
\n – 8811:8811
\n secrets:
\n – mcp_secret
\nsecrets:
\n mcp_secret:
\n file: .env\n<\/div>\n2. Choose and add your AI models<\/h3>\n
\n gemma3:
\n model: ai\/gemma3
\n qwen3:
\n model: ai\/qwen3:8B-Q4_0
\n context_size: 131000\n<\/div>\n3. Write the application<\/h3>\n
\n app:
\n build:
\n context: .
\n target: dev
\n ports:
\n – 4111:4111
\n environment:
\n MCP_GATEWAY_URL: http:\/\/mcp-gateway:8811\/sse
\n depends_on:
\n – mcp-gateway
\n models:
\n qwen3:
\n endpoint_var: OPENAI_BASE_URL_ANALYZER
\n model_var: OPENAI_MODEL_ANALYZER
\n gemma3:
\n endpoint_var: OPENAI_BASE_URL_COMMENT
\n model_var: OPENAI_MODEL_COMMENT
\n develop:
\n watch:
\n – path: .\/src
\n action: sync
\n target: \/usr\/local\/app\/src
\n – path: .\/package-lock.json
\n action: rebuild\n<\/div>\n
\nimport { MCPClient } from “@mastra\/mcp”;
\nimport { createOpenAI } from “@ai-sdk\/openai”;
\nimport { Memory } from “@mastra\/memory”;
\nimport { LibSQLStore } from “@mastra\/libsql”;\n
\nYou are a bot that will analyze a pull request for a repository and determine if it can be auto-closed or not.
\n…`;<\/p>\n
\n servers: {
\n mcpGateway: {
\n url: new URL(process.env.MCP_GATEWAY_URL || “http:\/\/localhost:8811\/sse”),
\n },
\n },
\n});<\/p>\n
\n baseURL: process.env.OPENAI_BASE_URL_ANALYZER || “http:\/\/localhost:12434\/engines\/v1”,
\n apiKey: process.env.OPENAI_API_KEY || “not-set”,
\n});<\/p>\n
\n name: ‘Pull request analyzer,
\n instructions: SYSTEM_PROMPT,
\n model: openai(process.env.OPENAI_MODEL_ANALYZER || “ai\/qwen3:8B-Q4_0”),
\n tools: await mcpGateway.getTools(),
\n memory: new Memory({
\n storage: new LibSQLStore({
\n url: “file:\/tmp\/mastra.db”,
\n }),
\n }),
\n});\n<\/p><\/div>\n
\n id: “prAnalyzerWorkflow”,
\n inputSchema: z.object({
\n org: z.string().describe(“The organization to analyze”),
\n repo: z.string().describe(“The repository to analyze”),
\n prNumber: z.number().describe(“The pull request number to analyze”),
\n author: z.string().describe(“The author of the pull request”),
\n authorAssociation: z.string().describe(“The association of the author with the repository”),
\n prTitle: z.string().describe(“The title of the pull request”),
\n prDescription: z.string().describe(“The description of the pull request”),
\n }),
\n outputSchema: z.object({
\n autoClosed: z.boolean().describe(“Whether the PR was auto-closed”),
\n comment: z.string().describe(“Comment to be posted on the PR”),
\n }),
\n })
\n .then(determineAutoClose)
\n .branch([
\n [
\n async ({ inputData }) => inputData.recommendedToClose,
\n createCommentStep
\n ]
\n ])
\n .then(prExecuteStep)
\n .commit();\n<\/div>\n
\nimport SmeeClient from ‘smee-client’;
\nimport { mastra } from “.\/mastra”;\n
\napp.use(express.json());<\/p>\n
\n const payload = JSON.parse(req.body.payload);<\/p>\n
\n return res.status(400).send(“Invalid payload”);<\/p>\n
\n return res.status(200).send(“Action not relevant, ignoring”);<\/p>\n
\n prNumber: payload.pull_request.number,
\n org: repoFullName.split(“\/”)[0],
\n repo: repoFullName.split(“\/”)[1],
\n author: payload.pull_request.user.login,
\n authorAssociation: payload.pull_request.author_association,
\n prTitle: payload.pull_request.title,
\n prBody: payload.pull_request.body,
\n };<\/p>\n
\n const result = await workflow.start({ inputData: initData });
\n console.log(“Result:”, JSON.stringify(result));
\n});<\/p>\n
\n source: “https:\/\/smee.io\/SMEE_ENDPOINT_ID”,
\n target: “http:\/\/localhost:3000\/webhook”,
\n logger: console,
\n});
\nconst events = await smee.start();
\nconsole.log(“Smee client started, listening for events now”);\n<\/p><\/div>\n4. Test the app<\/h3>\n
Lessons learned<\/h2>\n
1. Yes, automating workflows is possible with agents.\u00a0<\/h3>\n
2. Prompt engineering is still tough.\u00a0<\/h3>\n
3. Docker\u2019s tooling made it easy to try lots of models.\u00a0<\/h3>\n
4. <\/strong>It\u2019s possible to go overboard on agents. Split agentic\/programmatic workflows are powerful.\u00a0<\/h3>\n
5. Testing?\u00a0<\/h3>\n
Wrapping up<\/h2>\n