Building AI agents can be a complex task. But it also can be a fairly simple combination of answers to the following questions:\u00a0<\/p>\n
What is the AI backend that powers my intelligent fuzzy computation?<\/p>\n
What tools do you need to give to the AI to access external systems or execute predefined software commands?<\/p>\n
What is the application that wraps these together and provides the business logic for the agent (like when you\u2019re building a marketing agent, what makes it know more about marketing or your particular use-cases than a generic chat-GPT model)?<\/p>\n
A very popular way to build agents currently is to extend AI assistants or chatbots with the business logic as \u201csystem prompts\u201d or configurable profile instructions (which we\u2019ll show later), and tools via the MCP protocol.\u00a0<\/p>\n
In this article, we will look at an example of how you can build an agent like this (with a toy functionality of summarizing YouTube videos)\u00a0 with open source tools. We\u2019re going to run everything in containers for isolation and repeatability. We\u2019re going to use Docker Model Runner for running LLMs locally, so your agent processes stuff privately.<\/p>\n
You can find the project in the repository on GitHub: https:\/\/github.com\/shelajev\/hani<\/a>.\u00a0<\/p>\n We\u2019re going to use Goose as our agent and Docker MCP gateway for accessing the MCP tools.\u00a0<\/p>\n In general, hani (goose in Estonian, today you learned!) is a multi-component system defined and orchestrated by Docker Compose.<\/p>\n Here is a brief description of the components used. All in all, this is a bit of a hack, but I feel it\u2019s a very interesting setup, and even if you don\u2019t use it for building agents, learning about the technologies used might come useful one day.\u00a0<\/p>\n Component<\/p>\n Function<\/p>\n Goose<\/a><\/p>\n The AI agent responsible for task execution. It is configured to use the local LLM for reasoning and the MCP Gateway for tool access.<\/p>\n Docker Model Runner<\/a><\/p>\n Runs a local LLM inference engine on the host. It exposes an OpenAI-compatible API endpoint (e.g., http:\/\/localhost:12434) that the Goose agent connects to.<\/p>\n MCP Gateway<\/a><\/p>\n A proxy that aggregates and isolates external MCP tools in their own containers. It provides a single, authenticated endpoint for the agent, mitigating security risks like command injection.<\/p>\n ttyd<\/a><\/p>\n A command-line utility that serves the container\u2019s terminal, running the Goose CLI, as a web application accessible via a browser.<\/p>\n Cloudflare Quick Tunnel<\/a><\/p>\n (Optional) Creates a secure public URL for the local ttyd service, enabling remote access or collaboration without firewall configuration.<\/p>\n<\/div>\n The environment is defined by two primary configuration files: a Dockerfile to build the agent\u2019s image and a compose.yml to orchestrate the services.<\/p>\n Let\u2019s look at the Dockerfile first; it creates a container image for the hani service with all necessary dependencies and configures Goose for us.\u00a0<\/p>\n After installing the dependencies, there are a few lines that I want to emphasize:\u00a0<\/p>\n Installs ttyd. It\u2019s super convenient if you need a Docker image with a CLI application, but want a browser based experience.<\/p>\n This snippet installs Goose. If you like to live on the edge, you can add CANARY=true<\/a> and get the unstable but latest and greatest version.\u00a0<\/p>\n Note that we are also disabling CONFIGURE, because we\u2019ll configure Goose by supplying a pre-made configuration file with the next two lines in the Dockerfile:<\/p>\n We do the same with .goosehints, which is the file goose will read and take into account the instructions in it (with the developer extension enabled). We use this to supply business logic to our agent.\u00a0<\/p>\n The rest is pretty straightforward, the only thing we need to remember is that we\u2019re running ttyd running goose and not the latter directly.<\/p>\n Now would be a great time to look at the config for Goose, but in order to glue the pieces together, we need to define the pieces, so first we need to explore the compose file.\u00a0<\/p>\n The compose.yml file defines and connects the stack\u2019s services using Docker Compose.<\/p>\n Let\u2019s look at the compose.yml file starting with the models section<\/a>:<\/p>\nImplementation Details<\/h2>\n
\n chmod +x \/tmp\/ttyd.x86_64 &&
\n mv \/tmp\/ttyd.x86_64 \/usr\/local\/bin\/ttyd\n<\/div>\n
\n ls -la \/root\/.local\/bin\/goose &&
\n \/root\/.local\/bin\/goose –version\n<\/div>\n
\nRUN chmod u-w \/root\/.config\/goose\/config.yaml\n<\/div>\n
\nCMD [“goose”]\n<\/div>\n
\nqwen3:
\n # pre-pull the model when starting Docker Model Runner
\n model: hf.co\/unsloth\/qwen3-30b-a3b-instruct-2507-gguf:q5_k_m
\n context_size: 16355\n<\/div>\n