How yankeexe/llm-function-calling-demo works
1. Repository shape
- This is a very small, single-purpose Python demo repository.
- The core runtime lives in app.py; everything else supports local setup, containerization, and CI.
2. Primary runtime boundary
- The application is a local Python process that talks to a separately running Ollama service.
- Ollama is not embedded in the repo; it is an external runtime dependency that must already be installed and running.
3. Main execution flow
- A user starts the app either locally or in Docker.
- app.py sends prompts to Ollama using the configured model.
- The model can return a function/tool call request.
- The app executes the matching local Python function and sends the result back to Ollama.
- Ollama then produces the final natural-language response.
4. Function-calling loop
- The architectural point of the demo is the interaction between:
- the LLM response,
- the application’s function dispatcher,
- and the returned tool output.
- This is a request/response loop rather than a long-running server with multiple internal services.
5. Application responsibilities
- app.py is responsible for:
- configuring the model name,
- connecting to Ollama,
- defining callable functions,
- handling model requests for function execution,
- and printing or returning the final answer.
- The repo does not show separate modules for API, domain logic, or persistence, so the app is intentionally monolithic.
6. No persistent data layer
- There is no database, queue, cache, or external state store in the repository.
- All state is transient and lives only during the app’s execution and the ongoing chat/function-calling exchange.
7. Containerization boundary
- The Dockerfile packages the Python app for container execution.
- The container still depends on Ollama running outside the container, on the host machine.
- The README notes a host networking/DNS nuance: the container uses host.docker.internal to reach host Ollama, which is not portable to Linux without extra handling.
8. Model/runtime configuration
- The demo defaults to an Ollama model such as mistral-nemo.
- The README indicates the model can be switched to alternatives like llama3.1 or llama3.2 by editing app.py.
- This makes model selection part of application configuration, not infrastructure automation.
9. Developer workflow
- Makefile is the main orchestration entry point for local setup, running, linting, and fixes.
- requirements/requirements.txt and requirements/requirements-dev.txt separate runtime dependencies from developer tooling.
10. CI/CD boundary
- .github/workflows/ci.yaml defines automated checks in GitHub Actions.
- Based on the repo structure, CI is likely focused on install/test/lint/format verification rather than building deployable services.
11. How to draw the diagram
- The central box should be app.py / Python application.
- Show an external box for Ollama.
- Show Docker as an optional wrapper around the Python app, not around Ollama.
- Show Makefile and GitHub Actions as supporting developer/automation layers around the app, not as part of runtime data flow.
12. Overall architecture summary
- This is a lightweight local LLM function-calling demo: one Python application, one external model server, optional Docker packaging, and simple CI/tooling.
- The key architectural relationship is the bidirectional exchange between the app’s local functions and Ollama’s tool-call-capable model responses.
Main entry points: app.py app.py · ci.yaml CI · Makefile Makefile · Dockerfile Dockerfile
Components 13
Runtime
The local Python demo and its external model dependency
- User · Starts the demo and reads the answer
- app.py · Monolithic function-calling client and control loop
app.py - Model cfg · Chooses the Ollama model used by the demo
app.py - Ollama client · Sends prompts and tool results to Ollama
app.py - Dispatcher · Matches requested tool calls to local functions
app.py - Local tools · Callable demo functions executed by the app
app.py - Loop · Handles request, tool call, and final response
app.py - Ollama · Separate host service that returns tool-call-capable model responses
Support
Container, automation, and dependency management
- Dockerfile · Packages the Python app for container execution
Dockerfile - Makefile · Local setup, run, lint, and fix entry point
Makefile - CI · Automated install and verification workflow
.github/workflows/ci.yaml - Reqs · Runtime Python dependencies
requirements/requirements.txt - Dev reqs · Developer tooling dependencies
requirements/requirements-dev.txt
Connections 16
- User → app.py: start · User launches the local demo
- app.py → Model cfg: uses · App selects the configured Ollama model
- app.py → Ollama client: prompts · App sends chat requests to Ollama
- Ollama client → Ollama: request · Prompt is delivered to the external Ollama service
- Ollama → Loop: tool call · Model may request a local function execution
- Loop → Dispatcher: routes · App inspects the request and selects a callable
- Dispatcher → Local tools: executes · Matching local Python function runs in-process
- Local tools → Ollama client: result · Tool output is sent back into the chat exchange
- Ollama client → Loop: final answer · Ollama returns the natural-language response
- app.py → Loop: drives · Main program orchestrates the function-calling loop
- Dockerfile → app.py: packages · Container image wraps the Python application only
- Makefile → app.py: run/lint · Make targets orchestrate local developer tasks
- Makefile → Dockerfile: build · Make can support container workflows
- CI → Makefile: invokes · CI likely reuses the same project commands
- CI → Reqs: installs · CI validates runtime dependency installation
- CI → Dev reqs: installs · CI validates developer tooling installation