Tools, interfaces and agent teams

This page covers Stefan Preu's views on the interfaces agents use and on combining several agents. They are his preferences, proposed experiments and observations, not a verified comparison of every current harness or protocol.

Composable command-line interfaces

Stefan generally prefers command-line interfaces when work benefits from combining tools. A command can be called from a script, piped into another program, used in a workflow or run in CI/CD.

When data needs substantial calculation, filtering or extraction, he prefers to process it in code and give the agent the relevant result, rather than pushing a large raw dump into the model's context where the useful part is harder to find. The effect on quality or tokens has to be measured in the particular setup. This is a task-fit preference, not a rule that MCP is always wrong or that every CLI is good.

A selective place for MCP

Stefan's view of MCP has become more selective. He was long wary of large MCP tool catalogs because of context overhead and possible distraction. He now sees value in a small, useful MCP interface for information an agent should discover naturally, such as relevant recent communication, exposing what the workflow actually needs instead of a large catalog by default.

In his own experiments, he observed agents' workflows to find the most-needed tools and used that to shape a smaller interface. There is no controlled benchmark or general token-saving figure behind this.

Trying a smaller tool interface

Stefan's suggested experiment for an oversized tool catalog: keep access through a composable CLI, then compare how the agent behaves without the large catalog exposed directly. Observe what it discovers, what it uses, where it struggles and whether the task still works. Where available, collect tool-use frequency, errors and misuse alongside outcomes. The raw number of available tools is not a measure of usefulness.

MCPorter, a tool by Peter Steinberger, is one convenient way to reach MCP servers from a CLI, but the idea is not tied to that tool. Changing real access or configuration still needs proper authorization.

What remains uncertain about tools

Stefan has speculated about why agents seem drawn to MCP tool calls, for example as an effect of how models are trained, but he says he is unsure and that he is not a reinforcement-learning researcher. That explanation remains open.

How and when tool descriptions are loaded into context differs between clients and setups. His observations apply to the setups he used and should not be generalized to every MCP client.

Agent teams and a council of perspectives

For planning or brainstorming, Stefan suggests a simple exercise: if you had enough budget and time to assemble a human team for this job, which departments or specialists would you hire, and what would each be responsible for?

Those roles can inspire separate agent configurations: a small team, or "council", of agents that brings different perspectives to a concrete task. A council is a brainstorming tool. Several agents agreeing is not independent evidence that they are right.

Agents outside software

Stefan is interested in agentic work outside software, for example event planning and stage production. He would start with the information already available and the expertise the project needs.

Digital tasks worth testing include brainstorming a show from existing information, developing and comparing design concepts, organizing tour or project plans and the information collaborators need, scheduling and reminders, administrative review, and producing visual proposals to check with the people responsible. These are directions to test, not a promise of full automation. Physical work, safety, approvals and contracts keep their real-world responsibilities.

Vocabulary helps you steer agents

Stefan believes people can get useful results from agents without writing every line of code themselves. Basic development vocabulary still helps: it lets you express goals, understand how data flows, discuss a technology choice and ask meaningful review questions.

"Did you test this end to end as a real user would use it?" says much more about the check you want than "Is it finished?" His point is less micromanagement, not less checking.

Stefan's own agent practice

As Stefan reports it, his day-to-day engineering runs through coding agents, and all of his own work is tracked in PM CLI. He keeps a largely stable main prompt, moves guidance into documentation, skills and tools, and switches models and harnesses as they improve while goals, decisions and history stay in the project record.

He uses other models to review agents' results, and orchestrates agents across the PM ecosystem through a separate operator agent. These are his reported practices; they have not been independently audited.