{"slug": "larping-with-agents-and-why-it-works", "title": "LARPing with Agents (and Why It Works)", "summary": "A blog post argues that role-based multi-agent orchestration now pays off as models and harnesses have advanced, citing an Arxiv paper (2606.01770) from a team at Emory, Amazon, Penn State and other institutions finding that static harness evolution and heavy skills/tools configuration can hurt agents working on a heterogeneous stream of tasks because they cannot adapt to varying scope and complexity. The author recommends the Apache 2.0 Paseo meta-harness, which orchestrates agents across local hosts and SSH-accessible remote compute such as GitHub Codespaces and lets different models serve different sub-agents, after using it as a daily driver for a week. The post explains that Paseo's agent profiles look simplistic in the default dialog but work by inverting the view from the orchestrator's side, using the built-in list_profiles tool to pick named launch bundles whose notes match the delegated work.", "body_md": "# LARPing with Agents (and Why It Works)\n\n## Summary\n\n- Multi-agent orchestration has traditionally been challenging to get right, firsthand experience with earlier models and harnesses rightfully leaves teams with the impression of very little payoff for the extra effort and token spend.\n- As models and harnesses have advanced, it has become a more viable, more accessible technique that can allow agents to operate with increased autonomy without sacrificing quality.\n- While nearly all harnesses and models now support “native” sub-agents, not all multi-agent orchestrators are created equally and using them effectively is still a matter of configuration and tuning to your workload in most cases.\n- Using a meta-harness (harness of harnesses) has an additional advantage of using different models for different sub-agents, allowing better leverage of token spend across subscriptions; different inputs from different models/platforms, and more efficient use of tokens for specific tasks.\n- Getting the most out of multi-agent orchestration requires understanding “why” it works and how to leverage agent teams to autonomously deliver high quality software.  [A recent paper (Arxiv)](https://arxiv.org/pdf/2606.01770) published by a team from Emory, Amazon, Penn State, and other institutions offers some insights into how an adaptive, multi-agent approach can improve agent performance.\n- The Emory team highlights the finding that “static” harness evolution and heavy harness configuration (skills, tools) can be detrimental when agents operate on a heterogeneous stream of tasks since it cannot adapt dynamically to the varying scope and complexity of each task.\n- This blog post covers the theory of “why” role-based, multi-agent orchestration works and the practical configuration of “how” using Paseo ([https://paseo.sh](https://paseo.sh) ; Apache 2.0; no affiliation) to achieve this with very low lift but high payoff.\n\n## Roleplaying with agent teams\n\nI first stumbled upon [Paseo (Apache 2.0)](https://paseo.sh) 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).\n\nBefore 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.\n\nThe misleading first impression stems from the default agent profile dialog:\n\n*The agent profile dialog seems far too simplistic at first glance to have much power*\n\nNo 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.\n\n### Understanding the prompt flow\n\nThe 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…)*.\n\nThe 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:\n\n```\n**`list_profiles`** — named launch bundles configured by the human. Before\nchoosing how to launch a delegated agent, call this tool and read every\nprofile's `notes`. Pick a named profile the user requested, or the profile\nwhose notes best match the work.\n```\n\nIn 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*.\n\nHere is an example of a profile for a “Distinguished Member of Technical Staff”:\n\n```\nUse for design reviews, tie breakers, and input for challenging\narchitectural decisions to get a second or final opinion.  Ask for creative\nideas and ways to improve the design; explore alternate approaches that\nproduce faster, cleaner, more efficient code.  Ask to research and determine\nif there are other, better angles to approach the problem space.  DO NOT ask\nto write code; ask for ideas, input, creativity, new angles, alternate paths.\nExplicitly instruct: DO NOT CODE; only research, ideate, expand solution space,\nprovide feedback.\n```\n\nTake 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\n“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*.\n\n### Getting consistent behavior\n\nThis is all that is needed to get agentic behavior working with shocking efficacy in Paseo; for very little input, the payoff is sizeable.\n\nGo ahead and configure a full team of profiles and watch Paseo *just work*:\n\n*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.*\n\nIt 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.\n\nWhen 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.\n\nWatching 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:\n\n```\n<operating_environment>\nYou are operating in a Paseo agent harness; `paseo-*` skills and `paseo` CLI are available (as needed to explore the workspace, other agents collaborating)\n</operating_environment>\n\n- Use and prefer `paseo` built-in browser tools\n- Use `paseo-*` skills to coordinate with the team\n- 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.\n- 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>\n- 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.\n- Use clear, direct, terse language; be specific where needed\n- Use a \"risk-based\" approach when assembling team to work on a task; assign work that has higher risk to more senior engineers\n- Create workspaces (worktrees) only when work benefits from isolated branches (parallel, overlapping work).  Coordinate edits otherwise.  Worktrees add some complexity.\n```\n\nThe key is actually the 4th clause (reformatted here for clarity):\n\n```\nUse XML *when initializing new agents*:\n<role>(sub-agent role, identity; them)</role>,\n<lead_role>(\"self\", you; identity + role)</lead_role>,\n<objective>(sub-agent's goal)</objective>,\n<instruction_details>\n(existing context, inputs, info, details of task, tips, references, etc.)\n</instruction_details>,\n<scope>(what do vs what not do)</scope>,\n<team>\n(other sub-agents, team info, responsibilities, roles; as needed)\n</team>,\n<gates>\n(any specific exit gates, checks; only as relevant (optional))\n</gates>\n<comms>\n(specific instructions for comms, what to report, when to report,\nformat of report, etc.; optional as needed)\n</comms>\n```\n\nThis 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.\n\n### Real world examples\n\nFor the skeptic, it is instructive to see exactly how a lead uses this when it decides to create a new sub-agent:\n\n*A lead generated prompt used to initialize another agent.*\n\nYou 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:\n\n- The **roles** , responsibilities, and ownership boundaries of both parties\n- The **objective** as well as the**detailed instructions** with context about the task that has already been resolved either upstream or in other agents\n- The **scope** of work, bounding what the sub-agent does\n- Visibility into the **team** so the sub-agent knows who to communicate with and who owns what\n- Specific completion **gates** that define “done” for the sub-agent\n- Rules for **communication** including when and how to report back\n\nHere is another:\n\n*Another example; here a “Staff Engineer” being initialized by the lead.*\n\n## Does it work?  A few observations\n\nI 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.\n\nA few observations from my usage that have come up with folks I’ve shared this with:\n\n### It is generally NOT faster\n\nNo, 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*.\n\nEven when parallelizable, the work may slow down as the agents plan and coordinate themselves.\n\n### It is more autonomous with less quality drop-off\n\nThe 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**.\n\nThese 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.\n\nI 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.\n\n### It is more token efficient, not less\n\nYou’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:\n\n1. ***A clear hierarchy of roles.*** Both the lead and the sub-agent are assigned clear, titled roles which carry seniority.  The shared system prompt’s structure enforces this.\n2. ***Defined gates.*** When the lead prompts the sub-agent, it establishes clear scope and gates for completion.  Combined with Paseo’s setting to “Archive merged PR Workspaces”, this means that sub-agents are bounded by their gates, focused tightly on the task assigned.\n\nAdditionally, what is different about a meta-harness like Paseo is that it allows orchestrating agents across multiple platforms:\n\n*A set of agent profiles for my coding-focused agents spanning multiple providers and models.*\n\nThe 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.\n\nThe 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.\n\nWhat I find is that my work capacity in a given token session window is now extended significantly (caveat below with Anthropic platform models).\n\n### Human prompts are simpler\n\nMy 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.\n\nI 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.\n\n### Adherence is higher because the agents are explicit\n\nAdherence to guidelines, proper usage of skills and tools, and coding best practices is higher because the lead and peers LARP as their assigned roles and the leads will effectively remind the team what it needs to do to properly execute its task.\n\nIn this example, the lead gives clear, explicit direction on how the sub-agent needs to work and what it needs to read. The result is more consistency and better rule following, even with Anthropic models (notorious, IME, for not following guidance).\n\n## Why This Works\n\nNo, I did not benchmark this; most of this is through observation of the agent behavior as well as watching my token limits at work. I have now built multiple projects using this approach and it is plain as day in my usage how this affects autonomy, quality, and token use.\n\nI had my own intuition on why this worked so well, but a recent paper sheds some light on why this setup delivers results over the promises and hype of AIDLCs and other adaptive harnesses.\n\n[*Adaptive Auto-Harness: Sustained Self-Improvement for Agentic System Deployment on Open-Ended Task Streams* was recently published by an a team from Emory, Amazon, Penn State, and Northeastern University (Arxiv)](https://arxiv.org/pdf/2606.01770) and explores why most so-called “adaptive harnesses” have failed to prove their efficacy in a real-world software engineering environment.\n\nThe abstract opens with this:\n\nAuto-harness systems such as A-Evolve, GEPA, and Meta-Harness improve LLM agents by optimizing prompts, skills, tools, memories, and supporting infrastructure from execution feedback, but they are typically evaluated on fixed offline benchmarks. Real deployments instead present open-ended task streams: histories grow without a fixed endpoint, heterogeneous tasks require different harnesses, and problem distributions shift over time.\n\nIn other words, these harnesses require an offline/asynchronous recalibration which does not evolve dynamically enough for real-world, unbounded streams of tasks which then actively harms efficacy when the stream is high in “task heterogeneity”.\n\nOffline/async calibration is also difficult to achieve since it requires a large corpus of real-world datasets across this heterogenous mix from simple button color changes to complex new features. This is also true for AIDLCs which have an additional flaw in that they propose fixed workflows and a fixed menu of skills both are likely over- or under-fitted to the complexity and variety of the tasks. Optimizing a fixed skill after-the-fact seems like an obvious flaw in hindsight, especially if the stream of tasks is highly variable.\n\nThe team further expands on the problem with offline, “static” harness evolution:\n\nWe formalize why static auto-harness evaluation is insufficient once tasks arrive as unbounded, heterogeneous, and non-stationary streams.\n\n(As Claude might say, “heterogeneous” and “non-stationary” are “load bearing” 🤣)\n\nThe paper proposes a solution approach:\n\nWe introduce a stateful multi-agent evolver for sustained harness construction, a harness-tree router for solve-time adaptation…\n\n***Whoa***; “multi-agent” + “solve-time adaptation”?  This reads *a lot* like the Paseo setup where the lead decides how to assemble the team based on the task and injects the guidance dynamically.\n\nLet’s read on:\n\n**Multi-agent with distinct roles and objectives.** Because unbounded streams keep expanding the trajectory history an evolver must interpret, existing single-agent evolvers must fit analysis, research, implementation, and verification into one context window. We decompose evolution into four phases (Analyze → Research → Build → Verify), each with a dedicated objective and full context budget. This eliminates the single-window bottleneck and lets parallel Researchers explore disjoint hypotheses without premature convergence.\n\nThis mirrors my exact findings I observed by separating out “Distinguished Member of Technical Staff” and “System Architect”: the solution space expands instead of prematurely converging when using a single agent (assigning these to models on different platforms further amplifies this effect).\n\nReading this paper, it becomes more clear what this Paseo setup has created (and why it works): ***a truly auto-adaptive, role- and objective-driven, self-assembling, multi-agent “harness”***.  Instead of defining fixed sets of workflows or a static menu of skills, each novel task initiates self-assembly of an agent team based on the needs of the scope and complexity of the task.\n\n## How to set it up for yourself\n\nThere’s not much to it: start with Paseo and play around with the agent profiles and the shared system prompt 😎. This is perhaps the best part of this setup: the effort to get it configured is less than 10 minutes.\n\n### Paseo setup notes\n\nThere are a few key things to turn on:\n\n- `Settings > Agents > Enable Paseo tools` : turn this on.  These are the MCP tools that the agents use to list profiles and interact.  Agents can still use Paseo without this (using the CLI (which may be needed in some highly sandboxed environments)), but the tools are much more effective.\n- `Settings > Agents > Browser tools` : turn this on.  The Paseo browser tools internalize browser use into the Paseo app so you can see the screenshots as it works (similar to Devin).  Strongly recommend turning this on and explicitly prompting agents to use it.\n- `Settings > Agents > Orchestration skills` : install these so agents know how to use the tools to communicate with peers.\n- `Settings > Workspaces > Archive merged PR workspaces` : (optional) turn this on for more token savings and more focused context for sub-agents since they get archived once their PR is merged.\n\n### Anthropic autocompact configuration\n\nOne additional note here: if you are using Anthropic models, I strongly recommend turning the `autocompact` threshold to 300k or lower.\n\nBy default, all Anthropic models are now at 1m context.  This is fine and useful if you use long, interactive sessions since this hits cache.  But [Anthropic’s short cache TTL](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) means that in a multi-agent team, if an agent is idle and reactivated, this incurs a potentially huge cost for a fresh session with up to 900k+ tokens of input that also writes cache (!!).\n\n300k seems like a sweet spot where I’m able to get the most out of my session window with seemingly no observable tradeoff in quality when driven by another agent.\n\n### Use my profile plugin\n\nTo facilitate this setup in teams, I made a Paseo profile management plugin which publishes and pulls from gists: [https://github.com/zeeq-ai/paseo-profiles](https://github.com/zeeq-ai/paseo-profiles)\n\nInstall it to publish your configuration to your team and pull profile packs from others.  Use mine as a starting point: [https://gist.github.com/chrlschn-hg/fd322c40b92b537354441748c4ba96f8](https://gist.github.com/chrlschn-hg/fd322c40b92b537354441748c4ba96f8)\n\n### Use the lobby plugin for visualization\n\nThe [agent-lobby](https://paseo.sh/plugins/linhmh8/agent-lobby) plugin is not just a fun visualization, it really lets you see the agents communicating peer-to-peer, up-and-down the team hierarchy as they work.\n\n## Closing thoughts\n\nA few days back, I shared my Paseo team setup in a Hacker News discussion. One of the more interesting comments called this out as “larping” with agents (inspiration for this post):\n\nIndeed, it is *exactly roleplaying with agents* and it has been surprisingly effective at achieving more autonomous work with higher quality output.  In fact, Anthropic’s prompting guide specifically calls out “larping” as best practice:\n\nThis configuration with Paseo applies two of Anthropic’s best practices for prompting and Paseo provides the right harness setup to make agent communication effective (even across hosts!). The results for me have changed my workflow entirely and I have switched away from TUI-exclusive mode.\n\nAll of my work now starts from this setup from simple changes to complex, multi-hour feature builds; the lead decides the team it needs and drives the project (add the [keep-awake plugin](https://paseo.sh/plugins/hichamboushaba/keep-awake) for long horizon tasks!).\n\nGive it a shot; you have nothing to lose. Paseo is free, open source, and doesn’t alter any of your other harness setup (it sits above your other harnesses). If you don’t like it, just uninstall the skills and stop using it; it doesn’t alter the configuration of any of your other harnesses.", "url": "https://wpnews.pro/news/larping-with-agents-and-why-it-works", "canonical_source": "https://chrlschn.dev/blog/2026/10/larping-with-agents-and-why-it-works/", "published_at": "2026-10-27 09:37:00+00:00", "updated_at": "2026-10-27 09:41:33.226331+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-research"], "entities": ["Paseo", "Emory University", "Amazon", "Penn State", "GitHub Codespaces", "Herdr", "Arxiv"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/larping-with-agents-and-why-it-works", "markdown": "https://wpnews.pro/news/larping-with-agents-and-why-it-works.md", "text": "https://wpnews.pro/news/larping-with-agents-and-why-it-works.txt", "jsonld": "https://wpnews.pro/news/larping-with-agents-and-why-it-works.jsonld"}}