The Philosophy Behind Pluxtra

Over the past few months, I’ve been building and refining Pluxtra.

For me, Pluxtra has been an experiment in one question: Can an Agent Team actually make real-world work—especially coding—more efficient?

I use Claude Code, Codex, and Pi heavily in my daily work. Everyone seems to have a different idea of what agents, multi-agent systems, and Agent Teams should look like. Pluxtra is simply my attempt to build the version I had in mind, use it in my own workflow every day, and see what actually works.

TL;DR

A few things I’ve learned so far:

• Don’t rebuild the Agent Harness. Codex, Claude Code, and other coding agents already have extremely capable harnesses. Pluxtra started as a management layer on top of them. Ironically, once I tried to make Agent Teams work well, it gradually evolved into a multi-agent harness of its own.
• Keep context routing deterministic where possible. Each team has a Lead Agent that receives user messages and triggers other agents through MCP. Other agents don’t independently decide whether they should respond.
• Don’t build another memory layer, but do persist knowledge and artifacts. Coding agents are already building their own memory systems. What still feels underdeveloped is cross-session knowledge and artifact management, so every Pluxtra team has a shared workspace for persistent artifacts.
• Team management itself should be AI-native. A Lead shouldn’t just call sub-agents. It should be able to perceive and manage its team: spawn or remove agents, restart them, change runtime options, steer messages, etc.
• An agent should feel more like a persistent person than a disposable session. Each agent can have its own identity, runtime, model, and reasoning effort, and can be reused across chats and teams.
• Agent Teams are not inherently better than single agents. At least in coding, today’s agents don’t have much capability differentiation. Multi-agent becomes more interesting when agents have genuinely different permissions, tools, and harnesses.
• That’s why I eventually added Native Runtime support. Sometimes the best option is simply to run Codex, Claude Code, or Pi as-is, without injecting any additional context, tools, or harness.

Pluxtra isn’t an attempt to prove that one Agent Team architecture is the answer. It’s my attempt to build the Agent Team I imagined, use it every day, and continuously test and revise my assumptions.

1. I Didn’t Want to Build Another Agent Harness

This was one of my earliest decisions.

The harnesses behind Codex, Claude Code, and other coding agents are already very capable. I didn’t want to rebuild an agent harness from scratch.

Instead, I wanted to build a management layer on top of existing, mature coding agent runtimes—something focused on organizing, managing, and coordinating agents rather than reinventing the underlying agent loop.

But after working on it for a while, I noticed something interesting:

I started Pluxtra because I didn’t want to build another agent harness. But to make Agent Teams work well, I gradually ended up building a multi-agent harness anyway.

2. Context: Routing Messages Through Engineering

One of the earliest design decisions I made was around context and message routing.

Instead of letting every agent decide whether it should respond to a user message, I chose to handle routing at the engineering layer.

Every team has a Lead Agent.

By default, user messages only trigger the Lead. Other agents are not directly triggered by user messages. They have to be triggered through an MCP tool.

In theory, only the Lead can trigger other agents.

When another agent finishes its task, its messages are routed back to the Lead by the system.

So the team is fundamentally organized around the Lead, rather than having every agent receive the same context and independently decide whether it should participate.

3. I Chose Not to Build Another Memory System

I deliberately chose not to implement another memory layer in Pluxtra.

The reason is simple: coding agents such as Codex and Claude Code are already implementing their own memory systems, including longer-term and cross-session memory.

Since the underlying runtimes are already handling this problem, I didn’t want Pluxtra to duplicate it at another layer.

So Pluxtra itself does not focus on rebuilding agent memory.

4. But Cross-Session Knowledge and Artifacts Are Still Unsolved

Even though I chose not to build another memory system, there is another problem that I think most agent and coding agent products still haven’t handled particularly well:

Persistent knowledge and artifact management across sessions.

That led me to introduce a Shared Workspace for every Agent Team, separate from its working directory.

The workspace stores artifacts generated by the team while working on tasks.

These artifacts serve two purposes.

First, they give users a direct way to view the outputs generated by their agents.

Second, they can persist over time and gradually become a knowledge base for the team.

So instead of implementing another low-level memory system, I wanted to use the Shared Workspace and persistent artifacts to preserve what a team actually produces across sessions.

I also added some smaller cross-session features.

For example, Pluxtra can scan local Claude Code and Codex sessions and inject an existing session into the current context with one click, making it possible to continue previous work across sessions.

5. Letting the Lead Actually Manage Its Team

When running in Manager mode—where Pluxtra injects some additional harness capabilities—I want the team to operate in as AI-native a way as possible.

The Lead Agent isn’t just responsible for receiving messages and triggering other agents.

I want it to have full awareness of its team and the ability to actually manage it.

Through MCP tools, the Lead can:

• spawn a new agent
• remove an agent
• modify an agent’s runtime options
• restart an agent
• steer a message
• perceive the state and members of its team

The idea is to give the Lead comprehensive control over its own team.

Rather than defining every team structure and behavior through hard-coded orchestration, I want team management itself to be something the Lead can perform through tools.

6. An Agent Is More Like a “Person” Than a Session

Another difference between Pluxtra and many coding agent products is how I think about the agent itself.

In Pluxtra, an agent is closer to the concept of a person.

Each agent can have a predefined runtime, model, reasoning effort, and identity.

Once defined, that same agent can be reused across different chats and tasks.

I wanted agents to be relatively persistent entities rather than temporary instances created every time a new session begins.

You can define your “employees” once, then continue using them across different teams and tasks.

7. Marketplace: Agents as Shareable Snapshots

This idea eventually led me to build an Agent Marketplace.

My assumption is that as agent harnesses become increasingly mature, agents themselves may start to look more like agent snapshots.

The underlying layer is a mature harness. On top of it, you define the agent’s identity, behavior, and other configurations.

Those configurations can then be persisted and shared.

In other words, the experience someone accumulates while using an agent could potentially be captured as a snapshot layered on top of a mature harness, then reused by someone else.

That is why I built the Agent Marketplace.

I think more and more of an agent’s identity and behavior can eventually be defined through natural language, allowing it to perform specific tasks effectively.

8. Then I Started Questioning the Value of Agent Teams

After using the system for a while, my view of Agent Teams started to change.

At least in coding today, I haven’t found multi-agent systems or Agent Teams to be inherently more efficient or more accurate than a single agent.

One reason, I think, is simple:

Today’s coding agents don’t have that much capability differentiation.

When agents have largely overlapping capabilities, adding more agents doesn’t necessarily create much additional value.

At the same time, Codex and Claude Code are increasingly introducing their own native sub-agent and agent-spawning mechanisms.

That eventually led me to introduce a Native Runtime mode in Pluxtra.

In this mode, Pluxtra does not attach any additional context, tools, or harness to the agent.

It simply runs and manages the original agent runtime in its native form.

For some tasks, I’ve found this mode extremely convenient.

9. Agent Teams May Make More Sense When Agents Are Actually Different

The fact that Agent Teams don’t necessarily outperform single agents in coding doesn’t mean I think Agent Teams have no value.

I think part of the issue with coding today is that different agents have relatively similar capabilities.

Other environments could be very different.

If different agents have different permissions, tools, or harnesses, then an Agent Team may become much more useful.

So one important question for me is whether the agents inside a team actually have meaningful capability differences.

This is something I’m still experimenting with and observing.

10. One App for Different Coding Agents

There was also a much more practical motivation behind Pluxtra.

I use Codex, Claude Code, Pi, and other coding agents heavily, and I wanted a single app that could integrate all of them.

I didn’t want to constantly switch between different coding agent applications.

Over time, this made another part of Pluxtra’s value clearer to me:

You can build your own Agent Team, but you can also use Pluxtra simply to manage native agent runtimes.

Those two modes don’t have to conflict.

11. A Few Smaller Things I Added Along the Way

As I kept using Pluxtra myself, I gradually added some smaller features that I found useful or interesting.

One is the local session scanner I mentioned earlier: it can find existing Claude Code and Codex sessions and inject them back into context, allowing work to continue across sessions.

Another is a platform-level Agent Pet.

The idea was inspired by Codex’s Pet feature, but instead of being tied to a single session, it lives at the platform level and can listen to the runtime state of all sessions.

These weren’t part of the original plan for Pluxtra. They emerged gradually from using the product myself every day.

12. Final Thoughts

For me, Pluxtra has been a very interesting and meaningful experiment.

Everyone has a different understanding of agents, multi-agent systems, and Agent Teams. Everyone probably has their own idea of what the ideal Agent Team should look like.

I simply built mine.

Then I put it into my actual workflow to see which ideas worked, which ones were less useful than I initially expected, and kept adjusting the product based on what I learned.

After several months, I don’t think I’ve found the final answer to Agent Teams.

If anything, many of my initial assumptions have changed after actually using what I built.

And that might be the most interesting part of building Pluxtra in the first place.