Pourpoise in Practice: The brazil-bench Organization and my First Purpose-Oriented Agent Workflows
This post was discussed with ChatGPT then edited by me, because why should Claude have all the fun…
In my previous post, I introduced Pourpoise as an idea: a purpose-driven platform for managing autonomous coding agents. The premise was simple. Agents are fast and capable, but they need structure, guardrails, and intent in order to behave like a coherent engineering team rather than a cluster of eager new-hires. Purpose — not intelligence — is what keeps them aligned.
That was the architectural vision. This post is about the first concrete step toward making it real.
To turn theory into something testable, I created a new GitHub organization called brazil-bench. It’s both a standardized benchmark environment and the early home of Pourpoise itself. All experiments use the same well-defined task: build an MCP server that exposes a Brazilian football statistics knowledge graph. It’s a task I came up with for a demo, now formalized into a reproducible benchmark. Every run starts from the same template. Every agentic attempt gets its own repository. And every attempt is evaluated under identical conditions.
This setup allows something we’ve needed for a long time: a fair, repeatable, side-by-side comparison of autonomous development workflows. The centerpiece of the organization is a leaderboard, generated automatically from the evaluation pipeline in the pourpoise repo. It ranks each attempt based on spec completeness, quality, test behavior, and efficiency, using a consistent scoring model. We can actually observe whether a swarm, a hive-mind, a beads-based system, or any new orchestrator produces better results on the same task. Running the same configuration over time records improvements in the underlying AI coding models as well.
The purpose-driven heart of the work lives in github.com/brazil-bench/pourpoise. This is where Pourpoise begins to resemble an actual platform. Inside the repo is the first real expression of “management as code.” I’ve started to codify how the organization expects agents to behave, not as ad-hoc prompts, but using the new open source Standard Operating Procedures tooling. These SOPs describe how work should be performed. They are a human-readable definition of intent. There is a built-in SOP for codebase summarization that does a good job in a repeatable way.
I’ve seen some people say that AI tools can only reproduce things they were trained on, however Claude instantly learned a new tool and syntax model. It read the SOP introduction blog post (Nov 20th, 2025), then created three new SOPs for Pourpoise, which all worked well first time, then I asked for a few tweaks to align them with this specific project. They are all converted to Claude skills, which makes them easy to invoke without remembering specific syntax. The custom SOPs create a benchmark attempt from the benchmark-template repo, evaluate it and summarize the codebase using the built-in SOP, and compare all the attempts into a leaderboard. For now, the benchmark itself is run as a separate operation, specific to whatever is being tested.
This is the beginning of the NoMan idea — No Manager — where the platform performs the management labor that autonomous agents require. It’s the analog to what cloud platforms did for operations. Instead of automating Ops, we’re now automating developer management. And instead of relying on a human to remember the rules, the rules are part of the system itself.
The leaderboard does more than list scores: it tells a story about how agents behave under different management structures. The earliest swarm run produced a working system but required more human correction and generated a larger, less coherent codebase. The hive-mind run a month later completed the work in less time, maintained clearer boundaries between components, and needed fewer cleanup passes. After another month, and using Claude Opus 4.5, the beads-based workflow produced well-structured services and strong test coverage in much less time than before. Given the elapsed time and version changes, don’t read too much into the orchestration differences at this stage, but since each test takes an hour or so, it’s going to be easy to generate back-to back comparisons.
Each attempt is evaluated automatically. Pourpoise clones the repo, reconstructs the commit history, identifies how much work the agents performed autonomously, checks the tests, measures spec coverage, looks for structural and quality issues, and produces a written evaluation. These evaluations now form a growing archive of autonomous development attempts. The benchmarks have been run on Codespaces/Linux, and I’ve been running Pourpoise on my MacOS laptop, where some test checks fail because the Neo4j installation is Linux specific. I’ll rerun the evaluation itself on Codespaces when I get some more time to work on this.
We are still early in this journey. I’ve spent a few hours on this over the last few days. The SOPs are basic. The skills are prototypes. The evaluation formula will evolve. But we have a living dataset of autonomous engineering attempts, and a platform beginning to encode the management layer that these agents need.
The direction I’m heading in is to have an SOP that sets up and runs a series of benchmarks to explore and validate a hypothesis, like trying different languages to see how much difference that makes. At present each attempt is isolated in a repo, started by hand and doesn’t know that it’s part of a benchmark.
If anyone wants to join this organization to run their own benchmark tooling combinations, let me know. It’s all public and Apache licensed, so you can also clone the organization to run your own benchmark task.
