LARPing with Agents (and Why It Works)

I first stumbled upon Paseo (Apache 2.0) a few weeks back while investigating options for orchestrating agents across multiple remote hosts. Among the options I tried, it handled this quite smoothly spanning agent orchestration between local agents and into SSH accessible remote compute instances like GitHub Codespaces (much better UX than Herdr, IMO).

Before recommending it, I decided to use it as a daily driver for a week and quickly discovered the agent profiles as I was going through the configuration. In all honesty? It seemed quite underwhelming and tacked on as an afterthought.

The misleading first impression stems from the default agent profile dialog:

The agent profile dialog seems far too simplistic at first glance to have much power

No scoping to workspaces, no skills, no tool restrictions, generally very little control over the configuration, seemingly far too simple. You must be thinking: “why am I reading this?!”. As it turns out, the simplicity and flexibility of this model is what gives Paseo the right curve of complexity vs productivity.

The example in the dialog is too simplistic and indeed, when configured as guided by the example, the results are likely to be…underwhelming. But committing to it and spending some more time tweaking, I started to understand that it is necessary to invert the way I looked at this feature from the direction of the orchestrator instead (to be fair, the micro-sized hint text also kind of explains this…).

The trick is to actually understand how the agent profiles flow. Paseo ships with a set of skills and MCP tools that manage agent orchestration. Of particular interest is the list_profiles tool:

list_profiles — named launch bundles configured by the human. Before choosing how to launch a delegated agent, call this tool and read every profile's notes. Pick a named profile the user requested, or the profile whose notes best match the work.

In practice, a lead or orchestrator will use this tool to list out the profiles by first reading the configuration and then matching the work to the note for the profile. Understanding this inversion, it is then simply a matter of using it to inject instructions into the lead.

Here is an example of a profile for a “Distinguished Member of Technical Staff”:

Use for design reviews, tie breakers, and input for challenging architectural decisions to get a second or final opinion. Ask for creative ideas and ways to improve the design; explore alternate approaches that produce faster, cleaner, more efficient code. Ask to research and determine if there are other, better angles to approach the problem space. DO NOT ask to write code; ask for ideas, input, creativity, new angles, alternate paths. Explicitly instruct: DO NOT CODE; only research, ideate, expand solution space, provide feedback.

Take note of the verbiage: these are not instructions for the sub-agent; these are instructions for the lead agent to follow when it instantiates the sub-agent. When the lead reads the profiles, it will first select the correct set of agents by matching the task to the team. This profile configuration then causes it to prompt the sub-agent teammate with specific “asks” upon initialization. Observe the “inverted” nature of this configuration; instead of setting up the sub-agent with a role, the setup instructs the lead agent on how to dynamically select and prompt the sub-agents.

This is all that is needed to get agentic behavior working with shocking efficacy in Paseo; for very little input, the payoff is sizeable.

Go ahead and configure a full team of profiles and watch Paseo just work:

A subset of my agent profile configuration with different roles and profiles. Note that some profiles are plan only; I do not use more costly models for code output.

It turns out that additional tool configuration, skill configuration, directory scoping, and any number of harness bolt-ons are simply not necessary to get an agentic team to actually produce useful work.

When a lead agent sees the profiles in Paseo, the profile notes act like prompt-injected context (think of it as “dynamic skills”) and the lead agent decides exactly how to build and coordinate a team for the task at hand. Complex tasks may recruit 6-8 sub-agents while simple tasks may only create 1-2.

Watching the outbound prompts, I quickly noticed a bit of inconsistency in how the team operated and how well sub-agents were being utilized. To fix this required tweaking Paseo’s shared system prompt for agents:

<operating_environment> You are operating in a Paseo agent harness; paseo-* skills and paseo CLI are available (as needed to explore the workspace, other agents collaborating) </operating_environment>

• Use and prefer paseo built-in browser tools
• Use paseo-* skills to coordinate with the team
• When starting a new agent, always let them know their identity, specific role, ownership of responsibilities, and how they can contribute; set clear expectations at initialization.
• Use XML when initializing new agents: <role>(sub-agent role, identity; them)</role>, <lead_role>("self", you; identity + role)</lead_role>, <objective>(sub-agent's goal)</objective>, <instruction_details>(existing context, inputs, info, details of task, tips, references, etc.)</instruction_details>, <scope>(what do vs what not do)</scope>, <team>(other sub-agents, team info, responsibilities, roles; as needed)</team>, <gates>(any specific exit gates, checks; only as relevant (optional))</gates><comms>(specific instructions for comms, what to report, when to report, format of report, etc.; optional as needed)</comms>
• Avoid rework and retread: provide a solid instruction_details, current objective, responsibilities, expectations, best practices, who owns what, scope of work, specific commands if needed, reference files (source, notes, links/URLs, docs, etc.) if relevant. Do not let your team guess what you already know; provide the key, learned insights at initialization.
• Use clear, direct, terse language; be specific where needed
• Use a "risk-based" approach when assembling team to work on a task; assign work that has higher risk to more senior engineers
• Create workspaces (worktrees) only when work benefits from isolated branches (parallel, overlapping work). Coordinate edits otherwise. Worktrees add some complexity.

The key is actually the 4th clause (reformatted here for clarity):

Use XML when initializing new agents: <role>(sub-agent role, identity; them)</role>, <lead_role>("self", you; identity + role)</lead_role>, <objective>(sub-agent's goal)</objective>, <instruction_details> (existing context, inputs, info, details of task, tips, references, etc.) </instruction_details>, <scope>(what do vs what not do)</scope>, <team> (other sub-agents, team info, responsibilities, roles; as needed) </team>, <gates> (any specific exit gates, checks; only as relevant (optional)) </gates> <comms> (specific instructions for comms, what to report, when to report, format of report, etc.; optional as needed) </comms>

This has the effect of consistently shaping the instruction that the lead provides to the sub-agent when it initializes one. Now the lead has two key things it needs: 1) my instructions on what to ask of each agent profile and 2) how it should ask for it; the specific format it should use.

For the skeptic, it is instructive to see exactly how a lead uses this when it decides to create a new sub-agent:

A lead generated prompt used to initialize another agent.

You can see the structure, but more importantly, you can see the detail; far richer and more specific than anything a human might write. The system prompt guides the lead to structure:

Another example; here a “Staff Engineer” being initialized by the lead.

I do not have numbers or stats nor benchmarks to share with you, only “trust me, bro” 😅 (more on this in the Emory team’s paper) but this setup is shockingly effective (relative to the effort it took to configure) to the extent that I have stopped using all other harnesses and I just use Paseo via a lead agent for everything. Minimal extra skills, no special tools, no AI SDLCs, no Superpowers, no SpecKit; nothing else to tune. Just Paseo, a shared system prompt, and a few configured agent profiles.

A few observations from my usage that have come up with folks I’ve shared this with:

No, it is not faster. In general, speed is only achieved if the nature of the work itself can be parallelized. But this can also be achieved with your platform native sub-agents. You should not set this up expecting more speed; you should set this up to gain more autonomy.

Even when parallelizable, the work may slow down as the agents plan and coordinate themselves.

The big win, in my opinion, is that this setup allows more autonomy without degradation of quality, especially for long-horizon tasks. Why? Because, when set up right, some of the work critiquing the output of one agent now shifts to another agent. The End-User Customer Advocate will critique the UX proposed by the Principal Engineer. The Distinguished Member of Technical Staff will offer alternative routes to explore to the System Architect.

These are responsibilities that I would normally have to prompt manually or rigidly encode into an “AIDLC”, but because each agent in the team is LARPing (Live Action Role Playing), they end up autonomously owning this without my intervention and they do not need a strict AIDLC that is over-fitted to a heterogeneous stream of tasks.

I still inject my preferences and my “taste”, but this setup has been the one that has minimized excess interactions the most significantly and allows me to assign higher “trust” to the agent team output.

You’re skeptical. So was I. A key problem I’ve run into in the past is agents will discuss ad nauseam and go back and forth, wasting tokens. But here, there are some key dynamics at play that seem to keep this behavior in check:

Additionally, what is different about a meta-harness like Paseo is that it allows orchestrating agents across multiple platforms:

A set of agent profiles for my coding-focused agents spanning multiple providers and models.

The result is that it is possible to move implementation and high “tokens out” work to a mix of cheaper models across harnesses and platforms, freely mixing Sonnet 5.5 with GPT-6 Luna and DeepSeek v4.1 Flash 1017. The lower cost models are able to deliver surprisingly high quality code because the instruction from the lead is very detailed; far more detailed than any spec a human would hand write.

The other factor at play here is that the lead can choose to assign more complex, higher risk work to the Principal which is configured with a more expensive, more model. The assignment of discrete roles means that the lead knows the right heuristics to use and the team becomes auto-adaptive to the complexity of each work item.

What I find is that my work capacity in a given token session window is now extended significantly (caveat below with Anthropic platform models).

My observation is that full specs are no longer needed in this flow to get good results. Of course, the more intent and direction imparted to the lead, the closer the output is to the objective held in the human mind. But the mixture of agent roles is overall very effective at figuring out the edges by LARPing as the end user or as the UX expert.

I find that the output is more “complete” and covers more edge cases as well as adds facets to the implementation that I might normally have spent much more time planning before or iterating after to achieve. Net result: better implementation with less human effort.

Adherence to guidelines, proper usage of skills and tools, and coding best practices is higher because the lead and peers LARP a