Ollama for beginners: run a local AI model and review the result

The first answer looked tidy. It was also wrong in three ways: the model turned a participant cap into a fixed headcount, skipped one required heading, and added two tasks nobody had agreed to. Everything had run locally on the computer.

That is the point of this guide. Ollama is a tool for downloading and running AI models on your own computer. Local execution tells you where the computation happens. It does not tell you whether the answer is correct.

In 15–20 minutes, you will install Ollama, run gemma3:4b, create a handoff from six source notes, and review the result before saving it.

Who this guide is for

This guide is for anyone who wants to try a local AI model without starting with APIs or an advanced server setup. The workflow is useful for meeting notes, project material, and internal drafts where you want control over both where the model runs and what it writes.

If you have not decided which tasks should run locally, start with our guide to when AI work should stay local and when it can use the cloud. This tutorial takes the next step and runs the workflow.

What you will do

You will:

1. install Ollama and check that it works
2. download the exact gemma3:4b model tag
3. process a fictional work note containing six facts
4. reject an answer that changes or invents information
5. tighten the prompt and save a reviewed handoff with a source receipt

The exercise uses no customer data or real commitments.

Before you start

Ollama is available for macOS, Windows, and Linux. Go to Ollama's download page, choose your operating system, and follow the installer. Then open Terminal on macOS/Linux or PowerShell/Terminal on Windows.

Check the installation:

ollama --version

Download the model:

ollama pull gemma3:4b

Confirm that the exact tag is available locally:

ollama ls

Ollama's model page lists gemma3:4b at about 3.3 GB. Download time and response speed depend on your computer. Use the same tag as this guide if you want to compare your result with the workflow shown here.

Source: Ollama CLI Reference.

Source: gemma3:4b in the Ollama model library.

Step 1: write six source notes

Create a file named work-notes.md with this fictional material:

# Source notes: AI breakfast

1. Date and time: 3 September 2026, 08:30–09:15.
2. Place: The Library, Eken room.
3. Participant cap: no more than 18 people.
4. Participants should bring their own laptop.
5. Lina is responsible for sending the invitation by 28 August.
6. Open question: Do we need an HDMI adapter for the projector?

A source file makes review simple. You can compare every line of the AI answer against a fixed input instead of judging whether the prose merely sounds plausible.

Step 2: run the model locally

Start the model:

ollama run gemma3:4b

Paste this prompt followed by the source notes:

Turn the source notes into a short Markdown handoff in English.

Use exactly these headings:
# Handoff
## Confirmed
## Next step
## Open question
## Source receipt

Rules:
- Preserve all six facts.
- Do not add commitments, people, times, places, or decisions.
- Put only Lina's real task under Next step.
- Keep the HDMI item as an open question.
- In Source receipt, state that the source is work-notes.md, that 6 of 6 facts were checked, and that no new commitments were added.
- Return only the finished Markdown card.

Ollama's documentation uses ollama run as the standard command for running a model. It also distinguishes local models from cloud tags ending in :cloud. This exercise uses the local gemma3:4b tag.

Source: Ollama Quickstart.

Step 3: review the answer line by line

Do not read the answer as finished copy. Read it as a proposal that still needs approval.

Check six things:

• Are the date, time, and place intact?
• Is "no more than 18 people" still a cap rather than a confirmed headcount?
• Is the laptop instruction present?
• Does Lina have the correct task and deadline?
• Is the HDMI adapter still an open question?
• Did the model invent any task, person, or decision?

In our first test, gemma3:4b changed the cap into a fixed count, missed the Confirmed heading, and added tasks about attendance confirmation and preparing the room/projector. Those tasks sounded sensible, but they were not in the source. We rejected the answer.

Google's Gemma 3 model card says the model can generate incorrect or outdated factual statements and that open-ended or complex tasks can be difficult. The same problem appears in a routine work card: fluent writing is not proof of a correct handoff.

Source: Gemma 3 model card from Google DeepMind.

Step 4: lock the structure and run again

If the answer fails, do not change the source to suit the model. Make the checks more mechanical instead. Add these rules to the prompt:

Mapping:
- Confirmed: exactly four bullets for date/time, place, participant cap, and laptop.
- Next step: exactly one bullet for Lina and the deadline.
- Open question: exactly one bullet for the HDMI adapter.

Forbidden:
- new tasks
- new people
- new dates
- new decisions
- wording that turns a cap or question into a fact

Run the same model again. In our fresh publication check, the new answer preserved all six facts, used the required headings, and added no commitments. Only then did we save it as handoff.md.

Acceptance criteria make the decision less subjective. You know what must be true before the result can be saved.

Step 5: save a short run receipt

Save a receipt next to the handoff:

Tool: Ollama
Model: gemma3:4b
Source: work-notes.md
Check: 6 of 6 facts
New commitments: 0
Status: accepted

The receipt does not need to be sophisticated. It should help the next person see which model and source were used, what was checked, and who still owns approval.

Ollama's FAQ says Ollama does not see prompts or data when you run a model locally. That helps with the access boundary, but local outputs still need review and source files still need to follow your organization's rules. If you later connect this workflow to other systems, use scoped permissions, secrets stored in a secret manager or environment variables, clear approval steps, and traceable run logs.

Source: Ollama FAQ on local execution and data.

Common mistakes

• Using the wrong model tag: gemma3:4b and a cloud tag are not the same run. Check with ollama ls.
• Having no source to compare against: save the input before running the model.
• Reviewing style instead of facts: a polished answer can still change a cap or invent a task.
• Changing too much at once: start with one work card where you can count known facts and allowed actions.
• Leaving approval vague: do not save the final version until someone has completed the checklist.

Next step: turn the test into a workflow

Try the same method on a real but bounded internal source: a project handoff, decision draft, or status note. Define the source file, model tag, acceptance criteria, and reviewer before automating more.

If you want to make local AI useful in day-to-day team work, Hammer Automation's Tool Forge can help shape the workflow with the right access boundary, review point, and run receipt. Start with a task where both value and mistakes are visible.