Add example of multi-agent collaboration

[nforro]

Multi-agent collaboration with goose

Example

Run multiple agents:

$ make \
  ROLE=executor \
  TASK="Given a package name, determine and return version of the package in CentOS Stream 10, \
  if present. You can use https://mirror.stream.centos.org/10-stream/ to find RPM packages \
  present in CentOS Stream 10." \
  run-goose-agent

$ make \
  ROLE=commander \
  TASK="Get name of a random package in Fedora (you can use https://packages.fedoraproject.org/index-static.html) \
  and instruct the executor agent to run its task with that package name as an input. \
  Once the executor is done, print the result. Then get another random package name \
  and repeat the steps 4 more times." \
  run-goose-agent

How it works

• goose-team container runs the GooseTeam MCP server
• all agents (goose instances) connect to the server, it allows them to register themselves
  and exchange messages
• communication protocol description is part of the recipe

Concerns

• execution relies on an event loop, but LLMs have tendency to exit the loop despite
  being instructed not to

[gemini-code-assist]

Code Review

This pull request introduces an example of multi-agent collaboration using goose. The review focuses on improving security, reproducibility, and usability by suggesting a .gitignore for secrets, documenting sudo implications, ensuring reproducible builds, and making the Makefile more robust.

[gemini-code-assist]

To prevent accidental check-in of secrets, add a .gitignore file to the multi-agent/ directory that ignores the .env file.

[gemini-code-assist]

Granting the goose user passwordless sudo privileges is a significant security risk. Add a note in the README.md explaining the security implications.

[gemini-code-assist]

Add checks to ensure ROLE and TASK variables are set, providing a helpful error if they are not.

	@if [ -z "$(ROLE)" ] || [ -z "$(TASK)" ]; then \
		echo "Error: ROLE and TASK must be set." >&2; \
		echo "Usage: make ROLE=<role> TASK=<task> run-goose-agent" >&2; \
		exit 1; \
	fi
	$(COMPOSE) run --rm goose-agent \
		run --recipe recipes/agent.yaml --params "role=$(ROLE)" --params "task=$(TASK)"

[gemini-code-assist]

Pin the GooseTeam dependency to a specific commit hash to ensure build reproducibility.

RUN git clone https://github.com/cliffhall/GooseTeam.git /app && \
    cd /app && \
    git checkout <SPECIFIC_COMMIT_HASH>

[vrothberg]

Great work 🙏

execution relies on an event loop, but LLMs have tendency to exit the loop despite
being instructed not to

Did you see this happening?

I personally don't want long-running agents but short-lived ones with exactly one task (e.g., check one Jira card) and exit then. My hope is that this will be more resilient and it's easier to scale.

[nforro]

Did you see this happening?

Yes.

I personally don't want long-running agents but short-lived ones with exactly one task (e.g., check one Jira card) and exit then. My hope is that this will be more resilient and it's easier to scale.

We could create a custom MCP server that would spawn "worker" goose containers and pass them a recipe and parameters, exposing that as a tool for a "controller" goose instance. Or, if we don't want AI to be involved in the controller, we can just code some "container orchestration" logic.

[siteshwar]

Is this pull request obsolete? Shall we close this?

[nforro]

Is this pull request obsolete?

It depends whether you consider Goose obsolete.