Ollama tutorial
Build a local AI workflow with Ollama
Connect Ollama to Bandura, classify a synthetic support message, and inspect checks and failed steps.
Updated 2026-10-01
Start with a single task: assign a support message to billing, delivery, or other. The downloadable workflow checks the answer before recording it for review. It does not send a reply to a customer.
1. Prepare your local model
Install Ollama and run a local model that fits your hardware. This guide uses qwen2.5:3b as a concrete model identifier, not an accuracy recommendation. Downloading a model needs internet access and disk space. Ollama setup, model details.
ollama pull qwen2.5:3b
ollama list
Keep the Ollama app running. If you use a terminal-only installation and the server is not running, start it with ollama serve. An “address already in use” message can mean the app already owns the port; do not start a second server.
2. Connect Bandura
Install Bandura. Open Settings → AI and use these values:
| Setting | Value |
|---|---|
| Provider | OpenAI-compatible |
| Base URL | http://localhost:11434/v1 |
| Model | qwen2.5:3b, or the exact identifier in ollama list |
| API key | Leave blank for an unauthenticated local server |
Use Test connection. Bandura uses Ollama’s compatibility endpoint; /v1 belongs in the base URL. These instructions apply to a server on the same computer. Ollama compatibility documentation.
3. Run the classification workflow
Open the support classification template, download its ZIP, and extract it into a new folder. In Bandura choose File → Open Folder, select that folder, and open workflow.aether.
The input is “I was charged twice for my order.” Press Run. Select Classify message to inspect the returned category, then inspect Check allowed category. A suitable answer for this sample is billing. The workflow rejects extra explanation, unexpected capitalization, or any category outside its allowed list.
The last step records the category for review. It does not establish that the label is correct for every future message.
4. Inspect a failure
Change the allowed-category assertion to variables.category === 'impossible', run again, and select the failed step. Inspect the actual output rather than assuming a connection problem. Restore the assertion afterwards.
Try another synthetic message, then use the CSV evaluation template to compare several predictions with expected labels. Review each failed case before adding downstream actions.
Troubleshooting
- Connection refused: confirm Ollama is running, check the port, and confirm Bandura and the model are on the same computer.
- Model not found: copy the exact installed tag from
ollama list; pulling a model and choosing its identifier are separate steps. - Connection works but assertion fails: inspect the raw answer. The model may return explanation or an incorrect category. Adjust the prompt/model and rerun labelled samples.
- Very slow first call: model loading and hardware can affect response time. Try a model suitable for your machine and consult the runtime’s own diagnostics.
Privacy and validation limits
A local model endpoint processes the prompts on your computer when its runtime is configured for local inference. Hosted models, proxies, APIs, and tools can send data elsewhere; see data-flow details. A localhost URL alone is not proof that the runtime never forwards requests.
The downloadable workflow has automated format, execution, and failure-path checks with deterministic responses. This guide’s provider configuration follows official documentation; no real Ollama model accuracy benchmark was run for this article. Start with synthetic data and inspect your own results.