Goose: An Open-Source Agent You Can Assemble Yourself

A few days ago, I wrote about AGENTS.md, the file that gives coding agents project-specific instructions. While reading through the Linux Foundation's Agentic AI Foundation site, I came across another founding project: Goose.

The pitch caught my attention. Goose runs on your machine, lets you choose the model, and connects to tools through the Model Context Protocol.

However, The five-minute quickstart says Goose improves software development by automating coding tasks. The tutorial asks it to build a JavaScript game. The Goose homepage, however, calls it a general-purpose agent for research, writing, automation, data analysis, and code.

What was I looking at? Is it a coding agent or a general-purpose agent?

What i figured at the end is that Goose is both, but not equally. Coding is the go to path. Its extension system lets you give the same agent a different set of tools and a different job.

TL;DR

Goose is coding-first, not coding-only. Its built-in developer tools cover repository work. Change the extensions and instructions, and it can handle research, documents, browser tasks, data, and other automation. You also choose the model, including compatible local models. That freedom comes with more setup, evaluation, and security work.

So which is it?

Goose's history clears the confusion. When Block introduced it in January 2025, the launch post said its first use cases focused on engineering while the community was already trying it on non-engineering work. The examples included code migrations, tests, benchmarks, feature flags, and API scaffolding.

The product has since expanded. Its current homepage and README describe a general-purpose agent. Even its system prompt uses that term. The quickstart still takes the shortest route to a useful result: give Goose a working directory and ask it to build an application.

Both descriptions are accurate, but they set different expectations. Calling Goose a coding agent hides what its extension system can do. Calling it a general assistant makes it sound more ready-made than it is outside software development.

My read is simpler: Goose is an agent you install and configure. It comes prepared for coding. Its tools and instructions determine how far you can take it.

What actually changes

The architecture documentation splits Goose into three main pieces: an interface, the agent, and extensions. The model sits behind the agent and decides whether to answer or ask for a tool.

Ask Goose to change a repository and it sends the request, relevant context, and available tool definitions to the model. The model can ask to read a file, make an edit, or run a shell command. Goose executes the permitted call, returns the result, and gives the model another turn.

That loop can also prepare a weekly project brief. Give it local meeting notes and a read-only issue-tracker extension instead of a code repository. The model can read the notes, query completed issues, and write the brief. Goose still coordinates the model and tools; the toolbox and instructions are different.

The coding task and the project brief are not two different versions of Goose. The loop stays the same. The tools determine what work it can do.

Start with coding

Goose's built-in Developer extension can read and modify files, run shell commands, and maintain a plan. Start a session in a project directory and it has the basic tools needed to investigate and change a codebase.

This is why the quickstart builds a tic-tac-toe game. In a few minutes, Goose creates the files and, after you add the Computer Controller extension, opens the result in a browser.

Goose can also run as an ACP server. ACP, or Agent Client Protocol, separates the agent runtime from its interface. An ACP-compatible editor can use Goose as the agent while Goose keeps its configured models and extensions.

That does not make Goose an IDE. The desktop app and CLI do not replace an editor's navigation, autocomplete, debugging, or visual review tools. Goose is the agent doing the work. You can run it beside an editor or connect it to one that supports ACP.

For repository work, I would give it the same project guidance I give any coding agent. An AGENTS.md file can state the build commands, paths, conventions, and boundaries it should follow. Open source at the runtime layer does not remove the need for clear project context.

Beyond code, you assemble the workflow

Goose calls its MCP servers extensions. MCP is the open protocol for connecting agents to tools and data; the MCP track explains the host, client, and server roles in detail. Goose's built-in catalog includes the Developer, Computer Controller, Memory, and Auto Visualiser extensions, and it can connect to external MCP servers for other systems.

A research setup might get access to a document directory and a browser. An operations setup might use an issue tracker, a database, and a reporting destination. Calling Goose general-purpose does not give the model those abilities automatically. You add them by choosing extensions.

Recipes make those choices repeatable. A recipe can package instructions, parameters, model settings, and required extensions in YAML or JSON. Goose can run recipes interactively, headlessly, or on a schedule.

This is what I mean by an agent you assemble yourself. You do not have to build the agent loop, but you do choose the parts around it:

Part	What you choose	What you still have to verify
Model	Hosted provider, private endpoint, or compatible local model	Tool use, quality, context, latency, and cost
Capabilities	Built-in tools and local or remote MCP extensions	Data access, credentials, dependencies, and permissions
Workflow	Instructions, recipes, parameters, retries, and schedules	Correctness, failure handling, and review points
Interface	Desktop, CLI, API, or ACP client	Which surface fits the people and task
Distribution	Upstream Goose or a custom distribution	Upgrades and the cost of maintaining changes

This path is less turnkey than coding. Goose gives you the runtime and extension system. It does not know which business process matters, which source is authoritative, or what a correct result looks like. You still have to design and test that workflow.

Bring your own model, with caveats

Goose does not bundle one mandatory model. Its provider guide covers hosted providers, cloud platforms, compatible private endpoints, subscription-backed agents, and local options. Goose connects to the provider and runs the agent loop around the selected model.

A coding team can test another model without replacing Goose. A broader workflow can use a model and endpoint that fit its cost, data, or deployment requirements.

Ollama is one way to run inference locally. With a compatible tool-calling model, Goose and the model can both run on your machine. Newer Goose desktop releases also provide built-in local inference, so Ollama is no longer the only local route.

Local inference does not automatically make the whole workflow private or offline. A remote MCP extension still receives whatever its tool call sends, and browser work still uses the network. The model also needs to fit the hardware and reliably make structured tool calls. Goose's documentation warns that models without tool calling can provide chat completion only when extensions are disabled.

The models are not interchangeable just because Goose can connect to them. Two models may accept the same prompt and expose the same tools while producing very different results. I would treat every provider change as a new agent configuration and rerun the task evaluation.

Where Goose fits

I would choose Goose when the work begins with code but does not end there. The same agent that changes code might query an issue tracker, inspect a design document, update release notes, or prepare a deployment checklist. It becomes more useful when a job crosses tool boundaries.

It is also a useful place to compare models against a reasonably stable runtime. Keep the instructions, extensions, inputs, and acceptance criteria fixed, then change the provider. That does not make the models interchangeable, but it makes their differences easier to see.

I would also consider it when I need control over the runtime or data path. Goose is an Apache 2.0 project governed at the Agentic AI Foundation, and it documents custom distributions. An organization can inspect the system and adapt it instead of waiting for a hosted product to add the option it needs.

Open source still does not eliminate operating work. A private fork needs maintenance. A local model needs hardware and evaluation. Extensions bring dependencies and credentials. The benefit is the ability to make those decisions, not the disappearance of their cost.

When I would look elsewhere

If I wanted a polished coding experience entirely inside an editor, I would first check whether Goose's ACP integration provides the interactions I rely on. The agent can connect to an editor, but the surrounding editor experience still comes from that client.

If I wanted a general assistant with almost no setup, I would also look elsewhere. Choosing a provider, enabling extensions, defining permissions, and turning a task into a reliable recipe are part of using Goose. A managed assistant makes more of those decisions for you.

The biggest concern is how much authority you give it. Goose can execute commands, change files, control a browser, and call external services. Its permission controls, prompt-injection detection, and adversary review can reduce risk, but they do not make every extension safe. I would start with the smallest tool set, least-privilege credentials, approval for consequential actions, and an output I can inspect.

The agent security chapter explains why untrusted tool output needs rules enforced in code, not only instructions in a prompt. That becomes more important as Goose moves beyond a repository and into other systems.

How I would try it

I started with the question of whether Goose was a coding agent or a general-purpose agent. I would test it in that same order.

First, I would use it for one bounded coding task in a disposable branch: inspect a small repository, make a change, run the tests, and explain the result. That exercises Goose's strongest default path and reveals how well the selected model uses its developer tools.

Then I would reuse the runtime for one bounded non-coding task. My choice would be a weekly project brief built from a local notes folder and one read-only issue-tracker extension. I would define the required sections and citations, keep approval enabled, and compare the result with the source material.

Only after the interactive task worked would I turn it into a recipe or schedule. That sequence separates three questions: can the model complete the task, have I given the agent the right tools, and is the workflow dependable enough to repeat without constant supervision?

Goose is a coding agent you can turn into something broader. That is its sweet spot, and also its cost. You get to choose the model, tools, and job, but you also have to assemble and test the result.