Goose: from model to agent

The video is in Italian; this page is the written version in English.

A chatbot answers. An agent acts: it reads files, writes, runs commands, checks the result and tries again. Goose — an open-source project from Block — is one of the tools that makes this jump possible with a local model.

The practical difference: ask a chat “how do I rename all these files?” and you get instructions; ask an agent and the files get renamed.

What it does

It reads and writes files, runs terminal commands, installs dependencies, launches tests and reads the errors to correct itself. It is the think-act-observe loop from the advanced techniques lesson, applied with real tools.

It extends through MCP, a now widespread protocol for connecting external tools: database access, services, APIs. The extension architecture is native rather than bolted on, and it shows in use.

The delicate part: tool calling

For an agent to work, the model must invoke tools in a structured and reliable way: the request has to arrive in the right format, every time. Not all local models manage this consistently, and not all runtimes serve them equally well.

This is where the previous lesson comes back: LM Studio as a backend gives more reliable results on exactly this point. An agent that botches one call in five is not a tool, it is a source of frustration.

It is also worth being honest about expectations: an 8-billion-parameter model handles bounded tasks well — renaming, searching, reorganising, small repetitive edits — while long multi-step jobs remain the territory of large models.

The caution required

A tool that runs commands on your machine deserves to be treated as such. Three rules that avoid trouble:

Work in a dedicated folder, not your home directory or a system path. Keep version control on, so any change is one command away from being undone. And at first confirm actions one by one instead of letting it run: it teaches you how it reasons before you trust it.

Not pessimism: the same prudence you would apply to any new automation.

Why try it

If only to see where we are. Watching a model running on your own laptop read an error, fix the code and rerun the test is the moment the whole thing stops feeling like a demo and starts resembling a working tool.

Working safely

A tool that runs commands on your computer deserves to be treated as such. Not alarmism: the precautions you would apply to any new automation, applied beforehand rather than after.

Isolate the working folder. An agent launched from your home directory has everything in front of it: documents, keys, configuration. Launched in a project folder, the worst damage stays there.

Keep version control on. With git in the folder, every change is one command away from being undone, and the diff shows exactly what was touched. The most effective safety net, and it costs nothing.

At first, confirm actions one by one. The mode that asks permission before each command is tedious for ten minutes and teaches a great deal about how the agent reasons.

Mind the secrets. An agent reading files may end up putting the contents of a configuration file into the context — and if the model is remote, that content leaves the machine. With a local model the problem does not arise: one of the strongest arguments for inference at home.

Distrust instructions arriving in the data. An agent reading a web page may find instructions aimed at it. The real boundary is not set by recommendations in the prompt, it is set by the permissions you granted.

Risk	Defence
Destructive command	Dedicated folder, git, confirmations
Secrets leaving	Local model, or exclude sensitive files
Instructions hidden in data	Minimal tool permissions

What you can actually ask it

Initial enthusiasm leads to asking too much, and the disappointment that follows leads to abandoning it. Worth being precise about where output is good and where it is not, especially with a local model.

Task	How it goes
Renaming or reorganising files to a pattern	Very well
Finding something in a project and summarising where it is	Very well
Repetitive edits across many files	Well, if the instruction is precise
Writing a script for you to verify	Well
Fixing an error by reading the message	Decent, model dependent
Designing a feature from scratch	Poorly with a small model
Long multi-step jobs	Poorly: it loses the thread

The rule that emerges: bounded tasks with a verifiable success criterion. “Sort these list entries alphabetically across all files” works; “improve this project” does not, because there is no way to know when it is done.

How to frame a request that succeeds

Three habits that change the success rate more than any model choice.

Give the stopping criterion. Not “fix the tests”, but “make the tests in this folder pass without modifying source files”. The agent needs to know when to stop.

Narrow the field. Naming the files or folder to work on stops it exploring half the project and burning context — and with a local model context is the scarce resource.

Ask for a plan before the action. On non-trivial tasks, having it state what it intends to do costs one response and saves you from undoing something.

And a realistic note on local models: an 8-billion-parameter model gets the form of the tool call wrong more often than the reasoning. If you see repeated invocation errors, the task is not too hard — it is the model, or the runtime serving it.

In short

Concept	In one line
Agent	Does not just answer: reads, writes, runs, verifies
MCP	The protocol for plugging in external tools
Tool calling	The critical point: needs a reliable model and backend
Prudence	Dedicated folder, version control, confirmations at first
Expectations	Bounded tasks yes, long jobs not yet
Safety	Dedicated folder, git, confirmations: the boundary lives in permissions
Where it works	Bounded tasks with a verifiable success criterion
How to ask	Stopping criterion, narrow scope, plan before action